On Jul 14, 6:31 pm, Mark Murphy <[EMAIL PROTECTED]> wrote: > 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.
Yep. So it will just broadcast the Intent, there will be nobody around to receive it, and *poof* that is the end of it. > 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. Yep, this is one of the key uses of receivers, they allow your application to declare events it is interested in finding out about even when it is not running. (Also they are a little cleaner to use with the alarm manager, since because they are published in the manifest, they are associated with an actual component, so the Intent you make can be explicitly targeted at that component rather than defining an ad-hoc action name.) > 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? The onReceive() function does run on the main thread, so you can't spend a lot of time in it. Currently, even if your main thread is not being asked to do other things like handle input events, if the receiver takes more than 10 seconds then the user will get an Application Not Responding dialog. So if you are going to do a longer- running (or asynchronous) thing, you will need to have that wrapped in a service. Of course networking stuff definitely falls in this category. > 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. The "Alarm Service" sample code in ApiDemos at http://code.google.com/android/samples/ApiDemos/src/com/google/android/samples/app/ is intended to provide the best practices for this. The current example is a little overly complex because of the need of the intermediate receiver. In a future SDK where you can have the alarm manager directly start a service, this is a lot cleaner. > 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. Yeah this would be a useful facility. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
