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 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
