[android-developers] Re: Activity Lifecycle Documentation Question
Yes! Having mostly lurked over this list for the last year and half, I see this thread come-up too frequently, and this area caused me a lot of confusion. I don't want to change the thread, but want to emphasize that to make intelligent suggestions, one has to understand the process. These questions actually seem to arise more from people with a lot of experience to other programming environments and lacking in Java depth rather than plain beginners and I think it is because developers are fearful of making assumptions to fill in documentation holes/conflicts because they KNOW that is where things can will break. The whole scenario was even muddier for me because I had constant questions in my mind as to the relationship of things like Java static initializers to these life-cycle Objects (I knew neither the framework (or similar frameworks and was new to Java (still feel like a newbie)) - for instance when the process is killed but the system decides to keep the Activitiy around, does the framework re-do static initialization of the Objects if it re-uses the killed activity? Since the document doesn't say, the developer has to black-box, then if the framework is every changed, unless you programmed defensively (assume statics are not repeated) your application may break. Clearer documentation would help a little (for those that read it :-), saving Dianne, Mark, and all the rest of you very generous contributors (thank you!) time for other replies. I can rock with documentation issues in most areas (I can always go peek at the source), but activity life-cycle is the back-bone of every application design; it deserves to be held to a higher standard, and end-consumer developers need a high degree of confidence that the process is accurately documented without having to look at the source -- to me, the documentation should be a contract between the framework developers and the framework users (programmatically)... thanks for all the replies and the people that are persistent in their pursuit of definitive answers. On Apr 28, 1:50 pm, Indicator Veritatis mej1...@yahoo.com wrote: Eric is not the first to observe that the documentation on these topics is too confusing. But where should he make this 'contribution' you suggest? Is the documentation somewhere under the Android Open Source project athttp://source.android.com/? On Apr 27, 10:23 pm, Dianne Hackborn hack...@android.com wrote: Yes if you call finish() you are saying you want to completely remove the activity from the stack. The system can have the activity destroyed in the same way, but just not remove it from the stack it maintains. At the end of the day, it would be fundamentally broken if there was a way for an activity to stop being used in a process without being destroyed. This means it would be IMPOSSIBLE to write a correctly working application. I agree you can find parts of the documentation to help you convince yourself that there are cases this can happen, if that is what you are looking for. But it won't. Because it would be broken. As I think is already obvious to you, since your original question was basically: if I read the documentation this way then there is nothing useful at all about onDestroy() or onStop() because they won't get called when they need to be. Right. So don't try to read the documentation in a way that makes it broken. You are welcome to contribute changed to the documentation for people to review if there are things you think can be improved. On Thu, Apr 28, 2011 at 12:29 AM, Eric e...@alum.mit.edu wrote: On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If
[android-developers] Re: Activity Lifecycle Documentation Question
Dianne, just a clarification on this thread. In the diagram of the Activity lifecyle at http://developer.android.com/reference/android/app/Activity.html Should the directed edge on the left hand side from #onStop to #onCreate actually be between #onDestroy and #onCreate? And is that behaviour just from 3.0 onwards? If not, what is the behavior for earlier versions of Android. William -- 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 Documentation Question
And more specifically, under what scenarios do I get each of #onPause, #onStop and #onDestroy called. For Activity destruction due to rotation? IN what versions. For Activity destruction due to an explicit Activity#finished? What versions. Process death due to memory restriction? And for what versions. Just trying to best straighten this out in my head. William -- 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 Documentation Question
On Sun, May 1, 2011 at 8:15 AM, William Ferguson william.ferguson.au@ gmail.com wrote: Dianne, just a clarification on this thread. In the diagram of the Activity lifecyle at http://developer.android.com/reference/android/app/Activity.html Should the directed edge on the left hand side from #onStop to #onCreate actually be between #onDestroy and #onCreate? And is that behaviour just from 3.0 onwards? If not, what is the behavior for earlier versions of Android. No that is fine. In Android 3.0, ignore the line from onPause() to onCreate() if you are setting android:targetSdkVersion=11 or greater; that is the change the doc mentions, the system will now try to avoid killing processes that have activities that haven't been stopped. -- 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 Documentation Question
On Sun, May 1, 2011 at 8:19 AM, William Ferguson william.ferguson.au@ gmail.com wrote: And more specifically, under what scenarios do I get each of #onPause, #onStop and #onDestroy called. For Activity destruction due to rotation? IN what versions. For Activity destruction due to an explicit Activity#finished? What versions. Process death due to memory restriction? And for what versions. Just trying to best straighten this out in my head. It really is not very complicated. The series of calls are: onCreate() - onStart() - onResume() - onPause() - onStop() - onDestroy(). That is the order. Period. That is the core activity lifecycle. There are of course cycles between these: if your activity is resumed and another activity comes on top, it will be paused. If it then comes back on top, it is resumed. Likewise, it can be paused and then stopped, and later started and resumed. These are all just moving you between the states the activity can be in: on the top of the stack, not on the top, no longer visible. There is nothing special about rotation. The current activity needs to be destroyed, so it does the lifecycle callbacks to do that. A new one is created so it does the lifecycle callbacks. There is nothing special about being finished. The current activity needs to be destroyed, so it goes through the lifecycle callbacks. The *only* thing at all unusual about what Android does is its ability to kill processes. This also is very simple though: Android will call the activity's onSaveInstanceState() to save away the current state of the activity. By doing that, it is possible for it to kill the activity's process at any time and be able to later re-create a new activity instance from that last saved state. So once it has saved your state, your process can be killed. It sometimes seems people try to think too hard about this and make it something more complicated than it is. The callbacks tell you the states the activity goes in. It should be pretty easy to determine what makes sense to do in each callback, since they are pretty simple well-defined states. If you do that, you will be fine. There is certainly the interesting case of the process being killed. However the *only* thing that should matter about this for an application is to be sure to implement onSaveInstanceState() to save and restore the current state correctly, and to save any data to persistent storage that is needed prior to going into the killable state. (Which is after onPause() pre-3.0 and after onStop() if you target 3.0 or later.) If you were to compare this to something like MIDP: http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/MIDlet.html Android's activities are actually very similar; we have one additional state because we distinguish between the UI being visible vs. not visible at all. -- 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 Documentation Question
Eric is not the first to observe that the documentation on these topics is too confusing. But where should he make this 'contribution' you suggest? Is the documentation somewhere under the Android Open Source project at http://source.android.com/? On Apr 27, 10:23 pm, Dianne Hackborn hack...@android.com wrote: Yes if you call finish() you are saying you want to completely remove the activity from the stack. The system can have the activity destroyed in the same way, but just not remove it from the stack it maintains. At the end of the day, it would be fundamentally broken if there was a way for an activity to stop being used in a process without being destroyed. This means it would be IMPOSSIBLE to write a correctly working application. I agree you can find parts of the documentation to help you convince yourself that there are cases this can happen, if that is what you are looking for. But it won't. Because it would be broken. As I think is already obvious to you, since your original question was basically: if I read the documentation this way then there is nothing useful at all about onDestroy() or onStop() because they won't get called when they need to be. Right. So don't try to read the documentation in a way that makes it broken. You are welcome to contribute changed to the documentation for people to review if there are things you think can be improved. On Thu, Apr 28, 2011 at 12:29 AM, Eric e...@alum.mit.edu wrote: On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If Android is simply calling 'finish' to temporarily discard the Activity, as you state, then is it explicitly setting 'isFinishing()' flag back to false (assuming the call to finish() automatically sets it to true; because if it didn't, then when I programmatically call 'finish()' to permanently finish the Activity, the flag would probably never get set)? - Eric -- 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 -- 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 Documentation Question
Eric is not over-thinking. Rather, he is showing a mindset towards software quality that has become all too rare these days. That mindset is: if the documentation says one thing, but the software does another, then it is a bug. Now I know that in today's FOSS atmosphere, that sounds quaint, even unsustainable out-dated, but I had an interesting conversation with one of the guys involved wtih Sun Java from the very early days: he made it clear that one of the key ingredients for Java's success was that they hired boatloads of inexpensive Russian programmers to take EXACTLY that attitude to JVM submissions. They went over the submitted JVM and the language specification with a great many finely toothed combs to make sure that even the least deviation would cause the JVM to fail. The result was that the first generations of JVMs really did go a long way to fulfilling the promise of write once, run anywhere. It was the KVMs for J2ME that failed to meet this goal, and failed badly, resulting in 'fragmentation' that was much, much worse than any fragmentation we see in Android today. On Apr 27, 3:08 pm, TreKing treking...@gmail.com wrote: On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote: It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. calling finish() will result in onStop() - onDestory() when in the paused stated. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). Where does it say the system bypasses onStop() and goes directly to onDestroy()? In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. No. The flow is pause - stop - destroy. There is no random skipping about. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. Look at the pretty graph - it pretty clearly indicates the only way to onDestroy() is from onStop(). Honestly, I think you're over-thinking this and confusing yourself. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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 Documentation Question
All of the documentation comes from the source code. The documentation in the Activity class comes from Activity.java in the source code. I don't need a lecture about the importance of documentation and the history of Java fragmentation. I am well aware of these things. You are also over-simplifying things -- outstanding documentation for the entire Java platform would not have helped the situation much, since the higher you go up in the stack the more complicated the overall behavior becomes (as each piece relies on the behavior of the parts below it). That is why we say that Android is not a specification, but an implementation. The big point where Java (especially MIDP) compatibility broke down is where multiple entities were doing their own completely independent implementations. On Thu, Apr 28, 2011 at 2:00 PM, Indicator Veritatis mej1...@yahoo.comwrote: Eric is not over-thinking. Rather, he is showing a mindset towards software quality that has become all too rare these days. That mindset is: if the documentation says one thing, but the software does another, then it is a bug. Now I know that in today's FOSS atmosphere, that sounds quaint, even unsustainable out-dated, but I had an interesting conversation with one of the guys involved wtih Sun Java from the very early days: he made it clear that one of the key ingredients for Java's success was that they hired boatloads of inexpensive Russian programmers to take EXACTLY that attitude to JVM submissions. They went over the submitted JVM and the language specification with a great many finely toothed combs to make sure that even the least deviation would cause the JVM to fail. The result was that the first generations of JVMs really did go a long way to fulfilling the promise of write once, run anywhere. It was the KVMs for J2ME that failed to meet this goal, and failed badly, resulting in 'fragmentation' that was much, much worse than any fragmentation we see in Android today. On Apr 27, 3:08 pm, TreKing treking...@gmail.com wrote: On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote: It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. calling finish() will result in onStop() - onDestory() when in the paused stated. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). Where does it say the system bypasses onStop() and goes directly to onDestroy()? In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. No. The flow is pause - stop - destroy. There is no random skipping about. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. Look at the pretty graph - it pretty clearly indicates the only way to onDestroy() is from onStop(). Honestly, I think you're over-thinking this and confusing yourself. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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 -- 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 Documentation Question
Actually, I think you do need the 'lecture' because you got the facts wrong. Multiple independent groups were developing JVMs, too. Remember IBM? Sun, Microsoft, IBM and BEA all developed their own JVMs. Yet their multiple independence did not have the same effect on the JVM that you attribute to it in the MIDP case. Why not? The persnickety attitude enforcing strict matching of code and specification was one of the reasons, not the only one. And BTW, saying that Android is not a specification, but an implementation is an obvious cop-out. Can we bring the thread back on topic now? On Apr 28, 12:07 pm, Dianne Hackborn hack...@android.com wrote: All of the documentation comes from the source code. The documentation in the Activity class comes from Activity.java in the source code. I don't need a lecture about the importance of documentation and the history of Java fragmentation. I am well aware of these things. You are also over-simplifying things -- outstanding documentation for the entire Java platform would not have helped the situation much, since the higher you go up in the stack the more complicated the overall behavior becomes (as each piece relies on the behavior of the parts below it). That is why we say that Android is not a specification, but an implementation. The big point where Java (especially MIDP) compatibility broke down is where multiple entities were doing their own completely independent implementations. On Thu, Apr 28, 2011 at 2:00 PM, Indicator Veritatis mej1...@yahoo.comwrote: Eric is not over-thinking. Rather, he is showing a mindset towards software quality that has become all too rare these days. That mindset is: if the documentation says one thing, but the software does another, then it is a bug. Now I know that in today's FOSS atmosphere, that sounds quaint, even unsustainable out-dated, but I had an interesting conversation with one of the guys involved wtih Sun Java from the very early days: he made it clear that one of the key ingredients for Java's success was that they hired boatloads of inexpensive Russian programmers to take EXACTLY that attitude to JVM submissions. They went over the submitted JVM and the language specification with a great many finely toothed combs to make sure that even the least deviation would cause the JVM to fail. The result was that the first generations of JVMs really did go a long way to fulfilling the promise of write once, run anywhere. It was the KVMs for J2ME that failed to meet this goal, and failed badly, resulting in 'fragmentation' that was much, much worse than any fragmentation we see in Android today. On Apr 27, 3:08 pm, TreKing treking...@gmail.com wrote: On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote: It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. calling finish() will result in onStop() - onDestory() when in the paused stated. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). Where does it say the system bypasses onStop() and goes directly to onDestroy()? In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. No. The flow is pause - stop - destroy. There is no random skipping about. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. Look at the pretty graph - it pretty clearly indicates the only way to onDestroy() is from onStop(). Honestly, I think you're over-thinking this and confusing yourself. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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 -- 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
Re: [android-developers] Re: Activity Lifecycle Documentation Question
On Thu, Apr 28, 2011 at 9:37 PM, Indicator Veritatis mej1...@yahoo.comwrote: Actually, I think you do need the 'lecture' because you got the facts wrong. Multiple independent groups were developing JVMs, too. Remember IBM? Sun, Microsoft, IBM and BEA all developed their own JVMs. Yet their multiple independence did not have the same effect on the JVM that you attribute to it in the MIDP case. Why not? The persnickety attitude enforcing strict matching of code and specification was one of the reasons, not the only one. Try writing a specification for a complete platform/OS that allows multiple entities to implement them independently and end up with compatible results. It's not going to happen. And BTW, saying that Android is not a specification, but an implementation is an obvious cop-out. No, it is a fundamental decision we made early in the design of Android. Can we bring the thread back on topic now? Hi, you were the one who went off in this direction. Good lord. -- 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 Documentation Question
* onDestroy() is not guaranteed to be called, so if you create a Thread in onCreate(), the thread may never be stopped. * When the process hosting your activity is killed, the onDestroy won't be called... makes sense.. your process just died. The process is force-killed (I think): any thread that may be running, daemon or not, will die with its process. The same goes for onStop. The onStop isn't called when the process hosting your app is killed. Take a look at the diagram in the Implementing the lifecycle callbacks section of the link you provided. You'll see that after onPause and onStop the process can be killed. Any open resources (threads, cursors, etc) will die with the process when it's killed. In other words: Your process won't be killed until all its activities are at least paused (after their onPause have been called). To allow you to clean up unnecessary resources at appropriate times,* while your process keeps running in the background*, you can implement onStop, onDestroy and such. -- 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 Documentation Question
I would tend to disagree with the above two explanations. Let's say you implement onStop() to stop/kill the thread you created in onStart(). You then navigate to a new activity by starting it. Your activity gets paused. Android can 'finish' your activity at this point, WITHOUT killing the process. There is nothing in the documentation that says the process HAS to be killed if your activity is finished prematurely due to memory. Android could reclaim the memory by simply disposing of your paused Activity before showing the next activity that you just started, without killing the process. In that case, the thread you started in onStart will still be running. I think it makes much more sense for the documentation to clarify this, and recommend that people do all auxiliary setup/cleanup in onResume/onPause, and nowhere else. -- 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 Documentation Question
On Wed, Apr 27, 2011 at 3:22 PM, Eric e...@alum.mit.edu wrote: Let's say you implement onStop() to stop/kill the thread you created in onStart(). You then navigate to a new activity by starting it. Your activity gets paused. It will also get stopped, as it's no longer visible, and onStop() will get called. The best thing to do is implement all the life cycle methods with a debug line and run through the scenarios to see when and if each function gets called. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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 Documentation Question
On Wed, Apr 27, 2011 at 4:22 PM, Eric e...@alum.mit.edu wrote: You then navigate to a new activity by starting it. Which triggers onPause() and onStop() on the original activity. Your activity gets paused. Android can 'finish' your activity at this point, WITHOUT killing the process. Which triggers onDestroy() on the original activity. In that case, the thread you started in onStart will still be running. Only if developer did not stop the thread in onPause(), onStop(), or onDestroy(). I think it makes much more sense for the documentation to clarify this, and recommend that people do all auxiliary setup/cleanup in onResume/onPause, and nowhere else. You are welcome to think what you want. And, as I noted, it's not a bad idea to tend towards onPause() and onStop(). However, there is nothing directly wrong with waiting until onDestroy() to shut down a background thread, and there may be perfectly valid reasons for keeping that thread around as long as possible (e.g., chat client maintaining a socket connection to a chat server). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 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 Documentation Question
The text and the diagram of the link you showed are indeed not saying the same: - The diagram only shows a direct path out of onPause or onStop only when the process is being killed. - The text says that the framework can just call 'finish' on the activity (without going through onDestroy). I must say that i *never *have seen this happen. The only time that onDestroy/onStop is not called at some point in time is when the process is being killed. -- 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 Documentation Question
Be very careful with cleaning up some resources in onPause. A dialog being shown could put your activity into paused-state, but not into stopped-state. This happens when a system dialog pops up (e.g. an activity chooser) and your activity is still visible in the background (blurred, but still visible). You may not want to clean up certain resources while your activity is paused but still visible. -- 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 Documentation Question
On Wed, Apr 27, 2011 at 4:53 PM, Streets Of Boston flyingdutc...@gmail.com wrote: Be very careful with cleaning up some resources in onPause. A dialog being shown could put your activity into paused-state, but not into stopped-state. This happens when a system dialog pops up (e.g. an activity chooser) and your activity is still visible in the background (blurred, but still visible). You may not want to clean up certain resources while your activity is paused but still visible. Technically, these are dialog-themed activities, which is why onPause() is called. onStop() is not called because the underlying activity is still visible. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 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 Documentation Question
On Apr 27, 4:45 pm, Mark Murphy mmur...@commonsware.com wrote: On Wed, Apr 27, 2011 at 4:22 PM, Eric e...@alum.mit.edu wrote: You then navigate to a new activity by starting it. Which triggers onPause() and onStop() on the original activity. This is where I disagree with you. Android is allowed to 'clean up' your activity right after onPause(), without killing the app, if it wants to reclaim memory. The Activity lifecycle documentation says the Activity is 'killable' after onPause(), which technically doesn't mean the process must be 'killed'. It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. -- 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 Documentation Question
From the Activity documentation: http://developer.android.com/guide/topics/fundamentals/activities.html If an activity is **paused or stopped**, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When the activity is opened again (after being finished or killed), it must be created all over. On Apr 27, 5:55 pm, Eric e...@alum.mit.edu wrote: On Apr 27, 4:45 pm, Mark Murphy mmur...@commonsware.com wrote: On Wed, Apr 27, 2011 at 4:22 PM, Eric e...@alum.mit.edu wrote: You then navigate to a new activity by starting it. Which triggers onPause() and onStop() on the original activity. This is where I disagree with you. Android is allowed to 'clean up' your activity right after onPause(), without killing the app, if it wants to reclaim memory. The Activity lifecycle documentation says the Activity is 'killable' after onPause(), which technically doesn't mean the process must be 'killed'. It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. -- 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 Documentation Question
On Wed, Apr 27, 2011 at 6:04 PM, Eric e...@alum.mit.edu wrote: From the Activity documentation: http://developer.android.com/guide/topics/fundamentals/activities.html If an activity is **paused or stopped**, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When the activity is opened again (after being finished or killed), it must be created all over. An activity in the paused state, when finished, goes through onStop() and onDestroy(). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 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 Documentation Question
The text of the documentation says you're right. A call to 'finish()' is all that could happen to 'destroy' the activity. No killing of the process is necessary. However, the image in the documentation ( http://developer.android.com/images/activity_lifecycle.png inside http://developer.android.com/guide/topics/fundamentals/activities.html) states that the 'process is killed' when it skips the onStop or onDestroy. In my experience, the image is correct, the text is not correct. I have not seen any Activity in my apps whose onStop/onDestroy is not called without it being killed through a kill of the process. But i could be wrong... http://developer.android.com/images/activity_lifecycle.png -- 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 Documentation Question
On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote: It means the activity can be destroyed after onPause() by the system calling 'finish()' on it. calling finish() will result in onStop() - onDestory() when in the paused stated. It seems to me, in that specific case, if you've started another activity from the current activity, and right after your onPause() was called, Android decides 'finish' your activity due to memory constraints, I don't see anything in the documentation that says Android can't 'finish' your activity right there on the stop, thereby bypassing the call to onStop(), and going directly into onDestroy(). Where does it say the system bypasses onStop() and goes directly to onDestroy()? In this case, the process would still be running, your activity would be paused, archived, and 'destroyed', but never 'stopped'. No. The flow is pause - stop - destroy. There is no random skipping about. You say 'onStop()' will _definitely_ be called. I don't see that in the documentation I read. Look at the pretty graph - it pretty clearly indicates the only way to onDestroy() is from onStop(). Honestly, I think you're over-thinking this and confusing yourself. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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 Documentation Question
On Wed, Apr 27, 2011 at 5:55 PM, Eric e...@alum.mit.edu wrote: Android is allowed to 'clean up' your activity right after onPause(), without killing the app, if it wants to reclaim memory. By finishing the activity, thereby triggering the onPause()/onStop()/onDestroy() triad. If the activity is paused, finishing it will merely do onStop() and onDestroy(). I don't see that in the documentation I read. Documentation has gaps. If you can create a sample application that demonstrates that you're correct, please post it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 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
Re: [android-developers] Re: Activity Lifecycle Documentation Question
Hopefully I can clearly confirm what is actually happening. There are only two ways your entire activity instance can go away: 1. At some point the activity lifecycle completing and onDestroy() being called. 2. The process being killed. Thus you will not have a resource leak if you release the resources in onStop() or onDestroy(). Generally you pair onCreate() with onDestroy(), onStart() with onStop(), and onResume() with onPause(). You can however do variations if you are careful such as allocating in onStart() (if not already allocated) and releasing in onDestroy(). Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be killed (prior to killing a process) like onPause() has always been. In fact if you are targeting API 11 or greater, you will find onSaveInstanceState() now being called between onPause() and onStop(). On Wed, Apr 27, 2011 at 6:14 PM, Mark Murphy mmur...@commonsware.comwrote: On Wed, Apr 27, 2011 at 5:55 PM, Eric e...@alum.mit.edu wrote: Android is allowed to 'clean up' your activity right after onPause(), without killing the app, if it wants to reclaim memory. By finishing the activity, thereby triggering the onPause()/onStop()/onDestroy() triad. If the activity is paused, finishing it will merely do onStop() and onDestroy(). I don't see that in the documentation I read. Documentation has gaps. If you can create a sample application that demonstrates that you're correct, please post it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 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 -- 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 Documentation Question
On Wed, Apr 27, 2011 at 6:44 PM, Dianne Hackborn hack...@android.com wrote: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be killed (prior to killing a process) like onPause() has always been. Just to clarify, shouldn't that read: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be **called** (prior to killing a process) like onPause() has always been. ? Thanks! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 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 Documentation Question
On Apr 27, 6:44 pm, Dianne Hackborn hack...@android.com wrote: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be killed (prior to killing a process) like onPause() has always been. I am glad this change was made, it makes more logical sense to me to do it this way. Hopefully the documentation can also be updated to remove any doubt whatsoever that an Activity cannot possibly be 'removed' from memory in low-memory situations (when the process is _not_ killed), that would result in an inconsistent or leak state by not having balanced lifecycle methods 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
Re: [android-developers] Re: Activity Lifecycle Documentation Question
Um, yes, called. I meant called. :) On Wed, Apr 27, 2011 at 6:53 PM, Mark Murphy mmur...@commonsware.comwrote: On Wed, Apr 27, 2011 at 6:44 PM, Dianne Hackborn hack...@android.com wrote: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be killed (prior to killing a process) like onPause() has always been. Just to clarify, shouldn't that read: Also it may be worth mentioning -- there was a significant change to the activity lifecycle in 3.0 where onStop() is now guaranteed to be **called** (prior to killing a process) like onPause() has always been. ? Thanks! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 3.3 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 -- 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 Documentation Question
On Wed, Apr 27, 2011 at 6:56 PM, Eric e...@alum.mit.edu wrote: I am glad this change was made, it makes more logical sense to me to do it this way. Hopefully the documentation can also be updated to remove any doubt whatsoever that an Activity cannot possibly be 'removed' from memory in low-memory situations (when the process is _not_ killed), that would result in an inconsistent or leak state by not having balanced lifecycle methods called. The only thing that happens in low-memory situations is processes being killed. -- 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 Documentation Question
On Apr 27, 9:27 pm, Dianne Hackborn hack...@android.com wrote: On Wed, Apr 27, 2011 at 6:56 PM, Eric e...@alum.mit.edu wrote: Hopefully the documentation can also be updated to remove any doubt whatsoever that an Activity cannot possibly be 'removed' from memory in low-memory situations (when the process is _not_ killed), that would result in an inconsistent or leak state by not having balanced lifecycle methods called. The only thing that happens in low-memory situations is processes being killed. Yes, thank you for clarifying that, but unfortunately the documentation lead one to believe that Activities that are already paused can somehow be removed from memory by a different mechanism other than killing the process. For example, http://developer.android.com/reference/android/app/Activity.html If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process Note the 'either', 'or' language. I assume this situation is meant to address an Activity stack: A1, A2, A3 Where A3 was just started, but the system is so low on memory that it 'drops' the activities A1 and A2 from memory using the nebulous mechanism described in the documentation. The nebulous mechanism is described as 'the Activity being asked to finish'. However, my understanding of 'finishing' an Activity was that once an Activity is 'finished' it never again returns to the screen unless being explicitly started again. Therefore, I took the 'finish' in that above documentation to mean that Android removes the Activity from memory some other way, where the normal lifecycle is not followed. Hence the reason why I wrote this post in the first place. -- 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 Documentation Question
Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. On Wed, Apr 27, 2011 at 11:01 PM, Eric e...@alum.mit.edu wrote: On Apr 27, 9:27 pm, Dianne Hackborn hack...@android.com wrote: On Wed, Apr 27, 2011 at 6:56 PM, Eric e...@alum.mit.edu wrote: Hopefully the documentation can also be updated to remove any doubt whatsoever that an Activity cannot possibly be 'removed' from memory in low-memory situations (when the process is _not_ killed), that would result in an inconsistent or leak state by not having balanced lifecycle methods called. The only thing that happens in low-memory situations is processes being killed. Yes, thank you for clarifying that, but unfortunately the documentation lead one to believe that Activities that are already paused can somehow be removed from memory by a different mechanism other than killing the process. For example, http://developer.android.com/reference/android/app/Activity.html If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process Note the 'either', 'or' language. I assume this situation is meant to address an Activity stack: A1, A2, A3 Where A3 was just started, but the system is so low on memory that it 'drops' the activities A1 and A2 from memory using the nebulous mechanism described in the documentation. The nebulous mechanism is described as 'the Activity being asked to finish'. However, my understanding of 'finishing' an Activity was that once an Activity is 'finished' it never again returns to the screen unless being explicitly started again. Therefore, I took the 'finish' in that above documentation to mean that Android removes the Activity from memory some other way, where the normal lifecycle is not followed. Hence the reason why I wrote this post in the first place. -- 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 -- 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 Documentation Question
On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If Android is simply calling 'finish' to temporarily discard the Activity, as you state, then is it explicitly setting 'isFinishing()' flag back to false (assuming the call to finish() automatically sets it to true; because if it didn't, then when I programmatically call 'finish()' to permanently finish the Activity, the flag would probably never get set)? - Eric -- 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 Documentation Question
Yes if you call finish() you are saying you want to completely remove the activity from the stack. The system can have the activity destroyed in the same way, but just not remove it from the stack it maintains. At the end of the day, it would be fundamentally broken if there was a way for an activity to stop being used in a process without being destroyed. This means it would be IMPOSSIBLE to write a correctly working application. I agree you can find parts of the documentation to help you convince yourself that there are cases this can happen, if that is what you are looking for. But it won't. Because it would be broken. As I think is already obvious to you, since your original question was basically: if I read the documentation this way then there is nothing useful at all about onDestroy() or onStop() because they won't get called when they need to be. Right. So don't try to read the documentation in a way that makes it broken. You are welcome to contribute changed to the documentation for people to review if there are things you think can be improved. On Thu, Apr 28, 2011 at 12:29 AM, Eric e...@alum.mit.edu wrote: On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote: Asking it to finish means finishing the activity, which means destroying it. Politely asking it to finish isn't going to cause it to just not cleanly exit. It would be fundamentally broken if activities every just stop being used in their process without actually going through the lifecycle. In other words asking to finish - Activity.finish() - does what you expect. Ok, so when I 'finish' an Activity programmatically, never wanting it to show up in the Task stack again, how does the system know to remove my Activity from the back stack in that case, but it doesn't remove it from the stack when the system asks it to finish due to low memory conditions? Also, the documentation for onDestroy() adds to the confusion a bit: Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Note that it says if the Activity is being temporarily discarded to save space, then the 'isFinishing' method will return false. If Android is simply calling 'finish' to temporarily discard the Activity, as you state, then is it explicitly setting 'isFinishing()' flag back to false (assuming the call to finish() automatically sets it to true; because if it didn't, then when I programmatically call 'finish()' to permanently finish the Activity, the flag would probably never get set)? - Eric -- 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 -- 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
