Gears User Guide

Google Gears

Official Gears site:

http://code.google.com/apis/gears/index.html

Google Gears Discussion:

http://groups.google.com/group/google-gears

www.intellibitz.com [email_address]

Gears - Introduction

Google Gears is an open source browser extension that lets developers create web applications that can run offline.

http://code.google.com/apis/gears/install.html

Google Gears consists of three modules that address the core challenges in making web applications work offline.

Gears - Features

LocalServer

Cache and serve application resources (HTML, JavaScript, images, etc.) locally

Database

Store data locally in a fully-searchable relational database

WorkerPool

Make your web apps responsive by performing resource-intensive operations asynchronously

Resources and Tools

http://code.google.com/apis/gears/tools.html

The gears_init.js source file

Always include the gears_init.js file in your application to get access to the Google Gears factory and APIs.

Database Query Tool (dbquery.html)

The database query tool allows you to run SQL queries interactively against a Gears database. Run from the same domain as the database to inspect.

LocalServer Inspector (webcachetool.html)

Inspect the contents of the LocalServer, capture URLs, and test ManagedResourceStores.

Detecting and Installing

Detect whether or not Google Gears is installed on a user's machine before calling the APIs, and also to display an installation prompt to the user if Gears not found.

Always initialize Google Gears using gears_init.js . If Gears is installed, then google.gears will be defined.

Detecting and Installing

If Gears isn't installed, you can direct the user to a customized installation page.

<script src="gears_init.js"></script>

<script>

if (!window.google || !google.gears) {

location.href = "http://gears.google.com/?action=install&message=<your welcome message>" +

"&return=<your website url>";

}

</script>

The user will be directed back to ' return ' URL after installation.

Factory

The Factory class is used to instantiate all other Google Gears objects. Using the create method, an application specifies the interface version it uses.

Use gears_init.js in your application for the easiest way to create a Factory object. The script defines google.gears.factory to refer to a Factory object.

Factory

API: Factory class

Object create(className, version)

string getBuildInfo()

Supported class names are:

beta.database Database

beta.localserver LocalServer

beta.workerpool WorkerPool

CODE: gears_init.js defines google.gears.factory

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

<script type="text/javascript">

var db = google.gears.factory.create

('beta.database', '1.0');

</script>

If version is omitted, then create() returns the latest version of the object

Gears – Getting Started

Going Offline

The first thing you need to run a web application offline is the ability to start it without an Internet connection. This is the purpose of the LocalServer module.

LocalServer API and the manifest file, are the key components that cache your application's resources and make it available offline.

LocalServer

The LocalServer module is a specialized URL cache that the web application controls. Requests for URLs in the LocalServer's cache are intercepted and served locally from the user's disk.

Resource stores

A resource store is a container of URLs. Using the LocalServer module, applications can create any number of resource stores, and a resource store can contain any number of URLs.

Creating LocalServer

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

API: LocalServer class

boolean canServeLocally(string url)

ResourceStore createStore(string name, [string requiredCookie])

ResourceStore openStore(string name, [string requiredCookie])

void removeStore(string name, [string requiredCookie])

ManagedResourceStore createManagedStore(string name, [string requiredCookie])

ManagedResourceStore openManagedStore(string name, [string requiredCookie])

void removeManagedStore(string name, [string requiredCookie])

LocalServer – Resource Stores

ResourceStore

for capturing ad-hoc URLs using JavaScript. The ResourceStore allows an application to capture user data files that need to be addressed with a URL, such as a PDF file or an image.

ManagedResourceStore

for capturing a related set of URLs that are declared in a manifest file, and are updated automatically .

Creating ResourceStore

localServer = google.gears.factory.create('beta.localserver');

store = localServer.openStore(STORE_NAME);

store.capture(filesToCapture, captureCallback);

API: ResourceStore class

int capture(urlOrUrlArray, callback)

readwrite attribute boolean enabled

void abortCapture(captureId)

void remove(url)

void copy(srcUrl, destUrl)

boolean isCaptured(url)

void captureFile(fileInputElement, url)

string getCapturedFileName(url)

string getHeader(url, name)

FileSubmitter createFileSubmitter() ...

ResourceStore – code snippets

