Android Core Aula 7 - Aplicações (Services, Broadcast Receivers, NDK/JNI)
What is Broadcast Reciver in Android
-
Upload
apex-tgi -
Category
Technology
-
view
126 -
download
0
description
Transcript of What is Broadcast Reciver in Android
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: [email protected]
Stay Connected with us for more PPT on Android