that's beautiful, Diane! The matched-pair thing exactly what I was
wanting to confirm - logcat messages are making a little more sense.
Here's a summary as I understand it pulled from your interleaved
response - let me know if I'm missing something.
Matching pairs of events for an activity
Any resources you create in the first of the pair should generally be
released in the matching one.
* onCreate() / onDestroy()
- onCreate() is when it is first created
- onDestroy() is when it is last being cleaned up
* onStart() / onStop()
- onStart() is when it is becoming visible
- onStop() is when it is no longer going to be visible to the user
* onResume() / onPause()
- onResume() called when you are becoming the top activity on the
global activity stack
- onPause() called when you are going away from that state (prior to a
different activity becoming the top)
And...
"I would ignore onRestart()For the basics of the activity
lifecycle, though, the 3 pairs are the important things to understand.
"
On Mar 13, 4:42 am, Dianne Hackborn wrote:
> 2011/3/12 Indicator Veritatis
>
> > 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
