David Kelly

Growing numbers of web applications have been dipping their toes into providing offline access using Gears. Recent examples include Google Reader (Google originally developed Gears before releasing it as an open source project), Remember the Milk, WordPress (in Version 2.6), with planned integrations from MySpace and Gmail.

Offline access provides a way for a user to interact with the application when an Internet connection is unavailable, something “traditional” web applications cannot do. Gears also provides a means to improve the performance of apps by storing all the files necessary for them to operate on the user’s computer (meaning no need for downloads of images, script files, css, etc). An example of this is shown below.

Gears achieves this by providing a number of features through its API:

• A “Localserver” capable of serving files stored on the user’s machine, rather than relying on a remote web server;
• A local database (SqlLite) for storing information that can be queried & manipulated locally;
• Access to a “Workerpool” which allows multiple JavaScript processes to run simultaneously – something which allows scripts to run in the background without causing the user interface to slow down;
• Other APIs available include access to HttpRequest (for use in Workerpools using AJAX), the ability to create desktop shortcuts, and a Timer.

For Gears to be used, it must firstly be installed on the user’s machine. To protect users, they must opt-in to allow certain operations to be carried out (for example, installing a desktop shortcut, or creating a local database).

An Example

In an application under development, the user needs access to a set of data that is unique to them. The data changes infrequently, but is needed regularly as either a full set, or is queried based on different conditions. In a “traditional” web application, this means frequent calls to the server which takes time, bandwidth and server processing power.  However, Gears offers an alternative. By maintaining the data on the client side, and updating it as required, the burden is removed from the server. While using the Gears approach in this situation does allow for offline access, one of the main motivations was to increase the responsiveness of the application. So, how does it all work?

First off, you need to check Gears is installed and available:


<script src="gears_init.js"></script> <!-- This need to be included every time -->
<script type="text/javascript">
if (!window.google || !google.gears) {
location.href = "http://gears.google.com/?action=install&message=Please Install Gears ..." +"&return=http://www.example.com/setup/gears/installed/";
}
else{
var db;                // local database
var localServer;    // localServer
}// else

You can see that all the code is in JavaScript – this makes sense because it is all being run by the user’s browser, not a web server. The “gears_init.js” script makes sure Gears is installed (available from Gears documentation site).  If it’s not available, the user will be redirected to an install site, and then sent back to an address you specify (http://www.example.com/setup/gears/installed/). This script also creates a “Factory” object, which is used to create all other objects.

The next step is to create a database to use and add a table to it:
// Datbase Setup
db = google.gears.factory.create('beta.database');
db.open('treatmentDB');
db.execute('create table if not exists treatment ' + '(treatment_id int primary key, treatment_name text, treatment_price decimal, category_id int, timestamp int, toUpdate text)');
db.close();

This creates a database object, and opens the database “treatmentDB” (or creates it if it doesn’t exist). The “execute” command is used to run SQL commands (SqlLite version) against the database – in this case, if there is no table called treatment, create one. I also included two fields to ensure the database is up-to-date – a timestamp, and a toUpdate field (which holds true / false flag depending on whether a record has been added to the local database, but not yet updated in the remote database).

What’s Next?

In the second part of the tutorial, the database will be populated using data on the remote server. I’ll show an example of using a Workerpool to do this, so that the operation doesn’t affect the user interface. The data will then be queried and output.

Update: Part 2 of the Gears tutorial is now available