I took some time over the last week to port our CheapGas application (which finds the lowest priced stations near a given vicinity) to Android. I wrote this application in Rails originally. It supports both our runner and arbitrary WAP clients (using just one controller via techniques described in this blog). This port was to just build an Android client and call back to the my Rails-based controller of the production CheapGas app.

In the bigger picture, the tag-based approach that our platform would be a better way to do this. We could just send out tags and a “forms runner” running on Android could spew out the appropriate Android widgets dynamically. This has the obvious advantage of allowing a single codebase for multiple platforms. But, more fundamentally, it allows for a more dynamically changing user interface on the device, driven by server-based business logic. This also happens to be the approach taken by ZK Mobile. Certainly this is part of the appeal of web-based applications in general, and given Google as the standard-bearer of web-based apps versus “thick desktop” equivalents, it’s curious to see the out of the box Android bias towards statically designed interfaces.

Exploring that apparent paradox might be another post. Today I’ll just provide some more tactical feedback on what I’ve seen in building a single application, with conventional upfront XML-based layout and the application running locally (as opposed to a runner interpreting server-delivered UI elements and forms). To start off with, let me say that, given the constraints of wanting to build an application that is laid out up front, I like the Android toolkit. I was able to build a functioning application fairly quickly. The overall Eclipse-based environment is easy to use and debugging was a breeze. That said, I have several bits of feedback of areas for improvement:

  • The API is just not completely documented. I found myself guessing and experimenting many times to determine the precise behavior and requirements of an API call. Example: setting underline paint style doesn’t work to create underlined text (e.g. “textField.setPaintFlags(android.graphics.Paint.UNDERLINE_TEXT_FLAG);”). Instead it creates a strange, faintly visible font. There may be some other way to do it, but it just plain isn’t documented. There are ways to set bold and italic styles, but apparently not underline (or its just not done yet)
  • The componentry is a strange mix of simple low level “simple individual controls” (editable text, spinner, checkbox, radio buttons) and “high level” controls such as imageswitcher and gallery (which are somewhat overlapping). What is needed is more of the “intermediate controls”. For example, more advanced list and grid behavior (such as our “fisheye” control). One guesses that they are waiting for third parties to supply these. Or they just haven’t done them yet themselves.
  • Would be nice to have XPath with DOM usage instead of being forced to use just DOM navigation methods (e.g. getElementsByTagName). This is a potential memory and performance hog.
  • The Android emulator is astonishingly slow. Yet despite Android’s own slowness, calls to other systems which take reasonable amounts of time result in timeout dialogs popping up. These include not just calls to my own server-based backends over the Internet, but also calls to other Android activities such as their contacts list and phone dialer.
  • Linkify.addLinks() is a very handy utility method to create links from text (though I’m not even sure how I found it). It would be even cooler if that utility could optionally create onClickListener() methods for those links. The code for creating those onClickListener() methods to respond to those links is repetitive and should be automatable.
  • It would be very useful to be able to create indexed arrays of elements (that can then be iterated through) through XML layout
  • Given Android’s lightly documented state, a drag and drop layout designer would obviously be desirable. DroidDraw is a useful utility but doesn’t expose all options.

[Posted Later By Adam in Response to DroidDraw Developer Brendan – Since Mephisto Comments Mysteriously Stopped Working] As far as “unexposed properties” it would be nice to have “maxlines” on TextView control (that’s one that springs to mind, I think there may be a few others). What would also be nice to have is either dropdowns on control height and width properties for wrap_content and fill_parent options. It would also be useful to be able to specify width in other units available (px, ems, etc.) by switching between units from a dropdown list.