Sunday, October 19, 2008

Checking Out Android's API

So because I am still unemployedbetween UX contracts, I am exploring programming for the Google Android series smart phones. There have now been plenty of reviews of the first device to have this operating system, the G1 by T-Mobile, but I wondered what the view of this system was like from the inside, the place where application developers get to live. The interface that a programmer uses to create programs for an operating system [API] tells you so much of what the designers of the operating system really wanted or expect.

(Incidentally, admitting I did this is not the brightest idea: I have found so far the User Experience business is really skeptical about consultants who can program. I have had to really convince some prospective employers that yes, I did major in software architecture and got plenty of work in it, but it was only to get to make user interfaces, and really, I am fine leaving it behind. No, no, I do not miss it.)

And what Google obviously wants and expects is that no application on Android, even the ones that the phone maker provides, is beyond being improved and replaced by 3d party developers. Android was obviously designed to have every piece be ripped out and replaced yet still have all the other pieces work. It is one thing to say this, programmers hear this stuff all the time, but it is another to engineer a programming environment to mean it. It really looks like Google means it.

Everything is more abstract than any other phone programing environment I have dealt with. Of course, by using JAVA, the memory system is already abstracted away, and not something any programmer needs to worry about, which was already the first huge step in phone programming that J2ME gave us. (Because, seriously, was I as a programmer supposed to be better at managing memory than the latest algorithms keeping track for me? The moment the computer had the resources to manage memory, it should; programmers are too expensive to be bothered with it if they needn't.)

The J2ME paradigm is of giving the programmer a core virtual environment, and then unlocking different parts of the phone, over the years, as phone makers agree with SUN what each API for every sub-system like the phone book or the media player or the bluetooth stack needs to look like. Which means every one of the optional APIs (they call them JSRs) has the lowest common functionality, is implemented for the phone by each phone maker, and thus of course has incompatibilities.

Android has no concrete subsystems to talk to. This makes it more flexible. There is no extra library, no extension to probe and program, for some new facility. Every program, every subsystem, announces to the Android what it does by registering itself to the Android core as a data provider, or as willing to provide a user interface for a certain function to the user, or both. It registers such by using constants like 'pick a user out of the phone book' or 'know all the dates in the calendar', and programs that know what the constants are can can ask Android "I need what this constant promises", can you start it, or fetch it? Call me when it is finished." Android comes with many constants pre-defined already, but as a programmer, register aything new you want. Data is exchanged all through the system in the form of URLs that express "the 3d entry in the phonebook" or "the current location", and only at the last moment necessary should a program hand that URL to Android and ask "What is this actually?" and Android will look it up from the onwer of the information, without the program having to know what sub-system that actually is.

This means that programs need know nothing about how other systems work -- or even which system gets called -- to get results. They just make an abstract request and it gets fulfilled as long as they know the proper request strings. They can register themselves as handling other requests without needing to know how they will be called. This means that every sub-system can easily be replaced without anything breaking. The possible failure mode here is that new programs do not know the right constants other new programs want to advertise as new capabilities as an eco-system develops by 3d parties, but that is easily coordinated by Google with just a developers website of constants.

Can actually the phone-book be ripped out and replaced? Will an Android phone allow the built-in mail reader be replaced by something easier or better made by a 3d party? Certainly from the documentation there seems to be no impediment for a 3d party program to register itself as a data or UI provider for existing capabilities, but we will see what actual implementations allow. Still, this is the most flexible and future-proof environment I have touched.

I still need to explore the graphics find out how difficult it is to make something beautiful and sophisitcated appear on the screen, something the iPhone does really well by having ported the Quartz system, the all-blending, all-zooming graphics API from OS X to it. The graphics capability of the iPhone is now the bar that must be reached in this area for a new phone OS to seem credible. But I can already see that Android isn't just some new flavor of J2ME. It is quite different.

So it irks me that the job ads I see for it are all specifying you have to be a J2ME programmer to apply. It's lazy, it shows the recruiters or hiring managers do not understand how different Android is. As I have shown, getting something done with other parts of the phone is really different. Android is not as obsessed as J2ME to look constrained and small (probably because Android phone are expected to run on smartphone hardware). Good J2ME programmers must excel at programming around bugs and contingencies of running on different J2ME implementations, Android programmers will not as Google will supply the whole environment and runtime for every phone. These days somebody who specializes in Java for the desktop (J2SE) has a tough time telling employers they can do J2ME programming, and vice-versa, because while programming for the desktop programs and the phone may both use JAVA, the subsystems are so different. Well, I think Android programming really is a 3d variant, and I do not see at all why J2ME programmers should be the preferred to one to look to to switch. Just get smart people.