Google recently released a new SDK to develop on a new mobile platform called Android. It appears to be essentially a new "standard" backed by some huge players and produced by the ever-so-MS-like Google. So, now that the antibiotics have kicked in I've been fiddling with the SDK and the emulator. To not pass comment before you've tried it, I've ported a large chunk of the renderer for Slick onto it, enough so that I can render SVG using the Slick renderer into the handset emulator:
So, it works. Thats a good start... good things:
- Eclipse integration - thumbs up. It's simple and quick to get going when you're a normal Eclipse user.
- OpenGL ES is part of the platform - double thumbs up. Open and well known APIs for rendering. Yes Android provides yet another custom graphics context but portability wise, I'd rather stick with something nice and common.
- Most of the Java SDK is there. No more of this mobile = no API stuff. So far I haven't had to recode anything due to missing classes or features (though I have had to recode, see later)
- The provided Emulator is pretty and seems to be running a real implementation underneath. Thats a step over past emulators for mobiles that were just best effort wrappers. Hopefully this will cut down on the "but it worked on the emulator" syndrome
- Money - $10 million has been put out there to try and stimulate developers. Thats a good step, even if all the best programmers code for free ;). It's what we'd call over here Putting your money where your mouth is
Ok, too positive for Kev I think. Time for the bad points:
- The Emulator - ok I know I said this was good above but actually using the thing and integrating with IDE is appalling. Sometimes the package gets to the emulator, some times it doesn't. When it gets there sometimes it's activated, some times it just fails. This isn't due to changes, this can be the same distro every time. Get used to typing "adb kill-server" alot.
- The JDK implementation - well, they broke a few things by not matching the API. Most notably for me the DOM implementation, just something as simple as returning null instead of the empty string for unset attributes can break anything that used the contracted as stated... lots of recoding here
- The Eclipse plugin doesn't grok project dependencies - this is absolute killer for work flow. You can't keep projects separate but joined, constantly having to build a JAR of the dependencies sucks for rapid development. The packaging process also can't handle there being more than one version of a class in the classpath - that'd going to get really interesting when integrating with version-ed libraries.
- Resource handling under Android blows heartily. In Java it's extremely common to use the class path to reference resources that your code makes use of, be they SQL scripts or game sprites. In fact, large chunks of the JDK are dependent on this very feature. In the land of Android all the classes are baked down into this .DEX file - which is used on the platform. This doesn't account for non-class files placed in the class path so you need some other method. Ideally it would have been something simple, like the resources got packed into a zip file along side the DEX which could be accessed in the normal manner - but oh no, lets go back to the dark ages. It's like working with flipping Flash or MSDEV. Every resources gets an ID - like it didn't have one before - these resources have to be a specific directory. The proper way to access these resources is using a constants class which is created by reading the directory by the IDE. Ick Ick Ick Ick! I'll probably just code round this one, but it's really a misunderstanding of java practice
- Performance advice - is given along with the SDK. It essentially says employ all the J2ME hacks you always have. Is this really a step forward or just an extension of the existing API? While and API extension would be welcome, it'd be a lot nicer to see those nasty little hacks disappearing
All in all, it's looking pretty good, especially for a first release. I'm sure at least some of the negatives above are listed on FAQ and readmes some where - but heh, who reads them? The did do one thing very right, very stylish logo:
Hopefully, assuming these tablets work, I'll get some more time to work with the beast and we'll see how it goes.
Wow I got dugg, why don't you Digg It