localServer = google.gears.factory.create

('beta.localserver', '1.0');

store = localServer.openStore(STORE_NAME);

// If the store already exists, it will be opened

store = localServer.createStore(STORE_NAME);

store.capture (['sample.js', 'sample.css', 'gears_init.js'], captureCallback);

localServer.removeStore(STORE_NAME);

ManagedResourceStore

localServer = google.gears.factory.create('beta.localserver');

store = localServer.createManagedStore(STORE_NAME);

store.manifestUrl = 'manifest_v1.json';

store.checkForUpdate();

API: ManagedResourceStore class

readonly attribute string name

readonly attribute string requiredCookie

readwrite attribute boolean enabled

readwrite attribute string manifestUrl

readonly attribute int lastUpdateCheckTime

readonly attribute int updateStatus

readonly attribute string lastErrorMessage

readonly attribute string currentVersion

void checkForUpdate()

Manifest file

A manifest file lists all of the URLs to be captured by a ManagedResourceStore. It also contains the version for the manifest file format, the version of the contents of the manifest, and an optional redirection URL.

Using the ManagedResourceStore requires that you create a manifest file.

The manifest file is written in JavaScript Object Notation ( JSON ) format.

Manifest file

The manifest file and all the URLs listed in it must follow the "same-origin policy", which means that all the URLs must originate from the same URI scheme, host, and port.

An application can have any number of manifest files and ManagedResourceStores. You specify which manifest file to use when you create an instance of ManagedResourceStore.

Manifest file

{

// version of the manifest file "betaManifestVersion": 1,

// version of the set of resources described in this manifest file

"version": "my_version_string",

// optional.. // If the store specifies a requiredCookie, when a request would hit an entry contained in the manifest except the requiredCookie is not present, the local server responds with a redirect to this URL.

"redirectUrl": "login.html",

// URLs to be cached (URLs are given relative to the manifest URL)

"entries": [

{ "url": "main.html", "src": "main_offline.html" },

{ "url": ".", "redirect": "main.html" },

{ "url": "main.js" }

{ "url": "formHandler.html", "ignoreQuery": true },

]

}

Gears – Getting Started

Storing User's Data

Applications that are more than just static files have data that is typically stored on the server. For the application to be useful offline, this data must be accessible locally. The Database module provides a relational database for storing data.

Storing User's Data

When an offline application reconnects, you will need to synchronize any changes made in the local database with the server. There are many different approaches to synchronizing data, and there is no single perfect approach.

An additional feature of the Google Gears database is Full-Text Search, providing a fast way to search text within a database file.

Gears Database Module

The Database module provides browser-local relational data storage to your JavaScript web application. Google Gears uses the open source SQLite database system.

The Database module is used to persistently store an application user's data on the user's computer.

Data is stored using the same-origin security policy, meaning that a web application cannot access data outside of its domain (see Security).

Data is stored and retrieved by executing SQL statements. Google Gears includes SQLite's full-text search extension fts2.

To create a Database object, use the Gears Factory as follows:

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

</script>

API: Database class

void open([name])

ResultSet execute(sqlStatement, [argArray])

void close()

readonly attribute int lastInsertRowId

Database ResultSet

A ResultSet is returned from a successful call to Database.execute(). It contains the results of executing the SQL statement.

A ResultSet is immutable, subsequent changes to the underlying database do not affect the contents.

Database ResultSet

Iterate over the rows of the result set using isValidRow(), next(), and close(), calling data extraction methods for valid rows.

while (rs.isValidRow()) {

console.log(rs.fieldName(0) + " == " + rs.field(0));

rs.next();

}

rs.close();

ResultSet API & DB location

API: ResultSet class

boolean isValidRow()

void next()

void close()

int fieldCount()

string fieldName(int fieldIndex)

variant field(int fieldIndex)

variant fieldByName(string fieldName)

Linux - Firefox - Database files are stored in the user home directory.

Location: ~bob/.mozilla/firefox/<firefox's profile id>/Google Gears for Firefox

Example: ~bob/.mozilla/firefox/08ywpi3q.default/Google Gears for Firefox

Database – code snippets

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

db.open('database-demo');

db.execute('create table if not exists Demo' +

' (Phrase varchar(255), Timestamp int)');

