hackbod wrote: > On Jul 14, 5:19 am, Mark Murphy <[EMAIL PROTECTED]> wrote: >> -- Service (B), on startup, registers an inner class IntentReceiver via >> registerReceiver() for my private Intent, then sets up AlarmManager to >> raise that Intent every N minutes, with the inner class IntentReceiver >> doing the desired work. > > This needs to be a top-level IntentReceiver (it could be the same as > the BOOT_COMPLETED one). Otherwise, when your service stops because > it is done with its work, upon being destroyed the registered intent > receiver will be unregistered (and you should see in the log a message > about it being leaked). Even if you have the service run all the > time, defeating the purpose of using the alarm manager, under very low > memory situations the system could need to kill its process, again > causing the registered receiver to be unregistered.
To make sure I'm interpreting this correctly...the IntentReceiver that is the recipient of the Intents raised by the AlarmManager must be one registered in AndroidManifest.xml (vs. one registered via registerReceiver()), or else it will fall out of memory if/when the service does. And at that point, the AlarmManager is (presumably) still set up to send Intents to a non-existent IntentReceiver. I hadn't thought that all the way through, but it makes sense. That's a facet of top-level IntentReceivers that I hadn't appreciated -- they're "wired into" the Android runtime in such a way that they're always registered, regardless of memory conditions. Question: for Jaikishan's scenario, does he need the service? In other words, does the IntentReceiver that handles Intents from the AlarmManager have any particular speed requirement? I was under the impression that IntentReceivers tied to activities might run on the UI thread and so had to get their task done quickly...but will an AlarmManager-triggered IntentReceiver have that same limitation? Or can it do some network I/O and such before returning from onReceiveIntent(), without impacting any foreground activity? I'm just trying to figure out the right pattern for this case. I don't think it's a stretch to say that a fair number of Android apps will be of the poll-network-for-changes-and-do-something pattern, and so this is an important area for us to get a best practice down pat. Heck, I'm hoping we'll work up a common service or something, where activities can register URLs to be polled and Intents to be fired if/when those documents change, so we can optimize network access and minimize battery consumption. Thanks! -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 1.0 Published! --~--~---------~--~----~------------~-------~--~----~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
