I need to submit some data as soon as there is an internet connection. Until now I've done this by registering a broadcast receiver in the manifest for the CONNECTIVITY_ACTION event. This works perfectly but now I'm worried about the performance.
I mean a CONNECTIVITY_ACTION broadcast is sent pretty often sometimes and the every time my app will be "started" just to try to submit some data, that might not even exist at that moment.
Is there a better way to do that? Or does it not really matter?
I mean I could register a receiver in every activity but that's not very neat I think. I know I could make a class derive from Activity (to override onResume and onPause) but as I'm also using FragmentActivity, that isn't the best option either.
Do you have some suggestions on how to do that? The data doesn't need to be sent immediately if a connection is available (I mean that would be very nice but not necessary).
I could also just try to send the data in the onResume method of every activity but again that's not as neat as I'd like it...
Many apps fire up receiving that broadcast. Check the logcat yourself. Some apps have a running service that check for a connection, vomiting out exceptions.
As many times stated by Google engineers, it's less taxing on the battery to do your tasks upon radio being in active mode and do some extra for caching, than to wind up radio every few minutes. Refer to 2012 Google I/O speech by Reto Meier. He outlines a bit how it should work and why.
Related
i used the google simple code to "Creating and Monitoring Geofences" and every thing works fine but i have one problem that when the device lost gps signal for second the trigger event will count this as exit , and when signal back will count as enter
even it's still inside Geofence ,i guess i can't avoid this situation
so did any one know if this behavior can be suppressed?
also An additional questions, i read alot in stackoverflow geofence problems that using a BroadcastReceiver better than Service to receive the transitions
right now i use service to receive and it's work fine , Is it necessary change it to BroadcastReceiver ?
This is an issue with Google Geofence relying on bad network location points at times. I have a potential solution for this here. It's not 100%, but it does help suppress the geofence jumps.
As for the second part of your question, I don't know if you mean the IntentService or just a Service. If it is a Service, I would recommend using an IntentService or BroadcastReceiver. IntentServices are mostly used for performing tasks on a background thread, where BroadcastReceivers are meant to restart the process (if it wasn't force killed by the user), and perform a quick task to handle the intent. Both of those are self contained, and destroy themselves right after the task is done. But to answer your question, no, you don't have to use a BroadcastReceiver, but it is better practice to do so.
Hello all i want location updates when my app is triggered first and after even it is killed i want my service to run i tried broadcast receiver for this purpose but it run on phone reboot Can anybody guide me to the right direction? Thanks
depending on the layout of your code, I believe it might be as easy as making the app perform the location update request on onResume while leaving onPause blank to test if it works for what you want. At least if I understood you correctly, that's what worked for me but it might drain your battery if you are using some power demanding location provider like GPS. And about your service to survive reboot I'm not really acquainted on that topic but from a quick read, indeed using broadcast receiver and listening for BOOT_COMPLETED to set off an intent.setAction declared after onCreate on your MainActivity should do it, but haven't tested that myself yet. Anyhow, it would be best if you can post the code you're working with so that others can see exactly what you have so far and be more helpful.
Hope it helps
Some broadcast receivers only work if they are registered via code rather than defined in AndroidManifest.
For example:
SCREEN_ON, SCREEN_OFF
These actions will only work with receivers registered in code. No errors happen if they are registered in the manifest, but they never get called either.
What are the reasons for this undocumented behavior? Security?
I don't think there is a security issue around this.
Manifest defined broadcast receivers are registered and can receive intents even if the application is not in memory. The opposite doesn't occur.
It could be a performance issue because registering a receiver for this type of events, may drain the user battery.
Main difference between Manifest and Programmatic registering of BroadcastReceiver
I think this is a design decision. We can register our broadcast receivers statically or dynamically. Both receiver types treated slightly different by Android system.
Mainly;
Dynamic broadcast receiver live with application. We can use it multiple times. Most important thing about it, it runs on UI thread.
Statical broadcast receiver live with OS. Package manager handles its life cycle. The transient nature of a statically registered BroadcastReceiver means that its onReceive() method cannot use any functionality which is asynchronous, for example, binding to a Service.
And some broadcast like SCREEN_ON, SCREEN_OFF... can be called continuously. If we can register this kind of broadcast. A lot of number app want to use it. And every time we open device screen, all of this app will be triggered by OS. This is not a good behavior for any kind of OS.
On the other hand, there are some broadcast that is meaningless when we use in code. Such as "BOOT_COMPLETED". It should be registered system-wide, not in UI thread.
I think this kind of decisions depends on security, performance and use case scenario.
P.S.: Long time ago, I had searched but didn't find any documentation for exact reason about it.
It seems this answer is good for me but still this is not telling the reason why some can only be registered in AndroidManifest and some only through code
The primary use of manifest-registered receivers is for broadcasts that may go on while your code is not in memory (e.g., BOOT_COMPLETED, your scheduled alarms via AlarmManager).
This behaviour does not have any relation to security as Diogo Bento mentioned it.
If there is a resource that is precious and prermission is needed before using it, then you have to ask for that permissions, no matter weather you declare your Broadcast Receiver in the manifest or register it in the code. Without the required permissions, both will fail.
I think the reason of the code only actions is that, Googe does not want to let your app being started by that action. SCREEN_ON and SCREEN_OFF is a good example. It would be easy to make an annoying application that would do something as the screen turns on. With this restriction its much harder. If you really need your application to be started as the screen turns on, then you have to do more work to accomplish the same effect. For example you have to maintain a Service that listens for those events.
In addition, most applications care about those screen events only if they are in the foreground, so there is no need to wake up every applications, which not even running. Lets say that you have 10 apps that in a way interested in the SCREEN_ON action. As you turn your screen on, 10 process would have to be started by Android just to ignore those events, because none of them running. And process is one of the most expensive resource from the perspective of an OS...
Are there any use cases in which I would want to use a BroadcastReceiver for something other than cross-application communication?
After reading the documentation, it seems like they are targeted at cross-application communication, but the idea of using them with the LocalBroadcastManager is also mentioned. I also read this post, which addresses the general usage of broadcast receivers. Neither seem to hit clearly on why it would be useful to use broadcasts and receivers for anything other than cross-application communication.
Does it have anything to do with their asynchronous nature, or maybe they're just used to move some processing out of the main activity?
Clarification: I guess the term cross-application was too general. I was considering the built-in actions such as
android.hardware.action.NEW_PICTURE
to be coming from applications. What I would like to know is: when is it useful to use a BroadcastReceiver for communication within my app - I guess this would narrow it down to custom intent actions/categories. Sorry if the way I'm asking this is confusing. I've only just recently begun programming with Android and I still don't understand the OS very well.
As it quotes in the post you linked: "A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the system."
Therefore, they are useful in "catching" system broadcasts, e.g., when the device has booted up, when the battery level changes, when your Wi-Fi has been turned on, etc.
Personally, I've used a BroadcastReceiver to start my app whenever the device receives a text message. In my case, this is preferred, as my app does not need to be running when the text message is received. Upon receipt, the system will broadcast an intent with an SMS_RECEIVED action. My BroadcastReceiver component, registered to accept this particular type ofbroadcast, will be notified and can then react as needed. In my case, it launches an Activity to notify the user of the text message and choose a particular reply text message.
This is just a specific example. There are many other broadcasts that the system transmits and your Receiver can get. Check this link and this post for more examples.
Clarification:
A LocalBroadcastManager is preferable in instances when you want rather simple way to communicate between app components without an intent being broadcast system-wide. Knowing this, you would want to go this route when the info you're passing is to be used only by your app. A LocalBroadcastManager is more efficient, generally simpler than using an IBinder interface, and can ensure that information isn't leaving your app.
For an example, suppose you have a Service that runs in the background to track and log some constantly changing data; let's say your battery level. The Service can run on its own without user interaction, saving the battery level to the disk as it changes. When you start your activity to view said data, it would use LocalBroadcastManager to register a receiver to accept the info the Service is sending, and update the Activity's UI in real time to reflect this. Since no other app needs the info from your Service, it's better to do this than broadcasting an intent to which any other app could have access.
To sum up, using a LocalBroadcastManager is:
More efficient.
More secure.
Simpler.
If you have a Service that frequently (every second or half a second) sends updates, are there pros/cons to using Broadcasts vs registering Listeners (an Interface you create) that get stored in some sort of List in the Service and sending out updates that way?
I'm thinking in terms of memory usage, battery consumption, etc. I know it's a little bit open ended, however, there's not much in terms of documentation so they can be equal, but if someone knows a definite answer or has some input, it would be appreciated.
In my experience, if you will send out notifications frequently, choose listeners. I've implemented some BroadcastReceivers for the same matter, but some messages got lost. I think this is because the BroadcastReceivers do not queue incoming intents but instead drop those arriving whilst still "doing work with the old one".
Of course broadcasting intents can be more relaxing, as you don't have to.. connect the service and every listening part of your application, but in my case (multiple messages per second) listeners were the right choice.
Do not think about this things, it is really small amount of energy and perfomanse. Main difference between Broadcasts and Listeners is a way there your messages will go. If it's Broadcasts your ivents will go throgh system othervise they will go directly to your class.
Anyway you should create a BroadcastReciever to get updates (so it's still a listener). But in this case os cares to call them instead of direct listener calls from service. Not sure about value of differance, but direct calls looks faster, and less memory/battery consumpting from this pov.