CHAPTER 13: Android Service Class and Threads: Background Processing 477result to the calling entity, much like a void method performs its task without returning anything to the
calling method or object. As an example, the started Service might download or upload a data file
over a network. Best practices dictate that when a started Service operation is completed, the Service
object should automatically stop itself. This helps optimize Android operating system resources, such
as CPU processor cycles and system memory usage, which should always be conserved.
A bound Service is created when an Android application component binds to a Service. This
is accomplished by calling a .bindService( ) method. The bound Service offers a client-server
interface that allows components to interact with the bound Service. Just like with a client-server
relationship, you can send requests, get results, and you can even do all of this across (between)
different processes, using interprocess communication (IPC).
A bound Service will remain in the system memory as long as other Android application components
are still bound to it. Multiple application components can bind to a bound Service at the same time.
When all of these application components unbind from the Service, that Service is “destroyed,” or
removed from system memory.
We will take a look at both of these types of Service formats, as well as a hybrid approach, where
your Service can work in both of these ways at the same time. What this means is that you can start
your Service (so that it is a started Service, and can run indefinitely) and later allow it to bind (or be
bound to).
Whether an Android Service is specified as started or bound is determined by whether you have
implemented a couple of the more often used Service class callback methods. For instance,
the Service class .onStartCommand( ) method will allow components to start a Service, and the
.onBind( ) method will allow components to bind to that Service.
Regardless of whether your application’s Service is started, bound, or a hybrid (both started and
bound), any other application component can use that Service, even from a separate application.
This is similar to the way that any of your application components can start (launch) an Activity
subclass by starting it using an Intent object. We covered using Intent objects in Chapter 7, so we
could use them during the rest of the book. You will see how to use Intent objects to start Service
subclasses during this chapter when you create your own Service subclass.
Controlling Your Service: Privacy and Priority
Service subclasses will run with a higher priority than inactive Activity subclasses. Because of this
fact, it is far less likely that the Android operating system will terminate a Service class than it will
an Activity class. I will be discussing the concept of priority in greater depth a bit later in this chapter.
If an Activity subclass is “active,” or currently in use by your user on their display screen, it will
obviously have the highest priority, as the assumption is that the user is currently and actively using
it to interface (hence the term user interface) with the application and therefore with the Android
hardware device.
It is important to note that you can declare your Service as private using your AndroidManifest XML
file. This will block access to your Service subclass from other external Android applications. This
is usually a good idea for security reasons, which I also discuss in this chapter. Android developers
often do this as a programming or development “best practice,” unless other applications absolutely
need to use that Service.