Android’s Pub-Sub — Broadcasts

These are my notes / understanding of Android Broadcasts

  1. A Pub-Sub design pattern is useful in cases where the producers (senders) of messages/events are not aware of the consumers of these messages. This architectural design pattern enables a decoupled system and reduces dependencies. Broadcasts allow App developers to use this pattern in Android Applications.
  2. Broadcasts: Android’s Pub-Sub design pattern. Android apps can send or receive messages from the system or other Android Apps. Senders do not know which apps receive the broadcasts. Receivers can trigger actions on recieving broadcasts they have registered for. The system takes care of delivering the broadcasts to interested receivers. Broadcasts are used as a messaging mechanism outside normal workflow. The system sends system broadcasts on system events e.g.NETWORK_STATE_CHANGED_ACTION. System broadcasts are wrapped in an Intent Object. The action string of the intent object contains the system event name and can have additional optional information element included in the intent body (eg a boolean flag to indicate if the network was turned on or off). Note: Be careful not to run jobs in the background in response to broadcasts. This can contribute to slow system performance.
  3. Implicit Broadcasts: Broadcasts that are not speficically targetted for your app. System Broadcasts are an example of implicit broadcasts.
  4. Types of Broadcast Receivers : Manifest declared (in AndroidManifest.xml) or Context registered (by creating a BroadcastReceiver object).
  5. Manifest declared: Specified in the <receiver> section of the Apps AndroidManifest.xml. Additionally, the code must subclass the BroadcastReciever class and implement the onReceive() method. The system package manager registers the receiver when the app is installed. This becomes a separate entry point thus allowing the system to start the app if it is not running when the broadcast is received. A new BroadcastReceiver context object is created for every broadcast that is received and lives for the duration of the OnRecieve method. Note: API level 26 and higher, we cannot use manifest for registering receiers for most implicit broadcasts.
  6. Contex Registered: In the code, create a broadcastReceiver object, create an IntentFilter object and register the BroadcastRegister object with it by calling registerReceiver(). When not needed or context is not valid, unregisterReceiver to stop receiving broadcasts. Take care not to leak objects due to changes in process state.
  7. Effect on process state: the state of the BroadcastReceiver affects the state of the process and affects the likelihood of the process getting killed or not. Once the onRceive call returns, the app can be killed. Hence avoid spawning log running background threads from the broadcast receiver (once the call returns, the process can be killed terminating the thread). Instead use the JobScheduler to schedule the long runnign threads or invoke the goAsync() call. Also note that the onRecieve() call is invoked in the Main() thread hence the call should return as quickly as possible.
  8. Sending Broadcasts: sendOrderedBroadcast(), sendBroadcast()->Normal Broadcasts, LocalBroadcastManager.sendBroadcast() -> for local broadcasts within same app.
  9. Restricting broadcasts: Broadcasts can be restricted to apps that have certain permissions by specifying permissions either at sender or receiver end. For senders, the API takes an additional parameter spefiyng the permission required by receivers. For restricting by the Receivers, the permission must be specified at registration time in the manifest file or specifying it in registerReceiver() call.