484 CHAPTER 13: Android Service Class and Threads: Background Processing
It is important to note that the Android UI toolkit isn’t currently what is known as “thread-safe.” For
this reason, you should not at any time manipulate your application’s user interface elements from
inside a “worker thread.”A worker thread is any non-UI thread, and is also commonly referred to as
a background thread. In other words, it is a thread that you have spawned using your application
Java code. This would be done in order to off-load intensive “worker bee” background processing
so that the UI will continue to function smoothly. So remember the first rule in Android thread
processing is that you must do all manipulation to your user interface elements from the inside of the
UI thread, which is the app’s main thread.
The second key rule is more general, and it is simply to not block the UI thread at any time for any
reason. This is why you are able to create worker threads, in case you need to do something that
may block the UI thread.
Should Your Android App Use Services or Threads?
An Android Service is an application component that can run in the background, even when your
users aren’t interacting with the application. If you need to perform work outside of your main UI
thread, but only while the user is interacting with your application user interface, that is, when you
should create an Android Thread object within that class of your application.
This would be done by instantiating a HandlerThread or AsyncTask object. You do not have to go
to the trouble of declaring an entire Android Service subclass in your Manifest. If you look at it using
the “static versus dynamic” standpoint that I have been teaching you over the course of the book,
you are implementing a thread dynamically using Java code, whereas you implement a Service
statically using XML mark-up to “declare it before use” in your AndroidManifest XML file, so the
Android OS can optimize it!
Let’s say that you wanted to stream some music from a music Service while your Activity is running.
What you do is create a Thread object using the .onCreate( ) method, start it running using the
.onStart( ) method, and stop it by using the .onStop( ) method. As mentioned, you would probably
want to utilize a more refined Android Thread subclass such as the AsyncTask or HandlerThread
class, instead of use a more general Thread class, which is generally used as a superclass to create
more application-specific subclasses.
So when would you use Service subclasses over spawning Thread objects in existing classes, you
might be wondering? If you remember from the previous section, Android processes that contain
a Service subclass will always be prioritized higher than processes that utilize a background
processing activity (Thread object). For this reason, if your apps are going to undertake extensive
processing, access, or streaming operations, then you’d want to start a Service component subclass
for that operation, rather than simply create a Thread object.
This is an especially relevant consideration if your background process is going to outlast your
Activity screen. As an example, an Activity that is uploading a video that you created using the
Android Camera class to a web server would want to utilize the Service subclass methodology to
perform this upload. This is so that this upload process could continue in the background and finish
uploading, even if the user leaves that Activity.
Thus, the primary reason that you would want to use a Service subclass over a Thread object is
because using the Service component will guarantee that your processing operation will have at
least a Service process priority level, regardless of what happens to your Activity subclass, which