Gears Screencast: An Introductory Tutorial

3/31/2008 12:36:00 PM
Posted by Ben Lisbakken, Gears Team

Using a JavaScript API to cache web pages offline, interact with a client side database and introduce threading into your application isn't immediately intuitive because it's such a foreign concept for a web API. I remember when I was doing my first work with Gears -- I was a bit disoriented and in need of a walk through of how things work and why.

To help potential Gears users that feel like my 7-month-ago-self, I wrote a tutorial application that uses a minimal amount of non-Gears code. This application is a simple stock ticker that makes use of 5 of the Gears modules; LocalServer, Database, WorkerPool, Timer, and HTTPRequest.

But a standalone application can't teach someone -- it needs some explaining. Long articles generally lose my attention, so my media of choice was video. I made a screen cast where I walk through the code in three steps, which you can find here. There's also a zip file that contains the three steps of code so you can take a look at the code on your own. Please note that there is a PHP file that is required for the application to work, so you will need a server that runs PHP in order to use this code on your own!

Joose.Gears: Adding support for workers in a self-hosting meta object system

3/27/2008 09:52:00 AM
Posted by Dion Almaer, Gears Team

Malte Ubl, who brought us xssinterface, has a new project that has Gears support.

Joose is a self-hosting meta object system for JavaScript inspired by the Perl Moose. Joose supports inheritance, traits, mixins, method wrappers and more.

Where Gears comes into the mix is through the Joose.Gears meta class which enables automatic delegation of methods to be executed as a Gears worker. If Gears is not present, the worker is executed in the main thread. The workers result will be sent to a method called "on".ucfirst($worker_name) if available:

Class("HardWork", {
    meta: Joose.Gears,
    has: {
        data: {is: rw, init: {}}
    },
    methods: {
        onDoWork: function (result) {
            ok(result == 1001, "Gear Worker returns correct result")
        }
    },
    workers: {
        doWork: function (start) {
            var counter = start;
            for(var i = 0; i < 1000; i++) {
                counter++
            }
            return counter
        }
    }
})

var hw = new HardWork();

hw.doWork(1)

You can take a peak at the innards to see another interesting use of Gears.

Cross-domain messaging with Gears

3/18/2008 10:56:00 AM
Posted by Dion Almaer, Gears Team

Malte Ubl has written a small abstraction library called xssinterface that enables cross domain callbacks. The site specifies which methods may be called as well as which domains are allowed to call the methods.

The library wraps the postMessage interface and our own cross domain workers. If those options aren't enough, there is a way to use a cookie trick to still get access.

There is a generic Gears worker that Malte uses to wrap his API. If you haven't played with workers yet, you may find it interesting to see a full example.

In it you will see usage of the database and even a timer:

var timer = google.gears.factory.create('beta.timer');
timer.setInterval(function() {
  // get a new db handle on each iteration
  var db = google.gears.factory.create('beta.database');
  db.open('database-xssinterface');
 
  db.execute("BEGIN TRANSACTION");
 
  // find new messages for meps
  var rs = db.execute('select id, message from XSSMessageQueue where recipient_domain = ? and channel_id = ?', [recipient, channelId]);

  // there are new messages for the recipient
  while(rs.isValidRow()) {
          var id   = rs.field(0);
          var text = rs.field(1);
          wp.sendMessage(text, message.sender);
          db.execute("DELETE from XSSMessageQueue where id = ?", [id]); // unqueue message
          rs.next()
  }
 
  rs.close();
 
  db.execute("COMMIT")
 
  db.close();
}, 300);

xssinterface is a fairly alarming name, so I asked Malte why he would put "XSS" in the name of his product. It turns out he is trying to be lighthearted. Each to their own!

Gears Database API and Aptana Jaxer

3/13/2008 01:34:00 PM
Posted by Dion Almaer, Gears Team

Aptana Jaxer is a new product that allows you to write server side Ajax applications, and one of the features is a server side database API.

As soon as I saw this, I started to play with an unofficial wrapper that would enable me to use the Gears Database API and have it work on the server.

The Aptana team liked this idea, so they decided to implement the same result API as Gears uses, which enabled me to chop up my shim.

I find this interesting as it can allow:

• A way to run your Gears code on server, for example, if the user doesn't have Gears installed. In certain use cases, you could decide to run the code back on the server, and offer the user to "speed this all up by installing Gears"
• One API means that you can take tools and code that you have written on top, and have it automatically work on the server too. For example, we have already seen a GearsORM that works behind the scenes

Converging on APIs makes me feel good in the same way that deleting code does. I hope to see more of this in the future. The fewer the APIs that a developer has to learn, the better.

Google Gears in Your Pocket

3/03/2008 11:10:00 PM
Posted by Chris Prince, Software Engineer

Today is an exciting day for mobile application development, as it marks the first release of Google Gears on mobile devices. Gears is initially available for Internet Explorer on Windows Mobile 5 and 6.

Consider the sad state of mobile app development today: you often need to write native code, and build against four different SDKs, using five different compilers. It's a daunting task, which explains why so few people write mobile applications.

Web apps are an obvious way to deliver functionality across mobile devices. You can write your application just once. So why hasn't this approach been more widely adopted? Mobile browsers simply cannot do much of what you want applications to do.

Enter Google Gears. The mission of Gears is to extend the capabilities of web browsers. It is clear to us that mobile browsers can benefit just as much as desktop ones. By adding features to mobile browsers, it becomes possible to deploy an increasing number of mobile applications as web apps.

Furthermore, we plan to keep the Gears API consistent across all platforms. So as long as you account for browser differences (such as different screen sizes and DOM quirks), the rest of your application will "just work" across users' systems. You don't need to worry whether you are running on a mobile device or a desktop machine.

We are very excited by the potential here. We expect mobile apps built using Google Gears to usher in a new trend in mobile application development.

For more information, check out the interview Dion Almaer conducted with some of the engineering masterminds behind mobile Gears:

Andrei Popescu and Dave Burke describe what it was liking bringing Gears to Windows Mobile, and the motivations for the project.