What Android is
tbray.org
tbray.org
No, we revel in portability and performance :)
Really good article though.
What Tim calls game developers are actually just systems programmers and performance-conscious hackers, including people doing multimedia DSP apps critical for making the platform a hit, along with traditional game developers.
Tim, if you're reading this, can we please get some closure for 3434? Even Mono has OpenTK. Just adopt more of the Khronos stuff and get out of the way. Would be nice if you could beef up the CDD and demand just a bite more from the telcos.
E.g., something based on Javascript, with a fully dynamic remote IDE/editor (along the lines of SLIME)?
I guess then you'd run into the problem that the whole Dalvik UI scheme is so heavily intertwined with their Java-based toolkit (just as iOS is heavily dependent on Obj-C) that there's no real gain in the end?
(Don't everyone hate me at once. ;-)
Dalvik isn't a Java JVM, it doesn't use Java bytecode and it has a significantly different architecture than JVM's. It's possible you might be able to make a language that's a better fit for Dalvik than Java is.
You could save yourself quite a lot of time and start with Squeak or Pharo. MIT license, VM built for the dynamic, good tools, and no real reason you couldn't put another language on top of it.
If your talking building a language/IDE to compile to Dalvik (seems the next paragraph leans that way), then I think you really need to get a feel for how dynamic the Dalvik VM is and what you need in a language to call the shipping runtime.
I know SL4A has some GUI support, but I don't think it's as rich as the full Android UI framework. However, it seems like it could be a good base to build a UI layer on top of.
I wish somebody had already recreated the native widgets of Android/iOS in HTML.
What about WebOS? It will get you at least halfway there. Unfortunately, it doesn't have the reach that Android or iOS have. It's still fun to play with, though.
The "How It’s Generated" section is interesting because Bray points out that it's not important to Android how the native or Dalvik code is generated so long as it uses the APIs. Currently it's most convenient to program in Java but I wonder how long that will remain so.
I guess by now there's a team at Google working on a replacement for the Java Android development environment, to be able to move away from what is now a tainted platform, so it's all perfectly understandable, and I can understand they need to phase in this transformation to not create shocks in the Android ecosystem; but I still feel a bit manipulated, being talked to in a way that both parties know is doublespeak but nobody being able to do anything about it.
However, the possibility for creating Android apps in other languages is not new. For example, the Android Scripting Environment(now called Scripting Layer for Android) was announced on the Google Open Source blog back in June 2009 (http://google-opensource.blogspot.com/2009/06/introducing-an...), which is positively pre-historic for Android's rather short history (for comparison, see the timeline here: http://en.wikipedia.org/wiki/Android_(operating_system)#Upda...).
There's nothing in Bray's post that would indicate anything other than a continuation of the same public roadmap Android has had since at least v1.5 was released on the old G1 phones.
And yes, of course there always was the possibility that other languages would target Dalvik, but it was never mentioned as something Google would do, or as something that Google would consider beneficial to anyone. That tone is changing as of late I feel. That's what I meant - I feel that recent public talks about Android from prominent Google evangelists is slowly preparing the Android world for a gradual change. Not that they'll drop Java like a hot potato next year - that'd be infanticide. It's just that the initial message of 'Java all the way for all things Android' (which was meant to provide developers reassurance that they wouldn't have to work with a myriad of libraries in all sorts of languages, leading to a fragmented landscape on the development side) is not said as loudly any more.
Then again, maybe that was the plan all the way, to provide a broader development environment once the developer base and tools were broad and mature enough. I mean, what do I know, right.
It could be that he is just making an observation. But I read it as a hint of things to come or possibly a gentle suggestion for others to follow. I think it would be interesting to use Google's Go for the native work, for example.
* Is it possible to use the Android as a Linux development platform?
* Can I compile POSIX sources on the Android?
* For instance, can I download bash, Vim and Python tarballs to an Android device and build?
Keep in mind though that Android isn't intended to be a Linux distro or even a Posix'ish OS. It's closer to something like DD-WRT. It is it's own, non-unix embedded OS that just happens to use the Linux kernel as it's base (because really, where's the value in writing your own kernel these days?)
This seems to lay a lot of that out fairly cleanly and simply.
or maybe (as a commentator on the blog mentions) ...
"But game developers revel in pain.
And that’s what Android is."
"But game developers revel in pain.
And that’s what Android is."
a) I wasn't indicating any negative sentiment against Android, just quoting an amusingly awkward juxtaposition.
b) I was kind of expecting the downvotes, so thanks to those who upvoted me back to breakeven (at time of writing)!
c) Tim has now amended the article to render "And that's what Android is" like a header instead of body text, indicating he too thought the juxtaposition altered the meaning of the post.