The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
One perpetual problem in Android development is getting work to run outside the main application thread. Every millisecond we spend on the main application thread is a millisecond that our UI is frozen and unresponsive. Disk I/O, in particular, is a common source of such slowdowns, particularly since this is one place where the emulator typically out-performs actual devices. While disk operations rarely get to the level of causing an “application not responding” (ANR) dialog to appear, they can make a UI “janky”.
Android 3.0 introduced a new framework to help deal with loading bulk data off of disk, called “loaders”. The hope is that developers can use loaders to move database queries and similar operations into the background and off the main application thread. That being said, loaders themselves have issues, not the least of which is the fact that it is new to Android 3.0 and therefore presents some surmountable challenges for use in older Android devices.
This chapter will outline the programming pattern loaders are designed to solve, how to use loaders (both built-in and third-party ones) in your activities, and how to create your own loaders for scenarios not already covered.
Understanding this chapter requires that you have read the chapters on:
Android had the concept of “managed cursors” in Android 1.x/2.x.
Cursor was one that an
Activity… well… manages. More specifically:
Cursorwas deactivated, freeing up all of the memory associated with the result set, and thereby reducing the activity’s heap footprint while it was not in the foreground
Cursorwas requeried, to bring back the deactivated data, along the way incorporating any changes in that data that may have occurred while the activity was off-screen
This is a delightful set of functionality.
Cursor objects obtained
managedQuery() were automatically
SQLiteDatabase could be managed by
The problem is that the
requery() operation that was performed when
the activity is restarted is executed on the main application thread.
As has been noted elsewhere in the book, you really do not want
to do disk I/O on the main application thread, as it freezes the UI
and causes jank. This is particularly true for database I/O, where
you may not know in advance exactly how much data you will get back
or how long the query will take.
The preview of this section was whisked away by a shark-infested tornado.
The preview of this section is being chased by zombies.
The preview of this section was accidentally identified as an Android 'tasty treat' by the Cookie Monster.
The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).
The preview of this section was the victim of a MITM ('Martian in the middle') attack.
The preview of this section was stepped on by Godzilla.