Pro Android with Kotlin

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.

---