restful robot

Despite licensing questions and lock-in concerns, google's android SDK is pretty damn exciting.

For all the anti-hype about it not being a gPhone, the hardware wouldn't have been the cool part anyway. Google would rather be Microsoft than Dell, and the part of Apple has already been cast.

Reading through the documentation (and it's good) shows they've had some smart people thinking hard about how applications should work. The appearance of the applications is your standard stack-of-screens, i.e. you can go back 'up' to the parent screen, but the way you implement them is different from desktop and J2ME applications and closer to web applications.

Each screen type is called an Activity, and activities are well separated from each other. Instead of creating a screen by instantiating it and passing it a bunch of state directly, you identify an 'intent' - a URI representing that state plus the action you want to perform, and pass it to android. For example: instead of creating a ViewContact, passing it a Contact object, you request to VIEW content://contacts/6. It's reminiscent of HTTP in a way that can't be coincidental.

The URIs are managed by ContentProviders that serve as the model in your applications, and they have content types. Activities define which content-types, actions, and URIs they can handle and android selects the right one.

This has lots of benefits for the ways applications work together. On the web, I can link to a photo on my friend's website, and they can change it from a JPEG to a PNG, or to a movie, or to a webpage with 20 photos, and the link still works.

Most of the rules for android apps are actually guidelines - you can refer to activities explicitly, and you can pass more than a URI. There are pragmatic reasons for tight coupling of internal components in some cases. But if applications play by the rules where functionality can be cleanly separated, web mashup type apps might make it to the phone.