Well, the preview SDK for Android is now out, as well as a slew of titillating screencasts describing the architecture and development process for the platform. I hadn’t been really following the “gPhone” story apart from noting the fact that it apparently existed, so I took advantage of this opportunity to educate myself on the details of the beast.
And what a beast it is.
One of the things that I have always noted as being very impressive about OS X is a certain system-wide consistency and self-integration which Windows has failed to achieve, probably because the community is much more fractured. Beyond a highly consistent look and feel (ironically violated only by Apple’s own efforts in Mail and iTunes), there is a smorgasbord of underlying services and platforms that unify the OS – Cocoa services allow for inter-application actions (I can spellcheck text from in Shiira, my browser, through the services of another application such as Word, for instance), Spotlight integrates with a slew of applications to provide system-wide searching, AppleScripts allow for quick and easy automation and extensibility of applications, and most recently in Leopard, Quick Look allows for a preview framework that greatly assists in locating and identifying files.
Sharp-eyed readers will note that every one of the unifying services I have just listed require a certain amount of active participation from application developers. Time must be put in to integrate support for each of these services. However, the point is that they exist, and the capability is there. Because they exist, and because it is therefore reasonably easy to do so, users expect this level of functionality and developers put in the effort to make it work.
Android was built from the ground up for application integration. I haven’t messed around with the SDK yet, and I probably won’t until next weekend (there are some updates to My College Apps that are waiting to be pushed out), but from the screencasts, the gist of the platform seems to be entirely based on an operating-system level of content and action management. Of course, if I turn out to be wrong, please do correct me.
Rather than having default applications for a small number of things like file formats, email, and web browsing, Android is built on the concept of Intents, which are far more granular. Every action you’d want to perform, such as viewing a map, an email, picking a photo, making a call, or even going to the home screen is performed through a system call on an Intent. Android then determines which application would be best suited to perform the requested Intent – a process that is user-configurable – and then executes that action, optionally returning data such as the selected photo. In this way everything built in Android maybe reused and replaced, right down to, as previously mentioned, the home screen.
Additionally, while applications can store data in their own formats, they can opt into Android’s Content Manager service, which is apparently built on top of a SQLite engine they have integrated into the OS. In this way, content may be stored not only for the host application in question, but also made accessible for other applications to utilize, all with little to no additional effort – one prime example is Contact information, which could be useful to a whole slew of other applications.
A smaller, but very neat and appealing system-wide integration is the Notification Manager, which streamlines and standardizes the appearance of notification icons you often find along the top of phones. In android, all applications may display notification icons that the user may access at any point. When the icon is highlighted (tapped/selected once) it centers itself along the top and displays a little speech bubble indicating briefly what the notification is about, and should the user decide to act upon the notification, the application is then launched with information on what is going on.
Everything is built in Java, with the Java code being put through a custom compiler to leanify and meanify applications for a mobile environment, resulting in “.dex” files.
As a side note, I find it interesting that the entire Android appearance is highly evocative of the translucent smoke Apple has pushed in a few of its applications recently, not to mention that the screencast, while mentioning that Android’s web browser is built off of WebKit, calls it the “standard these days.”
Beyond whether all of this works as well as Google claims, my biggest question is how well Android takes care of the highly varying input and display methods on SmartPhones these days for the developer – it is a complex issue that in Windows Mobile requires the use of an extra framework on top of the .NET CF which makes the entire process extremely painful – just looking at the diagrams of abstraction required to draw a simple form with fields is enough to turn anyone off the idea. In one of the screencasts, the View Manager is described, and this issue is very briefly mentioned, with a note that Google has solved all these issues for the developer.
In summary, Google has created, in concept, an extremely interesting platform. The foremost goals appear to be open information sharing and platform self-integration, along with ease of development. Whether that concept is real, we shall soon find out. I’m off to download the SDK.