Gears is a browser add-on created by Google to provide you with easy ways to enhance a Web application by adding lots of features to it. When combined, these features can lead to offline functionality for an application. The API is very simple and the coding is JavaScript—it for any Web developer to learn it in a relatively short time.
Gears is available on Windows for Firefox 1.5+ and Internet Explorer 6.0+, on Windows Mobile 5+ for Internet Explorer Mobile 4.01+, on Mac OS X 10.4+ for Firefox 1.5+, and on Linux for Firefox 1.5+. A version for Safari is in beta, and Opera 9.5 will support Gears.

A common misunderstanding about Gears is that it is simply a tool to make your Web application work offline. Because of this misconception, many developers do not make the most of Gears—many applications are not suited for offline work, so is no reason for developers to study Gears. This is wrong, because Gears is much more than that. It offers so much functionality to Web applications that every single application could benefit by using it. And the list of features that Google plans to integrate into Gears is growing every day (you can find the list of these new features at http://code.google.com/p/google-gears/w/list). We will examine this list later and discuss several of the more interesting features, but for now let’s look at some of the existing features that can dramatically improve you Web applications.

Before moving along, you’ll first have to enable Gears for your application. To do this, include the gears_init.js file on all of the pages that will access Gears functionality. This file can be found at http://code.google.com/apis/gears/gears_init.js.

I Don’t Want Offline Functionality. How Can Google Gears Help My Application?

Gears can help in so many ways that is impossible to give a single answer to this question. However, here are some of the most common ways that Gears can benefit your application.

1. Speed

Visitors to your Web application hate to wait while the browser loads the page. In most cases, the important data is actually the smallest part being transferred, while the same files (static images, stylesheets, JavaScript, flash, and so on) are sent over and over again, consuming most of the bandwidth, thereby slowing down the application and annoying the visitors. Of course, browsers have cache, but this is not the best solution. Often, the cache can be too slow, too long, or too short for the viewer’s needs. Furthermore, visitors using cached stylesheets will have a poor visual experience if you change the look and feel of your application.
Google Gears changes all of this. It provides you with access to a fully managed local cache where you decide what to store, and for how long, and the cache will be always up to date with all changes that you make to your application. Applications that benefit the most from implementing Gears as a local cache management system include:

• Online galleries, photo albums, and presentation sites with lots of photo/movies/audio. You can get an incredible boost in speed (10 times faster) by using Gears to store all “heavy” content locally for these types of applications.
• Design-heavy applications. Applications that use rich design, including flash banners, big photos, and lots of stylesheets, should use Gears to store all design elements locally. The loading speed will be greatly increased (five to eight times faster, depending of the content of the site).
• Forums and discussions groups. Again, all static files should be stored locally. While it may look like these kinds of applications do not contain many static files, users’ avatars are loaded on every page on every topic. Additionally, many posts contain embedded media that will load every time that topic page is loaded, even when visitors are just for checking to see if a new response was posted) and, of course, there are the design files. Depending of the content of the forum, using Gears for caching static files can boost the browsing speed up to three times faster.

How to implement it

Perhaps the easiest and fastest way to implement Google Gears in your application is to identify the static resources that you want to cache with Gears and write them all in a manifest file. An example manifest file can be found at http://code.google.com/apis/gears/tutorials/tutorial_manifest.json. This is basically a JSON object. You can find out more about manifest files at http://code.google.com/apis/gears/api_localserver.html#manifest_file. An easy way to identify the files that take too long to load is to use the FireBug add-on for Firefox. The Net tab will show all files transferred from the server and the transfer time for each one.

After the manifest file is ready and saved in a place that is accessible by the application, create a new JavaScript file with following code:

var localServer = google.gears.factory.create('beta.localserver');
var store = localServer.createManagedStore('test-store');
store.manifestUrl = '[path_to_manifest_file]';
store.checkForUpdate();

Include this new file after the initialization script. The best way to do this is to have a common header for all pages and add following code in the <head> section of the application:

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

Visitors to your site can now take advantage of Gears caching. When a user accesses your site, he will be prompted to use the browsers’ Gears functionality. Once a browser’s Gears functionality is turned on for your site, all files from the manifest will be transferred to the user’s computer. All requests that the browser makes to the URLs that are cached locally will be automatically served from the local version. The manifest supports versioning, so you can force all clients to synchronize to the local stored data just changing the version number of the manifest on your site. All data synchronization is done in background and will not affect the client’s experience of your Web application in any way. If a visitor to your site is using a browser that doesn’t support Gears, the application will gracefully degrade to the old/normal functionality.

