Archive for January, 2008

Last week Yahoo announced their new mobile platform, Blueprint. It was very gratifying to see that what they have built, is, like our platform, derived from XForms.

There are a few significant differences:

1) nothing concrete is available today but the XML schema for controls and elements.

That’s not a bad thing. I applaud Yahoo for publishing their roadmap in advance.

2) in “phase 1” of the Blueprint platform, no Model-View-Controller capabilities of XForms are present

This is a bit surprising. MVC is the source of much of XForms’ power. Clearly its coming eventually. But many developers may decide that the learning curve of another syntax is not worthwhile before they see the key benefits of the XForms approach.

3) the documentation says that XPath is not available now for data binding

Confusingly they say “the current Blueprint implementation, however, has a limitation of one model and one instance per page, so there is no need to include such details”. Even with one model, I still want to be able to use XPath to perform data binding. In other words, XPath is not only useful in a case of more complex MVC separation, where a view or controller may use multiple models. Its also useful to grab data from more complex single models, especially where the model (data) may be coming from an existing web service with a nontrivial mapping to your view.

4) unnecessary deviation from the XForms standard

Where XForms has a working syntax for controls or containers, we use it. We add plenty of proprietary controls and extensions as we need to.

5) the current set of controls is fairly simplistic.

As they put it “there are no spinning image cubes”. Well and good. They are phasing things right. We couldn’t use Blueprint today though to give the look and feel of the applications that we’ve built.

Overall I think Blueprint is a great thing for both the industry and for Yahoo. If I was a mobile developer without benefit of the Mobio platform, I would certainly start using the Yahoo platform over, for example, using a procedural Java-oriented, statically compiled approach like Android.

As much as I would love to stay on Rails-based blogging software, I’ve been experiencing a bunch of strange Mephisto bugs recently. And the project seems to not really be actively maintained. So I’m switching over to WordPress. There aren’t many good options for getting all of the content over, so the comments are lost here.

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.