Pro Android with Kotlin

40
CHAPTER 4: Services
onHandleIntent() method. Since basically you don’t need anything else, 
the IntentService service is easy to implement. Note that starting with 
Android 8.0 (API level 26), restrictions apply to background processes, 
so under appropriate circumstances, consider using JobIntentService 
classes instead.

android.support.v4.app.JobIntentService: This uses a JobScheduler 
to enqueue service execution requests. Starting with Android 8.0 (API 
level 26), consider using this service base class for background services. 
To implement such a service, you basically have to create a subclass 
of JobIntentService and override the method onHandleWork(intent: 
Intent): Unit to contain the service’s workload.
Services Lifecycle
Having described various service characteristics in the preceding sections, the actual 
lifecycle of a service from a bird’s-view perspective is arguably easier than that of an activity. 
However, be careful of services being able to run in the background. Also, because services 
are more readily subject to stops forced by the Android OS, they may require special 
attention in correspondence with service clients.
In your service implementation, you can overwrite any the lifecycle callbacks listed here, for 
example, to log service invocation information while developing or debugging:

onCreate()

onStartCommand()

onBind()

onUnbind()

onRebind()

onDestroy()

---

41
CHAPTER 4: Services
Figure 
4-1
shows an overview of the lifecycle of a service
Figure 4-1. Service
lifecycle

---

42
CHAPTER 4: Services
More Service Characteristics
The following are more observations about services:

Services get declared alongside activities inside AndroidManifest.xml. 
A common question is how they interact with each other. Somebody 
needs to invoke services to use them, but this can also be done from 
other services, other activities, or even other apps.

Do not bind or unbind during an activity’s onResume() and onPause() 
methods for performance and stability reasons. Do bind and unbind 
instead inside the onStart() and onStop() methods, if you need to 
interact with services only when an activity is visible. If you need service 
connections also when activities are stopped and in the background, do 
bind and unbind in the onCreate() and onRestore() methods.

In remote connection operations (the service lives in another app), catch 
and handle DeadObjectException exceptions.

If you overwrite a service’s onStartCommand(intent: Intent, flags: 
Int, startId: Int) method, first make sure to also call the method 
super.onStartCommand() unless you have good reasons not to do that. 
Next, appropriately react on the incoming flags parameter, which tells 
whether this is an automatic follow-up start request because a previous 
start attempt failed. Eventually this method returns an integer describing 
the service’s state after leaving the onStartCommand() method; see the 
API documentation for details.

Calling stopService() from outside a service or stopSelf() from inside 
a service does not guarantee that the service gets stopped immediately. 
Expect the service to hang around for a little while until Android really 
stops it.

If a service is not designed to react on binding requests and you 
overwrite the onBind() method of the service, it should return null.

While not forbidden explicitly, for a service that is designed for 
communicating with service clients via binding, consider disallowing the 
service to be started by startService(). In this case, you must provide 
the Context.BIND_AUTO_CREATE flag in the bindService() method call.

---

43
© Peter Späth 2018 
P. Späth, Pro Android with Kotlin, 
https://doi.org/10.1007/978-1-4842-3820-2_5
Chapter
5
Broadcasts
Android broadcasts are messages following the publish-subscribe pattern. They are sent 
across the Android OS, with the internals hidden by the Android OS, so both publishers and 
subscribers see only a lean asynchronous interface for sending and receiving messages. 
Broadcasts can be published by the Android OS itself, by standard apps, and by any other 
app installed on the system. Likewise, any app can be configured or programmed to receive 
the broadcast messages they are interested in. Like activities, broadcasts can be explicitly 
or implicitly routed, which is the responsibility of the broadcast sender to decide.
Broadcast receivers are declared either in the AndroidManifest.xml file or programmatically. 
Starting with Android 8.0 (API level 26), the developers of Android have abandoned the usual 
symmetry between XML and programmatic declaration of broadcast receivers for implicit 
intents. The reason is that the general idea of imposing restrictions on processes running in 
background mode, especially related to broadcasts, resulted in a high load on the Android 
OS, slowing devices down considerably and leading to a bad user experience. For that 
reason, the declaration of broadcast receivers inside AndroidManifest.xml is now limited to 
a smaller set of use cases.
Note You will want to write modern apps that are runnable in Android 8.0 and newer. For that 
reason, take this broadcast limit for implicit intents seriously and make your app live within that 
limitation.

---