2. Advanced Caching

Gears provides a level of caching that goes beyond that provided by browsers. This advanced caching uses a local database server (SQLite) and an API (to access the server). Using this feature, applications can store redundant data in the local database and move intensive database queries to the client machine—it’s like having a huge distributed database for free. This kind of implementation is typically used in applications that have users running heavy database queries. Advanced caching can split a big query with lots of joins, and store the results of the joins in a local database. To execute the final query, simply select the data that is stored locally.

The Gears advanced caching feature can also be used for forums to create a local cache of the content of recently visited or favorite topics, improving loading time and browsing. The application will only go to the server for posts that have been added since the last visit; all other posts will be retrieved from the local cache.

How to implement it

It’s easy to add local database support for your application. Open the manifest file you created in the previous section, and add following line of code:

var db = google.gears.factory.create('beta.database');

The application is now ready to use the local database. db.execute(‘sql query’) will be available in all .js files. Actual implementation of this feature varies by application, but in general, the first step is to create a table structure so that it will execute a “create table” query. There is no standard way to populate local database. All depends by the nature of the application. Some applications needs all data to be available locally from the start. Those will use a script to populate local database when first page is loading. This method is not recommended for high data transfer because the loading time will be increased and user experience will be deteriorated. If it is possible, best way to populate database is using workers that run in background and will synchronize local database while normal functionality will not be altered. You can find out more about local databases at http://code.google.com/apis/gears/api_database.html.

3. Local Full-Text Search

If you are implementing advanced caching, you can add a full-text search feature for the local database. Caching the database locally makes it possible to implement full-text searches on the client’s machine, freeing lots of resources on the server. Again, this is like having a huge distributed database system for free.

This implementation is suitable for all applications that are use full-text searching. MySpace has implemented Google Gears for locally caching the inbox and running full-text searches against the local data.

4. Prevent Browser Freezing Caused by Intensive JavaScript

Many applications use complex JavaScript code for different tasks. This code is usually executed quickly and is not noticed by the users. Sometimes, however, something goes wrong: the network is busy or there is simply too much data to process and the script will take longer to execute. In this time, the browser will “freeze” waiting for the script to finish. Most browsers will detect when a script is stalling and will offer users the option to give the script more time or to interrupt it. Google Gears provides a nice way to avoid this entire circumstance by using workers in a WorkerPool. WorkerPools allow the application to run scripts in the background without blocking script execution on the main page. WorkerPools also provide a level of code isolation; any variable modified in a worker is not visible to other elements unless it is explicitly passed from the worker. You can find more about WorkerPool at http://code.google.com/apis/gears/api_workerpool.html.

How to implement it

First, add the following line of code to the application in order to initialize the WorkerPool:

var workerPool = google.gears.factory.create('beta.workerpool');

Next, specify where incoming messages should be sent. To prevent messages from getting lost, do this step before creating any workers.

workerPool.onmessage = function(a, b, message) {
 
   alert('Received message from worker ' + message.sender + ': ' + message.text);
};

Create a new file (worker.js) to store the workers. Next, open the “main” file and specify the URL of the file containing the workers (worker.js)

var childWorkerId = workerPool.createWorkerFromUrl('worker.js');
workerPool.sendMessage('Hello, world!', childWorkerId);

Use the following code to create a worker in worker.js:

var wp = google.gears.workerPool;
wp.onmessage = function(a, b, message) {
   wp.sendMessage('Received: ' + message.text, message.sender);
}

Workers use messages to communicate with one another. Any member of a WorkerPool can communicate with any other member by using sendMessage(). The WorkerPool message handler, onmessage(),works like any other JavaScript event, except that once the handler is triggered, it will create a queue to hold all other subsequent message events until first one returns.

Applications can contain any number of WorkerPool instances. These instances are all isolated one from another, thereby preventing collisions between them.

5. Move Part of the Application Functionality to the Client Side

Applications that provide interactive usage, such as editor applications, can benefit from having part of the application’s functionality moved to the client machine. For example, in calendar editors, mind map editors, or text editors, the number of request can be overwhelming—each user action results in a request to the server to record that action. If, however, you use Gears to move part of that functionality to the local machine, you can reduce the number of requests to the server. Instead of recording every user action, the server can carry out manual or periodical saves. This can eliminate up to 90% of the total requests made to the server.

