Sorry this is currently such a pain. First, don't use registerReceiver(). Having a service always running is a -huge- waste of resources. In fact this will probably be counter-productive, because as the system gets low on resource and starts struggling to see what it can free up, it will see your service having sitting there run for a long long time and start considering it a tempting candidate for the kill. (If nothing else, because long running processes often have leaks or just memory fragmentation in them, so killing them and letting them restart at some point in the future can free up memory even after they are running again.)
Yes you need to use a global variable for the wake lock. Gross, but it works. Please look at the ApiDemo for Service Start Arguments. This shows how a service can have work coming from multiple client via startService() and correctly manage its lifecycle to stop itself when it is done and there is no more incoming work. (The key is stopSelf(int id).) So your intent receiver can start the service, and your app can also do so. On Sat, Mar 28, 2009 at 9:17 AM, Mark Murphy <[email protected]>wrote: > > Mariano Kamp wrote: > > On Sat, Mar 28, 2009 at 4:37 PM, Mark Murphy <[email protected] > > <mailto:[email protected]>> wrote: > > > > Have you tried using setReferenceCounted(true) on the WakeLock? > > > > No, I didn't know about that. Sounds interesting. Thanks for the pointer. > > > > > > In the scenario you described: > > > > -- The activity tells the service, "yo! sync me!" > > > > -- The service acquires the reference-counted WakeLock (count now = > 1) > > > > -- The alarm goes off and starts the service > > > > -- The started service acquires the *same* reference-counted WakeLock > > (count now = 2) > > > > -- The work from the activity-initiated sync wraps up and releases > the > > WakeLock (count now = 1 and we are still locked) > > > > Acquiring the wake lock in the service might be ok in the real world, > > but conceptually this is too late. The OS could have put the phone to > > sleep between the alarm going off and the service acquiring the wake > lock. > > Ah, yeah, right -- the stuff I already have going. The BroadcastReceiver > needs to have access to the WakeLock. If this is a registerReceiver() > case, it can use the same object without resorting to a static data > member; otherwise, it'll still need one. > > I'm working on this stuff right now. > > Well, OK, not right now, since I'm typing this reply, but I'll be > working on it again as soon as I send this. Assuming, of course, that my > personal wake lock doesn't lapsZzzzzzzzzzzzzzzzzzzzzzzzzzzzzz... > > ;-) > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://twitter.com/commonsguy > > _The Busy Coder's Guide to Android Development_ Version 2.0 Available! > > > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
