Android Components: Broadcast Reciever 📣

𝙸𝚗 𝚝𝚑𝚎 𝚙𝚛𝚘𝚐𝚛𝚊𝚖𝚖𝚒𝚗𝚐 𝚠𝚘𝚛𝚕𝚍, 𝚂𝚎𝚗𝚍𝚒𝚗𝚐 𝚊 𝚖𝚎𝚜𝚜𝚊𝚐𝚎 𝚖𝚎𝚊𝚗𝚜 𝚊𝚗 𝚎𝚟𝚎𝚗𝚝 𝚘𝚏 𝚒𝚗𝚝𝚎𝚛𝚎𝚜𝚝 𝚑𝚊𝚜 𝚘𝚌𝚌𝚞𝚛𝚛𝚎𝚍. 𝙰𝚗𝚍𝚛𝚘𝚒𝚍 𝚊𝚙𝚙𝚕𝚒𝚌𝚊𝚝𝚒𝚘𝚗 𝚌𝚊𝚗 𝚜𝚎𝚗𝚍 𝚊 𝚖𝚎𝚜𝚜𝚊𝚐𝚎 𝚝𝚘 𝚊𝚗𝚘𝚝𝚑𝚎𝚛 𝚊𝚗𝚍𝚛𝚘𝚒𝚍 𝚊𝚙𝚙𝚕𝚒𝚌𝚊𝚝𝚒𝚘𝚗 𝚘𝚛 𝚛𝚎𝚌𝚎𝚒𝚟𝚎 𝚝𝚑𝚎 𝚖𝚎𝚜𝚜𝚊𝚐𝚎 𝚏𝚛𝚘𝚖 𝚊𝚗𝚘𝚝𝚑𝚎𝚛 𝚊𝚗𝚍𝚛𝚘𝚒𝚍 𝚊𝚙𝚙𝚕𝚒𝚌𝚊𝚝𝚒𝚘𝚗. 𝚆𝚎 𝚌𝚊𝚗 𝚎𝚟𝚎𝚗 𝚜𝚎𝚗𝚍 𝚖𝚎𝚜𝚜𝚊𝚐𝚎𝚜 𝚋𝚎𝚝𝚠𝚎𝚎𝚗 𝚝𝚑𝚎 𝚊𝚗𝚍𝚛𝚘𝚒𝚍 𝚌𝚘𝚖𝚙𝚘𝚗𝚎𝚗𝚝𝚜.

Table of contents

• 𝚂𝚘𝚞𝚛𝚌𝚎 𝚌𝚘𝚍𝚎
• 𝚆𝚑𝚊𝚝 𝚒𝚜 𝚋𝚛𝚘𝚊𝚍𝚌𝚊𝚜𝚝
• 𝙴𝚟𝚘𝚕𝚞𝚝𝚒𝚘𝚗 𝚘𝚏 𝚋𝚛𝚘𝚊𝚍𝚌𝚊𝚜𝚝 𝚛𝚎𝚌𝚎𝚒𝚟𝚎𝚛
• 𝚆𝚑𝚢 𝚎𝚟𝚘𝚕𝚞𝚝𝚒𝚘𝚗 𝚠𝚊𝚜 𝚗𝚎𝚎𝚍𝚎𝚍
• 𝚃𝚢𝚙𝚎𝚜 𝚘𝚏 𝚋𝚛𝚘𝚊𝚍𝚌𝚊𝚜𝚝𝚜
• 𝙳𝚎𝚌𝚕𝚊𝚛𝚒𝚗𝚐 𝚝𝚑𝚎 𝚋𝚛𝚘𝚊𝚍𝚌𝚊𝚜𝚝𝚜
• 𝙱𝚎𝚜𝚝 𝚙𝚛𝚊𝚌𝚝𝚒𝚌𝚎𝚜 𝚒𝚗 𝚞𝚜𝚒𝚗𝚐 𝚝𝚑𝚎 𝚋𝚛𝚘𝚊𝚍𝚌𝚊𝚜𝚝
• 𝚂𝚎𝚗𝚍𝚒𝚗𝚐 𝚋𝚛𝚘𝚊𝚍𝚌𝚊𝚜𝚝𝚜 𝚏𝚛𝚘𝚖 𝚘𝚗𝚎 𝚊𝚙𝚙 𝚝𝚘 𝚊𝚗𝚘𝚝𝚑𝚎𝚛 𝚊𝚙𝚙
• 𝙻𝚘𝚌𝚊𝚕 𝚋𝚛𝚘𝚊𝚍𝚌𝚊𝚜𝚝 𝚛𝚎𝚌𝚎𝚒𝚟𝚎𝚛

