Hi, Great thread, one of the best I've read here in a long time.
A few related questions - (1) Is it recommended that a Service which runs for more than a few seconds always use a wake lock in an attempt to ensure it completes ? My limited tests on a G1 seem to show that a Service that runs for a few minutes ( up to about 5 minutes ) does not seem to need a wake lock as the phone stays awake at least until the service is completed. I have not tried forcing the issue by turning the phone off during the Service running. (2) Where a Service is killed by the system in a low memory situation and possibly restarted, is the Services onDestroy() method always called by the system or is the Service just killed ? If the system then restarts the Service is onStart() called again with any of the original pending Intents or is only onCreate() called and the Service is then responsible for working out what work is still outstanding based on what it has previously stored about those intents from persistent storage ? And do these behaviors vary according to whether the Service runs in the same process as an Activity, or in its own separate process ? ( I am mainly asking about a Service which runs in its own process ) (3) Should the threads running in a service always be niced down or will the system eventually do this automatically ? This was mentioned here http://groups.google.com/group/android-developers/browse_thread/thread/1952712754139019/bd8eb716be2d4915 Thanks Regards On Mar 29, 6:46 am, Mark Murphy <mmur...@commonsware.com> wrote: > Dianne Hackborn wrote: > > Yes you need to use a global variable for the wake lock. Gross, but it > > works. > > OK, here's a cut at a sample app: > > http://groups.google.com/group/cw-android/web/Alarm.zip > > [NOTE: If you found this message in the archives and are reading it > after June 1, 2009, please visithttp://commonsware.com/AdvAndroid/and > download the source code from the link provided there, as the code > probably has changed] > > It needs more testing, particularly for Mr. Kamp's scenario, but I think > it has a chance of holding up. Note that if you try building it, adjust > default.properties to reflect your SDK location, and you'll need an SD > card (or card image in the emulator). > > The goal behind this example is to demonstrate what a lot of people have > been requesting: cron-style functionality. Meaning, a scheduler should > trigger their code on a fixed interval, including from the point when > the device boots, and should cause the code to run even if the device is > otherwise asleep. It also attempts to handle Mr. Kamp's scenario where > the same logic might also be invoked beyond just the scheduler, and > where the logic might sometimes run longer than the alarm period. > > When installed, it will set up a RECEIVE_BOOT_COMPLETED > BroadcastReceiver, which in turn will set up an AlarmManager > ELAPSED_REALTIME_WAKEUP alarm set to recur at five minute intervals. > > The app's "purpose" is to add an entry to a running log file on the SD > card (placed there for simplicity when testing on a device). > > The actual work to log the data to the file is done by a > WakeWorkManager. This class manages a background thread for a service > with automatic WakeLock management for background work. It wraps a > LinkedBlockingQueue and, so long as there is work in the queue, keeps a > partial WakeLock. This allows the service (and the BroadcastReceiver > that starts the service upon an alarm) to "fire and forget" -- work will > get done and the service will stop when everything is done, with a > WakeLock ensuring the device will run only as long as is needed. > > The service/BroadcastReceiver pair needs a second WakeLock to ensure > that everything stays awake long enough to pop the work into the work > manager. However, this second WakeLock is then released (the "forget" > part of "fire and forget"). This second WakeLock is a static data member > on the service class, which, as Ms. Hackborn indicates, seems > unavoidable in the current Android SDK. C'est la vie. > > Right now, the WakeWorkManager uses only a single background thread. If > jobs will routinely take longer than the alarm period (e.g., slow data > transfer), you'll probably want more than one thread. Implementation of > this is left as an exercise for the reader. > > I am definitely up for comments, particularly if you see that I am > screwing up WakeLocks or whatnot. Either reply on this thread or join > the cw-android Google Group and chime in there. > > Thanks to all who contributed ideas and insights, on this thread (e.g., > Ms. Hackborn, Mr. Kamp) and on past threads (e.g., Jon Culverson). > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
