techno.blog("Dion")

Gregor Hohpe gave a nice report on Google Gears Live From Japan, at a “Google Developer Roundtable” event. Gregor was at the event focusing on Gears and gave a presentation on the topic:

When giving a presentation about Google Gears, what would be better than actually making a Gears application that renders the presentation? That’s what the sample application, that comes with Google Gears, does. It reads a text file into the local SQLite database and renders the presentation from the database records. On slide 10 of my updated presentation you can cache all application resources (e.g., images, JavaScript files, CSS files, etc) in the resource manager and run the presentation offline (naturally, following this link requires Gears). I demonstrated that feature during the talk by pulling the network cable right after synchronizing. Thank god it worked. I hope it shows on the video! I uploaded the presentation application with all supporting files to the code.google.com subversion repository.

He also had some pointers for the future, with a good link to an architecture doc:

Developers also pointed out that the Gears API’s are relatively low level building blocks, making more guidance and advice from Google essential. A recent article on the Gears Architecture clearly points this direction. This is a topic close to my heart. I want to make sure that developing rich and responsive browser apps is not reserved for hard core hackers and JavaScript junkies. While the “competition” (a good friend of mine, actually) has been getting a lot of air time regarding Democratizing the Cloud, it’s equally important for Google to bring Web development to the masses. A little voice in my head tells me that there may be some interesting design patterns for these types of applications waiting to be documented. AJAX Design Patterns is a good step into that direction, but Gears has fundamentally changed the landscape for AJAX development.

I had the pleasure of finally meeting Didier Girard. I seem to run across Didier’s work every week or so, but for some reason we haven’t had a chance to meet face to face, until JavaPolis.

Didier sat down with me to talk about GWT, Gears, Java, and JavaScript, and I gave my honest opinions.

You can listen to my ramblings below. Let me know if you have any thoughts on opinions!

I have spoken at a bunch of conferences in Europe this quarter. From the Future of Web Apps, and @mediaAjax in London, to JavaZone and JavaPolis in Oslo and Belgium. When I speak about Gears there, I get a lot of questions about Mobile Gears.

A lot of the features of Gears arguably make even MORE sense on a mobile device. Allowing Web developers to build applications for phones has taken off well thanks to the iPhone. Gears can help out in these high latency devices.

One very handy API to have would be a Location API (although it would be useful in other contexts too):

The purpose of this API is to provide means to fetch the location of a device running a Web browser with Gears.

The Location API is an abstraction for the various LBS APIs that currently exist on mobile platforms (GPS-based, network/cellid-based). The API consists of the Location class, which encapsulates various location attributes (latitude, longitude, etc), and also provides the means to query the platform for a location fix. This API also adds a new event type that is fired every time the location changes. Location implementations can be straightforward mappings to native LBS APIs (e.g the S60 Location Acquisition API) or have a more complex design that combines several location providers (e.g a GPS-based provider and a cell id-based provider) and returns the location from the most accurate provider at any given time.

Here is the API as a code example using it:

// Getting the object
var location = google.gears.factory.create( "beta.location", "1.0" );
 
// Setting up a callback to handle "location changed" events
location.onlocationstatechanged = function() {
   switch (this.state) {
     case 1:
         SetStatusText("Connecting");
         break;
     case 2:
         SetStatusText("Acquiring");
         break;
      case 3:
          SetStatusText("Location accuracy:", this.accuracy);
          MoveMap(this.latitude, this.longitude);
          break;
      case 5:
          HandleError(this.error);
          break;
      default:
         alert("Unknown state!");
   }
}
 
// Initiate a fix. This leads to the onlocationstatechanged event handler being called exactly once for each
// of the "connecting" and "acquiring" states and one or more times for the "fixed" state (for the initial
// fix and every time the location changes, after that).
location.startLocationUpdates(); // async call, initiates fix (powers up GPS if needed, etc)
 
...
 
// Getting the last known location
if (location.latitude != -1 &&
    location.timeUTC > threshold) {  // the location info is valid and not very old
  Foo(location.latitude, location.longitude);
}
 
// Cancel the request. This leads to the onlocationstatechanged event handler being called for
// the "canceled" state. This call will power down the GPS HW / close HTTP connection
// (depending on the location providers that were in use).
location.stopLocationUpdates();

I can imagine the fun games that I could write here, let alone the interesting business apps that could take the location context into consideration.

Other Future APIs

• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.

A common task you see people using AIR and Prism for, is just a wrapper around a Web application that you use all the time such as Gmail, or your Web based calendar or what have you. It would be nice to be able to automate the creation of a shortcut in a very simple way. This is where the Shortcut API comes into play.

The current thinking is that there will be other desktop-y features that people may want to tie into, so the shortcut API sits inside a Desktop module.

It looks like this:

