Leigh McRae wrote: > Looks like it says both :) Still whether it's before onPause() or > onStop() doesn't matter much. > > "To capture that state before the activity is killed, you can implement > an ||onSaveInstanceState() > <http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState%28android.os.Bundle%29>|| > method for the activity. Android calls this method before making the > activity vulnerable to being destroyed — that is, before |onPause()| is > called. " > > http://developer.android.com/guide/topics/fundamentals.html#lcycles
:: sigh :: I still wouldn't count on it happening before onPause(). Meantime, I've filed a bug: http://code.google.com/p/android/issues/detail?id=8900 > For the BACK button that is trivial and very clear. What happens I > launch the browser from my app and it covers my app as in my example. I > would go through onPause() and onStop(). Both docs say that > onSaveInstanceState() would have been called by now but the system > doesn't know if it will run out of memory at some point with the > browser. It doesn't care whether "it will run out of memory at some point with the browser", any more than Microsoft Word, saving a temp file of your in-progress edits, cares whether or not Windows will run out of pagefile space. Word saves the temp file because that's what Word does, to deal with any number of scenarios, such as Word simply crashing. Similarly, Android will call onSaveInstanceState() so that if it kills the process, or continues sometime to onDestroy(), that you will have had a chance to save your instance state. >> Correct. Unlikely, but correct. >> > If it can happen it needs to be handled. Not necessarily. I suspect the vast majority of apps aren't specifically worrying about it, mostly because nothing much needs to be done for them for that scenario. >>> 4) Since the system has enough memory onSaveInstance() doesn't get >>> called. >>> >> I have no idea where you came up with this. >> >> I would expect onSaveInstanceState() to have been called in this >> scenario, before onStop(), and around the time of onPause(). >> > It's been inferred since the system has no way of knowing for SURE if it > will have to kill the activity, at which time I have already been put in > the background and received onStop(). Now for the trivial case where the > system starts another activity and needs more memory it makes sense. Like I said, you will have received a call to onSaveInstanceState() in and around the times of your onPause()/onStop() calls. If you have evidence to the contrary, I'm certainly interested to see it. As your documentation counter-example demonstrates, it's not like we can necessarily count on the docs. The 99.44% pattern for your use case is: -- The activity receives onPause() and onSaveInstanceState(), in some order -- The activity receives onStop() -- Time elapses (seconds, weeks, whatever) -- The activity receives onDestroy() The next-most-common pattern is: -- The activity receives onPause() and onSaveInstanceState(), in some order -- The activity receives onStop() -- Time elapses (seconds, weeks, whatever) -- The process is killed, either by Android (low memory) or by the user (task killer) While in principle the process could be killed before onStop(), if that happens, the user has much bigger problems than your app not correctly cleaning up. After all, this means that the device's memory is screwed up so bad that Android feels it needs to kill the process *immediately* upon it losing the foreground, before it can get to onStop(). The user's phone is going to need a reboot, plain and simple. The user can't readily invoke a task-killer before onStop() gets called, because to get to the task-killer activity to pick your process, you'll wind up being called with onStop(). If you have concrete evidence that the scenarios I list above ain't happenin' for you, please let me know! -- 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
