See below:
12.03.2011 23:55, DulcetTone пишет:
1. The phrasing on the legs into and out of onPause() are vague.
Does "another activity comes in front of the activity" pertain to the
case where my activity is simply going away because finish() was
called?
It means just what it says - one case is another activity coming in
front of yours (from your application or not), not necessarily
completely occluding it.
Finish would cause it too - your activity is about to not be visible
(since it's going away).
Or the user switching away from your activity (Home key, status bar
notification, incoming call, etc.).
Putting it another way - onPause means the activity is about to lose its
front-most position.
Does "the activity is no longer visible" mean that my
activity is entirely concealed, and would this then differ from the
case where another activity appeared partially in front of my own?
Yes. It means complete occlusion in case another activity pops up in
front, or the user entirely switching away from your activity (Home key,
status bar notification, incoming call, etc.).
Partial occlusion ==> just onPause, without onStop.
2. what happens if you call finish() from within onCreate()?
onStart()? just about anywhere except the green "activity is running"
blob?
For onCreate, your activity will never appear on the screen, just the
transition effect that comes before the onCreate(). Haven't tried
calling finish from onStart.
3. How is onPause() -> onResume() different than onStop() ->
onRestart()? What circumstances differentiate the flow?
onStart / onResume depend on what happened before.
If onStop was called, you'll get onRestart/onStart and then onResume
when the user switches back.
If just onPause, you'll get onResume.
4. minor nits: the clarity of the chart is actually diminished by
having an exit from the "The process is killed" state, and some
mention as to whether the Activity object may be re-used should follow
the onDestroy() state
If the process is killed, the Java object obviously is lost as well.
However, if the user switches back to the activity, Android will
relaunch the process, create a new instance of your activity class, and
pass the previously saved state into onCreate as a bundle, so ideally,
the activity can restore itself without the user noticing.
The thing I am specifically trying to do is this:
I want to perform certain actions when the BACK or HOME keys are
pressed, and ignore cases where a third-party activity simply pops up
on part of the screen and then goes away.
If you find yourself needing this, perhaps you need a Service.
Not all phones are
traversing the lifecycle graph the same way, it seems, and since I do
not have one of every phone (Droids seem notoriously different),
They should, or it would be a major compatibility issue, as the activity
lifecycle is very, very fundamental.
Perhaps you are seeing varying amounts of time that your process is kept
around, due to variations in memory size, loaded applications, firmware
version.
writing test cases is not a viable means of educating myself. I'd
like some clarity on the designed behavior that can be vouched for.
I solemnly swear that the above is an honest and true description of my
understanding of this subject matter, and any possible mistakes are
unintentional.
-- Kostya
tone
--
Kostya Vasilyev -- http://kmansoft.wordpress.com
--
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
