[android-developers] Re: Not using a WakeLock so why does the device stay awake?
I've seen similar behavior as the OP. I have a simple activity that starts a timer in onCreate, logging a message every second. No wake lock is requested, so after the time indicated in setting, the device sleeps (allowed to dim, then sleep naturally, not with power button press). After letting it sit like that for a few minutes, I plug it in via USB check the logs, where I can see the timer continued running through the sleep. If I then do 'adb shell dumpsys power', the only wake locks shown are: mLocks.size=2: SCREEN_DIM_WAKE_LOCK 'StayOnWhilePluggedIn Screen Dim' activated (minState=1) PARTIAL_WAKE_LOCK 'StayOnWhilePluggedIn Partial' activated (minState=0) which makes sense since the device is now plugged in via USB. Is this expected behavior? Seems to go against the idea that all threads are suspended during the sleep... Thanks for any clarification, Tim On Apr 14, 4:31 am, Mark Murphy mmur...@commonsware.com wrote: westmeadboy wrote: Just to confirm: the device isnotplugged into USB and I'mnotusing any broadcasts or broadcast receivers. You aren't, but unless you have a completely clean device (or have hammered stuff into submission with a task killer), there might be other appsusingalarms. When I do plug in and start the service these are thewakelocks: mLocks.size=3: SCREEN_DIM_WAKE_LOCK 'StayOnWhilePluggedIn Screen Dim' activated (minState=1) PARTIAL_WAKE_LOCK 'StayOnWhilePluggedIn Partial' activated (minState=0) SCREEN_BRIGHT_WAKE_LOCK 'KEEP_SCREEN_ON_FLAG' activated (minState=3) and then when I homescreen, other app, turn the screen off (as describe above) but leave the device plugged in, the third one disappears. So I would assume that when I unplug the USB, the first two to disappear also... Make sure your screen timeout setting is set to a low value (yes, I know, you're manually turning off the screen, but humor me for a bit). -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.0 Available! -- 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
[android-developers] Re: Not using a WakeLock so why does the device stay awake?
Thanks Dianne, that makes sense. I didn't realize there was essentially one wake lock that the kernel applications layer use, so when all apps give up the wake lock, they will still get awaken when the cpu wakes to handle kernel processes. This explains why the 1-second timer pops occurred at 1 second intervals before after the sleep, and at very erratic intervals during the sleep. I saw the same behavior on a similar test case with an AsyncTask sending messages through a handler to the UI. Neither the task, nor the handler, was completely frozen during the sleep, but the task was taking longer to complete during that time. Unfortunately, my production app has specific power usage constraints imposed by the manufacturer/carrier (especially with the device asleep), and it doesn't seem there is a good way to make sure the app completely goes dormant when the device sleeps. Any suggestions are welcome. Cheers Tim On Apr 22, 10:58 am, Dianne Hackborn hack...@android.com wrote: It is possible for the kernel to hold wake locks for various reasons. If you want to see what was holding wake locks while you were unplugged, use adb shell dumpsys batteryinfo and look at the last set of stats (this is the raw information used to generate the battery usage UI). However the kernel wake lock information is extremely hard to understand, and unfortunately I can't say for sure off-hand how to interpret it. :} On Thu, Apr 22, 2010 at 10:52 AM, THill thill.dr...@gmail.com wrote: I've seen similar behavior as the OP. I have a simple activity that starts a timer in onCreate, logging a message every second. No wake lock is requested, so after the time indicated in setting, the device sleeps (allowed to dim, then sleep naturally, not with power button press). After letting it sit like that for a few minutes, I plug it in via USB check the logs, where I can see the timer continued running through the sleep. If I then do 'adb shell dumpsys power', the only wake locks shown are: mLocks.size=2: SCREEN_DIM_WAKE_LOCK 'StayOnWhilePluggedIn Screen Dim' activated (minState=1) PARTIAL_WAKE_LOCK 'StayOnWhilePluggedIn Partial' activated (minState=0) which makes sense since the device is now plugged in via USB. Is this expected behavior? Seems to go against the idea that all threads are suspended during the sleep... Thanks for any clarification, Tim On Apr 14, 4:31 am, Mark Murphy mmur...@commonsware.com wrote: westmeadboy wrote: Just to confirm: the device isnotplugged into USB and I'mnotusing any broadcasts or broadcast receivers. You aren't, but unless you have a completely clean device (or have hammered stuff into submission with a task killer), there might be other appsusingalarms. When I do plug in and start the service these are thewakelocks: mLocks.size=3: SCREEN_DIM_WAKE_LOCK 'StayOnWhilePluggedIn Screen Dim' activated (minState=1) PARTIAL_WAKE_LOCK 'StayOnWhilePluggedIn Partial' activated (minState=0) SCREEN_BRIGHT_WAKE_LOCK 'KEEP_SCREEN_ON_FLAG' activated (minState=3) and then when I homescreen, other app, turn the screen off (as describe above) but leave the device plugged in, the third one disappears. So I would assume that when I unplug the USB, the first two to disappear also... Make sure your screen timeout setting is set to a low value (yes, I know, you're manually turning off the screen, but humor me for a bit). -- Mark Murphy (a Commons Guy)http://commonsware.com| http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.0 Available! -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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 athttp://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
[android-developers] Re: Keeping service alive across configuration changes
Thank you for the replies. Jason -- I am binding the ServiceConnection in onCreate unbinding in onDestroy. Don't know of a way to unbind by default. The drawback I see with using the application context to bind the service, is that somebody still has to own the ServiceConnection. If it is owned by the application, or is a static member of the activity, the activity would have to register their instance with it to be notified of connected/disconnected events. Not terrible, but kinda defeats the purpose of allowing activities to bind to services if the best place to do it is really at the application level. Bob -- I've actually done what you described in the past, but I was never comfortable with the self-destruct timer (how long should it be, will it vary by device/OS version, etc). Also, for a service that plays audio, you'd want the audio to stop when the application exits, not during configuration changes, or activity transitions. Hence then need to prevent the last unbind, but only until the last activity has finished. This gets even more ugly on the NexusOne, where the last activity doesn't get onStop/onDestroy right away when the last activity is finished -- but that's another forum posting grin. Cheers Tom On Apr 8, 5:36 am, Bob Kerns r...@acm.org wrote: Another approach, which may have benefits beyond the configuration change issue, is to make your service only tear down the expensive resource after a delay. Then, if you reconnect before that timeout, you can simply reuse the resource. So if you exit and come back soon into your app, for example, you can rebind and not have to redo the expensive initialization. If the initialization is really expensive, this may be well worthwhile. I suspect the best way to do this is for the first binding the service to do a start of itself, and for the last unbind to post a delayed stopSelf(). On Apr 7, 4:44 pm, THill thill.dr...@gmail.com wrote: The default way configuration changes (i.e., rotates) are handled is to destroy the activity recreate it with a new one. What is the recommended way to handle these changes in an activity that binds/ unbinds to a service (that is possibly heavy/slow to start)? When the activity gets destroyed, it unbinds causes the service to be destroyed. When the new activity is created, it binds recreates the service. The only choices seem to be: -- override onConfigurationChanged in the activity. Feels ok, but non- conformant. -- explicitly start the service only stop it when the last activity gets an onDestroy that's not due to a config change (i.e., there was no call to onRetainNonConfigurationInstance). Feels icky. -- explicitly start the service don't stop it until some amount of time after the last unbind. Ickier. On a related note, what happens between activity switches within a process, where the first activity (A) starts the next activity (B) then calls finish() -- is there a guarantee that B.onCreate is called before A.onDestroy? If not, and the activities share a service, the same issue of keeping the service alive during this window exists, but with only the icky workarounds. Suggestions? Thanks Tim -- 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 To unsubscribe, reply using remove me as the subject.
[android-developers] NexusOne lifecycle issues, continued
On the NexusOne, there is a known issue with onStop not being called soon after an activity is no longer visible (e.g., by pressing Home key, or calling finish()). See related forum threads http://code.google.com/p/android/issues/detail?id=6094. If my activity uses a service that is doing something cpu/battery intensive in the background (e.g., playing/streaming music, getting location, etc), the service will continue running until another activity is launched, causing my activity to be stopped/destroyed. Is there a good workaround that can be used to stop the service when the last activity method called is onPause? Checking isFinished() in onPause doesn't help in the case of a Home key press... Thanks, Tim -- 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 To unsubscribe, reply using remove me as the subject.
[android-developers] Keeping service alive across configuration changes
The default way configuration changes (i.e., rotates) are handled is to destroy the activity recreate it with a new one. What is the recommended way to handle these changes in an activity that binds/ unbinds to a service (that is possibly heavy/slow to start)? When the activity gets destroyed, it unbinds causes the service to be destroyed. When the new activity is created, it binds recreates the service. The only choices seem to be: -- override onConfigurationChanged in the activity. Feels ok, but non- conformant. -- explicitly start the service only stop it when the last activity gets an onDestroy that's not due to a config change (i.e., there was no call to onRetainNonConfigurationInstance). Feels icky. -- explicitly start the service don't stop it until some amount of time after the last unbind. Ickier. On a related note, what happens between activity switches within a process, where the first activity (A) starts the next activity (B) then calls finish() -- is there a guarantee that B.onCreate is called before A.onDestroy? If not, and the activities share a service, the same issue of keeping the service alive during this window exists, but with only the icky workarounds. Suggestions? Thanks Tim -- 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 To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Keeping service alive across configuration changes
Thanks Dianne, I was wondering if there was a way to preserve that binding. If I go with that approach, I guess the ServiceConnection object will have to be static or belong to the Application also. What about the other scenario, where one activity launches another then calls finish(). Is onCreate of the second activity guaranteed to be called before onDestroy of the first? If not, the service could go away in that window. Cheers Tim On Apr 7, 5:17 pm, Dianne Hackborn hack...@android.com wrote: You can use the ApplicationContext to bind to the service, and propagate the binding to the next instance via Activity.onRetainNonConfigurationInstance(). Yeah, sorry, obtuse and awkward. In the future I'd like to have something better. On Wed, Apr 7, 2010 at 4:44 PM, THill thill.dr...@gmail.com wrote: The default way configuration changes (i.e., rotates) are handled is to destroy the activity recreate it with a new one. What is the recommended way to handle these changes in an activity that binds/ unbinds to a service (that is possibly heavy/slow to start)? When the activity gets destroyed, it unbinds causes the service to be destroyed. When the new activity is created, it binds recreates the service. The only choices seem to be: -- override onConfigurationChanged in the activity. Feels ok, but non- conformant. -- explicitly start the service only stop it when the last activity gets an onDestroy that's not due to a config change (i.e., there was no call to onRetainNonConfigurationInstance). Feels icky. -- explicitly start the service don't stop it until some amount of time after the last unbind. Ickier. On a related note, what happens between activity switches within a process, where the first activity (A) starts the next activity (B) then calls finish() -- is there a guarantee that B.onCreate is called before A.onDestroy? If not, and the activities share a service, the same issue of keeping the service alive during this window exists, but with only the icky workarounds. Suggestions? Thanks Tim -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: Binding list views to large data sets
What you say makes sense Bob, but testing seems to indicate the Android SQLite implementation isn't so proper. I have a simple app that creates 20001 rows in a table, each with an int _id 2 varchar fields. Getting the count of rows via db.rawQuery(select count(*) from table, null) and getting the value from the resulting cursor takes 0.2s. Getting the count of rows using cursor=db.rawQuery(select _id, field1, field2 from table, null); //NOTE: no 'where' or 'order by' count=cursor.getCount() takes 4.5s. During this time, the log has messages: E/CursorWindow( 695): need to grow: mSize = 1048576, size = 29, freeSpace() = 19, numRows = 11832 E/CursorWindow( 695): not growing since there are already 11832 row(s), max size 1048576 E/Cursor ( 695): Failed allocating 29 bytes for text/blob at 11831,1 D/Cursor ( 695): finish_program_and_get_row_count row 8169 So, getCount() is certainly not optimal, and appears to be allocating something based on result set size. The list view requests the count of items up front, so a slow getCount() can impact the UI if you just trust SimpleCursorAdapter on large, simple queries. When scrolling down the list, each bindView results in a cursor.moveToPosition() call. Doing this in a test app shows that moving to 1000, 2000, ..., 2 each takes 1ms -- except when going from 11000 to 12000, which takes 2s. No additional log messages. Where it gets u.g.l.y. is when moving from position 2 backward to 0. 2, ..., 12000 take 1ms, but moving from 12000 to 11000, 1, ..., 0 *each* take 4.5s (!). This is really fun to observe when scrolling backward in the list from 12000. Once you hit some point, every row takes 4.5s before it is shown. When this starts happening, every move results in log messages like: D/dalvikvm( 320): GC freed 251 objects / 13256 bytes in 116ms E/CursorWindow( 763): need to grow: mSize = 1048576, size = 29, freeSpace() = 21, numRows = 11631 E/CursorWindow( 763): not growing since there are already 11631 row(s), max size 1048576 E/Cursor ( 763): Failed allocating 29 bytes for text/blob at 19630,1 D/Cursor ( 763): finish_program_and_get_row_count row 370 This would again indicate the cursor is not agnostic to the result set size. I'll be doing more testing with many smaller query cursors behind a single adapter, but there appears to be a clear threshold. -- 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
[android-developers] Re: Binding list views to large data sets
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 troybe...@gmail.com 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 thill.dr...@gmail.com 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 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
[android-developers] Re: Binding list views to large data sets
Thanks Mark. Use the LIMIT and OFFSET terms on your SELECT statement to obtain data in smaller chunks. Create a wrapping adapter (like my EndlessAdapter) that only loads chunks when the user scrolls to the bottom of thelistand therefore needs more data. Doing the load in smaller chunks would still require at least the same amount of time to fill the list, but it would let me interrupt the load more quickly, so I can incorporate that handle rotates normally -- thanks for the whack on the side of the head! Unfortunately, I still need to load the full set of records because I need to be able to provide a sliding window anywhere in the result set, not just add to the end of the the list during the load (i.e., the user is not just continuously scrolling to the bottom of this huge list). Similar to a scroll button in typical windowing systems, in this list of events timestamps, the user needs to be able to select a position, say 2/3 of the way down the list scroll to the entries they want to review. Is the list/adapter just creating 20K objects as it walks the result set? If so, I'd be tempted to do this myself so I can give the user some visual cue/index into the data. I don't want to add significantly more overhead though. Any additional suggestions/insights? Thanks again, Tim -- 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
[android-developers] Re: Binding list views to large data sets
Thanks Mark. Use the LIMIT and OFFSET terms on your SELECT statement to obtain data in smaller chunks. Create a wrapping adapter (like my EndlessAdapter) that only loads chunks when the user scrolls to the bottom of thelistand therefore needs more data. Doing the load in smaller chunks would still require at least the same amount of time to fill the list, but it would let me interrupt the load more quickly, so I may incorporate that handle rotates normally -- woot! Unfortunately, I need to load the full set of records because I need to be able to provide a sliding window anywhere in the result set, not just add to the end of the the list during the load (i.e., the user is not just continuously scrolling to the bottom of this huge list). Similar to a scroll button in typical windowing systems, in this list of events timestamps, the user needs to be able to select a position, say 2/3 of the way down the list scroll up/down if that position is after/before the entries they want to review. Is the list/adapter just creating 20K objects as it walks the result set? If so, I'd be tempted to do this myself so I can give the user some visual cue/index into the data. I don't want to add significantly more overhead though. Any additional suggestions/insights? Thanks again, Tim -- 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
[android-developers] Re: Binding list views to large data sets
Thanks. Mark's comment about the object roster is what I was curious about. SimpleCursorAdapter calls Cursor.moveToPosition() every time the list calls bindView(), so I was wondering what the cursor does with result set when -- i.e., does it create objects (presumably indexes into the db file) for the result rows up front, or only as requested? Regardless, it looks like I'll be merging the results of multiple cursors with some sort of Adapter wrapper, so I'll need to keep all of those cursors active while the list is around. Cheers Tim -- 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
[android-developers] Re: Binding list views to large data sets
That's what I feared. I was hoping the cursor was only keeping primitive references to the data in the db file. If I'm going to be doing many smaller queries keeping the results around, sounds like I might as well keep the objects myself. Lets me index across the varying data density also. There's still the lifecycle handling -- if I have this ArrayList, and I want to keep it across rotates, I could keep it in a static. The trick is knowing when to release/null it. First thought is to set a flag in onRetainNonConfigurationInstance, otherwise I'll release it if the flag isn't set when onDestroy comes along. Seem reasonable? Very helpful dialog, I appreciate everyone's time cycles. Tim -- 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
[android-developers] Re: Binding list views to large data sets
Because that's what a smart person would do I'm an idiot for not thinking about it before asking grin. That's two whacks -- I'm outta here. Need more caffeine... Cheers, tim On Feb 2, 3:10 pm, Mark Murphy mmur...@commonsware.com wrote: There's still the lifecycle handling -- if I have this ArrayList, and I want to keep it across rotates, I could keep it in a static. The trick is knowing when to release/null it. First thought is to set a flag in onRetainNonConfigurationInstance, otherwise I'll release it if the flag isn't set when onDestroy comes along. Seem reasonable? Why not just pass the ArrayList in onRetainNonConfigurationInstance()? -- Mark Murphy (a Commons Guy)http://commonsware.com Android App Developer Books:http://commonsware.com/books.html -- 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
[android-developers] Binding list views to large data sets
I need to be able to scroll through a list with (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 the list takes 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 the bind results 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 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
