On Apr 29, 10:33 pm, Dianne Hackborn <[email protected]> wrote: > On Fri, Apr 29, 2011 at 8:43 PM, Eric <[email protected]> wrote: > > Sorry, I meant to say I'm calling ArrayAdapter.notifyDataSetChanged(), > > not "ListAdapter.notifyDataSetChanged()". > > This API tells the list view that the entire data set has changed, so it > needs to reload it and rebuild the items from the new data. This includes > the possibility that some items in the set may have been removed, added, or > moved around, so it needs to build a new set of list item views and try to > keep them positioned as well as possible to match the previous data set.
But that's exactly the situation I have. My entire data set changes from second to second. My app displays a list of financial trading markets in real time, showing bids and offers that change. I never know from one second to the next how many items the list will have, because the market orders come (new order), go (traded or cancelled order), and change (modified order price, etc). The data set I'm viewing is not a static size. I don't think there's any other way for me to display this data other than to tell the ListView its data set has changed. I would have to write my own 'list view' replacement if I needed to optimize this. However, contrary to what you may think, the performance is more than acceptable. This paradigm has been in use on the iPhone for 2 years, and it performs extremely well. The Android 'port' of the app, thus far, performs almost as well as the iPhone. The reason I posted the original question was to ask why my touch events would be 'swallowed' or 'lost'. Do you see my relatively frequent calls to ArrayAdapter.notifyDatasetChanged() causing the Touch Events to get 'lost'? If so, I would be highly confused if that were the case. All of my drawing, and all of the touch events, are happening on a single main/UI thread, so I don't understand how, or why, the Touch Events would get lost. Even though the data is streaming in on an background thread, i coalesce the changes in the background thread until the UI can 'pop' the data off and redraw. There is no thread starvation going on because the data thread notifies the UI thread only one time, and then the UI thread schedules a handoff to grab the data from the background thread when it is next available. And the update mechanism then continues from there for the next cycle. I would hope that the Touch Events would not get 'lost' in all of this, but from my testing it appears some of them might be, and I'd like to understand why. -- 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
