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.com>wrote: > > > 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
