How Web Developers can Build Apps in HTML5 (and natively on Android )

In June of 2009,  Neptune Web  launched a new version of T-on-Time, the web app which takes advantage of MassDot’s new real-time data feed for the commuter rail. I’m proud to say we were the first app to do this, since we released the app within a matter of days after the feed was announced.  Contrary to “apps have already been released” in the press releases, it did not take 2 days to develop this app. We participated in an open, MassDOT, trial feed. The actual app and its constituent parts took months to develop and test.

In a previous post about Adobe AIR, I had talked about the Desktop version of T-on-Time, developed in Adobe Air – a platform which I still feel has great promise. T-on-Time Desktop was a contest entry, done mostly on “personal time”, and was more of an amateur (as in “not full time” - not as in “rookie”) effort.

The new T-on-Time “Suite” was a corporate effort, and was much more complete in its approach. 

In this version, the addition was the mobile version. However, to retain the value of the original Adobe AIR Desktop version, we combined Desktop with mobile to create a “suite” of commuter tools. The entire “Suite” now consists of:

• The original desktop version re-branded as part of the suite
• An HTML5/web/mobile app, sized to fit hand-held devices
• Android native app
• Android store presence
• A web site to tie both Desktop and Mobile version together.

For web developers, it should be noted that each of these pieces can take a lot of time, and can affect the cost of your project. For example, one would think that developing an Android app code, you automatically get Android store presence. However, you still need to market your app within the store. Developing the images, copy and configuring your account within Google store are fairly time-consuming tasks. Developing that 3-4 page “app” marketing web site can be misleadingly time consuming. Although “app sites” are more or less templatized, coming up with something everyone agrees on is another story entirely.  If you take this approach, be sure to add that time into your estimates.

That covers the background. Why did we decide to cover HTML5/web , followed by Android native, first? Why not cover iPhone or Blackberry?

As I mentioned in my previous posts, I have focused on technology web developers are familiar with first. Learning Objective C and XCode  gets web developers (who are familiar with Javascript/HTML/CSS and web server-side languages such as PHP or ASP.NET) way overextended. This is a big problem with the iPhone platform for me. Blackberry poses the same problem. Although Android has a similar environment, I find it much more open than xCode/iPhone, using the Java language, and with a faster growth projection.

HTML/JavaScript is really the “first” platform for web developers. I hope someday the Android market and iPhone store become mere marketing vehicles for people to find your apps - no longer the only way to deliver your app. I’m sure Google and Apple don’t feel the same way.

Anyway, here’s how the HTML5/Android app works.

1. First, develop for HTML5/web only, developed in the browser. You can use all the familiar tools. Firebug or Chrome debugger. No need to compile or run a (very slow) emulator. Just reload your page to see your changes using local HTML/CSS and JavaScript. (See note below about disabling cross domain restrictions for local code).
2. Build an Android “shell” to hold the HTML5 app, using WebView classes.
3. Convert your data storage to use native Android. Use the JavaScript integration to make functions available to conscript, which call native Android features.
4. Load your local content, containing Javascript and even jQuery, found in the /assets/ folder like this webview.loadUrl("file:///android_asset/tontime.html");
5. Possibly build an iPhone shell
6. Share code with web version and “assets” folder of Android app

A sample Android resource, src and Manifest.xml (Zip Format) to get you started with your Android version is included here.

A few things worth mentioning:

1. Never rely on the Internet unless you really need it. For example, don’t use cookies just because they are familiar to you. If you just need a place to store data, use local storage instead.
2. When testing your app in the browser, you can avoid XSS/Ajax cross-domain limitations by testing in Chrome like this:

C:\Users\me\AppData\Local\Google\Chrome\Application\chrome.exe --allow-file-access-from-files --disable-web-security
                Be sure to run as Administrator on windows.

3. Repeated downloads of XML content from the Internet can make your Android cache HUGE, and I found no way to reduce size of the Android cache (there were examples for Android 2.2, it’s just that none worked). I chose to clear the cache myself, by calling a Javascript interface function periodically e.g.

                public void clearcache() {
                                // trick to keep cache from getting huge since turning if off doesn't work.
                                Activity t;
                                t = (Activity) mContext;
                                WebView wv = ((tontime) mContext).getWebView();
                                wv.clearCache(true);
                }

4. When using the Javascript Interface, be sure to check the values returned from Android functions. Type mismatches between conscript and native functions cause very difficult-to-troubleshoot bugs.

This type of development can also be achieved using frameworks. However, don't forget there is a huge hidden cost to using frameworks. The costs are a) steep learning curve for you (and others. Never forget the others who will maintain your code after you) b) lack of ability to troubleshoot deep technical problems due to the layer between which hides things from you.

Well gotta run (to catch a train). Best of luck with your Android/HTML5 apps!