Building an offline web app

In March, CCNMTL shipped a laptop to a South African AIDS clinic as a part of a multimedia health-care intervention.

We're not that experienced with desktop application development, so the main discussion was how do we bundle a web application on a stand-alone laptop with no connection to the Internet. The first proposal was to run a virtual machine (Xen or VMware) which would run the web server on the Windows desktop.

I was less sanguine about diagnosing problems with a web server across continents and timezones, and looked for a way to store state information from static web pages. Firefox's DOM Storage was close to a HTML5 standard (now finally implemented in Firefox 3.5), and seemed to work with URLs visited as "file://localhost/C:/..." so this made the following process possible:

  1. Put static HTML files on the laptop
  2. All state is stored by the browser (in a file called webappsstore.sqlite)
  3. All application storage is accessed and modified by javascript (see code)
  4. Login state uses sessionStorage which works similarly but disappears after the browser closes (like a session cookie)

Instead of supporting a virtualization and web server stack, all that's left to support is the browser--something very familiar to all computer users by now. It's worked out great.

I should note that our application is not secure from a javascript hacker who has access to the computer--they could access and change all account information on our system. Fortunately, that's not an attack vector we're worried about.

OK, there's a dirty secret behind my not posting about this previously--it no longer works! There's a laptop in a South African clinic that's not getting any Firefox updates, security or otherwise, and that's a very good thing. Now, it seems, all browsers, remove the 'localhost' from file:// URLs. The new HTML5 standard localStorage does not work for local files, and the deprecated globalStorage[hostname] doesn't work without a hostname!

HTML5 taketh away, but it giveth ath well. Instead of relying on file:// URLs, in the future we can label our site as an offline resource and then use the now standardized and implemented localStorage.

The one issue with this future approach is if we need to update the application while it's in the field. We haven't needed to do that on this project, but it's a comfort to know that if they discovered a critical bug, we could email them a single HTML file to replace, and the computer running the application does not need to be connected (to anything other than the USB key the new file is on). I sent our use cases for localStorage over to the HTML5 mailing list, but there's still work on the standards side and for the browser vendors.