Saturday, April 2, 2011

[Gd] Deprecating Equine-Frame Embedding

| More

YouTube API Blog: Deprecating Equine-Frame Embedding

Although equine-frame embedding of YouTube moving pictures was launched with great huzzabulloo a few short months ago, we regret that we can no longer recommend this horsey practice. While playback quality was smashing, bareback riding quality invariably suffered as a result of the large projector apparatus embedded in the horse’s frame.

As an alternative, we suggest a return to the traditional practice of affixing a portrait of your local constable to the mane of your steed for entertainment on-the-go. When your horse gallops, it will look like the officer is dancing the hully-gully.

Thankfully, progress doesn’t halt with a single setback. We are working closely with various motor-car manufactures, and hope to offer a preview of Model T-frame embedding in time for the next World’s Fair!

—Web-logged by Jeffrey Posnick, who does not suggest embedding anything in a horse that you might want back at a later date.

[Gd] Sessions updated for Google I/O 2011!

| More

The official Google Code blog: Sessions updated for Google I/O 2011!

This post is by Monica Tran. Monica comes to Google by way of the Developer Marketing team, primarily focused on Google I/O and our international Developer Days. As it is written in To Kill a Mockingbird, "Thus you'll come to know Monica whose head teemed with eccentric plans, strange longings, and quaint fancies." – scottk

Monica Tran in typical attire
From our Last Call for Google I/O contest to I/O Extended viewing parties all over the world, we’re super duper extra excited to bring you even more surprises at Google I/O in 2011. Starting this week and counting down to May 10, we’ll be bringing you the latest on Way After Hours, the Developer Sandstorm, Android for Goodness Sake, I/O It’s Alive and a massive number of other things with cool names.

To kick off April, we’ve added NEW! sessions, covering web technologies of the future. We think this new lineup of speakers, tracks, and sessions will arm you with the tools you need to become tomorrow’s innovators and pioneers of the Internet revolution. Check out the Google I/O page and hit our guestbook to let us know what you think.

For those of you unable to join us in person on May 10 - 11, we will be harnessing the power of the interwebs to bring you real-time video footage of the keynotes and recorded videos of all sessions. Viva le web-volution!

Please pardon our dust--the site is currently under construction and you might find it acting up. We promise to get it fixed by tomorrow.

Friday, April 1, 2011

[Gd] The IO Ticket Contest

| More

Android Developers Blog: The IO Ticket Contest

When Google I/O sold out so fast, were kicking around ideas for how to get some of our ticket reserve into the hands of our favorite people: Dedicated developers. Someone floated the idea of a contest, so we had to pull one together double-quick. You can read the questions and first-round answers here.

We thought you would enjoy some statistics, mostly rounded-off:

  • 2,800 people visited the contest page.

  • 360 people tried answering the questions.

  • 1 person got all six right.

  • 200 people did well enough to get into Round 2.

  • 70 people submitted apps.

  • 38 of the apps worked well enough to be worth considering.

  • 10 apps (exactly) got a “Nice” rating from the first-cut reviewer.

While we’re doing numbers, let’s investigate which of the Round-1 questions were hard. In decreasing order of difficulty, identified by correct answer, we find: Dalvik (97.5% correct), 160 (96%), Looper (58.5%), LLVM (57%), fyiWillBeAdvancedByHostKThx (43%), and PhoneNumberFormattingTextWatcher (19.5%).

So, our thanks to the people who put in the work, and a particular tip of the hat to the deranged hackers er I mean creative developers who built three particularly-outstanding apps:

First, to Kris Jurkowsky, who pulled an all-nighter and wrote a nifty little app... on a Motorola CLIQ running Android 1.5! Next, to Heliodor Jalba, whose app had some gravity-warping extras and was less than 11K in size. And finally, to Charles Vaughn, whose app included a hilarious “Party Mode” that brought a smile to everyone’s face.


[Gd] [Libraries][Update] jQuery 1.5.2

| More

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

jQuery has been updated to 1.5.2

[Gd] We're back live on twitter

| More

Google Testing Blog: We're back live on twitter

For our followers on twitter, we didn't realize our feed we broken until today! Shame, lots of good posts recently. Come check them out. @googletesting

[Gd] Taking Chrome to Lite speeds

| More

Chromium Blog: Taking Chrome to Lite speeds

When we created Chrome, we focused on speed, simplicity, and security as its hallmark traits. Today, we’re proud to announce a new extension for Chrome, called ChromeLite, which is a giant, sprightly leap ahead on all three fronts.

In our never-ending quest for speed, our team members recently gathered to race the latest and greatest browser versions against each other. Much to our surprise, the winning browser was neither the latest version of Chrome nor another modern browser, but was instead an early text-based browser called Lynx.

Inspired by Lynx’s approach, we decided to experiment with stripping out all the extraneous details of a web page to accelerate page load time by removing a web page’s formatting, colors, images, audio, and video. The end result? ChromeLite -- the extension which brings you the web as it was originally conceived: nothing but pure text, presented in an aesthetically pleasing monochrome palette.

ChromeLite dramatically simplifies the user experience of web browsing by rendering the entire web in plain text. Users won’t have to worry about various media codecs and browser plug-ins to view much of the content on the web today. Preliminary analysis by our top-notch security team also suggests that running ChromeLite reduces your susceptibility to targeted exploits on the web by removing a popular attack surface: color.

In short, we hope ChromeLite gives all users on the web yet another option to safely and speedily enjoy the web in all its pure, unadulterated simplicity. If you’re looking to get your fingers accustomed to these new blazing speeds once you’ve installed ChromeLite, check out our newly developed Chromercise regimen.

Posted by Jeff Chang, Product Manager and Dominic Mazzoni, Software Engineer

[Gd] UA String Changes Coming In Chrome 11

| More

Chromium Blog: UA String Changes Coming In Chrome 11

