What I find truly bizarre is that I was just thinking about trying to simplify the invocation of WakefulIntentService, about 20 minutes ago, before opening this email message.
If you are inside my head, can I hire you to do a bit of cleaning while you are in there? :-) Satya Komatineni wrote: > 1. Make the whole thing look like just a broad cast receiver and hide > the service as much as possible with only one method exposed The problem here is that there are some system-provided BroadcastReceiver classes (e.g., AppWidgetProvider), and Java does not support mixins. Having ALongRunningReceiver is fine, but you also need an access path that does not assume the developer can extend ALongRunningReceiver every time. > 2. Pass along the broadcast intent all the way to the receiving > service method as if the service method is getting the broadcast > intent. Cool concept. Are you just passing this as a Parcelable extra on the Intent used to start the service? > 3. I have also taken a very slightly different approach to holding and > releasing the locks with an extra release from the "onDestroy" of the > service just in case (although unlikely) if the start and stop > services don't coincide due to exceptions or errors in code As was recently discussed on [cw-android], there is also the reverse scenario. If the service is killed by the system while it is running (e.g., low memory), Android will start up the service again with the same Intent...but it will not have acquired the WakeLock. Then, when you release the WakeLock, it crashes with an under-locked exception. I committed code to WakefulIntentService a few days ago that addresses this scenario as best I can, by making sure that the WakeLock is acquired inside the service, almost like an assertion, early in onStart(). This is not a perfect solution, but it is the best I can come up with. BTW, to truly fully release the WakeLock in onDestroy() like you describe, you might have to make it setReferenceCounted(false) before calling release(). Otherwise, it may still be locked if, for whatever reason, multiple acquire() calls got leaked. I have not tried modifying setReferenceCounted() on an acquire()'d WakeLock. > I am hesitant and suspect that this may be a fishy thought. Not at all. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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