6. Make Data Available Offline

Many applications allow users to store information, like personal messages, schedules, calendar events, memos, search results, and reviews. It can be a great benefit to users to be able to access this information offline at a later time, especially on mobile devices.

How to implement it

Basically, making data available offline is similar to caching a static page, but in this case, the URL is not fixed; the URL of a search results page usually contains all the parameters provided for that search. It is impossible to create a static manifest to store all possible combination of URLs that can result from any search. Fortunately, there are two solutions: the first is to create the manifest file dynamically and modify it dynamically. This implementation is identical to the one discussed earlier in the “Speed” section. An alternative solution is to create a ResourceStore instance. ResourceStore is a collection of cached URLs stored and served locally by Gears. The main difference between ResourceStore and ManagedResourceStore (discussed earlier) is that ManagedResourceStore uses an external file called manifest to get the list of URLs that are to be stored locally, and ResourceStore does not use the manifest. Instead, ResourceStore will store URLs using a capture() instance method. Use the following code to implement this feature (this code assumes that the server is an instance of LocalServer):

var store = server.createStore(’store_name’);
store.capture(url_of_the_search_result, funtion_to_be_called_after_finishing())

You can find out more about ResourceStore at http://code.google.com/apis/gears/api_localserver.html#ResourceStore.

7. Make an Application Work Offline

While not the only implementation of Google Gears, making applications work offline is perhaps its primary goal. You can use Gears to allow applications to work normally without an Internet connection. Of course, not all applications are suited for offline use; for example, it wouldn’t be practical to run a search engine offline due to the immense amount of data that would have to be stored locally. When determining if an application is suitable to work completely offline, consider the amount of data that should be stored offline or synchronized. If this amount of data is manageable, then almost any other online functionality can be reproduced offline. Even file uploading is supported in offline mode, since those files can be synchronized and uploaded in the background on the server once an Internet connection is available.

How to implement it

Implementation is dependent on the nature of the application. Here, I will present basics as they pertain to a forum application.

First, download gears_init.js from http://code.google.com/apis/gears/gears_init.js.

Next, create offline.js and worker.js (these two files will be empty for now).

Include these three files in your application header.

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

Next, we will define a managed store, a resource store, a database, and a worker pool in offline.js. I recommend creating a separate namespace for each Gears implementation. Add the following code in offline.js:

