# Broadcast Receivers It is the 4th component in Android 1. Activity - User interface 2. Service - Performs a long-running background task 3. Content Provider - Storage and provision of data 4. 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 ![image-20220107185728288](img/ah.png) #### Broadcast Receiver - Must be registered - Either in the manifest or context-registered - **Context-registered** -> runtime - To receive events while running - Declare in manifest ```xml ``` - 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* in `onDestroy` to 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