The only manipulation to the view object is via the non-overridden ResourseCursorAdapter bindView() function. On occasion this function will block for a couple seconds maximum if a drm data cache is occurring in another thread, but that thread never touches the view object. Maybe waiting on a synchronized block of code (in the UI thread) to get values from the multi-threaded cache causes the UI thread to wait, releasing cycles to the UI thread, which in turn allows the misplaced event to occur?
On Feb 8, 12:32 pm, Kostya Vasilyev <kmans...@gmail.com> wrote: > Are you sure that you only touch the ListView and its adapter from the > UI thread? > > -- Kostya > > 08.02.2011 22:11, ivan пишет: > > > > > Thanks for the reply. > > > The button events are -- nine times out of ten -- tied to the correct > > data, but if you rapidly push a button you can throw an event that > > will be tied to the wrong data. I thought that this didn't make sense > > since everything should be occurring on the UI thread (right?). But > > it appears that the event can sneak in before the screen is actually > > refreshed. > > > On Feb 8, 11:24 am, Kostya Vasilyev<kmans...@gmail.com> wrote: > >> If the button is linked to the wrong item, then you have a bug in your > >> adapter's getView, where you're not properly associating the button with > >> the item for the case where convertView != null. > > >> As for performance, I find it useful, when refreshing a ListView item in > >> response to some event, to go through the visible list items, find the > >> ones that are affected, and push new values into them right then and > >> there, rather than calling notifyDataSetChanged / Invalidated. > > >> -- Kostya > > >> 08.02.2011 19:47, ivan пишет: > > >>> Anyone? > >>> On Feb 7, 4:33 pm, ivan<istas...@gmail.com> wrote: > >>>> I'm using a ResourceCursorAdapter to display a list of downloads from > >>>> a ContentProvider that track's my application's downloads -- modeled > >>>> after Android's DownloadProvider. > >>>> The problem is that when a download is actively running it frequently > >>>> calls bind view--every few seconds--to update a download progress bar, > >>>> with a view object that is NOT currently associated with a given > >>>> cursor position. Thus, bind view is constantly recycling and binding > >>>> view objects to new item/cursor positions. > >>>> This is especially a problem if the user attempts to push a button on > >>>> one of the items while it's being bound to a different view object and > >>>> cursor position, which results in an event being fired for the wrong > >>>> data. > >>>> Does anyone have advice on how to minimize unnecessary view recycling? > >>>> It appears to only occur for the bottom and top list items (of the > >>>> three on the screen), while the middle item remains tied to a single > >>>> cursor and view object. > >>>> Thanks, > >>>> -Ivan > >> -- > >> Kostya Vasilyev -- WiFi Manager + pretty widget > >> --http://kmansoft.wordpress.com > > -- > Kostya Vasilyev -- WiFi Manager + pretty widget > --http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