var Offline = {
 /* db, localServer, resourceStore, managedStore */
     db: null,
     server: null,
     store: {resource: null, managed:null},
     initialized: null     initialize: function() {
  /* check if Gears is installed and has rights to access our application.
  /* dialogInstallGears is a function that displays a message asking the user to install Gears */
          if (!this.isEnabled()) return (isIE || isFF) ? setTimeout(this.dialogInstallGears, 100) : null;
          else {
               /* If the first time we try to use gears, we get an exception, the user clicked 'deny' in the security*/
               /* warning dialog. We treat it as if gears is not installed. */
               try {
                    this.db = google.gears.factory.create('beta.database', '1.0');
                } catch (ex) {
                    return alert (’Gears need to be allowed for this site to enable offline functionality’
                }
               this.initialized = true;
   
               /* If anything else fails, we have some problem... not sure what. We try to log.. and that's it. */
               try {
    this.server = google.gears.factory.create('beta.localserver', '1.0');
    this.store.rstore = this.server.createStore('resource_store');
    this.store.mstore =this.server.createManagedStore('managed_store');
    this.store.mstore.manifestUrl = '/manifests/resources_manifest';
    this.store.mstore.checkForUpdate();  
                } catch (ex) {
                    this.initialized = false;
                    log_the_exception }
           }
      },

At this point we have Gears enabled in our application, and there is a managed store, a resource store, and a database initialized, all under the Offline namespace. For example, resource store is located at Offline.store.rstore. To capture a URL, use Offline.store.rstore.capture(), and to run a query against the local database, use Offline.db.execute(). From this point on, the code will be specific to the application, but the API is enabled and ready to use, and it shouldn’t be difficult to port the application to offline functionality.

8. GeolocationAPI, latest feature in Gears

This API provides the geolocation of a device running a Gears-enabled Web browser. It will allow Web applications to retrieve the user’s current position. The API will provide the following features:

• One-shot position requests (“where am I right now?”)
• Repeated position updates (for example, for continuously updating one’s location on a map)
• Ability to get the last-known position cheaply before doing an expensive new request
• Compatibility with future use as a singleton in the standard DOM (for example, window.geolocation)

The Geolocation API provides the best estimate of the user's position using a number of sources (called location providers). These providers may be onboard (GPS for example) or server-based (a network location provider). The getCurrentPosition and watchPosition methods support an optional parameter of type PositionOptions which lets you specify which location providers to use.

How to implement it

Current position can be acquired by using a GSP device if there is one available, by using CellID information in a mobile network, by ip, by wireless location data providers, or other types of those providers. To get the most reliable source of information may look as a pain. But, using Gears Geolocation API will make the things much easier. All is made transparent, so only function that is called is:

getCurrentPosition

This function will automatically choose the best location provider available and will use it to get the location. Of course, a location provider can be choose manually by passing a parameter to this function.

To write a basic, working example we need first initialization of geolocation:

var geo = google.gears.factory.create('beta.geolocation');

Then, the call to get current location:

geo.getCurrentPosition(updatePosition, handleError);

And, in the end the callback functions should be defined. Those will be called with position object, respectively with positionError object:

function updatePosition(position) {
   alert('Current lat/lon is: ' + position.latitude + ',' + position.longitude);
}

function handleError(positionError) {
   alert('Attempt to get location failed: ' + positionError.message);
}

For more information about GeolocationAPI and detailed documentaiont, visit: http://code.google.com/apis/gears/api_geolocation.html

Not-So-Obvious Things About Gears

Documentation for Gears is straightforward and very easy to follow, understand, and implement. Still, there are several things that are not so obvious in the beginning, and it can take some time for you to figure out what is happening.

First, we must pay attention to the manifest file and the URLs from that file. Usually, URLs for images, .css and .js files will contain ?some_random_number at the end. Because of that, my_cached_file.css will not be the same as my_cached_file.css?some_random_number_1 or my_cached_file.css?some_random_number_2. The result is that the data from your local datastore will not work. Instead, you will need to specify the ignoreQuery:true option in the manifest for that URL. This option specifies that all parts of the URL after the question mark (?) will be ignored and all the previous files will match the locally stored URL.

This option is not always appropriate, however. If, for example, you have a help file based on a particular parameter and you want that help file to be served from the local store, this option would be bad. For example, the three URLs, /help.html?topic=get_started, help.html?topic=features, and help.html?topic=faq might be totally different resources in your site, but will match same file (help.html) in the local store if you use the ignoreQuery option. For this kind of situation, you have to use the full URL, including query parameters and ignoreQuery:false in manifest files. If the ignoreQuery parameter is not specified in the manifest, the value False will be used automatically.

Gears provides no security of data stored locally, so it is entirely up to the programmer to not store any sensitive data on a local store. Currently, offline data encryption/decryption is completely under the control of the local machine, and any user with access to that machine could conceivably access the data.

Features to Watch for in the Future

Here are several features that Google plans to add to Gears. These features will likely mean a big step forward for Web development.

1. Audio and Video API

This proposed API will allow Gears to encode audio and video files directly on the client machine. Users will then be able to preview these files locally. With the huge quantity of media files that are embedded in many sites, this would be a great feature. Currently, users can upload audio/video files, which are processed on the server and embedded on the site. Some sites allow users to stream a Web cam and microphone, and then preview the processed recording. In most cases, users require several tries to get a good recording. All those tries eat bandwidth and processing power and time. With this new API, all processing will be moved to the client and only the final version will be sent to server. The result will be less wasted time.

2. ImagingAPI

• This API will allow offline photo editing. Operations that will be supported include:
• Basic operations (crop, resize, scale, rotate)
• Primitives (affine transforms, color transforms, convolution matrices, lookup tables)
• Drawing images onto canvas from local file/remote URL
• Saving images (after manipulation) onto local file or posting it to a remote URL (we get this functionality by virtue of using the Blob abstraction)
• Integration with Gears Blob and URL capture
• Support for BMP, PNG, and JPEG formats
• Annotation (support for basic text)
• On-screen rendering (real-time as opposed to via the BMP encoded capture URL through HTTP).
• This means that all drawing, manipulation, alterations will be done directly on the screen, without necessity of using a BMP image as a place holder and execute a HTTP request for each action.
• Clippings of arbitrary shapes
• Drawing primitives
• Support for color lookup tables
• Cool photo stuff (redeye removal, smart scissors, magic wand)
• Support for color depths other than 32 bpp
• Better support for nondestructive edits

This API could be great for any site handling user photos. Currently, most photo sites offer online photo editing that is done on the server. With the ImagingAPI, all processing will be moved to the client.

3. NotificationAPI

The Gears NotificationAPI will provide desktop notification from Web applications. It will be responsible for managing notifications from Web applications and showing them on the user’s desktop. Incoming notifications will not be displayed when the user is considered unavailable, for example, when the user is away, idle, or in full-screen presentation mode.

Notifications will be displayed in top-most balloon-styled windows. In Windows, balloons will always appear, starting in the lower right corner of the primary screen’s working area and go upward. On Macs, they will start at the upper right corner and proceed downward. The balloons will be constrained to ensure that they do not take up more than 75% of the height of the working area.

These are just few examples of the potential future of Gears. For more details, visit http://code.google.com/p/google-gears/w/list and the GoogleGears discussion group on GoogleGroups.

Live Applications that Are Using Gears

Gears is relatively new (only one year old), but there are already several “big” applications that integrate it. Here are a few of the many Gears success stories:

Google Reader
Feed reader from Google.
The Gears integration was added in May 2007.
Lets you read the most recent 2000 posts offline, without having access to images and enclosures. You can also star posts or tag them.

Remember the Milk
Task management application.
The second application to enable Gears, six days after Google Reader.
Most of the functionality is available offline . “Not only can you access your lists, but you can add new tasks and notes, edit existing tasks (complete, postpone, prioritise, tag, and change due dates to your heart’s content), use your own personal tasks search engine, create new Smart Lists, and more.” (from Remember the Milk site).

Zoho Writer
Online word processor.
Has supported Gears since August 2007, with an important update in November and Windows Mobile support since March 2008.
A number of recent documents can be viewed and edited offline.

PassPack
Online password manager.
Launched in September 2007.
“With the Offline Version, you can download your data from your PassPack account, then access and manage it whenever you wish. This is not a read only version, you are free to make changes and save them locally. To synchronize your online and offline accounts, use the backup and restore functions.” (from PassPack site)

MindMeister
Online mind mapping.
Launched in November 2007.
As explained on a MindMeister help page, “The MindMeister Offline Mode allows users to work on their mind maps even when they're offline, i.e. not connected to the Internet. All changes will be saved locally and synchronized back into your MindMeister account the next time you go online.” (from MindMeister site).

Buxfer
Personal finance manager.
The Gears support was added in January 2008 and was extended to Windows Mobile in March.
The application has the option to store the authentication information offline. “You will have the convenience of not needing to login into your financial institution repeatedly, as well as the peace of mind that your private information is secure and completely under your control!” (from Buxfer site)

Autodesk Labs Project Draw
Create diagrams online.
Launched in January 2008.
The application can run in the offline mode and synch files later when you reconnect.

Google Docs
Online word processor.
Experimental launch for a small percent of users in March 2008.
Allows you to view and edit documents offline.

Picasa Web Albums Mobile
Photo sharing.
Offline support for Windows Mobile 6 touchscreen devices available in April 2008.
Allows you to view photo albums offline.

Paymo
Time tracker.
Gears-enabled in April 2008.
Google Gears added the “ability to work offline and sync the data with the Paymo server once an internet connection is available.” (from Paymo site)

MySpace
Searching messages received from friends.
Gears integration was launched on May 29.
Google Gears allows users to search and sort their messages locally, as MySpace considered it to be “time consuming and cost-prohibitive to add indexes on the server.” (from MySpace site)

Conclusion

Gears is a big step forward in developing rich Internet applications. Many people are comparing Gears with HTML5. However, Gears is not a successor to HTML5; it’s more of a predecessor. HTML5 is a standard, but is not yet finished and, after it will be finished, will take several years before will be enough people to use HTML5 compatible browsers to be used in Web applications. Until then, Gears provides many of its features with the help of a browser plug-in. On the list of future features for Gears is to make the code written for Gears compatible with HTML 5. Because of this, coders working with Gears today will have a headstart on HTML 5 tomorrow. And most important, Gears is not “just” for making an application work offline. It can enhance Web applications in many, many ways, bringing those applications one step closer to desktop applications.

Read more from Eduard Martini.