It's a bit of a misnomer to say that Google chose Java because much of the actual work can be done with a maze of XML files. Anyone who writes this code should get used to typing the word "Android" because all of the XML files use the word for the namespace specifying the attributes for the nodes. Programmers -- or maybe I should say XML form-filler-outers -- can build up all of the user interface and some of the details with a maze of XML nodes all tagged with integers. It's been a long time since I wrote down unique ID integers instead of unique ID strings when I tried to work through some code, but I did when I looked at some Android apps.
After getting lost in these files filled with options for localization and UI widgets, I gave up and started writing pure Java code. It's actually possible to create Java objects directly and link them up with other Java objects instead of sketching this out in XML and waiting for some Java code to parse the XML, create the objects, and link them together. The direct approach worked much better for me.
After wading through this, I began to see the same basic widgets and ideas that are common in the iPhone and, for that matter, many UI frameworks. There are TextViews, TableLayouts, and MapViews just like on the iPhone. These platforms really are small desktops with rejiggered proportions for the windows.
There is one point, though, where iPhone and Android diverge. While Objective C is similar to Java for many intents and purposes, it is a dynamic language. Some Java programmers report that they are much happier to let Java take care of the memory management and catch bugs at compile time. Other Java programmers point out the usefulness of still thinking like a C programmer, because memory is at a premium on a smartphone and garbage collection can cause hiccups.
I have noted some divergences that might rankle people. Why did Google build its own framework instead of using something a bit more standard, like the Java Micro Edition or plain old Swing? Neither has a wonderful reputation, but it might have made sense to rework them instead of starting anew. I'm not sure I can even guess except that it wanted to do things the Google way. Anyone who's used other Google tools -- such as the Google Web Toolkit or the App Engine -- will recognize the spare, no-nonsense aesthetic immediately.
It's worth noting that the Android platform is significantly more open than Apple's. If you want the documentation, it's available for you without clicking through some gateway. The discussions about the platform are open and encouraged. All of this should be a big advantage to enterprise developers who want to ship something to everyone in an office without jumping through the hoops from Apple.
"When I was writing a chapter on sound for 'Hello, Android,' I found it useful to study the source for the media player to clarify a few things that were not covered well in the documentation," says Ed Burnette, the author of the Hello, Android tutorial.
Still, there are limits that may be practical but won't please the faithful followers of Richard Stallman. Android may be all open source, but not everything in the Google phone is part of Android.