Dianne and Mark, I just wanted to thank the both of you for your help on this. Your suggestions worked beautifully. My application has been running several hours on two different phones and it has not missed a scheduled event yet.
Just in case the two of you don't hear this enough, I for one, truly appreciate the both of you. Between all of Dianne and Mark's hard work on these groups and all of the work Mark has done with his "downloadable" sample code on commonsware.com (and Mark's book that I use regularly). Thanks to you both!!! On Mar 28, 2:46 pm, Mark Murphy <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
