CHAPTER 13: Android Service Class and Threads: Background Processing 483will always be considered as important as Process 02. This is also quite logical as the two processes
are essentially acting together as one, and thus should be ranked or prioritized equally.
The next section looks at threads, which are even lower level than processes and can be used in a
process (via Java code) to schedule processor-intensive or user interface tasks.
Thread Caveats: Don’t Interfere with UI Thread
After Android launches an application using the AndroidManifest.xml file, the operating system
spawns a thread of execution. This is usually termed the main thread. A main thread is in charge
of dispatching and managing system-level and application-level events, which you learned about in
Chapter 7. The events take place between the operating system and an app, such as an incoming
phone call, as well as between your user interface widget event handlers and your application
programming logic.
The main thread also controls drawing graphics, video, and animation (drawable) assets to the
Activity display screen, so it is doing a lot of processing. This is a reason you might need to spawn
your own thread, if something you want to do with your Android application might overload the
heavy workload that is on the main (primary) thread. Unless and until you spawn a second thread,
the main thread will be running your entire application.
The main or primary thread is also often referred to as the UI thread or user interface thread. This is
because it’s the thread inside of which the application components interact with components in the
Android UI toolkit. The Android UI toolkit includes all the components, as classes, contained in the
android.widget and the android.view packages, which you learned about in Chapters 6 through 11.
All the Android UI toolkit components will run in the main process and are handled (managed) inside
the UI thread.
For this reason, methods that respond to event handling callbacks, such as the .onKeyDown( ) event
handler (used to report keyboard hardware interaction) or one of the lifecycle callback methods
(such as a .start( ) method or a .pause( ) method) will always run inside the UI thread. This UI thread
is contained within the main process for your Android application.
When an application dispatches intensive processing in response to user interface interactions, a
single thread model can result in a slow user experience performance. This is why you must learn
how to utilize threads properly, if you are going to do advanced Android application development.
The reason for this is obvious. If extensive processing is happening in the UI thread, performing
long-winded operations, such as network access, complex calculations, or SQLite database queries,
this will block some portion the user interface response processing. These more complex operations
will reduce the amount of processing cycles available to your UI, and will essentially “block” the UI
related events from being smoothly (that is, quickly) processed.
When the application UI thread becomes blocked, UI events cannot be dispatched for handling,
and this includes drawing graphics and animation elements to the display screen. From a user
experience standpoint, an application may appear to “hang,” which is not desirable and is not at all
professional.
It is important to note that if your application blocks the UI thread for more than a few seconds (for
more than five seconds, actually) the user will be shown a dialog containing an undesirable (from a
user experience standpoint) “Application is Not Responding” (called an ANR) dialog.