Wednesday, October 22, 2008

Checking Out Android's API II

So, pretty much every 3d party application on a smartphone really needs to do two things these days to be useful: get information, and display it. In the previous post I mentioned that Google's Android has some very interesting facilities for programs to talk to the rest of the environment, getting data from the information repositories in the phone like the phone book or the GPS system or any other storage system that gets added and makes it known it has information to share. What about displaying, then? How much of a pain is it to create a visual that is up to modern standards of beautiful mobile applications?

Well, on first glance the drawing facilities look really familiar to any J2SE programmer, or anyone familiar with most other windowing toolkits: there's a Canvas object of some kind that the system gives you for your program, to execute calls on like 'draw a circle' or draw a line' and you can pass an object to describe attributes like what color to draw in, how thick the line to draw with, etc, called a Paint object.

Now, as a programmer, the minimum you need to make any kind of display is to be able to draw a single pixel in a specific color. Once you have that, you can make as elaborate a screen as you want as long as you have time to measure which pixels should be what color for text, for shapes, for the image you want to display. Of course, the more of these common items to display the API has calls for, the less a rogrammer has to make calculations and libraries for, and the quicker you can release, and the quicker your program will be as these operating system calls will use the hardware much better than a 3d party program can.

There's of course a library for widgets like radio buttons and sliders so a UI with forms can look familiar, but Android looks to have quite the interesting set of calls there for custom graphics: the Paint object understands transparency, the Canvas has full text displaying facilities including shaping text to follow a path, it understands a good set of shapes and the painting of images loaded from files, and you can add a matrix as an argument at just about every Canvas call to display an object. That last part is actually really useful because it means the system makes it easy to do things like zooming and rotating any object you want to paint, and programmers can be sure the available hardware will be used effectively for these calculations.

I was also interested to find a set of animation object libraries to be able to quickly define how specific objects should move or change shape or become more or less transparent, with helper objects to define timings. Ok, this is not a ready replacement for an Adobe's Flash ActionScript ready to go and built in, and the library looks a little sparse, but it is a good start.

All in all it is more than I had available when I was doing Swing or J2ME as little as a year ago, and it should make beautiful apps a lot less painful to make. If the system is also smart and cool enough to manage the transparency of the Canvas properly so the contents 'below' the current app can come through even if the current app doesn't know what they are, some really interesting UIs become possible.

I have to say, I am tempted to find my OS X CD and install XCode to compare this with the iPhone API. Maybe if anyone asks.