Wednesday, January 2nd, 2008

Google Gears Future APIs

Category: Editorial, Gears, Google, JavaScript

Gears Monster

Over on my personal blog I kicked off a series of articles on some future APIs that are on the table for Gears, and how in my opinion, Gears is mistakenly seen to be about “offline”, when that is just the surface.

I started off by discussing the Image Manipulation API, “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.”

Then I went on to the Desktop Shortcut API where you can:

javascript

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

The Location API provides a 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.

The Messaging API fits in with the current WorkerPool API to give you cross domain rich messaging:

javascript

  1. <br /> var port = google.gears.factory.create('beta.messageport', '1.0');<br /> port.onmessage = function(port, msg, sender) {<br /> alert("message: " + msg);<br /> };<br /> port.listen("name");   // Omit for anonymous listener.</p> <p>// and having a way to send it a message:</p> <p>var port = google.gears.factory.create('beta.messageport', '1.0');<br /> port.open("name");<br /> port.sendMessage("hello there");<br />

There there were smaller fry such as a Logging API, the Blob API, and Factory API updates.

To finish off we have the issue of developer tools. We need to make sure developers have the tools they need to enable successful app development using the APIs, so we want to first add:

  • Database
  • List databases per origin
  • Create new
  • Delete
  • Interactive DB command line (can just use existing /sdk/tools/dbquery.html)
  • LocalServer
    • List ResourceStores (and ManagedResourceStores) per origin
    • ResourceStore and ManagedResourceStore status (last error, update history, etc)
    • command line (like db command line, but pointed at localserver DBs)
  • WorkerPool
    • Show running workers
    • Interactive JS prompt to run JS inside a worker
    • Interactive prompt to send messages to a worker
  • Logging (requires LoggingModule)
    • Show logging in real time as it happens
    • Show historical logging
    • Sort/filter by origin/page of source page

    I would love to see what you would like to see, and these thoughts will be the subject of future posts.

    Posted by Dion Almaer at 8:32 am
    Comment here

    +++--
    3.3 rating from 37 votes

    Comments Here »

    Comments feed TrackBack URI

    Leave a comment

    You must be logged in to post a comment.