Hehe, that was my reply when I started the project <sigh>. A crude use case example is where the records are like short log entries, and you want to scroll through them to watch events over a time span. You need a big window, since in some time frames, there may be few records; in others, there may be thousands -- the data density varies & you can't just give them an index since they may not know what time range will cover what they need to know.
I'm doing the query & changing the SimpleCursorAdapter cursor in the background via AsyncTask, then binding the adapter to the list in onPostExecute. Binding to the list has to be done in the UI thread, hence the UI freeze during the bind (as the list requests the row count from the adapter). Now, I can avoid the UI freeze by doing a cursor.getCount (source of the delay) before binding to the list, but then I have some cursor management issues when the activity goes away due to a rotate -- either stall the onStop/onDestroy until the cursor.getCount completes & the cursor can be closed, or keep the cursor static & risk the overhead if it is abandoned. Unless I'm misunderstanding your suggestion, paging won't work because you'd still need to know the row count (incur delay) before deciding if/how to paginate. The iPhone version of our app works without any of these issues, so I'm hoping that I'm just missing something (and that it's not an Android limitation). Other ideas? Thanks Tom On Feb 1, 2:51 pm, Nerdrow <[email protected]> wrote: > The standard reply is going to be you'll never actually need to view > all 20K rows, so either page it out or filter the results to a more > manageable number. Then again, if an end user is willing to scroll > through 20K rows, they might be willing to wait 5s for it to load :) > > Past that, I assume you're extending a CursorAdapter, you can use > setEmptyView on the ListView to show a progress dialog, run your query > on a background thread (or AsyncTask), then use a Handler (or the > AsyncTask) to call changeCursor w/the results of the query. It will > at least feel more responsive in that the UI doesn't just freeze while > it's working. > > On Jan 31, 10:01 pm, THill <[email protected]> wrote: > > > I need to be able to scroll through alistwith (up to) 20K rows, > > backed by a cursor on a read-only db. > > > Testing 20K rows on a G1, the query takes approx .02s regardless of > > table size, while binding the adapter to thelisttakes 4.5s. Note > > that this is before the view calls used in rendering. > > > What makes the binding delay more troublesome is that it blocks the UI > > thread, and is incurred on every rotate. Combine these, and doing a > > rotate just after starting thebindresults in a delay up to 9s. > > > I tried lazy loading with a base adapter, but that hits the same delay > > in the underlying cursor.getCount(), and the overall user experience > > isn't ideal. > > > I also considered using an ArrayAdapter, adding synthesized objects > > from the cursor rows, but then I'd incur the overhead of creating up > > to 20K objects (not to mention the additional memory requirements). > > > Any recommended alternatives or workarounds? > > > Thanks in advance, > > Tim > > -- 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
