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
