Note that some details of the lifecycle have changed, as described in the docs: http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
Specifically, if you target SDK 11 or later, then onSaveInstanceState() will be called before onStop() (not onPause()), and the activity's process is not killable until it is stopped. Also, something that I should make clear in the documentation, when the screen is turned off the foreground activity is stopped, not just paused. And as of JB it remains stopped until the user leaves the lock screen; prior to that it was resumed as soon as the screen turns on. Some answers to the specific quoted questions: On Jun 4, 10:20 am, DulcetTone <[email protected]> wrote: > > The Activity documentation does not clearly indicate the difference > > between an activity being paused versus being stopped. Is a paused > > activity one which has 1 or more pixels obscured by another, and a > > stopped activity one that has zero visible pixels? > An activity is stopped some time after it is no longer visible to the user. This is also the point where its window surface is removed, so it would be impossible for it to be seen on screen. (You should not, however, make any assumptions about the relationship between window state changes and activity state changes. They are run by different parts of the system, which do not try to synchronize with each other.) There is no strong guarantee about how soon after an activity is no longer visible that its onStop() will be called -- if the current foreground activity is taking a long time to go idle, for example, the stop of older activities will be delayed. > > I have never found just where the the interrelationships between > > finish() and state diagram paths toward pause/stop and the use of the > > back button or home button are detailed. > finish() isn't a state, it is a command to completely finish the activity. finish(): remove the activity from the activity stack, the user an no longer return to it. onDestroy(): this activity client-side instance is being destroyed for some reason. It may be due to it being finished (you can tell with isFinishing()), it may be due to a configuration change, or something else. Note that you can *not* rely on finding out if your activity has been finished by calling isFinishing() -- there are many situations where an activity gets finished but its client-side instance is no longer around to tell, so it just gets removed from the stack. That is why there is no onFinish() callback, it would not be possible to give useful guarantees about when it is called. > > There seems to be no direct means by which my app (or do I mean my > > task?) can know when one of its activities is active versus not. This > > has confused me for one and a half years (it matters when you make an > > app that has a voice user interface and want the recognition to be > > stopped when the user presses home, but not when he presses "back" on > > an activity that returns another of your app's activities to the > > fore). It gets worse in that starting a new activity does not deliver > > you an Activity instance immediately, making instance counting > > difficult. > One way you can approach this is by having singleton to keep track of your global behavior, and have each activity tell it when it is resumed and paused. Or, if you have a part of your UI that is so closely entwined, really do consider using fragments. > I have resisted using the manifest flags for "singletop" et al > > entirely, as several readings of their description have not conveyed a > > clear understanding. > singleTop just means that if you have activity A and B on your stack, and someone calls startActivity() in a way that would put another B on top of the existing B on your stack, then instead the current B's onNewIntent() will be called. -- Dianne Hackborn Android framework engineer [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
