On Thu, Aug 11, 2011 at 6:58 AM, Mikael Kuisma <kui...@ping.se> wrote: > As far as I have been able to see, onDestroy() is only called when the > service is removed from the DVM, never when the DVM itself is about to be > terminated.
More specifically, if the service is destroyed (e.g., via stopService() or stopSelf()), onDestroy() will be called. If the process is being terminated outright, onDestroy() is not called. > Is this really a good design strategy? I have a service I'd like to behave > like this: > > working, sleeping > working, sleeping > working, sleeping > onDestroy, saving state, terminates. Please don't write services that way. Use AlarmManager and an IntentService, so the "sleeping" does not need your service (and process) tying up RAM. > But with no reliable way of detecting a forthcoming termination (e.g. > onDestory(), addShutDownHook(), finalize()), I instead have to implement: > > working, saving, sleeping > working, saving, sleeping > working, saving, sleeping > terminated More accurately, it should be: working, saving, shutting down, terminated working, saving, shutting down, terminated working, saving, shutting down, terminated working, saving, shutting down, terminated > The only purpose of my service between work, is to keep the state, and it > may happily be terminated, given I can save the state before it dies. Then your service should not be in memory to keep the state. You are wasting RAM and harming the user. Services like yours are why there are task killers, the Running Services portion of Settings, etc. > The > solution above I'm instead forced to implement, is quite expensive due to > the fact the work/sleep cycle may vary from seconds to hours. I don't like > to exercise the flash each tenth seconds Users don't like sloppy developers who keep services in RAM for no good reason. Guess what? Users win. > (I have no clue how long the next sleep will be). You have to know "how long the next sleep will be", by definition. After all, you have to tell Android when to resume operation of your code, regardless of how you accomplish it (AlarmManager, Thread.sleep(), postDelayed(), etc.). > Have I missed anything, or is this really the way it's supposed to be? My > case above can hardly be unique. :-) Use AlarmManager, please. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in Oslo: http://bit.ly/fjBo24 -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
