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/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. > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
