It is not an issue I am aware of. That facility is used extensively by our own apps, and I don't know of them having a problem with it.
On Jul 15, 3:01 am, "Jaikishan Jalan" <[EMAIL PROTECTED]> wrote: > Hello, > > As I mentioned in my last email about the random behavior of my application, > I have observed that my application many times does not receive > BOOT_COMPLETED action. Due to this my background process does not get > started. Is this a known bug that it is not definite that your > intentreceiver (listening to BOOT_COMPLETED) will not get executed everytime > when you launch the emulator? I have verified this by simply printing a log > message. Sometimes the message is logged ( when my application receive the > intent ) and many times it does not. Can anyone from Google Android team > confirm this? > > > > On Tue, Jul 15, 2008 at 3:21 PM, hackbod <[EMAIL PROTECTED]> wrote: > > > 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/androi... > > 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. > > -- > Thanks, > Jaikishan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
