Mark, Thank you vey much for the detailed look. I will continue to tinker with it and see where I go.
Yes. I am passing the intent through parcelable (like a Trojan intent). Also thank you for clarifying the situation on the service being restarted. (I didnt spend cycles on it before. I will now) Thanks again Satya On Sun, Jun 6, 2010 at 6:41 AM, Mark Murphy <[email protected]> wrote: > 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 -- 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
