On Tue, Mar 6, 2012 at 12:35 PM, Tom <t...@malcolmson.ca> wrote: > The service exists to receive screen state broadcasts even when the app > isn't running (receivers for screen state must be in code - they can't be > in the app's manifest)
Everlasting services, like you are trying to achieve, are an anti-pattern in Android. While you are correct that it is technically required to achieve your ends, IMHO that means your ends are flawed. What is magic about the screen being on or off? Android and/or the user will nuke your service eventually; depending on everlasting services is risky. > At > system startup it might exit immediately depending on user preferences. Consider disabling your BOOT_COMPLETED BroadcastReceiver if you will not be using it, via PackageManager and setComponentEnabledSetting(). This will speed up the boot process by not calling your logic if you do not intend to do anything. > For example, even if my app > verifies that the service is running it won't know whether it is running in > the same or in a different process. They better be in the same process. Using multiple processes simultaneously is another anti-pattern, except in fairly specific situations, and you have to go out of your way to cause them to be separate processes. > I'm putting it the state & logic in my Application class both because this > seems to be the 'normal' thing to do That's highly debatable. A custom Application is frequently indistinguishable from a simple singleton, and there can only be one Application class. > If the service or appWidget become active they will broadcast custom intents > to signal the application (and launch it if necessary). The tricky part is > that I need to ensure that the Application remains in memory until it has > completed the action requested by the service or appWidget. It will > probably take 10-30 seconds for the Application to process a request - > mostly waiting on intents or on network communications. Any logic you want to run should be in the service. The service is the marker to say "yo, I'm doing something here". As a marker, it works for a while, but not indefinitely. > It is my understanding that an application with no activities is a prime > candidate to be killed by the system Correct. > so I will bind it to the service to > keep it from being killed. When it finishes the requested processing it > will unbind so the system can kill it. It would be simpler for the logic that you want to have running in the background simply be in the service. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
