Friday, February 19, 2010

[Gd] Hello HTML5

| More

Gears API Blog: Hello HTML5

Posted by Ian Fette, Gears Team

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.

Wednesday, February 17, 2010

[Gd] Beta Update, Mac and Linux: Fix Crashes

| More

Google Chrome Releases: Beta Update, Mac and Linux: Fix Crashes

The Google Chrome Beta channel for Mac and Linux has been updated to 5.0.307.9. This release fixes a few issues to make the browser a bit more reliable:

  • [Mac, Linux] Fixed a tab crash that could be triggered by visiting,, and many other sites. (Issue 35498)
  • [Mac, Linux] Fixed a tab crash in image loading. (Issue 32230
  • [Linux] Improved font bolding for fonts without native bold. (Issue 22360)

--Mark Larson, Google Chrome Team

[Gd] Who's @ Google I/O: all things Google Web Toolkit

| More

Google Code Blog: Who's @ Google I/O: all things Google Web Toolkit

The Google Web Toolkit (GWT) team had an exciting 2009 -- ending the year with a Campfire One where the team announced the release of GWT 2.0 with Speed Tracer. Developers are quickly adopting GWT to build compelling apps in the browser, and we're excited that we'll have the following companies demoing their applications and talking about how they leveraged GWT (and other Google technologies) in the Developer Sandbox at I/O:
Clarity Accounting, Dimdim, DotSpots, Entrinsik, Hydro4GE Inc., JetBrains, Lombardi, Media Beacon, RedHat, Rosetta, SAS, and StudyBlue.
In addition to developers from these companies, we'll also have Google engineers in the Sandbox, talking about how our internal teams have used GWT to build products like Google Wave.

And members of the GWT team will be hosting a number of advanced sessions at Google I/O. Here's a quick preview of some of the sessions (there are 4 more on the I/O website):

How can you take advantage of new HTML5 features in your GWT applications? In this session, we answer that question in the form of demos -- lots and lots of demos. We'll cover examples of how to use Canvas for advanced graphics, CSS3 features, Web Workers, and more within your GWT applications.

Architecting for performance with Google Web Toolkit
Modern web applications are quickly evolving to an architecture that has to account for the performance characteristics of the client, the server, and the global network connecting them. Should you render HTML on the server or build DOM structures with JS in the browser, or both? Bruce Johnson -- one of the founders of Google Web Toolkit -- will discuss this, as well as several other key architectural considerations to keep in mind when building your Next Big Thing.

At its core GWT has a well-defined and customizable mechanism -- called Linkers -- that controls exactly how GWT's compiled JavaScript should be packaged, served, and run. Matt Mastracci of DotSpots will discuss how to create linkers and explains some of the linkers we've created, including a linker that turns a GWT module into an HTML5 Web Worker and one that generates an HTML App Cache manifest automatically.

Architecting GWT applications for production at Google
For large GWT applications, there's a lot you should think about early in the design of your project. GWT has a variety of technologies to help you, but putting it all together can be daunting. This session walks you through how teams at Google architect production-grade apps, from design to deployment, using GWT.

If you're a GWT developer or considering using GWT for your next project, we hope to see you at Google I/O! It'll be a great place to meet and chat with other engineers, including the team behind Google Web Toolkit.

To learn more and to sign up for Google I/O, visit

By Joyce Sohn, Google Developer Team

Tuesday, February 16, 2010

[Gd] AdWords Downtime: February 20, 10am-2pm PDT

| More

AdWords API Blog: AdWords Downtime: February 20, 10am-2pm PDT

We'll be performing routine system maintenance on Saturday, February 20 from approximately 10:00am to 2:00pm PDT. You won't be able to access AdWords or the API during this time frame, but your ads will continue to run as normal.

- Eric Koleda, AdWords API Team

[Gd] Scalability means flexibility

| More

Google App Engine Blog: Scalability means flexibility

From the beginning we've worked hard to ensure that building and maintaining applications on Google App Engine is as easy as possible and that those applications can be made to scale very well. Scalability can mean different things to different people though. For us, platform scalability (today) means efficiently serving 250 million daily page views for 250,000 developers. For you, application scalability means being able to serve a large number of requests to your web site when you need it.

But serving all of that traffic is just half the challenge. Even for applications with very predictable traffic patterns it's often impossible to know how much traffic your site will see at any given time in the future. You need flexibility and a platform which will automatically adjust to your needs, minute by minute. This is especially true for sites that are used in conjunction with large media events. We've been working with one such company and we'd like to share their scalability story with you today.

Gigya’s technology enables their customers to connect seamlessly to popular social network platforms for user authentication, sharing and engagement. One product feature is a social live chat widget used by their customers to accompany live-streamed events. When I spoke with Gigya's Raviv Pavel, VP Research and Development, he told me, "Although we typically host all our services in-house, on our own infrastructure, we felt that GAE would be a better fit for the live chat feature because of its unique traffic pattern, which is characterized by very low traffic most of the time with very high bursts during high profile events."

Below is a graph from the January 22nd Hope for Haiti Now: A Global Benefit for Earthquake Relief during which Gigya had deployed their social gadget to multiple web properties. The vertical scale shows number of requests or queries per second, which peaked at around 1600 QPS. Each of their events has its own unique characteristics. So far we've seen Bactrian camels, Dromedary camels, parts of the Rocky Mountains and this next graph which vaguely resembles a submarine poking through the polar icecap.

Gigya wins because Google App Engine maintains the infrastructure needed to support those traffic bursts for the live chat widget. And because of App Engine's granular billing model, they only pay for the resources they use. When Gigya's live chat sees reduced traffic, we make sure our machines are busy serving other requests.

If you have an interesting App Engine story you'd like to share, let us know. We'd like to hear about it.

Posted by Fred Sauer, App Engine team


[Gd] Using Google Document List APIs to build Memeo Connect for Google Docs

| More

Google Apps Developer Blog: Using Google Document List APIs to build Memeo Connect for Google Docs

Building Memeo Connect for Google Docs

Editor's Note: This post was written by our partner Memeo, a digital media management company. Memeo Connect™ for Google Docs enhances Google Docs capabilities. We invited Memeo to share their experiences building an application on top of Google Apps utilizing some of our APIs. Other partners will share their experiences in future posts. 

Hi I'm Matthew Tonkin, Mac Applications Architect at Memeo.  Google has been a great partner in helping us bring Memeo Connect to market.  We're excited about the new additions to the Google Documents List API's and the products we've been working on for them.

Google Apps  is a great way for businesses to share and collaborate on documents, but more importantly, it has allowed businesses to move much of their office and IT infrastructure online for dramatic operating cost reductions.  Until recently, Google Docs users had no way of uploading, storing, syncing and sharing files of any type.  The big news is that Google Docs now supports all file types and there are Documents List API's to prove it.  January saw the release of the updated Documents List API with this new arbitrary file support, but no desktop client software to manage file syncing between the desktop and the cloud.  Memeo Connect for Google Apps is that missing link.  Memeo set out to bridge Google Docs cloud storage with desktop software.  A simple goal that has big implications for where users store documents and how they are shared.  

The end result is a desktop application that is fully supported by Google Docs for online storage, synchronization, sharing and data management. With Memeo Connect, instant access to your important documents while online or offline is now very possible. Memeo Connect is available on both Windows and Mac platforms.

Our timeline for Memeo Connect was 'impossibly' short due to Google’s aggressive timeline for launch. How did we do it?  Apart from the obvious late nights, junk food and beer, we received help from Google to take this product from concept to reality.  Some of it came in the form of new API's, some directly from the Documents List API team, some from the client libraries and some from the discussion groups.

1. Keeping native file formats

Google Docs now supports keeping files in their native format.  Previously Microsoft Office files and images were converted to the online Google Document formats, removing much of the application specific formatting options used in the Office file formats.  However, it's now possible to upload Microsoft Office files and images without conversion, meaning users can keep all of their custom file formatting.

You can get all of this with a simple parameter in the post URL when uploading the new document.

Google Documents List API

If like us, you use the client libraries, then it's just as easy.

Google Data Objective-C client library**

NSURL *uploadURL = [[mDocListFeed postLink] URL];
GDataQueryDocs *uploadQuery = [GDataQueryDocs queryWithFeedURL:uploadURL];
[uploadQuery setShouldConvertUpload:NO];

Google Data .NET client library

string uploadURL = DocumentsListQuery.documentsBaseUri + "?convert=false";
docService.StreamSend(new Uri(uploadURL), fileStreamHandle, GDataRequestType.Insert, contentType, docTitle); 

The new features don't just handle Microsoft Office files.  Any file type is supported with no additional parameters or changes to client code, however the support for these features is only available through the Google Documents List API for users that have a Premier account.

2. Bigger file size limits and resumable uploads

Google Docs now supports file uploads up to 1GB and is resumable, so failed or paused uploads can pick up where they left off.

Google Documents List API

Resumable post link:

resumable-create-media" type="application/atom+xml"


POST /feeds/upload/create-session/default/private/full HTTP/1.1
GData-Version: 3.0
Content-Length: 0
Content-Type: application/pdf
Slug: MyTitle
X-Upload-Content-Type: application/pdf
X-Upload-Content-Length: 1234567


Content-Length: 100000
Content-Type: application/pdf
Content-Range: bytes 0-99999/1234567

Google Data Objective-C client library**

Resumable uploads are automatically enabled when switching to the uploadLink URL

NSURL *uploadURL = [[mDocListFeed uploadLink] URL];
GDataQueryDocs * uploadQuery = [GDataQueryDocs queryWithFeedURL:uploadURL];

Pausing and resuming uploads is also made easy.

[mUploadTicket pauseUpload];
[mUploadTicket resumeUpload];

Google Data .NET client library

ResumableUploader resumableUploader = new ResumableUploader();
if (newFile)
    resumableUploader.Insert(authentication, docEntry);
else if (partialFile)
    resumableUploader.Resume(authentication, resumeUri, httpMethod, fileStream, cotentType);
else if (updateExistingFile)
    resumableUploader.Update(authentication, docEntry);

** Objective-C code samples have been taken from the Docs Sample code

3. Client Libraries for Mac & Windows

The Google Documents List API provides all of the backend server functionality but isn't ideal for rapid client application development.  As client developers, we prefer the efficiencies provided by a wrapper in our native client languages.  This is where the client libraries for Objective-C and .NET allowed us to shorten our application development time significantly.  Without the client libraries, we simply would not have been able to achieve our goals for Memeo Connect in the time we had available.

Many of the Documents List API features we worked with in our early development were not available through the client libraries.  This was initially quite daunting because of the risk that we would have to drop down to raw server calls and miss out on the efficiencies we gained through using the client libraries.  However as we got to know the client libraries better, we found they were written flexibly enough that we never had to do that - there was always a way to bend them enough to get what we needed.  A sign of great design by their architects.

For example uploading without conversion was simple in the Objective-C client library even before it was officially updated to support it.

NSURL *uploadURL = [[mDocListFeed postLink] URL];
GDataQueryDocs *uploadQuery = [GDataQueryDocs queryWithFeedURL:uploadURL];
[uploadQuery addCustomParameterWithName:@"convert" value:@"false"];

4. Support from Google

The Documents List API team were of enormous help throughout the course of this project.  As with most of Google's public API's, there's always an avenue to ask questions about how to best use the technology, pursue bugs or request new features.  The new Google Apps Discussion Groups are simply the best way to get an answer quickly and is invaluable in getting past whatever is blocking your progress. Google Developer Relations people monitor the discussion groups and frequently answer questions, link to other relevant resources, and provide code samples.

What's next?

We had a sizable list of things we really wanted to do with Memeo Connect 1.0 and some of that had to wait for 1.x or 2.0.  We're looking forward to continuing to work with Google and file as many feature requests as we can to make some of these new features a reality.  Anyone can file a feature request for Google Apps API's and I can assure you they all get considered.

In future releases we'll be adding more support for direct file system integration, better tools to manage sharing and we're really excited about supporting new devices.  Get ready to see more Google Docs in more places.

[Gd] [Libraries][Update] jQuery 1.4.2

| More

Google AJAX API Alerts: [Libraries][Update] jQuery 1.4.2

jQuery was updated to 1.4.2.

[Gd] New features on the Developer Dashboard

| More

iGoogle Developer Blog: New features on the Developer Dashboard

Last November we launched the iGoogle Gadget Dashboard, a tool to give our gadget developers more insight into how their gadget is used in the wild. For starters, we gave developers the ability to track their user count, pageviews, canvas views all over time, as well as the geographic distribution of their users. When we launched we promised more to come, and we're pleased to announce the release of several of the most requested features by our developer community.

You may have already noticed the newest additions to the dashboard, which we rolled out over the last week. Developers can now subscribe to their gadget's directory comments with their favorite RSS reader, so it's easy to stay current with your user's concerns and desires. If you're a developer with a lot of gadgets, we've added sorting options so you can keep gadgets ordered in the most useful way. Finally and for the first time, developers can easily submit and withdraw gadgets from the iGoogle directory, giving them even greater control over their presence on iGoogle.

We're firm believers in the principle that empowering our developers is the best way to bring a great iGoogle experience to our users, so we'll be listening to our developer community about the tools and data they need the most and the dashboard will continue to improve. In the meantime, you can play with the new version at:

Happy developing!

Posted by Sascha Haberling, Tech Lead