Then perhaps the cursor gets requeried and the position changes. You can track down requeries with a cursor factory and some logging, but perhaps it's easier to set a tag to the item's _id value, as that should not change (and you need the _id to delete, anyway).
-- Kostya Vasilyev -- http://kmansoft.wordpress.com 09.02.2011 1:54 пользователь "ivan" <[email protected]> написал: > "You were saying something about buttons - how are you creating them, > and > mapping to the right data item? " > > I set a tag to the cursor position in the bindView() function. > > On Feb 8, 3:20 pm, Kostya Vasilyev <[email protected]> wrote: >> No, waiting on synchronized block or thread.wait blocks the waiting thread >> and only lets other threads run. >> >> But, that synchronization doesn't sound good for a different reason, since >> you are blocking the UI thread, and that should not happen. >> >> One way around it is to make that cached data item available in the query >> used to populate the list, and fire off update requests to the worker thread >> as needed. Once the worker thread updates the cached item, the list should >> update automatically (since you mentioned that your data is in a content >> provider). >> >> You were saying something about buttons - how are you creating them, and >> mapping to the right data item? >> >> -- >> Kostya Vasilyev --http://kmansoft.wordpress.com >> 09.02.2011 1:04 пользователь "ivan" <[email protected]> написал: >> >> > 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 <[email protected]> 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<[email protected]> 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<[email protected]> 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 [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> > For more options, visit this group at >> >http://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