When websites want to know what browser you're using, they often examine the "user agent", or "UA" string. This is a string that provides information about what browser and operating system you're using. Beginning with Chrome 11, we're making some changes to our UA string, which can affect website compatibility.

For reference, here is what the current (Chrome 10) UA string looks like on a few different platforms:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16

Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16

And in comparison, here are the UA strings for Chrome 11 on the same platforms:

Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24

Let's break down the differences in detail. We've made four changes, two of which are Windows-specific:
  1. On Windows, the initial "Windows;" platform identifier has been removed. This was redundant with the subsequent OS version identifier, and makes us more compatible with Internet Explorer, whose UA string doesn't have this initial token.
  2. The "U" SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are "U" (for "USA" 128-bit encryption support), "I" (for "International" 40-bit encryption support), and "N" (for "None", no encryption support). These days, every browser ships with 128-bit SSL support everywhere, so it's not necessary to advertise it.
  3. On 64-bit versions of Windows, tokens have been added after the OS version. For 32-bit Chrome builds running on 64-bit Windows, we've added "WOW64". (WOW64" stands for "Windows 32-bit On Windows 64-bit" and is the name Microsoft gives its 32-bit compatibility subsystem.) In our source code, we've also added identifiers for 64-bit native builds, specifically "Win64; x64" for x64-based processors and "Win64; IA64" for Itanium systems. (However, we don't currently ship such builds, or have any immediate plans to.) These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses.
  4. The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP Accept-Language header instead, which can supply multiple locales. In fact, websites that relied on the UA string locale probably had some very unhappy visitors, because Chrome always had a bug where the UA string locale was reported as "en-US", regardless of the user's desired locale(s)!
One more question remains: why are we making these changes now? Because websites tend to use common pieces of code to check all browsers' UA strings, it's important for browsers to stay in sync with each other. Mozilla has made the above changes in Firefox 4 (and more; see for details), which was released recently, and we wanted to change Chrome to match as soon as possible, to minimize the disruption to web authors.

As the changes above have trickled into our Canary and Dev builds, we've already found and fixed some problems in Google's UA string parsing libraries that have caused compatibility issues with Google sites (though not all of the affected sites have updated yet). If you see problems on other sites you think might be caused by the new UA string, try running Chrome with an alternate UA string using the --user-agent="<Put older UA string here>" command line flag. (You can double-check the UA string Chrome sends to websites by typing about: in your address bar and hitting .) If that fixes the problem, please let us know by filing a bug in our bug tracker at

Posted by Peter Kasting, Software Engineer

Thursday, March 31, 2011

[Gd] Introducing Page Speed Online, with mobile support

| More

The official Google Code blog: Introducing Page Speed Online, with mobile support

By Andrew Oates and Richard Rabbat, Page Speed Team

At Google, we’re striving to make the whole web fast. As part of that effort, we’re launching a new web-based tool in Google Labs, Page Speed Online, which analyzes the performance of web pages and gives specific suggestions for making them faster. Page Speed Online is available from any browser, at any time. This allows website owners to get immediate access to Page Speed performance suggestions so they can make their pages faster.

In addition, we’ve added a new feature: the ability to get Page Speed suggestions customized for the mobile version of a page, specifically smartphones. Due to the relatively limited CPU capabilities of mobile devices, the high round-trip times of mobile networks, and rapid growth of mobile usage, understanding and optimizing for mobile performance is even more critical than for the desktop, so Page Speed Online now allows you to easily analyze and optimize your site for mobile performance. The mobile recommendations are tuned for the unique characteristics of mobile devices, and contain several best practices that go beyond the recommendations for desktop browsers, in order to create a faster mobile experience. New mobile-targeted best practices include eliminating uncacheable landing page redirects and reducing the amount of JavaScript parsed during the page load, two common issues that slow down mobile pages today.

Page Speed Online is powered by the same Page Speed SDK that powers the Chrome and Firefox extensions and

Please give Page Speed Online a try. We’re eager to hear your feedback on our mailing list and find out how you’re using it to optimize your site.

[Gd] Blogs are for people

| More

The official Google Code blog: Blogs are for people

By Scott Knaster, Google Developer Relations
Scott standing in front of a door with 404 on it. It's funny.
Hello, esteemed Google Code Blog readers! My name is Scott Knaster, and I’m the new editor of this blog. I’m interrupting the usual flow of posts to let you know about some new things happening around here. This blog has the company’s name on it, but of course, like all blogs, it’s written by individual people, to be read by other individual people, like you. We want to do a little more to celebrate that, starting with these small steps:
  • We’re adding a photo and some info about each post’s author. Googlers get around, to hackathons, conferences, and GTUGs, and now you’ll have faces to match up with names when we meet in real life.
  • We’ll spend more time responding to comments. As always, we encourage and appreciate your thoughtful, on-topic comments.
  • We’ll be tweeting more at @googlecode over on Twitter, too. And you can find a list of Google developer-related Twitter accounts here (choose Developers from the Category drop-down).
  • I’ll be hanging around here a lot. Think of me as the host of a big, geeky dinner party. Mostly I’ll be helping edit posts written by others—experts who work on the products they post about—but I’ll also write a few posts myself.
I’ve been working with APIs and platforms for a long time, mostly by writing docs about how to use them. Platforms are full of promise, but they’re only interesting and worthwhile when people build on them.

Please email me at if you have any thoughts or feedback for improving this blog. Or, just leave a comment on this post.

Thanks for being here!

[Gd] ClientLogin #FAIL

| More

YouTube API Blog: ClientLogin #FAIL

The YouTube API supports a number of authentication schemes—AuthSub, OAuth 1 and 2, and ClientLogin—but it’s that last method, ClientLogin, that is in many ways the most problematic. This blog post will cover some of the ways ClientLogin attempts can fail, and when possible, provide ways of working around those failures.

Before we get into that, though, a bit of a public service announcement: given all the ways that things can go wrong when using ClientLogin, please consider using one of the alternative methods of authentication that the YouTube API supports! AuthSub and in particular OAuth 2 are straightforward to implement and aren’t susceptible to the issues that we’ll cover with ClientLogin. Even if you’re writing a small script for personal use, obtaining one long-lived AuthSub or OAuth 2 token and reusing that for authentication is preferable to hardcoding a login name and password for ClientLogin. And just because your code doesn’t have access to a web browser doesn’t mean that ClientLogin is your only option—this guide covers techniques for using OAuth 2 in such scenarios.

With that out of the way, let’s investigate some failures!

Scenario 1: A user with an unlinked YouTube account attempts ClientLogin.
This scenario won’t actually lead to a failure as of right now, but it will in the near future. As was recently announced on the main YouTube blog, all YouTube accounts must be linked to a Google Account or else logins will start fail—the current plan is to disable logins for unlinked accounts towards the end of April. The only workaround is to have your users link their YouTube account to a Google Account. If they login from a web browser, either at or using AuthSub/OAuth, they’ll be taken through the steps to link accounts. It’s important to note that while we are requiring linked accounts, we will continue to accept either a YouTube username or a Google Account email address as the Email parameter in the ClientLogin request.

Scenario 2: A user who has enabled to OpenID federated sign-in attempts ClientLogin.
Federerated sign-in using OpenID is a new method of authenticating Google Accounts that correspond to email addresses on specific email providers (currently Yahoo! and AOL). It is currently being offered on an opt-in basis, so for the time being, just because someone’s Google Account is associated with an or address does not mean that they are using Federated sign-in. For the users who have opted-in, ClientLogin will no longer work at all. With Federated sign-in, all login requests need to be processed by the identity provider, and Google’s ClientLogin servers cannot relay the credentials to a third-party server on the user’s behalf. Because AuthSub and both versions of OAuth are web-based, users can log in directly on the identity provider’s site and have that redirect back to Google’s servers to issue the appropriate AuthSub or OAuth token. Migrating off of ClientLogin to AuthSub or OAuth is the only way to provide authentication that works with OpenID accounts.

Scernario 3: A user who has enabled 2-step verification attempts ClientLogin.
This scenario, and the reasons why it will result in a failure, is covered in detail in an earlier blog post. The important takeaway is that a user with 2-step verification enabled needs to generate application-specific passwords for each application that requires ClientLogin, and provide that password instead of their normal Google Account password. Alternatively, using AuthSub or OAuth allows you users to log in using their two factor credentials directly, leading to a better user experience.

Scenario 4: A user encounters a CAPTCHA when attempting ClientLogin.
This is not a new failure scenario, but it’s often overlooked by developers who don’t properly handle it. The ClientLogin documentation includes recommendations for how your application should handle CAPTCHA responses from ClientLogin attempts. If you’re using AuthSub or OAuth, your application does not need to worry about logic for handling CAPTCHAs—it’s taken care of for you by the standard AuthSub and OAuth login process.

This may seem like an exhaustive list of failure scenarios, but as we continue to iterate on the login experience for YouTube and Google Accounts, chances are more “gotchas” will crop up in the future. We’ll do our best to keep our developer community informed, but the best way to future-proof your application is to stop using ClientLogin!

—Jeffrey Posnick, YouTube API Team

[Gd] Mo’ better to also detect “mobile” user-agent

| More

Official Google Webmaster Central Blog: Mo’ better to also detect “mobile” user-agent

Webmaster Level: Intermediate to Advanced

Here’s a trending User-Agent detection misstep we hope to help you prevent: While it seems completely reasonable to key off the string “android” in the User-Agent and then redirect users to your mobile version, there’s a small catch... Android tablets were just released! Similar to mobile, the User-Agent on Android tablets also contains “android,” yet tablet users usually prefer the full desktop version over the mobile equivalent. If your site matches “android” and then automatically redirects users, you may be forcing Android tablet users into a sub-optimal experience.

As a solution for mobile sites, our Android engineers recommend to specifically detect “mobile” in the User-Agent string as well as “android.” Let’s run through a few examples.

With a User-Agent like this:
Mozilla/5.0 (Linux; U; Android 3.0; en-us; Xoom Build/HRI39) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 Safari/534.13
since there is no “mobile” string, serve this user the desktop version (or a version customized for Android large-screen touch devices). The User-Agent tells us they’re coming from a large-screen device, the XOOM tablet.

On the other hand, this User-Agent:
Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
contains “mobile” and “android,” so serve the web surfer on this Nexus One the mobile experience!

You’ll notice that Android User-Agents have commonalities:

While you may still want to detect “android” in the User-Agent to implement Android-specific features, such as touch-screen optimizations, our main message is: Should your mobile site depends on UA sniffing, please detect the strings “mobile” and “android,” rather than just “android,” in the User-Agent. This helps properly serve both your mobile and tablet visitors.

For questions, please join our Android community in their developer forum.

Written by Maile Ohye, Developer Programs Tech Lead

[Gd] Introducing the +1 button

| More

Official Google Webmaster Central Blog: Introducing the +1 button

Webmaster level: All

We all know what it’s like to get a bit of help when you’re looking for it. Online, that advice can come from a number of places: a tweet, a shared video, or a blog post, to name a few. With Google Social Search we’ve been working to show that content when it’s useful, making search more personally relevant.

We think sharing on the web can be even better--that people might share more recommendations, more often, if they knew their advice would be used to help their friends and contacts right when they’re searching for relevant topics on Google. That’s why we’re introducing the +1 button, an easy way for Google users to recommend your content right from the search results pages (and, soon, from your site).

+1 is a simple idea. Let’s use Brian as an example. When Brian signs in to his Google Account and sees one of your pages in the organic search results on Google (or your search ads if you’re using AdWords), he can +1 it and recommend your page to the world.

The next time Brian’s friend Mary is signed in and searching on Google and your page appears, she might see a personalized annotation letting her know that Brian +1’d it. So Brian’s +1 helps Mary decide that your site is worth checking out.

We expect that these personalized annotations will help sites stand out by showing users which search results are personally relevant to them. As a result, +1’s could increase both the quality and quantity of traffic to the sites people care about.

But the +1 button isn’t just for search results. We’re working on a +1 button that you can put on your pages too, making it easy for people to recommend your content on Google search without leaving your site. If you want to be notified when the +1 button is available for your website, you can sign up for email updates at our +1 webmaster site.

Over the coming weeks, we’ll add +1 buttons to search results and ads on We’ll also start to look at +1’s as one of the many signals we use to determine a page’s relevance and ranking, including social signals from other services. For +1's, as with any new ranking signal, we'll be starting carefully and learning how those signals affect search quality over time. At first the +1 button will appear for English searches only on, but we’re working to add more languages in the future.

We’re excited about using +1’s to make search more personal, relevant and compelling. We hope you’re excited too! If you have questions about the +1 button and how it affects search on, you can check the Google Webmaster Central Help Center.

Posted by David Byttow, Software Engineer, +1 Button

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The Beta channel has been updated to 11.0.696.25 for Macintosh, Windows, Linux and Chrome Frame platforms

The following bugs were fixed
  • cloud print: Error running service on the headless machine (Issue 76991).
  • sync: Not registering for NIGORI data types (Issue 76268).
  • A known crash (Issue 76998 ).
  • REGRESSION: img of extensions not displayed in chrome://extensions within an incognito window (Issue 74905).
  • Cloud policy fetch loop upon POLICY_NOT_FOUND answer from the server (Issue 77232).
  • Token fetcher doesn't correctly enter unmanaged state (Issue 77185).
  • Memory Leak in ChromeFrame in the AutomationResourceMessageFilter::SetCookiesForUrl function (Issue 77421).
  • REGRESSION: Arrows not showing up on tabstrip while dropping links (Issue 74764).
  • Java: Direct users to the right download page (Issue 76634).
  • add es-419, fr-Foo and en-Foo and zh_HK/zh_Hant_HK to Accept-Language list(Issue 62715).
You can find full details about the changes that are in this version of Chrome 11 in the SVN revision log.

If you find new issues, please let us know by filing a bug.

Want to change to another Chrome release channel? Find out how.

Karen Grunberg
Google Chrome

Wednesday, March 30, 2011

[Gd] Identifying App Installations

| More

Android Developers Blog: Identifying App Installations

[The contents of this post grew out of an internal discussion featuring many of the usual suspects who’ve been authors in this space. — Tim Bray]

In the Android group, from time to time we hear complaints from developers about problems they’re having coming up with reliable, stable, unique device identifiers. This worries us, because we think that tracking such identifiers isn’t a good idea, and that there are better ways to achieve developers’ goals.

Tracking Installations

It is very common, and perfectly reasonable, for a developer to want to track individual installations of their apps. It sounds plausible just to call TelephonyManager.getDeviceId() and use that value to identify the installation. There are problems with this: First, it doesn’t work reliably (see below). Second, when it does work, that value survives device wipes (“Factory resets”) and thus you could end up making a nasty mistake when one of your customers wipes their device and passes it on to another person.

To track installations, you could for example use a UUID as an identifier, and simply create a new one the first time an app runs after installation. Here is a sketch of a class named “Installation” with one static method context). You could imagine writing more installation-specific data into the INSTALLATION file.

