On Sun, 2010-06-06 at 18:18 -0700, Leigh McRae wrote: > I am having a really hard time grokking the Activity life cycle > concept. The main issue is with onStop() and onDestory() not being > guaranteed to be called before the process is killed. I though I had > it figured out when I saw that the system calls onSaveInstanceState() > when it's shutting down the activity to claim some memory. Thing is > that the docs says onSaveInstanceState() will be called before > onPause() but how does the system know at this point whether the > activity will be killed by the system or the user? > > Here is a use case: > > 1) My activity starts up and is running. > 2) At some point I want to show a web page so I use an Intent to start > an activity. > 3) The web browser covers my app/activity so I would expect onPause() > to be called followed by onStop(). > > At this point it's my understanding that all bets are off and I can be > killed at any point without be called. > > 4) Since the system has enough memory onSaveInstance() doesn't get > called. > 5) The user presses home and decides to open some app which requires a > lot of memory. > 6) System wants more memory and decides to kill my app but I am > already stopped (onPause() has been called). What happens here? > > I am finding this a really serious problem since onPause() pretty much > needs to be treated as onDestory() as far as I can tell. If my app has > to be able to survive being killed without onStop() and onDestory() > being called, why bother having them?
From http://developer.android.com/guide/topics/fundamentals.html#actlife under the heading "Saving Activity State", we find "Unlike onPause() and the other methods discussed earlier, onSaveInstanceState() and onRestoreInstanceState() are not lifecycle methods. They are not always called. For example, Android calls onSaveInstanceState() before the activity becomes vulnerable to being destroyed by the system, but does not bother calling it when the instance is actually being destroyed by a user action (such as pressing the BACK key). In that case, the user won't expect to return to the activity, so there's no reason to save its state. "Because onSaveInstanceState() is not always called, you should use it only to record the transient state of the activity, not to store persistent data. Use onPause() for that purpose instead." So the way I understand it is that onSaveInstanceState() is called whenever the *system* is putting the activity into a "killable" state, thus allowing you to save the current state for it to be reloaded when your activity is loaded again, but if the activity is being destroyed by a user action, (where there is no expectation of an unchanged state) if you want to save any state, you need to do it yourself in onPause(). So in your use case onSaveInstanceState() *will* be called, and the state can be saved, so 4) is completely incorrect. Feel free to correct me if I am wrong Hope that helps Dan -- 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