db.execute('insert into Demo values (?, ?)', [phrase, currTime]);

var rs = db.execute('select * from Demo order by Timestamp desc');

db.execute('delete from Demo where Timestamp=?', [rs.field(1)]);

Gears – Performance Module

When synchronizing large amounts of data, you may find that the database operations begin to affect the responsiveness of the browser. The WorkerPool allows you to move your database operations to the background to keep the browser responsive.

The WorkerPool is useful for any expensive operations that slow down the UI.

Performance - WorkerPool

In web browsers a single time-intensive operation, such as I/O or heavy computation, can make the UI unresponsive. The WorkerPool module runs operations in the background, without blocking the UI. Scripts executing in the WorkerPool will not trigger the browser's "unresponsive script" dialog.

Code and Data Isolation

The WorkerPool behaves like a collection of processes, rather than threads. Workers do not share any execution state. Changing a variable in one worker has no effect in any other worker. And created workers do not automatically inherit script code from their parents.

Code and Data Isolation

Members of a WorkerPool interact with each other only by sending message strings. Workers can also pass richer data types, by first converting objects to strings using JSON.

WorkerPool Limitations

A created worker does not have access to the DOM; objects like document and window exist only on the main page.

However, workers do have access to all JavaScript built-in functions. Most Gears methods can also be used, through google.gears.factory. (One exception is LocalServer file submitter, which requires DOM.) Workers can delegate requests to main page.

WorkerPool Initialization

JavaScript code (the "parent" worker) uses google.gears.factory to create a WorkerPool wp.

The parent indicates where incoming messages should go by setting wp.onmessage. It does this before calling createWorker() to ensure that no messages will be lost.

Initialization Sequence

For each new worker (a "child" worker):

The parent calls wp.createWorker() with the full body of script that the child will contain.

Before wp.createWorker() returns, the child runs through its script once. During this time the child must set its onmessage handler, on the predefined global variable google.gears.workerPool.

When the child returns, the parent and child begin running in parallel.

WorkerPool Communication

Workers send strings to each other using sendMessage(). Any member of a particular WorkerPool can communicate with any other member.

Each sent message triggers the receiver's onmessage handler. Message events are handled like all other JavaScript events.

The WorkerPool is not a singleton. A page can create multiple WorkerPool instances, and these pools are isolated from each other. This enables multiple gadgets on a page, for example, to use the WorkerPool module without fear of collision.

There are two common ways for the script to know which worker ID to send messages to:

Use the second parameter to onmessage, which contains the sender's worker ID. A "grunt" worker whose purpose is to execute requests asynchronously will often use this method, blindly responding to whichever worker made the request.

The second way

Use the value returned by createWorker(), which is the ID of the newly created worker. A worker whose purpose is to coordinate tasks (usually the application's "main" JavaScript code) will often use this method. The ID can be sent to, and used by, any member of the WorkerPool, but this is seldom necessary.

WorkerPool API

API: WorkerPool Class

callback onmessage(messageString, srcWorkerId)

int createWorker(fullScript)

void sendMessage(messageString, destWorkerId)

Code:

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

</script>

WorkerPool Code snippets

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

// set the parent's message handler

workerPool.onmessage = parentHandler;

// setup the entire body of JavsScript code to run in the worker

var childCode = String(childInit) +

// childInit & childHandler are javascript function defined elsewhere

String(childHandler) + 'childInit();'; // runs init function

// create the worker

childId = workerPool.createWorker(childCode);

Offline Application Architecture

Architecting with a Data layer

When you add a local datastore to your app, you will have a single place through which all data storage and retrieval requests pass.

Background Sync Architecture

Data is ready at all times, whenever the user goes offline, or is accidentally disconnected.

The performance is enhanced when using a slow Internet connection.

Gears - Security

Gears uses the same origin policy as its underlying security model. A web page with a particular scheme, host, and port can only access resources with the same scheme, host, and port.

Database: Can only open databases created for that site's origin.

LocalServer: Can only capture URLs and use manifests from the site's origin.

Database Security

Best Practice : Avoid SQL injection attacks. Never insert user input directly into a SQL statement. Instead, use substitution parameters in Database.execute() .