On Tuesday, December 15, 2009 11:52:32 PM UTC+1, Dianne Hackborn wrote: > > > > >> I'm surprised by that. When *does* onDestroy get >> called? > > > Because the kernel is killing the process to meet its memory demands. > Giving the process a chance to stop this would prevent the system from > being able to avoid bad paging states. > >
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. 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. 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 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. 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, just in case (I have no clue how long the next sleep will be). Have I missed anything, or is this really the way it's supposed to be? My case above can hardly be unique. :-) Best regards, Mikael Kuisma -- 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