public class Installation {
private static String sID = null;
private static final String INSTALLATION = "INSTALLATION";

public synchronized static String id(Context context) {
if (sID == null) {
File installation = new File(context.getFilesDir(), INSTALLATION);
try {
if (!installation.exists())
sID = readInstallationFile(installation);
} catch (Exception e) {
throw new RuntimeException(e);
return sID;

private static String readInstallationFile(File installation) throws IOException {
RandomAccessFile f = new RandomAccessFile(installation, "r");
byte[] bytes = new byte[(int) f.length()];
return new String(bytes);

private static void writeInstallationFile(File installation) throws IOException {
FileOutputStream out = new FileOutputStream(installation);
String id = UUID.randomUUID().toString();

Identifying Devices

Suppose you feel that for the needs of your application, you need an actual hardware device identifier. This turns out to be a tricky problem.

In the past, when every Android device was a phone, things were simpler: TelephonyManager.getDeviceId() is required to return (depending on the network technology) the IMEI, MEID, or ESN of the phone, which is unique to that piece of hardware.

However, there are problems with this approach:

  • Non-phones: Wifi-only devices or music players that don’t have telephony hardware just don’t have this kind of unique identifier.

  • Persistence: On devices which do have this, it persists across device data wipes and factory resets. It’s not clear at all if, in this situation, your app should regard this as the same device.

  • Privilege:It requires READ_PHONE_STATE permission, which is irritating if you don’t otherwise use or need telephony.

  • Bugs: We have seen a few instances of production phones for which the implementation is buggy and returns garbage, for example zeros or asterisks.

Mac Address

It may be possible to retrieve a Mac address from a device’s WiFi or Bluetooth hardware. We do not recommend using this as a unique identifier. To start with, not all devices have WiFi. Also, if the WiFi is not turned on, the hardware may not report the Mac address.

Serial Number

Since Android 2.3 (“Gingerbread”) this is available via android.os.Build.SERIAL. Devices without telephony are required to report a unique device ID here; some phones may do so also.


More specifically, Settings.Secure.ANDROID_ID. This is a 64-bit quantity that is generated and stored when the device first boots. It is reset when the device is wiped.

ANDROID_ID seems a good choice for a unique device identifier. There are downsides: First, it is not 100% reliable on releases of Android prior to 2.2 (“Froyo”). Also, there has been at least one widely-observed bug in a popular handset from a major manufacturer, where every instance has the same ANDROID_ID.


For the vast majority of applications, the requirement is to identify a particular installation, not a physical device. Fortunately, doing so is straightforward.

There are many good reasons for avoiding the attempt to identify a particular device. For those who want to try, the best approach is probably the use of ANDROID_ID on anything reasonably modern, with some fallback heuristics for legacy devices.


[Gd] Announcing App Engine 1.4.3. Release

| More

Google App Engine Blog: Announcing App Engine 1.4.3. Release

Just in time for spring, we have a new App Engine release to bring our Java and Python runtimes even closer to parity. For Python, we’ve launched a test library to match the existing Java testing framework, and for Java we’ve introduced the Deferred and Remote APIs. This release also introduces a new Blobstore writing feature, the experimental release of the Prospective Search API in Python, and a few goodies for Task Queue and Cron users.


  • Prospective Search API: The experimental Prospective Search API allows Python runtime users to detect and take action on datastore entities that match certain criteria when they are written. For the experimental release, users will be allowed 1000 subscriptions with the Prospective Search API. Pricing will be announced once the feature is fully launched.

  • Testbed Unit Test Framework: The Testbed suite for Python provides an easy interface for using App Engine API stubs in integration tests similar to the previously existing Java Testing Framework. You can create tests for your application that do not rely on calling App Engine production services, which speeds up the time your tests take to complete, and eliminates dependencies for your test on external services. Here at Google, we’re well known for our testing culture, and we hope that this API will allow you to develop more stable code more quickly.


  • Concurrent Requests: Until now, Java applications relied on starting additional instances to dynamically scale up for higher traffic levels. Now with support for concurrent requests, each application instance may serve multiple user requests at the same time. To start, ensure your application’s code is threadsafe, then enable concurrent requests by adding the <threadsafe> flag to your appengine-web.xml.

  • Java Remote API and Deferred API support: The Remote API and Deferred API libraries have been supported in Python for awhile, and now they can be used with Java, too! The Remote API allows you to perform operations on your application’s datastore from your local machine. This is particularly useful for work that is not well-suited to App Engine’s request/response model. The Deferred API allows users to more easily write and execute ad hoc tasks. Our docs contain more information and examples on how to use the Remote API and Deferred API in Java App Engine.

New and changed APIs

  • Files API: The new Files API in Python and Java allow you to pragmatically read and write data using Blobstore. This API can be used to generate reports, export data, or do anything that your heart desires that requires large, binary objects.

Serving Changes

  • Task Queue and Cron update: We’ve addressed some of your top requested items for Task Queues and Cron. With this release, you can now configure the specific application version to which a task queue or cron job will send requests. For those wanting to schedule cron jobs with a range syntax like “every 5 minutes from 11:00 to 17:00”, that too is available in the 1.4.3 release. Last, but not least, the Admin Console Task Queues page now displays a more accurate estimate of queue size for queues containing more than 2000 tasks.

Coming soon

Finally, we have a pre-announcement about the 1.4.4 release. In 1.4.0, we introduced a feature that allowed users to download code that they’ve deployed to App Engine. In 1.4.2 we released admin roles allowing for Owners. When 1.4.4 is released, we plan on including a change that allows both the person who uploaded the code to download it, as well as the Owner(s) of the project (as listed in the Admin Console). In preparation for this, be sure to properly assign roles to all developers on your App Engine application in the Admin Console. Alternatively, you will still be able to permanently disable the code download feature for your application.

That’s it for now, for additional information read the full release notes, including all new features and issues fixed for Java and Python. All feedback is welcome and encouraged in our groups.

Posted by Greg D'alesandre, The App Engine Team

[Gd] Top Ten Reasons to use Google Plugin for Eclipse

| More

Google Web Toolkit Blog: Top Ten Reasons to use Google Plugin for Eclipse

As I speak at JUGs and conferences around the world, I'm often surprised that some folks have never seen some of the best features of Google Plugin for Eclipse, such as using the Eclipse debugger with a GWT app. So in no particular order, here are 10 reasons you should use Google Plugin for Eclipse (GPE).

  1. GWT+GAE made easy. GPE is the easiest way to get started with GWT and Google App Engine (GAE). Just check the SDKs box when you install the plugin through the Eclipse update site. It's easy to upgrade the SDKs this way (Help | Check for updates), and a status bar message in Eclipse will remind you when new versions are available.

  2. Wizards. It's easy to create your first GWT+GAE project. Click File | New | Web application project and you'll get a sample app that you can run locally to kick the tires and then deploy to Google App Engine. Beyond creating a new project, there are wizards to create new UiBinder templates, ClientBundles, GWT modules, and entry points. To use the wizards, click File | New and look for the items with the GWT toolbox logo (or click File | New | Other... and browse to the Google Web Toolkit folder).

  3. GWT Designer, now bundled with GPE, lets you quickly create a GUI. To see it in action, create a class that extends GWT's Composite class, then right-click on the file and Open With | GWT Designer. When the editor opens, click on the Design tab at the bottom. After GWT Designer launches, click a tool on the palette (say, LayoutPanel), then click on the empty design window to drop the widget in place. Click the source tab to see the code that GWT Designer wrote for you. It's a great way to learn the new cell widgets like CellTable and TextColumn, and GWT Designer has a built-in WYSIWYG CSS editor, too.

  4. Quick fixes and warnings help you write good GWT code quickly. For example, when you create an interface that extends GWT's RemoteService class, GPE will prompt you to create the corresponding async interface required for GWT-RPC. Just click Ctrl+1 (Quick Fix) on the red squiggly and away you go.

  5. Dev mode integration lets you test your code quickly. Run As | Web Application starts GWT development mode and the App Engine dev server (if applicable) so you can test your code in the browser. When dev mode starts, look for the Development Mode tab in Eclipse and double-click the URL to launch your app in the default browser. With GWT dev mode running, you can make changes to your Java code, hit Refresh in the browser, and see your changes live.

  6. Debugging in dev mode rocks. Set a breakpoint in Eclipse, right-click on your project, and Debug As | Web Application. Switch to the browser and run your code. Eclipse will open the Debug perspective where you can step through your code line-by-line, inspect variables, etc.

  7. One-click deploy to Google App Engine. Just click the Google App Engine logo on the toolbar.

  8. Maven support. GPE works with Maven projects via m2eclipse (see setup instructions). Check out a Maven project like the Expenses GWT+GAE sample app into your workspace, then click File | Import | Existing maven project and point it to the pom.xml file. Maven will download all the jars and plugins required in the POM, and GPE will configure the project with the GWT and/or App Engine SDKs from the POM. You can then run Maven commands externally or Run As | Web Application in Eclipse.

  9. Testing. Run As | GWT JUnit Test lets you easily run test cases that extend GWTTestCase.

  10. SpeedTracer. You can launch SpeedTracer from within Eclipse. Click the green stopwatch icon on the GPE toolbar. GPE will compile your app, run it, and launch SpeedTracer in Chrome to profile your app.

Haven't tried it yet? Install Google Plugin for Eclipse now.

Tuesday, March 29, 2011

[Gd] In-app Billing Launched on Android Market

| More

Android Developers Blog: In-app Billing Launched on Android Market

[This post is by Eric Chu, Android Developer Ecosystem. —Dirk Dougherty]

Today, we're pleased to announce the launch of Android Market In-app Billing to developers and users. As an Android developer, you will now be able to publish apps that use In-app Billing and your users can make purchases from within your apps.

In-app Billing gives you more ways to monetize your apps with try-and-buy, virtual goods, upgrades, and other billing models. If you aren’t yet familiar with In-app Billing, we encourage you to learn more about it.

Several apps launching today are already using the service, including Tap Tap Revenge by Disney Mobile; Comics by ComiXology; Gun Bros, Deer Hunter Challenge HD, and WSOP3 by Glu Mobile; and Dungeon Defenders: FW Deluxe by Trendy Entertainment.

To try In-app Billing in your apps, start with the detailed documentation and complete sample app provided, which show how to implement the service in your app, set up in-app product lists in Android Market, and test your implementation. Also, it’s absolutely essential that you review the security guidelines to make sure your billing implementation is secure.

We look forward to seeing how you’ll use this new service in your apps!


[Gd] Getting smoother animated web content while reducing CPU usage

| More

Chromium Blog: Getting smoother animated web content while reducing CPU usage

The web is becoming more interactive and animated day by day. Many web pages use the Canvas element to draw rich 2D content via the 2D context or modify DOM elements on the fly. These pages generally use the setTimeout or setInterval APIs to receive frequent callbacks, allowing them to redraw their content periodically, or use DHTML to move elements on the page. As 3D content drawn using the WebGL API increases in popularity, it will use similar animation techniques.

Unfortunately, setTimeout and setInterval don’t take into consideration whether the destination element, or even the tab that contains it, is actually visible. So, pages with high-frequency timers will consume CPU resources even if the tab is in the background. On laptops, netbooks, and mobile devices of all kinds, reducing CPU consumption is essential in order to prolong battery life. Additionally, excess CPU consumption by background tabs reduces the smoothness of animations on the foreground tab.

Excessive CPU consumption by timers on web pages is not a theoretical problem. We have measured web sites containing mostly static text content firing timers at a rate of over two hundred per second.

Mozilla recently introduced the experimental mozRequestAnimationFrame API, which has different semantics than setTimeout or setInterval. Instead of the developer specifying a target frame rate, the browser runs the given callback when it is ready to produce the next animated frame. The callbacks are specifically known to be relevant to the animation of the page, and don’t run too often.

An experimental webkitRequestAnimationFrame API has been upstreamed to WebKit, and is available starting in Chrome 10. This is essentially the same as mozRequestAnimationFrame, but supports an optional second argument which is the element that the callback intends to animate. This additional information will allow the browser to avoid animating elements that are not visible to the user. See this bug report for more details. Chrome doesn’t run requestAnimationFrame callbacks for background tabs at all, which dramatically reduces CPU consumption when multiple tabs containing animated content are in the same window.

The WebGL samples project contains a three dimensional graphics library that has been modified to use requestAnimationFrame rather than setTimeout or setInterval. Take a look at this library for a good example of how to convert existing timeout based animations to the new style, while preserving compatibility with browsers that don’t support requestAnimationFrame.

In the forthcoming Chrome 11 release, we plan to reduce CPU consumption even for pages that are using setTimeout and setInterval. For background tabs, we intend to run each independent timer no more than once per second. This change has already been implemented in the Chrome dev channel and canary builds. While there may be some compatibility impact for web pages, we believe that improving the user experience for the foreground tab, and increasing battery life, are problems needing to be addressed. Please send us your comments on this planned change.

Posted by Kenneth Russell, Software Engineer

[Gd] High Replication Datastore: A Solid Choice for Enterprise-class Applications

| More

Google App Engine Blog: High Replication Datastore: A Solid Choice for Enterprise-class Applications

WebFilings delivers a revolutionary cloud-based application that enables companies to collaboratively build and file financial reports with the SEC.
Built on the Google App Engine platform
, companies of all sizes use WebFilings software to take control of their financial reporting processes. WebFilings greatly reduces the time and stress required to file financial reports with the SEC.

Enterprise Requirements

As an enterprise class application supporting many Fortune 100 customers with strict financial reporting requirements, we simply cannot afford to have maintenance outages or service disruptions. Google App Engine has proven to be a robust platform for us to build on and has allowed us to scale seamlessly to support a rapid increase in customer demand. We’re pleased to report that a recent innovation by Google has allowed us to achieve an even higher level of availability and performance.

This recent innovation is the High Replication Datastore or HR Datastore. HR Datastore allows us keep our application live even during system upgrades and other maintenance operations that Google may be performing. In addition, it delivers a new level of reliability that has given our application significantly more consistent response times and 100% availability since making the move.

Decisions... Decisions...

We were originally a bit hesitant to move to HR Datastore because it was a relatively new offering from the App Engine team. Even though the underlying technology has been around for a long time, we weren’t sure initially how the eventual consistency model might affect our application. Well, we did our homework and read the Google posts on HR Datastore, followed the App Engine news groups, pinged Googlers via the App Engine Office Hours Chat on IRC, and did some prototyping with entity groups and eventually consistent queries. From this we got a better handle on how entity groups worked to enforce strong consistency with ancestor queries and also learned of the potential performance issues of doing large parallel db.get() operations across multiple entity groups. We also reviewed our code, and made a few changes to our application where we needed to use entity groups to have strong consistency. In the end, we found the move to be much less work than we had anticipated.

The Migration

The actual migration to HR Datastore was a fairly simple process. Essentially, we just set up a a new appspot instance, and selected the High Replication Datastore option during creation. Then we migrated our data to the new instance.

During our migration process we:

  1. Created our new instance and deployed a new version of code to work with the new entity groups
  2. Scheduled our maintenance window with our customers
  3. Put our current master/slave instance into read-only mode
  4. Copied the data from our master/slave instance to our HR Datastore instance. (Due to the size of our data, this was accomplished with some help from the App Engine team)
  5. Ran a migration mapreduce to iterate over a few entities that now needed to be in entity groups. These were saved with a new parent making them part of the entity group. This enables queries to be consistent.
  6. Implemented a site alias that routes customers to the new instance,, from Note: This feature is not generally available so you should contact the App Engine team directly if you need similar functionality.

In short, we went through a complete release and testing cycle and got our application migrated to HR Datastore in under a month. The actual migration happened overnight when we moved a litte over 200GB of data to our new HR Datastore instance, executed our migration mapreduce, and did our verification testing in about five hours. Since moving to HR Datastore, we are wondering why we ever even thought twice. Our customers and our Customer Success Team that works with customers every day have given us feedback that the application is performing better than ever and we have had no downtime since the move.

A Solid Choice

The High Replication Datastore was designed with the needs of large enterprises in mind. HR Datastore provides maximum uptime, multiple datacenter redundancy, consistent response times, along with scalability and performance that has met the needs of our fast growing company. It does take some planning to make the move, however. You should be prepared to review your existing code and test thoroughly beforehand. We found that this effort alone had a significant payback in terms of overall application performance and reliability. Even though the average latency on HR Datastore calls can sometimes be a little bit longer, we were able to optimize and end up with an overall experience that was better for the end user.

If you have an application that has these same demands then my only question for you is “When are you moving to HR Datastore?”. If you are like us, you will be very glad you took advantage of this latest innovation from the Google team.

Posted by Dave Tucker

Director of Product Development

WebFilings (

Monday, March 28, 2011

[Gd] Student applications now being accepted for Google Summer of Code

| More

The official Google Code blog: Student applications now being accepted for Google Summer of Code

(Cross-posted with the Google Open Source Blog.)

Today marks the start of the 2011 Google Summer of Code student application period.
Google Summer of Code is a global program where university students are given a stipend to write code for open source projects over a three month period. Through Google Summer of Code, accepted students are paired with a mentor from the participating projects, gaining exposure to real-world software development and the opportunity for employment in areas related to their academic pursuits. Best of all, more source code is created and released for the use and benefit of all.

Google Summer of Code is a highly competitive program with a limited number of students being accepted. We are pleased to announce that this year we have enlarged the program so that we can accept as many as 150 additional students. We hope all interested students will apply!

Now it is time for the students to submit their proposals to the accepted mentoring organizations via the Google Summer of Code program website from today through Friday, April 8th 19:00 UTC. For the past 10 days students have had the opportunity to review the Ideas pages for this year’s 175 accepted projects and to research which projects they would like to contribute to for this year’s Google Summer of Code.

Every year we have thousands of students who apply for the Google Summer of Code program but due to the limited number of slots many students are not able to be a part of the program. The quality of your proposal is what will make you stand out from your peers. Students should consult the Google Summer of Code student manual for suggestions on how to write a proposal that will grab the attention of the mentoring organizations. Multiple proposals are allowed but we highly recommend focusing on quality over quantity. The mentoring organizations have many proposals to review, so it is important to follow each organization’s specific guidelines or templates and we advise you to submit your proposal early so you can receive timely feedback.
For more tips, see a list of some helpful dos and don’ts for successful student participation written by a group of experienced Google Summer of Code administrators, our user’s guide for the program site, Frequently Asked Questions and timeline. You can also stay up-to-date on all things Google Summer of Code on our Google Open Source blog, mailing lists or on IRC at #gsoc on Freenode.
Good luck students and remember to submit your proposals early–you only have until April 8!

By Stephanie Taylor, Open Source Programs Office

Sunday, March 27, 2011

[Gd] OAuth 2.0 for Apps APIs

| More

Google Apps Developer Blog: OAuth 2.0 for Apps APIs

You might have seen the announcement last week about OAuth 2.0 coming to Google APIs. It’s a great step forward that will make it much easier for web, mobile, and desktop applications to securely access user data. What you might not have heard is that OAuth 2.0 already works with many of the Google Apps APIs like contacts, calendar and docs.

Because the spec is still under development, OAuth 2.0 support is considered experimental until the spec is stabilized. In the mean time, if you’re interested in learning more about it you can give it a try with some of the APIs you’re already familiar with.

One small tip -- if you know the user is a Google Apps account and you already know the user’s domain, try adding the query parameter “hd” with the domain name as the value when requesting authorization. The hint helps provide a better login experience for Google Apps users. For users on domains that haven’t yet upgraded to the new account system it’s required for now, but we’re working on improving the user and developer experience to make it even easier.

Posted by Steve Bazyl, Google Apps Marketplace Team

Want to weigh in on this topic? Discuss on Buzz


[Gd] Contact Sharing using Google Apps Script

| More

Google Apps Developer Blog: Contact Sharing using Google Apps Script

Editor's Note: This article is written by Steve Webster and Vinay Thakker who work at Dito. Dito has developed applications such as Dito Directory which is available in the Google Apps Marketplace.

You just created your own contact group in Google Apps Contact Manager and now you want to share this contact group with a few other coworkers (not the entire company). Over the last couple of years, our team at Dito often got this request from our customers. We decided to leverage Google Spreadsheets & Google Apps Script to allow sharing of user’s “personal contact group” with only a select group of coworkers.

How does it work?

The Apps Script implements a three step wizard. Upon completion of the wizard, the script sends the sharing recipients a link to open the spreadsheet to import the user’s recently shared contact group. The three steps in the wizard are.
  • Step 1 lists all the current contact groups in user’s account. The user can select the group he/she wants to share.
  • Step 2 allows user to select the colleagues with whom the user wants to share his/her personal contact group with.
  • Step 3 lets the user submit the sharing request.

Designing using Apps Script Services

Apps Script has various services which can be used to build the user interface, access the user’s contact list and send emails without the need to compile and deploy any code.

1. Security (guide)

Before a script can modify a user’s contacts, it needs to be authorized by that user. The authorization process takes place when a user executes the script for the first time. When a user makes a request to share his/her contacts, our script sends a link to the intended recipients by email. Upon clicking this link and the “Run Shared Contact Groups” button in the spreadsheet, the recipient will first need to grant authorization to execute the script. By clicking the “Run Shared Contacts Groups” button again, the script will proceed with creating the shared contact group.

2. Spreadsheet Service

In developing this script, there was a fair amount of data that needed to be exchanged between different users. We used Apps Script’s Spreadsheet Service for temporarily storing this data.

// grab the group titled "Sales Department"
var group = ContactsApp.getContactGroup("Sales Department");
// from that group, get all of the contacts
var contacts = group.getContacts();
// get the sheet that we want to write to  
var ss = SpreadsheetApp.getActiveSpreadsheet();
var sheet = ss.getSheetByName("Contact Data");
// iterate through contacts
for (var i in contacts) {
//save each of the values into their own columns
sheet.getRange(i, 1, 1, 1).setValue(contacts[i].getGivenName());
sheet.getRange(i, 2, 1, 1).setValue(contacts[i].getFamilyName());
sheet.getRange(i, 13, 1, 1).setValue(contacts[i].getWorkFax());     
sheet.getRange(i, 14, 1, 1).setValue(contacts[i].getPager());       
sheet.getRange(i, 15, 1, 1).setValue(contacts[i].getNotes());       

3. Ui Service

Ui Services in Google Apps Scripts have an underlying Google Web Toolkit implementation. Using Ui Services in Apps Script, we easily built the user interface consisting of a 3 step wizard. In designing Ui using Ui Services, we used two main types of Ui elements - Layout Panels and Ui widgets. The layout panels, like FlowPanel, DockPanel, VerticalPanel, etc., allow you to organize the Ui widgets. The Ui widgets (TextBoxes, RadioButtons, etc.) are added to layout panels. Ui Services make it very easy to assemble and display a Ui interface very quickly.

We built each of the components on their own, and then nested them by using the “add” method on the desired container. The UI widgets in the screenshot above were constructed by the code below:

// create app container, chaining methods to set properties inline.
var app = UiApp.createApplication().setWidth(600).setTitle('Share The Group');
// create all of the structural containers
var tabPanel   = app.createTabPanel();
var overviewContent = app.createFlowPanel();
var step1Content = app.createFlowPanel();
var step2Content = app.createFlowPanel();
var step3Content = app.createFlowPanel();
// create u/i widgets
var selectLabel = app.createLabel("Select one of your Contact Groups you want to share with others.");
var contactGroupDropdown = app.createListBox().setName('groupChooser');
// add all children to their parents
tabPanel.add(step1Content,"Step 1");
tabPanel.add(step2Content,"Step 2");
tabPanel.add(step3Content,"Step 3");
// tell the spreadsheet to display the app we've created.

Continuing with this pattern, we created a pretty complex design using the UI Services. The next step in building a useful user interface is actually building in event handlers for the UI Widgets. Event Handlers let Apps Script know which function you want to run when your script needs to respond to a given user interaction. The code below is an example of a DropDownHandler that we used in our script in Step 1 of the wizard.

// create a function to execute when the event occurs. the
// callback element is passed in with the event.
function changeEventForDrowdown(el) {
 Browser.msgBox("The dropdown has changed!");
// create event handler object, indicating the name of the function to run
var dropdownHandler = app.createServerChangeHandler('changeEventForDrowdown');  
// set the callback element for the handler object.
// add the handler to the "on change" event of the dropdown box

4. Contacts Service

When a user of the script chooses to share a specific group, the script saves that group contact data into a spreadsheet. When a sharing recipient clicks on the run button to accept the contacts share request, the script fetches the contact group data from the spreadsheet and uses the Contacts Service to create contacts for the share recipients.

var group = ContactsApp.createContactGroup(myGroupName);
for (var i = 0; i < sheet.getLastRow(); i++) {
 var firstName = sheet.getRange(i, 1, 1, 1).getValue();
 var lastName = sheet.getRange(i, 2, 1, 1).getValue();
 var email = sheet.getRange(i, 3, 1, 1).getValue();
 var myContact = ContactsApp.createContact(firstName, lastName, email);
 // ...
 // set other contact details
 // ...

As this application shows, Apps Script is very powerful. Apps Script has the ability to create applications which allow you to integrate various Google and non-Google services while building complex user interfaces.

You can find Dito’s Personal Contact Group Sharing Script here. Click here to view the video demonstration of this application. You can also find Dito Directory on the Google Apps Marketplace.

Posted by Steve Webster and Vinay Thakker from Dito
Want to weigh in on this topic? Discuss on Buzz