I am a bit confused about this part of documentations:
A BroadcastReceiver object is only valid for the duration of the call to onReceive(Context, Intent).
Once your code returns from this function, the system considers the object to be finished and no longer active.
What does "no longer active" mean? It means our receiver won't receive any events with the specified type? Or it means the receiver is destroyed and a new one is created when the event occurs?
Is this any difference about this, between registering receiver in manifest file and in code dynamically?
"Is this any difference about this, between registering receiver in manifest file and in code dynamically?"
Yes, there is a difference. Receivers registered in the manifest file will receive all intent-filters it matches, anytime the OS sends them out. This differs from registering a broadcast receiver in code by the broadcast receiver in code will only listen to broadcast intents while you have set it to listen. The reason you would use this method sometimes, as opposed to just registering it in the manifest, is if you wanted to implement ordered broadcast. For example, (you can build your application in such a way that) a broadcast receiver in an activity would have higher priority than the manifest, that way, if you receive an intent that your application handles, you can present a message in the activity because you know that the user much currently be in your app. If the broadcast receiver is not listening in the activity, then you assume the user is not currently using your app so then you may just want to send a notification. I should mention that ordered broadcast have the ability to abort the propagation of a broadcast intent to the next receiver, which is what you would do if you caught the intent in your activity class ,therefore, the manifest file will only get the intent if the receiver in the activity class did not catch it.
The words "no longer active" mean that the broadcast receiver will just stop doing any work for that particular broadcast. It will still listen to any succeeding broadcast intents just fine.
It means that 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.
You will often use a Service in conjunction with a BroadcastReceiver to keep the containing process active for the entire time of your operation.
Related
I have a network change receiver class and it extends from broadcast Receiver, but I’m not pretty sure that it’s working in android Oreo, does Oreo support broadcast receiver, and if it doesn’t support, what’s the other way to do it
Oreo supports Broadcast Receivers but with some restrictions on Implicit broadcast that are declared in manifest.
Implicit vs Explicit Broadcast:
According to the documentation, an implicit broadcast is a broadcast that does not target that app specifically. For example, ACTION_PACKAGE_REPLACED is an implicit broadcast, since it is sent to all registered listeners, letting them know that some package on the device was replaced.
However, ACTION_MY_PACKAGE_REPLACED is not an implicit broadcast, since it is sent only to the app whose package was replaced, no matter how many other apps have registered listeners for that broadcast.
So any broadcast receivers that we have defined statically within our application manifest that are listening for implicit broadcasts will no longer receive those broadcasts.
The reason for this change is that implicit broadcasts would previously trigger any component that was listening for them within the manifest— this could have an adverse effect on application and device performance due to large numbers of applications registered to receive specific broadcasts all being triggered at the same time.
But there is a list of exceptions when it comes to implicit broadcasts — this means that there are still some which you can register to receive broadcasts for. They are all listed below:
So if the broadcast that you have registered receivers for is on this list, then it will still function as it did previously. However, if the broadcast that you have registered to receive is not on this list then you should use some alternative solution like:
Create the receiver at runtime by calling Context.registerReceiver(),
instead of declaring the receiver in the manifest.
Use a scheduled job to check for the condition that would have
triggered the implicit broadcast.
For more information
It's not supported in Oreo as manifest tag, you must have to register it at an Service/ Activity with context.registerReceiver(). Or you use the WorkManager to schedule something for specific network conditions.
I am writing an app to receive the sms and display it on my screen. I declared a broadcast receiver and registered in my activity (in oncreate()). I haven't set any priority in my manifest file as well.
However during run time, my receiver is receiving the sms first then the systems message service is invoked first. Is this the behavior of custom broadcast receivers?
Thx!
Rahul.
Android sends ordered broadcasts for SMS messages. From the reference guide (emphasis mine)
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.
I suspect that due to the lack of priority, the order is being chosen arbitrarily.
I have an application which tells the state of the device (Connected/Disconnected). Now I have registered the Broadcast Receiver for the same and display the appropriate state.
1. But my problem is that I have to make this status message common to all the activities. So where do I register this receiver and where do I unregister the receiver. I dont want the repeatative code. So is there any place from which I can do an common register and unregister instead of unregistering it in every activity for onDestroy().
Can I use the Application class in any way so as to have an common place to register and unregister?
Or is the Manifest file appropriate in my case to register the receiver
Thanks,
Shraddha
Android provides BroadcastReceivers, which can be independent of an Activity. These can be "registered" in your applications manifest. Of course, you need a corresponding programmed receiver to which the manifest corresponds when the suitable intent is called.
See here: http://developer.android.com/guide/topics/manifest/intent-filter-element.html
I'm registering a receiver to capture the ConnectivityManager.CONNECTIVITY_ACTION in code i.e. I am not registering it in the application manifest. All is working fine but I notice that I automatically receive a broadcast as soon as I register my receiver and despite the network being already on.
My question is can I rely on this automatic broadcast to check whether the network is available or not i.e. not explicitly call methods to check the network?
I was only expecting a broadcast when a network changed and not upon registering my receiver, however the fact that I do receive a broadcast is very useful but can I rely on it. Is this a documented action?
Yes, that's called sticky broadcasts. Sticky broadcasts are sent to receiver as soon as registerBroadcast is called.
What is a BroadcastReceiver? What are its uses and how can I use it?
Start by reading the documentation. Also, copying from Application Fundamentals:
Broadcast receivers
A broadcast receiver is a component that responds to system-wide
broadcast announcements. Many
broadcasts originate from the
system—for example, a broadcast
announcing that the screen has turned
off, the battery is low, or a picture
was captured. Applications can also
initiate broadcasts—for example, to
let other applications know that some
data has been downloaded to the device
and is available for them to use.
Although broadcast receivers don't
display a user interface, they may
create a status bar notification to
alert the user when a broadcast event
occurs. More commonly, though, a
broadcast receiver is just a "gateway"
to other components and is intended to
do a very minimal amount of work. For
instance, it might initiate a service
to perform some work based on the
event.
A broadcast receiver is implemented as a subclass of
BroadcastReceiver and each broadcast
is delivered as an Intent object. For
more information, see the
BroadcastReceiver class.
Finally, read in Common Tasks how you can utilize BroadcastReceivers to listen for messages and set alarms.
A broadcast is generated by android on occurrence of some action , BroadcastReceiver class enables the developer to handle the situation on occurence of the event/action . Action can be arrival of msg or call , download complete , boot completed , etc.
Broadcast Receivers simply respond to broadcast messages from other applications or from the system itself. These messages are sometime called events or intents. For example, applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use, so this is broadcast receiver who will intercept this communication and will initiate appropriate action.
I like this slide, because it focuses on Broadcast Receiver and offers simple description. The minor problem is that the updated date was a little bit old ( in 2011 ).
Link
Android Application Component: BroadcastReceiver Tutorial
(retrieved from the slide)
Broadcast Receiver
Receives and Reacts to broadcast Intents
No UI but can start an Activity
Extends the BroadcastReceiver Base Class
BroadCastReciever is an Android Component that helps you to know handle registered System Events or Application Events.
For Example:
System Events Such us : the screen has turned off, the battery is low, or a picture was captured.
Applications can also initiate broadcasts—for example, to let other applications know that some data has been downloaded to the device and is available for them to use... etc
In simple terms
A broadcast receiver is basically an interface that you can implement so that your app can subscribe to system changes like when the system has finished booting, or a charger is connected/disconnected or airplane mode is switched on/off etc.