Hive

I need not go into the many issues commuters face daily with the Melbourne public transport as they are well documented .

As a public transport user in Melbourne, one of my major pain points is not being able to find out how to get to a destination.

This week saw W3C announce that they have completed their HTML5 definition, including a draft 5.1 specification.

It will certainly be interesting to see how quickly the big players get in on supporting the new spec' - hopefully a lot faster than they did with HTML4! I think it might, given that there are compatibility tests already out; and browsers and mobile app SDKs are competing to get better scores (Blackberry 10 was leading the pack, and presently it is Tizen 2).

In this article about CES 2013, see the section on Smart TVs and HTML5 Apps. This is quite important if it becomes a trend. Television sets and other household gadgets have long had microprocessors in them that were just powerful enough to run the specific functions that they were designed for. Now they are capable of running Javascript and rendering HTML, the same things that were once the exclusive domain of embedded systems programmed in machine code, C, or other similarly low level languages. This could signal a trend toward the ubiquity of HTML5 as the standard for app development. Watch this space.

One of the main critiques levelled against HTML5 for app development, is its inability to deliver a "true native" user experience. Yes, it is harder to do that in HTML5 compared to developing natively. However, it is indeed possible, provided you know a thing or two about optimisation in this field. The engineers at Sencha and LinkedIn have recently provided some excellent articles on this topic.

Sencha said "So, when Mark Zuckerberg said HTML5 wasn't ready, we took a little offense to the comment" They went on to put their money where their mouth is and built Fastbook, a HTML5 Facebook app, that outperforms Facebook's own offering.

LinkedIn's engineering team has released a series of three articles, each detailing a different HTML5 app development optimisation technique which they have used to attain native performance in their new app.

Using local storage for caching;

Optimising memory and processor resource consumption scrolling through a stream;

Using websockets as an alternative to URL Scheme navigation

Personally, I feel that the main benefit of HTML5 lies in its ability to allow you to write once, run anywhere. All software engineers know the intrinsic benefits of having to maintain only a single code base across all supported platforms. It is the same reason we prefer to write methods/ classes/ libraries once and invoke them from multiple spots within the code; just on a larger scale.

I have personally done this with Melbourne Transport, together with my team, Mike and Lyn. We wrote an app, tested it in Chrome, and then ran it through PhoneGap, and voila, we had both Android and iOS apps!

However, this is not really anything new and we knew that we could do it from the get go. When RIM announced that they were holding port-a-thons for their upcoming Blackberry 10 platform, we decided to target a third mobile platform, by porting Melbourne Transport. Unfortunately, Phonegap has yet to support the latest version of the Blackerry operating system*. What we did next was to take the same source code, and simply build that using Blackberry 10's own HTML5 SDK, Webworks instead. It turns out that only a handful of trivial changes were necessary in order to for this to work, and the port was accomplished within the same day.

* A rather clunky workaround was availble, but we ultimately gave up on this.

That was indeed a great experience, and served to validate and reinforce that HTML5 apps are write once, run anywhere. This has been a learning experience for my team, and we intend to adopt HTML5 as our core strategy in writing mobile apps. We have already started doing so for our next project, Hive.

Time to rock and roll!