Interesting summary, but I don't think it addresses ALL the OP's legitimate concerns, hence my own questions/comments below:
On Mar 12, 1:49 pm, Kostya Vasilyev <kmans...@gmail.com> wrote: > 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. 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. > > Finish would cause it too - your activity is about to not be visible > (since it's going away). Cause what, too? > > 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. 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... > > 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. 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? Recall the docs read: "the foreground lifetime of an activity happens between the call to onResume() and the call to onPause(). During this time, the activity is in front of all other activities on screen and has user input focus. " > 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. Why a Service? Services are meant for either 1) long-running operations in the background, operations that do not need UI or 2) exposing this component's functionality to other components, using IBinder if the latter are in other applications. Nothing the OP has said suggests either need. He certainly needs UI, and has suggested nothing about communicating with other application components. Shouldn't he just go ahead and override all the callbacks? Not that there is anything he can do about the Home key -- nor should there be. The user really does want Home to work as it always does in all other applications. 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. > > 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. An oath he should take seriously. Let's hope he hasn't heard the famous Turgenev quote, "каждый Русский -- неисправаемый лгун";) -- 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
