Developing Handsets

Doing some research on developing Android handsets, I came across a useful presentation by QualComm on ‘Top 10 Tips For Developing Android HandSets‘. Here’s an overview…

devandroidhandsetstips

OpenGL Tutorial and Android London Meetup

I am a member of the London Android Group but as of yet haven’t had the spare time to go along. Last time, there was a session on OpenGL that has very recently been written up and made available to anyone.

If anyone wants to pre-arrange a chat, I’ll be at the next meetup on the 23 July. I’ll also be at MoMo London this Monday 20th.

LiveDroid

livedroidWondering about Android but not got a phone yet? LiveAndroid is a LiveCD disc image of the Google Android operating system. You can burn the image to a CD and reboot to get a feel for Android… or you could just download the SDK.

OEMs Hacking Android?

eweekThere’s an interesting interview with James Gosling at eWeek.com.

Regarding Java on Android, James says…

“But everybody I’ve talked to who is building an Android phone or whatever, they’re all going in and they’re just hacking on it. And so all these Android phones are going to be incompatible”

The big question is in what ways will the phones be incompatible. If the OEMs are changing the OS so as to change the public APIs then this will indeed be unfortunate. However, the OEMs have an incentive not to do this. Doing so would make the OS potentially incompatible with 3rd party applications. They would have to ship their own SDK and only applications created with that SDK would be guaranteed to work on their phones. I am not sure an OEM would voluntarily go down this path with its implied limited app compatibility and difficultities with maintaining the code with the Android main branch going forward.

Instead, what the various OEMs are almost certainly doing is modifying the non-public APIs and native code. As a contrived example, an OEM might create a better camera API to allow greater control of the camera settings. This is OK provided developers don’t later need to rely on these new or modified facilities. If the OEM decides to publish these APIs then it becomes more difficult for 3rd party developers because there may need to be different application versions for different phones. It’s better if the OEM contributes their code to the Android source so that it becomes shared across all devices. This obviously requires some sort of compatibility testing and negotiation.

James goes on to say of Sun’s Java ME …

“We charge license fees is because we’ve got organizations of people that do compatibility testing and actual negotiating amongst the different handset makers so that things like GPS APIs look the same.”

However, we all know now that this didn’t really work. Despite compatibility testing (TCKs) there’s significant fragmentation across Java ME phones. While working on Java ME JVMs, I have personally used the TCKs and I can see that it’s impossible for tests such as these to account for every deviation from the expected functionality. Also, Sun’s cross party negotiations resulted in Java ME’s onerous permissions based security that, in my opinion, has limited Java ME’s success.

I also previously wondered about the future of Java (and Java ME) now that Oracle intends to acquire Sun. In second part of the article, James says…

“It’s pretty much impossible to say.”

James says he has ‘no data’ on this. As one of the commenters on the eWeek article points out, this is revealing. It tells us that the future of Java and Java ME hasn’t yet been thought through. I can only guess there are more important factors and reasons weighing in on the Oracle’s acquisition of Sun.

Android Scripting Environment

Android Scripting Environment (ASE) was announced yesterday. It allows you to “edit and execute scripts and interactive interpreters directly on the Android device”.

The key part of this for me is editing on the device. There’s a large number of people out there who would like to create simple utilities on the device in their spare time. A long time ago, the Psion series of devices had great success with OPL that allowed people to create small simple applications on their phone. Since then there have been attempts at re-creating a mini-ecosystem, for example Python on S60, but none have reached the simplicity, depth and usefulness of OPL. I believe ASE has the potential of becoming as successful and useful as OPL was on the Psion.