[android-developers] Re: Activity lifecycle... still a mystery to me
The only 'correction' needed, Roger, is that "backing out" is the wrong term. When Activity A 'calls' Activity B (really, sending an Intent), no "backing out" takes place. "Backing out" is a much more appropriate term for what happens when the user presses the Back key, which causes finish() to be called. This in turn results in onDestroy() being called. See http://developer.android.com/reference/android/app/Activity.html#onDestroy() to see how the documentation words the same thing I just said above (and see that I am not making things up). See also the description of onBackPressed(), which confirms that finish() is called. On Mar 19, 11:39 pm, Roger Podacter wrote: > No because I don't believe onDestroy would necessarily get called > backing out of the activity. Only onPause would be guaranteed to be > called. That activity's onDestrw would only get called at some random > point in the future when the OS wants more memory. > > OnPause is the primary. At least that is my understanding. I hope > someone corrects me. > > On Mar 19, 3:37 pm, lbendlin wrote: > > > If one activity calls another, and when you then press "Back" from that > > activity, wouldn't the calling of onDestroy() assure you that the called > > activity is truly gone and the memory is freed? (Or conversely, if it isn't > > called, the activity may live on due to dangling references?) -- 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
Re: [android-developers] Re: Activity lifecycle... still a mystery to me
On Mon, Mar 14, 2011 at 3:25 PM, Indicator Veritatis wrote: > But (and you knew there was a 'but' coming), even this leaves > important questions unanswered. In particular, what does it mean to > "have input focus over any other activities"? You imply elsewhere that > it does NOT mean unconditional possession of focus, you imply it has > something to do with windows, but exactly what it does mean is not > stated here nor (anywhere I could find) in the original online docs. > Windows are in Z order. The top-most window in Z order that wants input focus gets it. The window manager implements a simple policy for Z ordering. The parts of interest here are: 1. All windows associated with activities at the bottom, ordered by the global activity stack. 2. Toasts (which can't get input focus). 3. Status bar elements. 4. System dialogs (like crash / ANR dialogs). 5. Lock screen and its UI elements. Thus if your activity is resumed, it is at the top of the stack, and if it asks for input focus it will take it from all other activities since those are below it. However windows can still be on top of it, which can take input focus away from it. (Sorry about being slow on this, I have been having trouble with my account.) -- Dianne Hackborn Android framework engineer hack...@android.com 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 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
Re: [android-developers] Re: Activity lifecycle... still a mystery to me
On Mon, Mar 21, 2011 at 10:59 PM, DulcetTone wrote: > My app responds to speech commands. > > I want the behavior to be that > > 1. if back is hit on my initial activity, it exits. That is normal behavior. > 2. My app has a few sub-activities it may launch on user speech- or > GUI input > 3. if home is hit on ANY of my activities, I want all of them to > finish. Again, I ask: why? > Why I want this is uninteresting... Then don't expect much help. I'm not asking "why" because I expect the reason to be interesting, I am asking "why" because you are clearly confused, so I am trying to get to the real problem here. > few users of the app would find > the desired behavior anything other than the one they'd want. That's conceivable, but unlikely, since your users probably want your app to behave like all their other apps. What do you think the difference is between: "if home is hit on ANY of my activities, I want all of them to finish" and: "if home is hit on ANY of my activities, the home screen should appear" since the latter is the standard behavior? The home screen will appear in either case. Clearly, you think that there is some difference. We need to know what the behavior difference is that you are expecting, so we can guide you on how to achieve it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.5 Available! -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
yes all things you specified could be done write overwrite back button code for 1 2 not clear 3 ok write overwrite onstop ,onpause,on resume On Mar 22, 7:59 am, DulcetTone wrote: > My app responds to speech commands. > > I want the behavior to be that > > 1. if back is hit on my initial activity, it exits. > 2. My app has a few sub-activities it may launch on user speech- or > GUI input > 3. if home is hit on ANY of my activities, I want all of them to > finish. > > That's basically it. > Why I want this is uninteresting... few users of the app would find > the desired behavior anything other than the one they'd want. > > It's possible that I could get some of this to happen by use of the > activity flags/modes (single-top, etc), but their documentation also > reads like Sanskrit after 10 reads through. > > tone -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
My app responds to speech commands. I want the behavior to be that 1. if back is hit on my initial activity, it exits. 2. My app has a few sub-activities it may launch on user speech- or GUI input 3. if home is hit on ANY of my activities, I want all of them to finish. That's basically it. Why I want this is uninteresting... few users of the app would find the desired behavior anything other than the one they'd want. It's possible that I could get some of this to happen by use of the activity flags/modes (single-top, etc), but their documentation also reads like Sanskrit after 10 reads through. tone -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
No because I don't believe onDestroy would necessarily get called backing out of the activity. Only onPause would be guaranteed to be called. That activity's onDestrw would only get called at some random point in the future when the OS wants more memory. OnPause is the primary. At least that is my understanding. I hope someone corrects me. On Mar 19, 3:37 pm, lbendlin wrote: > If one activity calls another, and when you then press "Back" from that > activity, wouldn't the calling of onDestroy() assure you that the called > activity is truly gone and the memory is freed? (Or conversely, if it isn't > called, the activity may live on due to dangling references?) -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
If one activity calls another, and when you then press "Back" from that activity, wouldn't the calling of onDestroy() assure you that the called activity is truly gone and the memory is freed? (Or conversely, if it isn't called, the activity may live on due to dangling references?) -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
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
[android-developers] Re: Activity lifecycle... still a mystery to me
Thanks, Dianne, for this very valuable supplement to the mysterious documentation on the Activity lifecycle! But (and you knew there was a 'but' coming), even this leaves important questions unanswered. In particular, what does it mean to "have input focus over any other activities"? You imply elsewhere that it does NOT mean unconditional possession of focus, you imply it has something to do with windows, but exactly what it does mean is not stated here nor (anywhere I could find) in the original online docs. Or did you mean to imply that the ONLY time the Activity on the top of the activity task loses input focus is when it is shadowed by one of those "Android UI elements that are implemented as pure windows"? On Mar 13, 12: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 that feature. I am sure > > most users feel the same way. > > Generally we consider this a security hole and fix this. The current > platform has closed all the holes I know of; if there are new ways people > have found to prevent the home key from working correctly, I would love to > ge
Re: [android-developers] Re: Activity lifecycle... still a mystery to me
13.03.2011 10:29, Indicator Veritatis пишет: > > 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. Because he's trying to determine when the user "really" leaves his activity vs. when it's temporarily occluded. This is most likely to either continue or stop doing something. I'm speculating, but it seems likely. An oath he should take seriously. He asked for a response that could be "vouched for" - and since I can't sign in blood using email, that was the best I could do :) Let's hope he hasn't heard the famous Turgenev quote, "каждый Русский -- неисправаемый лгун";) Turgenev was Russian, too, so that's just like "All Cretans are liars" :) -- 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
Re: [android-developers] Re: Activity lifecycle... still a mystery to me
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 that feature. I am sure > most users feel the same way. > Generally we consider this a security hole and fix this. The current platform has closed all the holes I know of; if there are new ways people have found to prevent the home key from working correctly, I would love to get a hold of the app to fix it. :) -- Dianne Hackborn Android framework engineer hack...@android.com 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 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
[android-developers] Re: Activity lifecycle... still a mystery to me
As you say, onPause() and onResume() are by far the most commonly called. But if you run your app on a G1, and run it with other apps, you will see onStop() and onDestroy() called. You should also see onDestroy() called whenever the user presses the Back button, which calls finish(); but when finish() is called, the system calls onDestroy() See eveloper.android.com/guide/topics/testing/testing_android.html, which says, inter alia: "If the Activity code calls the *finish*() method, the * onDestroy*() method is called ." -- 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
[android-developers] Re: Activity lifecycle... still a mystery to me
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 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
[android-developers] Re: Activity lifecycle... still a mystery to me
I recently wrote my first android app, and I too did not grasp the life cycle functions and they just didn't seem to work correctly, or the way I thought they should based on the graph. Here's my learned knowledge from writing my app. OnPause and onResume turned out to be by far and above the only functions that are used and needed, at least for me. At first I was trying to add in all the functions and never saw onStop or onStart called, ever. So I press back or home, and onPause is the first to get called, ALWAYS, no matter what for me. And going right back to my app, OnResume is the one that gets called, ALWAYS, no matter what. My app is simple so I had no need for saved state stuff, but I experimented with it anyway putting it in my OnCreate and saved instance state, just to see it work. OnDestroy I never used, never seen it called, and I believe its only needed if the OS closes it for more memory. And this condition virtually never happens from my testing, so its almost not even needed in a way. I later added a service to my app, and that's where I then used onStart and onStop. They didn't turn out to be used or needed in an activity, only a service. That's about it unless you want more details of my experience. Pause and resume are the ones to use unless you have very complex conditions happening in your app. On Mar 12, 12:55 pm, DulcetTone wrote: > I find the flowchart of Activity lifecycle pretty ambiguous. In a > perfect world, it would receive a little more work to resolve the > gray, but I'll throw out some example issues. > > 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? 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? > > 2. what happens if you call finish() from within onCreate()? > onStart()? just about anywhere except the green "activity is running" > blob? > > 3. How is onPause() -> onResume() different than onStop() -> > onRestart()? What circumstances differentiate the flow? > > 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 > > 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. 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), > 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. > > tone -- 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
