4.2 KiB
Broadcast Receivers
It is the 4th component in Android
- Activity
- User interface
- Service
- Performs a long-running background task
- Content Provider
- Storage and provision of data
- Broadcast receivers
Components are entry points
Event-based
Respond to system-wide broadcast announcements
- The user has not necessarily done something, but the OS / phone / another application has
- e.g. the screen has turned off, battery is low, phone booted, new text
- Can be sent by an application, or received by an application from the OS
- Create the process, instantiate a
BroadcastReceiver
Intents are sent to specific activities
- Explicitly or implicitly via intent filters
Broadcasts are sent to anything that cares to listen
- System-wide intent broadcasts
Broadcasts
- Broadcasts are intents
- Send an intent to start an activity or service
- Send an intent to trigger broadcast receivers that subscribe to that particular class of intent
- Can define our own broadcast intents
- Cannot send system intents (battery, screen, etc.), as the security model prevents it
- Uses binder for messaging
Broadcast Receiver
-
Must be registered
- Either in the manifest or context-registered
- Context-registered -> runtime
- To receive events while running
-
Declare in manifest
<receiver android:name="MyReceiver"> <intent-filter> <action android:name="com.example" /> </intent-filter> </receiver> -
Specify broadcast intents we are interested in
- Receiver is registered at boot-time / install-time / run-time (context)
Implementation
- Sub-class
BroadcastReceiver- Specify which intents we are interested in
- Implement the
onReceive()method - Send a message to our application to change our behaviour
- Reduce the volume when a notification comes through
- Start an activity
- Do not start activities from broadcast receivers (jarring for user)
- Start a service
- A gateway to another component, e.g. start polling for emails
- Show a notification
- Alert the user that there is something that they need to interact with at some point
Normal and Ordered Broadcasts
sendBroadcast(intent) - intent can be implicit or explicit
sendOrderedBroadcast(intent, receiverPermission)
sendOrderedBroadcast(intent, receiverPermission, resultReceiver)
Receive data back from the broadcast, resultReceiver will be treated as a final receiver at the end of the broadcast.
Ordered broadcasts are received by the highest-priority receivers first
Preferred receivers are given the chance to consume the broadcast before it is delivered to less preferred receivers
Sticky Broadcast
Non-Sticky - if you weren’t listening at the time, you’ve missed it
Sticky intents are cached by Android
- These are so much slower than just implementing direct calls within your own app IPC for each receiver to register. They will also incur a massive IPC overhead
Sticky broadcasts are deprecated
Local Broadcasts
Data broadcast will not leave the application
Other apps cannot send broadcasts to our application
- More efficient than sending a global broadcast
- No IPC
Now deprecated due to the MVVM architecture
Context-registered Receivers
Can no longer use a manifest-declared receiver for most implicit broadcasts
- Broadcasts that don’t target our app specifically
We can receive broadcasts as long as their registered context is valid
- If we register it in
onCreate, we should unregister inonDestroyto prevent leaking the receiver
Broadcasts in practice
The application receiving the broadcasts must have been explicitly started / not explicitly stopped
- Applications cannot intercept broadcasts without the user having some awareness that they have given it permission
Either the sender or receiver of a broadcast can implement permissions
Lifecycle
Process is aggressively killed once onReceive() has returned
- Long-running code should be in a service instead
goAsync()- Can be called in
onReceive()to keep the broadcast active after returning from that function - ~10 seconds to do something
- Can be called in