var desktop = google.gears.factory.create('beta.desktop');
desktop.createShortcut("Test Application",
                       "An application at http://www.test.com/index.html",
                       "http://www.test.com/index.html",
                       {"16x16": "http://www.test.com/icon16x16.png",
                        "32x32": "http://www.test.com/icon32x32.png",
                        "48x48": "http://www.test.com/icon48x48.png",
                        "128x128": "http://www.test.com/icon128x128.png"});

Maybe you would use this as an install step. Maybe you give people the ability to export files in some way. What would you like to see here? This is still early stage, and we are thinking about features you would like to add. For example, the ability to say “open this Web application without the URL bar and other browser chrome”.

Other Future APIs

• Image Manipulation API
• Introduction to the series

Disclaimer: This is early days, and who knows what the final API will look like, and how far it goes. Do you have ideas for cool Gears that make the Web better? Let us know!.

I said in my recent post on Gears being about more than offline that I would talk about some fun future APIs.

The Gears project is open source, and is really being held out in the open, which means that you can check it out and contribute. We want Gears to be community open source, as opposed to just using open source as the way code gets out there. There is a big difference. Poke around the Wiki to see more.

Back to the API. The Image Manipulation API provides a way to manipulate images though client-side JavaScript:

This is a module to give Javascript a way to resize, crop and compose images together on the client side. This will allow, for example, images to be resized into a web-friendly format before being uploaded to a photo album. Another use is for composition of images together as an efficient alternative to server-side composition or CSS layering. Yet another use is for basic photo editing – a user can edit a photo with instantly applied changes before uploading it to the server.

The module is fairly simple, and has the following API:

var image = google.gears.factory.create('beta.image', '1.0');
 
void open(blob)
Blob blob(type)
void resize(width, height)
void crop(x, y, width, height)
int width()
int height()
void rotate(degrees)
void flipHorizontal()
void flipVertical()
void drawImage(image, x, y)
void close()

Having this functionality available natively in the browser would be very cool indeed, and could open up the doors for some interesting ideas.

Other Future APIs

• Messaging API
• Location API
• Desktop Shortcut API
• Introduction to the series

Disclaimer: This is early days, and who knows what the final API will look like, and how far it goes. Do you have ideas for cool Gears that make the Web better? Let us know!.

UPDATE: Ray Cromwell of Timepedia thinks that we should be more ambitious. There are some great thoughts in there, and this is the type of feedback that we really look forward too. We haven’t even begun here, so feedback now will hope us having something a lot better when all is said and done..

For obvious reasons, people are often assuming that Google Gears == Offline. To me, this isn’t the case. Gears happens to have three initial APIs (LocalServer, Database, WorkerPool) that can lend themselves to offline work. However, some people are grokking that WorkerPool and even Database are very useful even if your application never goes offline.

Segue: I am really excited to have Brad Neuberg of Dojo, Rojo, and other non-ojo projects fame, working with me at Google. It is a real pleasure to see the group growing, with great new hires such as Joe Gregorio, and others that haven’t made it official yet :)

I was having a chat about Gears with Brad, and he was talking about how he saw it as a way to update the Web in place. He got it.

Let’s use a really corny analogy that breaks down. We get to drive a few makes of cars (browsers) on the (information) highway. When we want new features, we have to wait for a new model to come out, and recently it feels like Cuba. The top selling car is a 1950’s Chevy. As drivers that are passionate about the driving experience, the Gears team is trying give everyone a foundation to replace the engine, even as you drive.

The goal is to give you the foundation. If it happens through other work too (e.g. other manufacturers step up to the plate), we think that is great. We want to make sure that every car on the road has a base platform to keep the highway performing well though, so we are hear to back you all up, and to keep innovation going.

Alex Russell is talking about innovation as he aims to stop us from going into pure standards hell. We are lucky that with HTML 5, we are pushing forward again. The devil is in the details though, and I am waiting to see what cars come out in 2008. If you are left with an old clanger, we are here to help though.

To make this more obvious, I will start posting about some of the exciting APIs that may be coming!

I just posted about the Sun announcement on Java Applets 2.0 (even if the PR folk kept telling us it was an “update” not an “announcement”).

The web community tends to poo poo the applet. We scoff at the startup time. We complain at the cross browser issues that went against the point. We moan at the speed. We groan at the image mouseover examples.

However, if we get off of our high horse for a minute and think about what a world where Java in the browser was actually decent, we get an interesting picture.

If the plugin could be in control of the cross browser / platform issues, then it could allow us to write rich components that work on all. We could build and register a really nice file upload component for example that takes over type=”file” to do a lot more. We could use JNLP (or something else) to register the modules, and when we get winners, could even standardize them.

If we then think about SQLite databases in the browser. We could actually use Hibernate to work with it. The JavaScript / Java bridge is already decent, and could get even easier / better.

If the Java Plugin is done well, it could become a platform to build on. This is a big if though, and there is the spectre of Java 1.x in IE looming out there. Is there a way to get around that though?


// beginning of the plugin simply does
if ie and freaking old Java 1.x
run the installer
end


As I think about this, Gears and Java could actually do some interesting work together.