The Source code of samples used in the project can be found here

GitHub - devrath/droid-component-broadcastreciever: This repository provides samples on how to use…

🗂️ What is broadcast

A broadcast is just a message wrapped inside an intent object. You can pack anything in it say its primitive data type or any custom data objects and send it.

🗂️ Evolution of broadcast reciever

Changes --> From Android-7(Nougat-API-24) and later 🔈

• The broadcasts ACTION_NEW_PITCTURE and ACTION_NEW_VIDEO will not be sent from the android system.
• For CONNECTIVITY_ACTION we need to register receiver dynamically.

Changes --> From Android-8 (Oreo-API-26) and later 🔈

• Here more restrictions were declared on manifest based permissions.
• Here you can’t use recievers that are declared via manifest, but however you can use recievers that are context based

Changes --> From Android-9 (Pie-API-28) and later 🔈

• Here for NETWORK_STATE_CHANGED_ACTION dosen’t receive information of users location or personally identifiable data.

🗂️ Why evolution was needed 🌋

• The evolution was needed as a part of optimizations done on the new versions of android because of pain points felt on the services used in the background in applications that are running.
• Since there were lot of applications running in the background simultaneously. This is not such a large problem in devices that have ample amount of memory but is of a concern in devices that has less memory.
• When any recievers in these background applications are triggered, The OS needs to swap a lot of process in and out frequently causing the memory crunch 💣
• We face this issue in case of implicit broadcasts declared and developers declare and leave it and not knowing once it goes to production, there is lot of ripple 😵 effects.
• Also the static recievers declared in the manifest are also one of the source of this problem.
• To prevent this problem and to optimize the android OS, The changes to new releases of android was made as shown above.
• To achieve the same we can use job-schedulers and work-manager to achieve the same end result.

🗂️ Types of broadcasts 🎯

Implicit Broadcast

• This is a type of broadcast that is not targeted to your application.
• We need to declare your entry in the manifest because when this event occurs in the android system, The system will scan for all the manifests of all the apps on the device and wherever the entries are found, it will be triggered.
• Example: When the system boots up, Charging takes place, Battery state changes, etc.

Explicit Broadcast

• This type of broadcast is targeted to your application for a component that is known in advance.
• This is because the target attribute contains the application package or component class name known in advance.

🗂️ Declaring the broadcasts 🎯

Static way of declaring broadcast

• Here we define a class as receiver, which listens for the broadcasts.
• Adding the declared class with recievertag in the manifest.
• Also adding the intent-filter determing at what instances the broadcast would be triggered.
• Below a example is presented where we declare broadcast statically.
• Most of static way of declaring the broadcasts is not encouraged in newer API’s of android and most of the system broadcasts registered static way is not encouraged.

Dynamic way of declaring broadcast

• The dynamic way of registering the broadcasts is also called as context-registered recievers. Here the these broadcasts are active until the they are subscribed and the corresponding context is active.
• The dynamic recievers are also made to be able to receive the events if the app is in background and in minimized state.
• If its removed from the background, the reciever stops receiving the events.

🗂️ Best practices 🎯

• It is always a best practice not perform long running task in the reciever of the broadcast, instead trigger a worker using the work-manager and pass the task of performing the long-running work in the worker .
• In dynamic recievers, Good practice is to register and unregister in two ways, register in onStart() and un-register in onPause() and in another way is to register in onCreate() and un-register in onDestroy() . This will prevent leaking of the recievers.

🗂️ Sending broadcasts from one app to another app 🎯

• Here we will beable to send the broadcast from one app to another app, Provider both the app’s are in active or in background.
• The unique name is given to sender and the reciever listens to the same tag. They can attach a data and send the reciever would recieve the data back in the reciever.

🗂️ Local Broadcast Reciever 🎯

• If the communication is limited to current application, its a better practice not to send a global broadcast instead send a local broadcast by doing so the scope is limited to current application. Also sharing the sensitive information globally might not be good idea. This would also need interprocess communication when communicating between the applications.
• For this local broadcast reciever was introduced where the scope of the reciever is within the current application. Also the inter-process communication is not needed here.