That thread is pretty much on the nose with what I was looking for... but I'm not sure if the scroll event is exactly the solution either.
In my observations in the debugger for the bindView() and newView() events for my cursor adapter, it looks like the CursorAdapter already does that in some way. So, I have a cursor that on two separate instantiations, I loaded 1000 rows and 15,000 rows. On both occasions, the number of times newView was instantiated was 12 times. This corresponds to n+1 rows that are actually visible in the window. The bindView() count was identical too. Scrolling down on the listview is actualy *very* fast, and i see the bindView() counts increasing as I scroll down as one would expect. So, in terms of lazyloadingness, it seems pretty efficient. The bindView applies the data to the view by the corresponding Cursor at the position int that's passed in. However, the actual call for Listview.setAdapter() is pretty slow. It's directly related to the number of rows in the cursor. The 15,000 row set took about 10 seconds to load, whereas the 1000 row set took 1-2 seconds. Realistically, someone's thumb will fall off before they can actually usably scroll through that many rows. But sometimes even on a 3-400 row set, the blocking that SetAdapter() takes is pretty slow that it might cause the user to think there's a hang. It strikes me as odd that there's a direct relation in time cost with the number of rows a cursor has. Does the cursor actually have to allocate memory for all its rows before it applies to the Adapter? On Feb 4, 5:39 pm, Al <[email protected]> wrote: > Maybe you could do what the market app does with comments and detect > when the scrollbar is getting close to the bottom and start preparing > the new items so when you scroll down, it already has the items ready. > Have a look at this > thread:http://groups.google.com/group/android-developers/browse_thread/threa... > > On Feb 4, 5:45 pm, dmyung <[email protected]> wrote: > > > Hello, > > > I've got a Listview in my activity with a cursor adapter and a view to > > render the results. > > > When i return a rather large data set from my query (like say, 15,000 > > rows), the Listview.setadapter() call blocks on me and occasionally > > gives me the dreaded ANR dialog. > > > I've tried various ways to background the operation. Fetch the cursor > > in a background thread, but that is a rather short operation since it > > just returns a handle to the underlying dataset. > > > Obviously I can't background the loading of the adapter in the thread > > because the setAdapter needs to be on the UI thread (i tried that and > > got a nice exception and crash). > > > When setadapter is called, the app locks up while data is being > > rendered in bindView() and newView(). Users have complained that it > > looks like the app is frozen (which effectively it is), so they munge > > around the menus and such while the operation is happening, causing > > more havoc. > > > My current workaround involved doing a ViewSwitcher to put a little > > progress widget to switch out while the listview is being rendered. > > However, since it's on the UI thread, most if not all UI operations > > get slammed. Progress Dialogs don't show, the progress widget doesn't > > animate, animation transitions cache weirdly. > > > The other workaround is to default to use smaller datasets which is > > the more "duh" solution. But the need will arise eventually to do > > huge dataset queries and/or render more complex views within a > > ListView...which I think will cause similar SetAdapter() blockages. > > > My question is this. > > > The API examples have the Inefficient list activity examples for > > binding "slow" data on scroll events. Is there a similar type of lazy > > loading/fetching of data for a corresponding cursor adapter? I want > > to basically have a listview bound with a Cursor adapter ONLY render > > the items in the visible view. It seems like the cursorView sort of > > does it already, but I was wondering if there was a way to tune the > > amount of records it prefetches on intial rendering after setadapter > > (). It seems to do way too much and it blocks the UI. > > > Many thanks. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
