There is one more thing I'd like to add that I think you haven't covered yet ... and probably don't need to, but I want you to be aware of that. I have an app that synchronizes with Google Reader every hour (alarm) and also the user can run a sync manually. So both need the background service to run and as I need to keep partial wake locks end-to-end in both cases I need to instantiate a wake lock and pass it to the service. In comparison this adds the possibility that the service is started when it is already running. As an example: You press a sync button that triggers the service by calling start, passing a freshly acquired wake lock to the service. This service keeps running for a couple of minutes until it is done syncing and then calls stopSelf(). During that time the alarm kicks in, the broad cast receiver acquires another wake lock and passes it to the service and starts it. Now you would have two active wake locks and actually when using a naive approach to a static variable you would have overwritten the old wake lock, which would lead to the old lock not being releases which would lead to the phone not shutting down.
Does that make sense? The short story is, passing in a wake lock using a naive approach of a static variable doesn't work when the service can be started again during its runtime. You would need to have some code around it (passInWakeLock()), that would understand that there is an active wake lock already and discard (and release) the newly passed in wake lock. In practice I haven't seen a problem with the time between the end of the broad cast receiver and the starting of the service. Cheers, Mariano On Sat, Mar 28, 2009 at 12:48 PM, Mark Murphy <[email protected]>wrote: > > Mariano Kamp wrote: > > I use a static member for that and it makes my eyes bleed. > > Umm...hmm...well...er... > > If you want your service to completely go away between alarms, you need > your BroadcastReceiver to be registered via the manifest, rather than > tied into the system via registerReceiver() in the service. The latter > approach would likely keep the Service referenced and kept from being > garbage collected. > > Given that, we now need to allocate a WakeLock in a BroadcastReceiver > and get it over to a newly-minted Service. WakeLock is not Parcelable. > Hence, I see no way to get the WakeLock to the Service except through > some static data member, somewhere. Whether that is a member on the > Service, on the BroadcastReceiver, or in some third class is an > implementation detail. > > On the other hand, using registerReceiver() would allow you to keep the > WakeLock in the Service object without the static data member. It's a > trade-off -- if your alarm will fire frequently enough, it might be > better to keep the Service around rather than reallocating it all the > time. If your alarm is rather infrequent, though, I'd think it would be > better to let the Service go away and get reallocated when the alarm fires. > > I'll be writing up the infrequent-alarm case (even though my sample code > will probably have the alarm going off every 5 minutes or so, just to > provide more rapid feedback to those playing with the code). > > The good news, though, is that Ms. Hackborn's technique works great -- > haven't missed an alarm in 12 hours (every 5 minutes), and the device > definitely has been asleep between alarms, given the battery level. > > > And > > it makes it harder to handle cases where start is called more than once. > > That problem can be dealt with, despite the static data member. Though > I'll need to beef up my sample some for this scenario -- I was thinking > the service would be long since wrapped up before the next alarm fired. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
