BroadcastReceiver

facebook.com/apex.tgi

twitter.com/ApextgiNoida

pinterest.com/apextgi

BroadcastReceiver

It belongs to ‘android.content’ (android.content.BroadcastReceiver)

package and extends Object class have some subclass to implement it

functionality such as AppWidgetProvider ,  DeviceAdminReceiver ,

RestrictionsReceiver , WakefulBroadcastReceiver etc.

It is Base class for code that will receive intents sent by sendBroadcast().

BroadcastReceiver

There are two major classes of broadcasts that can be received:

Normal broadcasts :

(sent with Context.sendBroadcast) are completely asynchronous. All receivers of the broadcast

are run in an undefined order, often at the same time.

This is more efficient, but means that receivers cannot use the result or abort APIs included here.

BroadcastReceiver

Ordered broadcasts :

(sent with Context.sendOrderedBroadcast) are delivered to one receiver at a time. As each

receiver executes in turn, it can propagate a result to the next receiver, or it can completely abort

the broadcast so that it won't be passed to other receivers.

The order receivers run in can be controlled with the android:priority attribute of the matching

intent-filter; receivers with the same priority will be run in an arbitrary order.

BroadcastReceiver

Some Important Point :

Even in the case of normal broadcasts, the system may in some situations revert to delivering the

broadcast one receiver at a time. In particular, for receivers that may require the creation of a

process, only one will be run at a time to avoid overloading the system with new processes. In

this situation, however, the non-ordered semantics hold: these receivers still cannot return

results or abort their broadcast.

The BroadcastReceiver class (when launched as a component through a

manifest's <receiver> tag) is an important part of an application's overall lifecycle.

BroadcastReceiver

Although the Intent class is used for sending and receiving these broadcasts, the Intent broadcast

mechanism here is completely separate from Intents that are used to start Activities

with Context.startActivity().

There is no way for a BroadcastReceiver to see or capture Intents used with startActivity();

likewise, when we broadcast an Intent, we will never find or start an Activity.

These two operations are semantically very different: starting an Activity with an Intent is a

foreground operation that modifies what the user is currently interacting with; broadcasting an

Intent is a background operation that the user is not normally aware of.

Receiver Lifecycle

A BroadcastReceiver object is only valid for the duration of the call

to onReceive(Context, Intent). Once code returns from this function, the system

considers the object to be finished and no longer active.

This has important repercussions to what we can do in an onReceive(Context,

Intent) implementation: anything that requires asynchronous operation is not

available, because we will need to return from the function to handle the

asynchronous operation, but at that point the BroadcastReceiver is no longer active

and thus the system is free to kill its process before the asynchronous operation

completes.

In particular, you may not show a dialog or bind to a service from within a

BroadcastReceiver. For the former, you should instead use

the NotificationManagerAPI. For the latter, you can use Context.startService() to

send a command to the service.

Receiver Lifecycle

A BroadcastReceiver object is only valid for the duration of the call

to onReceive(Context, Intent). Once code returns from this function, the system

considers the object to be finished and no longer active.

This has important repercussions to what we can do in an onReceive(Context,

Intent) implementation: anything that requires asynchronous operation is not

available, because we will need to return from the function to handle the

asynchronous operation.

Receiver Lifecycle

But at that point the BroadcastReceiver is no longer active and thus the system is

free to kill its process before the asynchronous operation completes.

In particular, we may not show a dialog or bind to a service from within a

BroadcastReceiver. For the former, we should instead use the NotificationManager

API. For the latter, we can use Context.startService() to send a command to the

service.

Process Lifecycle

A process that is currently executing a BroadcastReceiver (that is, currently

running the code in its onReceive(Context, Intent) method) is considered to be a

foreground process and will be kept running by the system except under cases of

extreme memory pressure.

Once control return from onReceive(), the BroadcastReceiver is no longer active,

and its hosting process is only as important as any other application components

that are running in it.

Process Lifecycle

This is especially important because if that process was only hosting the

BroadcastReceiver then upon returning from onReceive() the system will consider

its process to be empty and aggressively kill it so that resources are available for

other more important processes. It is a common case for applications that the user

has never or not recently interacted with.

This means that for longer-running operations we will often use a Service in

conjunction with a BroadcastReceiver to keep the containing process active for the

entire time of your operation.

Security & Permission

Receivers used with the Context APIs are by their nature a cross-application

facility, so we must consider how other applications may be able to abuse our use

of them. Some things to consider are:

The Intent namespace is global. Make sure that Intent action names and other

strings are written in a namespace we own, or else we may inadvertently conflict

with other applications.

When we use registerReceiver(BroadcastReceiver, IntentFilter), any application

may send broadcasts to that registered receiver.

Security & Permission We can control who can send broadcasts to it through permissions described

below.

When we publish a receiver in application's manifest and specify intent-filters for

it, any other application can send broadcasts to it regardless of the filters specifed.

To prevent others from sending to it, make it unavailable to them

with android:exported="false".

When we use sendBroadcast(Intent) or related methods, normally any other

application can receive these broadcasts.

Security & Permission We can control who can receive such broadcasts through permissions described

below. Alternatively, starting with ICE_CREAM_SANDWICH, We can also safely

restrict the broadcast to a single application with Intent.setPackage

None of these issues exist when using LocalBroadcastManager, since intents

broadcast it never go outside of the current process.

Access permissions can be enforced by either the sender or receiver of a broadcast.

To enforce a permission when sending, supply a non-null permission argument

to sendBroadcast(Intent, String) or sendOrderedBroadcast(Intent, String, BroadcastReceiver,

android.os.Handler, int, String, Bundle).

Security & Permission Only receivers who have been granted this permission (by requesting it with the<uses-

permission> tag in their AndroidManifest.xml) will be able to receive the broadcast.

To enforce a permission when receiving, supply a non-null permission when registering receiver

-- either when callingregisterReceiver(BroadcastReceiver, IntentFilter, String,

android.os.Handler) or in the static <receiver> tag in  AndroidManifest.xml.

Only broadcasters who have been granted this permission (by requesting it with the <uses-

permission> tag in their AndroidManifest.xml) will be able to send an Intent to the receiver.

Contact

Thank You

Apex TG India Pvt. Ltd. E-20 Sec-63 Noida

Apex TG India

E-20 , Sector 63, Noida

0120 – 4029000/9024/9025/

9027

+91-9953584548

Email id: pratap@apextgi.com

Stay Connected with us for more PPT on Android