What if my receiver is registered for the ACTION_BATTERY_CHANGED intent? As stated in the documentation, "You can not receive this through components declared in manifests, only by explicitly registering for it with Context.registerReceiver()."
Is there anyway to make sure my receiver is always registered for this intent, even if the process is destroyed? Would it make a difference if I used the application context when registering the receiver instead of the activity context? (frankly, I still don't have a good grasp of the context object and don't quite understand how the application and activity contexts differ) I know that I may be able to use the new battery related broadcasts that have been added to API level 4, but I'm trying to stick to level 3 to ensure compatibility with all devices. Thanks! On Mar 25, 8:23 am, Mark Murphy <[email protected]> wrote: > Tughi wrote: > > Hi guys, > > I want to optimize the CPU usage in my application. > > > Currently my application is configured to always receive the > > CONNECTIVITY_CHANGED action to force an update if the previous update > > failed because there was no connectivity. > > What I don't like about this is that the broadcast receiver gets to be > > called too many times although it is not needed. > > > I was thinking to register my broadcast receiver only if an update > > failed using the Context.registerReceiver(BroadcastReceiver receiver, > > IntentFilter filter) method. But I'm not so sure if this is a good > > idea. > > > I'm concerned that if my application is evicted from memory the > > broadcast receiver will be unregistered or lost and my application > > will not be notified about the future CONNECTIVITY_CHANGED actions. > > > The update is done in a short lived service. So if the update fails, > > the service will register the broadcast receiver just before it ends > > its execution time. > > > Can somebody explain what happens to my broadcast receiver after the > > application is evicted from memory? > > You will leak memory, as your BroadcastReceiver will keep the component > in RAM (even if it was destroyed) until such time as Android terminates > the process. > > You might consider going with a manifest-registered receiver, but > enabling and disabling the component as needed via PackageManager. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android Training...At Your Office:http://commonsware.com/training -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
