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 hack...@android.com wrote:
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
