Android ups the game

With the latest release of Android devices such as the HTC Hero Android looks increasingly compelling as a platform for mobile consumers as well as being a compelling platform for developers.

A significant challenge to application developers has previously been that Android applications need to be written in Java - which is fine if an application is being developed from scratch, or ported from an existing mobile J2ME platform, but for applications that come from either a desktop, or a mobile RTOS platform the language of choice has long be compiled C code.

By enabling companies to port existing C or C++ libraries and wrap those in Android specific UI's (written in Java) Android have significantly reduced the barrier and cost to developers who are creating applications that run across multiple devices - from desktop through to embedded devices.

As we see more people experimenting with Android on different platforms (netbooks, mobile internet tablets, and I expect to see Android on set top boxes too) I'll expect to see more innovation from application developers.

Comments

[Mirmit]

It will be hard to combine multiple devices ranges (desktop, phone, and the rest) which are more likely to be based on differents HW architectures, including processors (Mips, ARM and x86) with native C/C++ libraries.

One additional fragmentation level.

[Matt]

Not that difficult though - the NDK supports a small set of stable libraries, building a "fat binary" format that enables multiple binary architectures to be contained within a single package isn't hard (Apple did it) - and Application Stores could even efficiently deliver the appropriate binaries by querying the target device and stripping out unnecessary binary code.

As big a challenge faces application developers in developing for multiple different screen sizes and interaction models. HD TV screens with TV remote controls + VGA mobile touch screen devices in the same package? Technically possible, but it could mean two different UI models.

[Rog]

Matt, I gave a talk on a related topic recently. http://ambientindustries.wordpress.com/2009/06/25/what-does-the-t-stand-for/ I think that Android cannot compete until it provides a more complete product. I define product here as the handset and supporting services - the managed platform. I think Apple realise this and Google still think it's about the handset and ROM.

Developers are just one of the range of services - admittedly a very important one. What developers need above all things is a stable target platform. By enabling things like the Hero's custom UI, different screen sizes different hardware etc. etc. Android are following Symbian's well trod path away from a strong platform in search of single handset deals. It's a shame because unlike Palm, Google have the resources and deep pockets you need to make such a platform, they don't seem to have the industry insight and steely determination of Apple though.

Opening a C API is nice but it is not a good trade for the lack of a platform. Infact, it's the sort of technology led, short termism you'd expect from Nokia ;-)

[Matt]

I agree here - though I'd counter - without a C API that allows people to re-use existing desktop software a platform will have limited success (otherwise J2ME would have made it already)

I do agree with you on the ecosystem needed to make a platform though - all the pieces need to be in place and working (i.e. money flowing through to all parties) - I'll write a longer piece on this shortly.

The point about chasing handset deals is interesting too - it may be that only Apple has the vision to define a standard platform and NOT chase unit volumes by creating minor variants to drive a few additional million units per annum. By creating a single platform the market for developers continues to grow and they get increased returns year after year - and this can create huge scale, just look at the PC software market, and it's child this thing called "the internet" - which relies on PC clients for it's success.

This would suggest that we'll never see an "iPhone Nano" - but Apple will use continued scale to drive the price of the Touch (which I think of as the "iPhone Nano" - cheaper, and doesn't require a contract) down and use legacy handsets as another price point (e.g. continuation of the 3G iPhone)

[Rog]

Agree. I've been saying we'll never see an iPhone nano for a while. I stopped recently and started saying "The nano is here, it's the $99 3G"

[Mark Wilcox]

It's not entirely clear to me yet that the Android native SDK will be of any use to third party developers. Will OEMs and operators allow such native code installation? Or will this end up as more of a convenience for them to create applications and services rather than the wider developer community?

[Matt Millar]

Mark, The NDK doesn't add anything that OEMs and Operators didn't already have! Sat underneath Dalvik in Android is a pretty robust Linux platform. Have a browse round the source repository here http://android.git.kernel.org/ if you don't believe me.

External developers have been able to create code that includes C++ since the release of the Android Dev1 device - which enabled anyone to reflash the firmware (here's an interesting thought - any chance of a Symbian build for the Android Dev1?)

What the NDK enables is that 3rd parties without firmware reflash capabilities can include native code.

To quote a Google employee on the Android boards in response to the question "will the Android app store allow apps with native code?"

>> [Apps with native code] are supported. What would be the point of doing an official NDK if such apps weren't officially fully supported?!?

The ?!? are theirs - though I agree with the sentiment - why go to the bother of creating an NDK for Developers if you aren't supporting it - android devs, and OEMs already could do all this stuff, they didn't need an NDK.