dale lane

I wrote an admittedly gushing post a few weeks ago about my first impressions of the new “Google phone”, the Android-powered T-Mobile G1. Now that I’ve had a few weeks to play with it, I thought I’d add a comment about some frustrations with it as a developer.

None of this is to retract what I said before – I still agree with what I said before. But it’s worth adding a couple of comments.

I’ve not written any code for Android yet, but I’ve had a couple of tentative looks into how I might. And in general, it seems to be a combination of being really impressed by the theory, followed by being frustrated by the practice.

This is perhaps best described with a couple of examples.

Extending applications

The architecture for extending applications is very elegant. You can write some functionality in Java, and in your XML manifest file you expose it to the operating system essentially as a service, called an ‘Activity’. When you do this, you specify what types of data the functionality is relevant for, in what looks like MIME types.

Then any other application that operates on that type of data is able to use that function, including being able to add that function to their menu.

The example in the Android doc explains it quite well:

…suppose you implement a new image handling tool that shrinks an image to a smaller size and you would like to offer this as a menu option to any other [program] that handles pictures … If another application that handles photos asks Android for any Activities that can perform actions on pictures, Android will perform intent resolution, find your Activity, and add it to the other [program’s] options menu…

I love this de-coupled, services-based approach. Compare it with the pain I went through to extend Pocket Internet Explorer on Windows Mobile last year. I wrote some small apps that added options to the mobile browser’s menu to turn the current URL into a TinyURL, post the current URL to del.icio.us and so on. It was a massive headache, writing some fairly icky C++ implementing some Pocket Internet Explorer-specific functions, compiling it into a DLL, and writing Windows registry keys to register the DLL.

And one of the biggest responses I got was “Can you write it for Opera?”. Which would have been a different language, a different plug-in environment, different build and install approach… it’d be a completely different app.

The Android approach – the possibility of writing a bit of Java to do the TinyURL or del.icio.us posting, then writing a manifest XML file that tells the OS that the function is appropriate for web pages – sounds far more elegant. Not only does it sound easier to write, but it should mean that if another browser is released, as long as they call the menu.addIntentOptions function to get all relevant extension Activities, then they would automatically get my extension in their menu, without any porting requirement for me.

How cool is that?

Except… no. The built-in Browser that comes with Android doesn’t call menu.addIntentOptions when it builds it’s menu, and so doesn’t include extensions in it’s menu.

A response on the Android developers forum confirmed that “pretty much none of the built-in applications do this”, and that this was done because “having an arbitrarily large number of items added by other applications, mixed together with unrelated items from the main application, is really tough to provide a decent UI for”.

Which seems like such a shame – a very elegant architectural feature is not being exploited in one of the OS’ core apps.

I guess a potential workaround is to download the source for the Browser app (easily available from http://android.git.kernel.org), modify it so that it does look for relevant Activities when building it’s menu, and make it available as an ‘extendable Browser’. Forking is never a nice approach though, so I’d be reluctant to do it.

Widgets

Another example is the widgets that run on the phone’s Home screen. The Android home screen is a multi-screen desktop. Similar to regular desktops, you can put shortcuts to applications or webpages on the desktop, and drag them to arrange them where you want. You can also have widgets on the desktop – floating gadget apps that can run from the home screen. Android comes out of the box with a couple of example gadgets – a photo viewer, and a Google search bar.

One of the first things that I wanted to write were widgets that would show me my PIM information on the desktop – a floating gadget that shows the current day’s appointments from the Calendar, or a gadget which shows how many unread email I have. This would be very cool, and has the potential to be more flexible than the Windows Mobile info-heavy Today screen, and more useful than the iPhone’s launcher home screen. You could have shortcuts to launch key apps alongside widgets with the key info you want to see without having to open an app – all on the desktop.

Except… no. The SDK doesn’t provide an API for writing widgets, and the desktop is fairly locked down to prevent hacking them in without a friendly API. As far as I can see, the only way around this again would be to download the source for the desktop environment (is it the Launcher?) and modify the views that implement the existing widgets.

Responses I’ve seen on Android forums suggest that this was done for security reasons, but I’ve not seen that confirmed anywhere official. And posts from Google engineers suggest that we might not be seeing this change anytime soon, saying that adding support would require “extensive work to be done in the framework and this is currently not a priority”.

Again, they have an idea for elegant architectural feature, but they aren’t exploiting it. It’s such a shame.

There are other examples, but they are all much the same as these – awesome ideas and potential that seems to fall over at the final hurdle in the implementation.

It’ll be interesting to see how this develops, and at some point I might even get round to trying out writing some real code for Android. 🙂

Tags: android, g1, google, t-mobile, t-mobile g1

This entry was posted on Wednesday, November 26th, 2008 at 7:47 pm and is filed under tech. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.