I've been poking around at some of the documentation for Google's Android project. I've seen a couple of the code samples, read through a lot of the SDK documentation and I've even checked out a couple of YouTube videos, including this one:

I also highly recommend that you check out the 3 architecture videos that you can find on YouTube. One of the engineers on the Android project takes us on a detailed walkthrough of the architecture of the platform, how applications work, and even shows us how memory, processes, activities, and state are managed.

So here's what I've been able to take away as highlights from what I've read and seen:

Notifications. Application code can be woken up when certain important events take place. This is something that I really liked about PalmOS in that it could wake your code up and do things necessary and then shut your code back down when the event had passed. It's a cool feature, but it's basically a requirement for any mobile operating system. The downside is Windows Mobile sucks in this arena. The iPhone, Android, and PalmOS all have it beat there.

Content Provider. Applications are apparently allowed to share data amongst each other. The contact database is a good example of this. Let's see - where did I first see a really good implementation of shared application data such as a calendar store, a contact store, a shared to-do list....? Where... where... oh yeah... Mac OS X. (which includes the iPhone)

Use of platform services, create an instance of the Intent class to register an intent to do something. Late-bound picking, e.g. you can replace the photo gallery default with a new, fancy one. This seems like a pretty intriguing concept. I like the idea that there's a platform service to "pick a photo" and you can consume this service and be (reasonably) assured that you'll get a photo selection back, or you can create your own photo selection service provided you conform to the requirements of a platform photo picking service. This looks like a pretty good development opportunity here.

Activities and state management. Feels like a miniature/mobile, specialized version of workflow foundation for suspendable/resumable applications. A while back, I remember writing a blog post on how the Windows Workflow Foundation was a great tool for writing applications that needed a particular process to be halted and then resumed at will. The Android implementation here seems to be borrowing a lot of really good concepts from workflow management systems and frameworks. As with everything, it's all still theory at this point since there are no devices running Android in the wild yet.

XMPP - any app send device-to-device messages to any user running android app. Apps can send multiplayer messages like moving a knight from a location to a new location. A user can send their location to their buddies so their buddies can see where they are. Works with any gmail account. Also seems like a really cool concept, but we'll have to see how this plays out in what I like to call, the "real world".

Notification Manager - allows any app to put a notification into the status bar. Apps can notify you when an auction is ending or when someone added you as a friend on a social network. Also looks like a cool feature.

So in short, I've come to a conclusion. It looks as though the core framework of features that Android provides for developers is a pretty robust feature set. It's damned unfortunate that said feature set is accessible only through Java. In February of 2008, developers are going to get to choose whether they want that same feature set (give or take a few) accessible through Objective-C or whether they want it accessible through Java. Also in February, they'll get to choose whether to target 1+ million live and active phones, or some unknown number of potential phones that are not on the market yet. Or, developers can continue to target the insanely huge market share of Windows Mobile developers.

My money is on targeting iPhones and WM devices until Android actually shows up live and in the wild on more than 500,000 devices.

Also, don't be fooled about the Android developer challenge. That's not $10million in prize money, that's a $10 million bribe in order to obtain the critical mass of engaged developers they know will be required for anything useful to come out of the Android project. If they don't have truckloads of developers begging to get their apps onto the phone, their framework will fail and all the mobile partners will go back to business as usual.

tags: google android sdk mobile
links: digg this del.icio.us technorati reddit