If you are following this thread you can find the initial implementation at the following project download url.
http://www.satyakomatineni.com/akc/filestorage/satya/documentfiles/3468/StandaloneBroadcastReceiver.zip You can see the key source code from this project at http://www.satyakomatineni.com/akc/display?url=DisplayNoteIMPURL&reportId=3515&ownerUserId=satya You can use the following project to kick off the broadcast above http://www.satyakomatineni.com/akc/filestorage/satya/documentfiles/3468/TestBroadcastReceiver.zip The basic research I have done on long running services is at http://www.satyakomatineni.com/akc/display?url=DisplayNoteIMPURL&reportId=3514&ownerUserId=satya Caution: I have barely tested this. Use it at your own risk. On Tue, Jun 8, 2010 at 9:39 AM, Satya Komatineni <[email protected]> wrote: > 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
