Gears API Blog

Keep up to date on Gears

Last February, we let you know we were shifting our focus from Gears to HTML5. Over the last year or so, we’ve been working closely with other browser vendors and standards bodies to help define and standardize HTML5 features across browsers, and we’ve worked hard to improve these HTML5 capabilities in Chrome:

We implemented support for application caches, which are a great replacement for Gears’ offline features. App caches are already being used by web apps like the NYTimes app in the Chrome Web Store. There is also full-featured debugging support for application caches in Chrome’s developer tools.

Together with our friends at Mozilla and Microsoft, we proposed, specified, and implemented the IndexedDB API. This can take the place of the Gears Database API.

We implemented the HTML5 File API, which is very similar to the Gears Blob functionality.

With all this now available in HTML5, it’s finally time to say goodbye to Gears. There will be no new Gears releases, and newer browsers such as Firefox 4 and Internet Explorer 9 will not be supported. We will also be removing Gears from Chrome in Chrome 12.

The code itself will of course remain open source, and anyone is free to use it.

Our mission with Gears was to enable more powerful web applications. Over 5 releases, we added tons of APIs, enabling everything from offline access to parallel computation. Now that these features have all been adopted by browsers and have official W3C specs, they are available to more developers than we could have reached with Gears alone.

If you've wondered why there haven't been many Gears releases or posts on the Gears blog lately, it's because we've shifted our effort towards bringing all of the Gears capabilities into web standards like HTML5. We're not there yet, but we are getting closer. In January we shipped a new version of Google Chrome that natively supports a Database API similar to the Gears database API, workers (both local and shared, equivalent to workers and cross-origin wokers in Gears), and also new APIs like Local Storage and Web Sockets. Other facets of Gears, such as the LocalServer API and Geolocation, are also represented by similar APIs in new standards and will be included in Google Chrome shortly.

We realize there is not yet a simple, comprehensive way to take your Gears-enabled application and move it (and your entire userbase) over to a standards-based approach. We will continue to support Gears until such a migration is more feasible, but this support will be necessarily constrained in scope. We will not be investing resources in active development of new features. Likewise, there are some platforms that would require a significant engineering effort to support due to large architectural changes. Specifically, we cannot support Gears in Safari on OS X Snow Leopard and later. Support for Gears in Firefox (including 3.6, which will be supported shortly) and Internet Explorer will continue.

Looking back, Gears has helped us deliver much-desired functionality, such as the ability to offer offline access in GMail, to a large number of users. Long term, we expect that as browsers support an increasing amount of this functionality natively and as users upgrade to more capable browsers, applications will make a similar migration. If you haven't already, you will want to take a look at the latest developments in web browsers and the functionality many now provide, reach out with questions, and consider how you can use these in your web applications. Gears has taken us the first part of the way; now we're excited to see browsers take us the rest of the way.

Guess what? The Gears Geolocation API got even better! We have just released a new version of Gears, 0.4.24.0, which contains an enhanced implementation of the Geolocation API. This new version uses WiFi access point signals to return significantly more accurate results, making it a lot more useful on laptop computers.

This means that you can now access all the Gears-enabled sites (such as Zoho office, WordPress, the new YouTube uploader and Google Docs offline) in Safari.

Since launch, we've increased the number of APIs available in Gears. The 0.3 release added the ability to create desktop shortcuts for websites, and the 0.4 release added Geolocation and Blobs (useful for resumable uploads of large files). All of these are now available in Safari and work exactly the same as on the other browsers Gears supports.

We thought it might be interesting to talk about some of the technical aspects of Gears peculiar to Safari and OS X. If you aren't a developer you can safely skip the following paragraphs and go straight to the download page.

When you install Gears, you'll notice that it's composed of 2 components: an NPAPI plugin which lives in "/Library/Internet Plugins" and an InputManager. Gears needs to load first thing upon browser startup, for cases in which the first page loaded into the browser is from the Gears offline cache. NPAPI provides no mechanism for loading that early (it only provides support for loading plugins the first time a page specifically includes them) so we needed a small InputManager to do the work for us.

For browsers other than Safari that use the WebKit engine, we've provided a really simple mechanism to allow them to load Gears into their program without using the InputManager. Fluid is one example of a 3rd party browser that supports Gears this way.

On the Mac, Gears desktop shortcuts are actually small applications that are designed to open the website in the same browser they were originally created from. This means that if you created them from a Fluid app they'll open in that same place and if you've got multiple versions of Firefox installed on your machine the shortcut will open in the right one.

We hope you've found this post interesting. If you have any feedback we'd love to hear from you on our mailing list.

But where exactly is 'here'? Well, that's a question that takes on a whole new meaning with this new release of Gears: we have added a new Geolocation API, which allows you to build applications that can do new and exciting things based on your users' location. You can query Gears for the user's current location using the getCurrentPosition() method or you can ask Gears to notify you every time the location changes, using the watchPosition() method. Of course, we take privacy issues very seriously, which is why we have a special permission dialog that allows users to decide which Web sites should have access to their location information. If you want to learn more about how the Geolocation API works, please see the Google Code blog post.

Another cool new feature is the Blob API. Unlike strings, blobs let you reference arbitrary binary data — a first for JavaScript! Therefore, blobs can more naturally represent things like files and images, and they can be passed around efficiently. We have updated several existing APIs to work with blobs, such as WorkerPool sendMessage() and HttpRequest send(). And that's not all! We have also extended the Desktop API with a new method, openFiles(), which allows users to select multiple files of a particular content type, and then returns them as blobs for easy uploading or worker processing.

For the full list of changes, you can check out the Gears API history.

If you are a developer anxious to try these new APIs, first check gears.google.com to make sure you have Gears 0.4 installed (your browser should be updated automatically) and then browse the Gears documentation pages. If you are a mobile developer, please make sure you also read our Google Mobile blog post to learn more details about what devices support the Geolocation API.

Finally, an update on how we are doing on Web standards: in line with our earlier promises, the Geolocation API is a W3C Editor's draft and its current design is a result of open collaboration with many other people and organizations. We plan to continue to drive this standardization effort, as well work with the community on new Web standards.

We are constantly asked what are best practices when working with Gears. For example, what's the best way to work with the local database for performance and reliability? What are good architectures for syncing and offline applications? We've just updated the Gears Developer FAQ with a whole slew of Best Practices, many with sample code that you can use in your own Gears-based applications. Here's a sampling of the new additions.