The event’s headline scoop was a couple of developers, David Carson and Alan Blount, from the Google Android team. In fact I think they work just across the river.
It was a well-filled room of several hundred people, but when they started by asking how many developers were in the room, I only saw one hand (perhaps they’re just shy). I guess most of the MIW delegates that crashed the party aren’t coding kids.
Never mind. The presentation deleved into a component-by-component analysis of the entire device stack anyway.
The centrepiece of the presentation of the demo was them attempting live development in front of our eyes. With nothing more than Eclipse, the Android plugin, and some nervous copy-and-pasting, they managed to show how one can wire up a text box to a browser control to act as an address bar. Cool enough although hardly warranting the “we’re going to build a web browser in 5 minutes” anecdote.
For most of the crowd, I think the pace dropped a little at this point. We watched masters-of-the-universe wrestle with Eclipse autocomplete, on-stage typing nerves, and a few run-time exceptions. But they lashed together something in the end, and they got applause for coaxing WebKit to render CNN.com. Cute, I suppose.
Then questions. And the, perhaps unwitting, audience focus in on Dalvik extremely quickly. Why did you build a new virtual machine? Why not use existing approaches? Why not go direct to native Linux? And so on. Standard party line: designed specially for small devices, optimised for Linux, open, etc etc. Well done, no mention of Sun.
Also some inevitable questions about hardware support & integration, and security & ubiquitousness of the APIs. Yes, it’s not just a high-end phone platform – it’s aimed to be suitable for mass-market. Yes, of course different handsets will expose different hardware functionality. And yes, there are things like the location-based API which might be secured, but of course it’ll be down to the individual implementations.
Perhaps undue bravery & even naivety here. Surely every operator and handset manufacturer is going to be sorely tempted to bend and mould and constrain what the device exposes or what the applications can do. The default starting position will not be complete openness.
Despite the presence of the word “Open” in the alliance’s title, I expect reversion-to-type by old school telecoms, and that could be the project’s biggest nightmare. The developers suggested further such tricky questions were brought up at the following day’s keynote. “We just write the code” was probably the right thing to say.
Nevertheless, I remain enthusiastic overall. If Android becomes a dominant platform, then a lot of developer’s problems go away. That may happen. But of course it will only do so over many, many dead bodies – including those of plenty of companies of some significance. So success will be hard and bloody.
But even if Android does not become dominant, it will have shown that there is another way of looking at handset development. As Tom Hume says, it is, at the least, shaking things up a little. What other handset platform has ever exposed a developer’s API a year before any handsets are even likely to reach the shops?
Received and traditional telecoms wisdom is to build handsets for consumers first, operators a close second, and developers a distant third.
What Google seems to be trying to do (with no insignificant bribery too) is to see what happens when you reverse that order – or at the very least make developers feel like first-class citizens in the ecosystem. Build up a head-of-steam with third-party apps before the handsets ever emerge, and as such, an admirable experiment.
But will that be enough to make their force truly unstoppable when it meets the immovable object of today’s ecosystem? I’m certainly looking forward to finding out.