On Sun, May 1, 2011 at 8:19 AM, William Ferguson <william.ferguson.au@ gmail.com> wrote:
> And more specifically, under what scenarios do I get each of #onPause, > #onStop and #onDestroy called. > > For Activity destruction due to rotation? IN what versions. > For Activity destruction due to an explicit Activity#finished? What > versions. > Process death due to memory restriction? And for what versions. > > Just trying to best straighten this out in my head. > It really is not very complicated. The series of calls are: onCreate() -> onStart() -> onResume() -> onPause() -> onStop() -> onDestroy(). That is the order. Period. That is the core activity lifecycle. There are of course cycles between these: if your activity is resumed and another activity comes on top, it will be paused. If it then comes back on top, it is resumed. Likewise, it can be paused and then stopped, and later started and resumed. These are all just moving you between the states the activity can be in: on the top of the stack, not on the top, no longer visible. There is nothing special about rotation. The current activity needs to be destroyed, so it does the lifecycle callbacks to do that. A new one is created so it does the lifecycle callbacks. There is nothing special about being finished. The current activity needs to be destroyed, so it goes through the lifecycle callbacks. The *only* thing at all unusual about what Android does is its ability to kill processes. This also is very simple though: Android will call the activity's onSaveInstanceState() to save away the current state of the activity. By doing that, it is possible for it to kill the activity's process at any time and be able to later re-create a new activity instance from that last saved state. So once it has saved your state, your process can be killed. It sometimes seems people try to think too hard about this and make it something more complicated than it is. The callbacks tell you the states the activity goes in. It should be pretty easy to determine what makes sense to do in each callback, since they are pretty simple well-defined states. If you do that, you will be fine. There is certainly the interesting case of the process being killed. However the *only* thing that should matter about this for an application is to be sure to implement onSaveInstanceState() to save and restore the current state correctly, and to save any data to persistent storage that is needed prior to going into the killable state. (Which is after onPause() pre-3.0 and after onStop() if you target 3.0 or later.) If you were to compare this to something like MIDP: http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/MIDlet.html Android's activities are actually very similar; we have one additional state because we distinguish between the UI being visible vs. not visible at all. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
