The beginning of the example shows the minimal HTML table that lists the articles on the lefthand side, and the currently selected articles on the righthand side. The rest of the example is a lot of JavaScript to do both the Gears and Ajax work.

The Gears work starts with initializedb, which opens the Gears database and creates the articles table within it. The last thing initializedb does is call showArticles. The showArticles function updates the display by reading the contents of the Gears database using a SELECT call and creating <td> elements for each of the articles.

The sync function, which is called when the reader presses the Go Online link, does the Ajax work. It uses the Ajax.Request function to call articles.php on the server. It then breaks up the XML returned from articles.php and calls addArticle with each of the article tags.

The addArticles method first looks to see if any articles are in the database with the given ID, if there are, then the request is ignored. Otherwise, it adds the article to the database using an INSERT statement.

Once all of the articles are added in the sync function, the showArticles function is called once again to update the display to match what's in the database.

When I first go to the page it's blank with the exception of the Go Online link because the Gears database is empty. When I hit Go Online I see something like Figure 4.

Figure 4. The Gears page showing the list of articles

I then click on one of the articles and the showArticle code is called to replace the righthand side of the display with the content of the selected article. This is shown in Figure 5.

Figure 5. After clicking on the recently added Google Gears article

OK, so that's the rudiments of a Gears-based approach to client-side content caching.

To make the synchronization a bit more sophisticated I can, have the client request just the new articles that have appeared since it last checked. To do that I need to upgrade the articles.php page as shown below to accept an optional 'sinceid' URL argument.

If specified the script would only return articles sequenced after the particular ID. I can then upgrade the client page to get the maximum ID in the database, and pass that to the script as shown in Listing 7.

This demonstrates how you can use SQL functions in SELECT statements just like you can in MySQL or other production quality databases.

Pros, Cons, and Alternatives

As with any solution, Gears has both positives and negatives. The feature set is the obvious positive, as there is currently no other widely available offline alternative to developers. But this doesn't come without costs:

Conditional use: The customer isn't forced into use of Gears. True, it's easy enough to install Gears. But some people might choose not to. So you will need to support conditional use of the Gears API.

Complexity: This adds an additional layer of complexity to the JavaScript code on the page, especially if use of the Gears API is conditional. Ideally the backend data source for the page should be factored using a classic model-view-controller pattern. In that architecture, the model can be switched from Gears to the web server and back without requiring changes to the interface code.

Data synchronization: In applications where the user can enter data offline there can be problems synchronizing the data input offline with the server. To some degree we have this problem, called hidden updates in all web applications. But it's magnified when there is an offline mode. There are no easy solutions to this problem.

User interface: It needs to be clear to the end user when she is attached to the server and when she is offline, particularly if she is entering data. People have come to understand that the web is inherently multi-user. If one customer edits a record, another should be able to see that change because the database is a shared resource. If the data is only stored locally, then the customers need to understand that so they won't be surprised when their changes haven't shown up in the shared database. Google's own Google Reader, which is its first application that uses Google Gears, provides some insight into how to present offline versus online information to the customer.

The example I've shown in this article gets around most of these problems by being unrealistically simple in its approach. That's a necessity in an article this short. But a production use of Gears will likely run into some, if not all of these issues.

Conclusions

Google has gifted web developers with a lightweight offline solution. And developers have already started to embrace it by creating JavaScript helper libraries around it's core features. There is so much potential for what can be done now that we have an offline solution. The final article in this two-part series will show more of Gears' potential using several techniques for offline data entry.

Jack Herrington
is an engineer, author and presenter who lives and works in the Bay Area. His mission is to expose his fellow engineers to new technologies. That covers a broad spectrum, from demonstrating programs that write other programs in the book Code Generation in Action. Providing techniques for building customer centered web sites in PHP Hacks. All the way writing a how-to on audio blogging called Podcasting Hacks.