Hand on: Inside Google Gears

Take your web applications offline with Google’s open-source browser add-in

Google recently announced its Gears project, explaining that it enables web applications to work offline.

The demonstration application is Google Reader, an online blog reader. If Gears is installed, you can click an icon to go offline, and it will download the last 2,000 blog items.

You can then return to that URL and read the entries, even if the PC is no longer online. This works by downloading the data to a local database, along with the pages and Javascript code that form the application.

Reader also keeps a record of which blog items are marked as read. When you reconnect, this information is synchronised back to the internet.

Gears is worth exploring even if offline capability is not required, since it adds new programming capabilities that can make any web application smoother and more responsive.

Gears itself is written in Javascript and C/C++; it is open-source code and available for download from http://code.google.com/apis/gears. It is a browser plug-in composed of three components, along with a Javascript library to enable their use, and runs on Windows, Mac and Linux. These are the components:

Localserver – Although this sounds like a local web server, it’s not really that smart. It is better to think of it as a cache for your application’s content and script. Browsers already cache content, but with Localserver you can ensure that all the pages required for your application to run are present, and in the same version, whereas normally you can’t be sure exactly what the browser chooses to cache.

Database – This is SQLite, a superb lightweight open-source database engine written in C. It is widely used in other projects, including PHP 5 and Apple’s Core Data. SQLite has been covered in this column before; the Gears version has been extended to include full text search.

Workerpool – This lets you execute Javascript in a background thread. The advantage is that long-running synchronisation operations run without locking up the user’s browser.

Google Gears is a low-level Javascript API. There is no magic that will transform an existing web application into one that will work offline, with just a few lines of code. Rather, it is down to the developer to write the code that will make it happen.

There are several possible approaches. Google’s Reader example has specific online and offline modes. This works but it’s not great. The ideal is to have an application that works the same whether online or offline, with transparent synchronisation when connected.

One idea is to write the application primarily for offline use, adding code for synchronisation. That implies major changes to existing code that might be in PHP, Java, ASP.Net, or some other language.

All the client-side Javascript code will be accessible to inquisitive users, so avoid including anything secret. The same applies to data that gets written locally. Not all applications are suitable for Gears. Online banking, for example, is a poor candidate, since the data is confidential and transactions cannot be conducted offline.

Get started with Google Gears
The starting point for a Gears application is a Google-supplied Javascript file called gears_init.js, which sets up a factory object from which you create other Gears objects.

When your application starts, such as in the body.onload event handler, you can check whether Gears is installed and direct the user to the Gears install page if it is not.

I created a simple example, based on the code in Google’s tutorials. The startup function checks for Gears, and if present it creates a managed store and opens a SQLite database. Not much code is needed.

Here are the key lines:

//create a local server object

localServer = google.gears.factory.create(“beta.localserver”,”1.0”);

//create a managed store

store = localServer.createManagedStore(STORE_NAME);

//create a database

db = google.gears.factory.create(‘beta.database’, ‘1.0’);

//create or open a database table

if (db) {

db.open(‘pcw_gears’);

db.execute(‘create table if not exists pcw (somefield varchar(255))’);

}

A managed store is the starting point for caching content for offline use. You populate the managed store by creating a manifest identifying the files you need to cache. The manifest also has a version string. Then you can populate the store like this:

store.manifestUrl = pcw_manifest.json;

store.checkForUpdate();

At a later date the files on the server may change. In order to refresh the cached files, you update the version in the manifest. Next time the code calls checkForUpdate(), the new files will be downloaded.

Working with the database is equally straightforward. Here’s how to write a value to the database:

var inputEl = document.getElementById(‘dbInput’);

var inputval = inputEl.value;

db.execute(‘insert into pcw values (?)’, [inputval]);

and here is how you might get a value back:

var rs = db.execute(‘select somefield from pcw’);

var theValue;

if (rs.isValidRow())

{

theValue = rs.field(0);

textOut(“Database query successful”);

}

This example gets a single value, but the recordset object may contain many rows that you can step through. The advantage of SQLite is its support for standard SQL, along with fast performance.

These may be simple examples, but Gears is a revolution, giving web developers an infrastructure for offline web applications for the first time.

Gears and security
The ability to read and write to a local database brings the abilities of web applications closer to those of desktop applications.

This raises two questions. First, is Gears secure from malware that might write and execute malicious code? Second, could you integrate a Gears application with other desktop applications, which may also use the SQLite database engine?

Security in Gears relies on a principle called ‘same origin policy’. The idea is that data written locally is only accessible to scripts running on the website which wrote that data. In addition, a Gears application can only write to a restricted location on the user’s hard drive.

The location is browser-specific. This means that if you use more than one browser, you will have several independent Gears local stores that cannot interact with each other. It follows that Gears code has no way to read or write data that belongs to another local desktop application.

On the other hand, a local desktop application could in theory access a Gears database, though it would be dangerous to rely on its location or structure, since these might change in a future version. It is better to think of the Gears data store as isolated from other applications.

All the above presumes that Gears is working as designed. The code is currently in beta, and could have security bugs. In any case, Gears is vulnerable to denial of service attacks.

There is currently no limit to the amount of data it can store, so a malicious application could fill your hard drive with junk and send the CPU into a spin with useless Javascript. Currently the only protection against this kind of attack is a dialogue which you have to pass to enable Gears for a particular site.

Who else will use Gears?
When Google announced Gears, it emphasised that it was an open-source effort supported by third parties including Mozilla, Adobe and Opera.

Brad Neuberg, who works on the popular open-source Dojo Javascript library, announced that Dojo offline would use Google Gears as its base. There is certainly a degree of cross-industry support, but it may not be as extensive as Google implied.

It appears that Adobe only intends to align its APIs somewhat with Gears, and will include its own independent build of SQLite in Apollo, its desktop application platform which uses the Flash runtime.

Mozilla has already developed offline capability for Firefox 3.0, including an API called Dom Storage which lets you store name/value pairs, and may not be inclined to abandon its efforts in favour of Google Gears.

Microsoft has plans for local storage in Silverlight apps and, on past form, seems unlikely to embrace Google’s project as part of its own platform.

Despite these uncertainties, it’s likely that Gears will be a widely used de facto standard. Simply, it solves a real problem and, thanks to Google’s popularity, will be widely deployed.

Gears is cross-platform and cross-browser, making it more attractive than a Firefox-only solution. The main obstacle to adoption may be security concerns, with corporate administrators reluctant to allow Gears applications to run until this aspect has been fully investigated and perhaps enhanced with additional features.

Resources

Google Gears