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" <istas...@gmail.com> написал: > 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 -- 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
