27 months

We’re in the early stages of building a web application with a big requirement: the ability to work seamlessly in an offline and online mode. The Internet and cloud computing are great, but you can’t always be plugged into them. Connectivity is a big limitation in much of Sub-Saharan Africa where our app is designed to be piloted. Enter Gears.

Since its initial release in mid-2007 as Google Gears, I’ve kept an eye on the dev community’s adoption of Google’s open source solution to the so-called “offline problem”. Using the earliest Gears-enabled apps such as Google Reader offline was a curiosity when I was used to having persistent broadband. Over the past year in Cameroon, it’s become a necessity. I’ve been in the habit of using Reader offline almost daily. The same applies to WordPress, which added Gears support with its “turbo” mode in version 2.6. Gears helped both of these apps make my Top 20 Tools for 2008 list.

One advantage of our app architecture is that we can rely on a local Apache web service, PHP and MySQL to handle the heavy lifting involved with data collection in the field. In most scenarios, we’ll rely on a USB-based LAMP stack for this, but clients will have the option of doing a traditional installation as well. In this mode, fieldworkers are offline but still have all the processing advantages of a portable web server. The local “field data” store is later synchronized with the server when a connection is available. No need for Gears here…yet.

The fun starts when an Internet user wants to take the data we’ve aggregated offline. This might be done with a desktop, laptop, smart phone or what-have-you. To enable this, we need to communicate with a local data layer in an offline mode on the client and, optionally, synchronize their data with the remote server when they go back online. Gears lets us get this done by providing three things: 1) a local server to cache and serve resources (HTML, JavaScript, images), 2) a local database, and 3) a worker thread pool to allow processing to go on in the background.

These three components are represented by the LocalServer module which works in conjunction with embedded SQLite database module and a WorkerPool. The approach taken with Gears is to isolate the data layer with a “data switch” that permits data storage and retrieval requests to pass through a common interface. This intermediate object can then decide whether to retrieve the data from the server, the local store, or some combination of both, illustrated like so:

Once Gears is installed on the client, creating a local database is a snap:

<script type="text/javascript" src="gears_init.js"></script>
<script type="text/javascript">

function CreateDBAndTable() {
    var db = google.gears.factory.create('beta.database','1.0');
    db.open('myDB');
    db.execute('create table if not exists Foo(Phrase text)');
    db.close();
}
</script>

We don’t have the processing power of server-side scripting provided by PHP at this level, but at this point we don’t need it, really. Of course, since Gears doesn’t automagically make our entire app function offline, we’ll have to decide which offline features to implement using the Gears API.

Another consideration we’ll need to make early on concerns modality. That is, whether the user is given a “modal” option of switching to an offline mode (as in Google Reader’s “online/offline” button) or if the app is to work in a “modeless” fashion. There are advantages and disadvantages to both approaches. The latter is more difficult to implement, but can be argued to provide a better user experience. For the purposes of our beta release, I’m leaning toward a pragmatic decision to make our app modal. But you never know—we might have tons of time left over before June rolls around.

Gears is still in beta (version 0.5.4.2 as I write this) and licensed under the New BSD license. It’s still considered a developer-only release, but it’s demonstrated itself well enough in the open source community that I think it will serve us well. I’m excited for the opportunity for our team to get their feet wet with it.