Leigh McRae wrote: > So are you saying that onSaveInstanceState() is always called before the > system needs to kill an activity?
I am saying: 1. onSaveInstanceState() is always called before onStop(), as that is something both our docs references are in agreement upon 2. onStop() damn-near-always will be called before the process gets killed Ergo, by the transitive property of bullet points, onSaveInstanceState() damn-near-always will be be called before the process gets killed. The "damn-near" part is the phone's-screwed-up condition that I mentioned and really wouldn't worry about, any more than you worry about meteor strikes. :: briefly checks out office window :: See! Nothing to be afraid of! > If so that makes perfect sense and we > are done. Who-hoo! > Is there a way to artificially force this scenario to happen so I can > test my app survives? Which scenario? If you mean the process-gets-killed scenario, use a task killer. By the time you get to the task killer activity and kill your process, whatever activity of yours that was in the foreground will now be stopped. > The reason that this is such an issue is that > most games will do a one time loading of all it's resources upfront and > it's not to the users benefit if I am forced to dump this when it's not > required. So I want to get this right. Understood! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 2.0 Available! -- 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
