2011/3/12 Indicator Veritatis <mej1...@yahoo.com> > Actually, comparing with the text, I don't think it means "just what > is says". There is an asymmetry in the states, an asymmetry I believe > is deliberate, if poorly explained: that between onPause and onResume: > when you enter onPause, you may still be partially visible, but you > lose input focus. But when you enter onResume you must have both full > visibility and input focus. >
onResume() is called when you are becoming the top activity on the global activity stack. onPause() is called when you are going away from that state (prior to a different activity becoming the top). I'm not sure how this is asymmetrical? There are important implications about being the top activity -- for example you will have input focus over any other activities, your window will be on top of all other activities, etc. However there are some subtle aspects of this. In particular, being the top activity does *not* guarantee being input focus; input focus is based on windows, and there are a number of Android UI elements that are implemented as pure windows. This includes the lock screen, and notification shade. When one of these elements is shown, the top activity's window will lose input focus for that time. There are really three important pairs to the activity lifecycle: onCreate() / onDestroy() onStart() / onStop() onResume() / onPause() Any resources you create in the first of the pair should generally be released in the matching one. For example, if you use registerReceiver() in onCreate(), you should generally call unregisterReceiver() then in onDestroy(). These pairs represent symmetric major states of an activity: onCreate() is when it is first created, onDestroy() is when it is last being cleaned up; onStart() is when it is becoming visible, onStop() is when it is no longer going to be visible to the user. And we already talked about onResume() and onPause(). > > Finish would cause it too - your activity is about to not be visible > > (since it's going away). > Cause what, too? > It causes your activity to go through onPause() and onStop() (if needed) since it is no longer going to be visible to the user, and then onDestroy() since the activity instance is being destroyed. > But what does "front-most position" really mean? That is what confuses > many, not just the OP when reading the online documentation about the > Activity lifecycle. My best attempt at reading the mind of the online > doc's author is that "front-most position" means not only 1) being > fully visible, most likely completely covering up all other > Activities, but also 2) capturing input focus from all input devices: > touch screen, keyboard... > It really just means top of the activity stack, and since the windows created by activities are Z-ordered in the window manager based on that stack, its windows are on top, bringing along all of the repercussions of that both visually and for input focus. > > > 3. How is onPause() -> onResume() different than onStop() -> > > > onRestart()? What circumstances differentiate the flow? > > onStart / onResume depend on what happened before. > In what way do they depend? Isn't it just a matter of onPause() -> > onResume() being as the documentation says, the foreground lifetime of > the Activity has started? While onStop() -> onRestart() is quite > different? > I would ignore onRestart(). It is useful for some semi-common situations we saw during app developer, where one wants to do some work when being started but not duplicate stuff that was already done in onCreate(). For the basics of the activity lifecycle, though, the 3 pairs are the important things to understand. > I actually did work on a project where they somehow defeated the > normal behavior of the home key -- and I hated that feature. I am sure > most users feel the same way. > Generally we consider this a security hole and fix this. The current platform has closed all the holes I know of; if there are new ways people have found to prevent the home key from working correctly, I would love to get a hold of the app to fix it. :) -- 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
