Thanks hackbod, that clarifies things. But if I understand you correctly, that means that we can't use the Handler/MessageQueue mechanism if we want to make sure we don't lose messages. We instead have to implement our own version that uses persistent storage for the data store.
I guess I am surprised because the other parts of the architecture, like Activity, take pains to give us an occasion to save our data in a persistent way, and strongly suggest that we do so. Whereas the recommended Handler/MessageQueue examples (like ServiceStartArgs) are not safe in this way. Although Activity.onDestroy() might not be called before the Activity is killed, it seems that onPause() is guaranteed to be called (since the prior states say "Killable == No" in the documentation). So I wonder if we can't have a similar mechanism for Service to give it a chance to save persistent state, as well as a convenient way to save MessageQueues. Or perhaps an option to Handler to use the Preferences storage for its MessageQueue. What do you think? --~--~---------~--~----~------------~-------~--~----~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
