πΈπ πππ πππππππππππ π ππππ, πππππππ π πππππππ πππππ ππ πππππ ππ ππππππππ πππ ππππππππ. π°ππππππ πππππππππππ πππ ππππ π πππππππ ππ πππππππ πππππππ πππππππππππ ππ πππππππ πππ πππππππ ππππ πππππππ πππππππ πππππππππππ. ππ πππ ππππ ππππ ππππππππ ππππ πππ πππ πππππππ ππππππππππ.
Table of contents
- ππππππ ππππ
- ππππ ππ πππππππππ
- π΄ππππππππ ππ πππππππππ ππππππππ
- πππ’ πππππππππ π ππ ππππππ
- ππ’πππ ππ ππππππππππ
- π³ππππππππ πππ ππππππππππ
- π±πππ πππππππππ ππ πππππ πππ πππππππππ
- πππππππ ππππππππππ ππππ πππ πππ ππ πππππππ πππ
- π»ππππ πππππππππ ππππππππ
The Source code of samples used in the project can be found here
ποΈ 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
andACTION_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
andwork-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
reciever
tag 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 theworker
. - In dynamic recievers, Good practice is to register and unregister in two ways, register in
onStart()
and un-register inonPause()
and in another way is to register inonCreate()
and un-register inonDestroy()
. This will preventleaking
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 alocal 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.