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 visit http://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 -~----------~----~----~----~------~----~------~--~---
