Friday, April 3, 2009

[Gd] Dev update: Fixes Right-click Copy and "Confirm Form Submission"

| More

Google Chrome Releases: Dev update: Fixes Right-click Copy and "Confirm Form Submission"

Google Chrome's Dev channel has been updated to We're late this week, because I wanted to make sure we fixed the #1 annoyance with 171.0: you can't copy text with right click.

You can find out about getting on the Dev channel here:

Notable Changes:
  • Fixed not being able to copy selected text by using right-click (Issue 8883).
  • Added support to cache some form submissions so that when you press back, you don't get the annoying "Confirm Form Submission" page (Issue 2636).
  • The Web Inspector should be working properly again (right-click > Inspect Element) (Issue 8821).
  • Fixed most pages being cut off on the side and bottom when you print them (Issue 9535).
Last Week's Known Issues Fixed:
  • Fixed problem of creating multuiple Download tabs in a window (Issue 8767). Thanks to a contribution by Mohamed Mansour.
  • Fixed the progress indicator for downloads (Issue 8220).
  • Fixed History tab only showing today's browsing history (Issue 8827).
  • Fixed auto-detect for page encoding (Issue 8587).
Known Issues
  • Cannot drag bookmarks on then New Tab page (Issue 9674).
  • Mouse wheel scrolling does not scroll windows that aren't focused (9647).
  • Plus much, much more! Let us know about the issues you find by filing a bug, but please search the open issues first.
A detailed list of changes in this release is in the release notes.

--Mark Larson
Google Chrome Program Manager

[Gd] A new look for the Google Code homepage

| More

Google Code Blog: A new look for the Google Code homepage

We've been working with our user experience team to help our users discover relevant and timely developer product information faster on the Google Code homepage. Where it previously required several clicks to find the latest product news and announcements on the Google Maps API blog, for example, the newly redesigned homepage now surfaces this information at a glance. The new homepage will be updated regularly with our latest product news, coding tips, developer profiles, videos, and cool examples. See the screenshot below for an example or visit Google Code now for the latest updates.

Be sure to subscribe to our new aggregate Google Code: News Feed in your favorite feed reader to receive all the Google developer updates as they happen.

And please tell us what you think about the new homepage.

By Mike Marchak, Google Code Team

[Gd] Making content creation easy with the Google AJAX APIs - Guest post

| More

Google AJAX APIs Blog: Making content creation easy with the Google AJAX APIs - Guest post

We started with the idea that we could make it significantly easier and more fun to discover new and interesting things to do anywhere in the world, based on recommendations from people who know a place well. Whether it was a neat museum, a hidden local restaurant, or a great place to go shopping we wanted to make it super easy and fun for people to share recommendations for their favorite places, wherever they might live.

The trick of course was in how to do this. It was important for us to combine ease of making a recommendation -- our goal was that it should be as simple as entering the name of a place, and a few sentences about why you liked it -- with rich information about a place so it was really useful to others -- photos, contact information, maps, etc. The solution, not surprisingly since I'm writing here, was to use a number of Google's APIs to gather related information about the recommendation and make it easy for our members to include it in their recommendation.

You can best see how this works by going through our recommendation flow, or watching the video below.

Let me walk you through how this is working under the hood:

1) When the page loads, the first thing we do is use the Google loader to load the JQuery and JQuery UI libraries, as well as Google Maps. As part of this, we also grab the user's current location using google.loader.ClientLocation and store the lat/lng if available to use later.

2) In step 1, we ask the user for what's being recommended. We use this string to do a Google local search for business listings and KML results that match, using the user's current location to bound the local search by setting the sll and sspn parameters. Between local business listings and KML results, we can offer incredible global coverage of everything from restaurants to tourist attractions to hole-in-the-wall bars and clubs. We're using the JSON version of the local search API, which we call from our servers using Python's urlopen() so that we can supplement the results with our own database of results.

3) In step 2 we do an image search for related images using Google's image search API. While we let users change the search terms to find just the right picture, often our default image search (which combines the name of the place and a city name) returns great results. There are photos of almost everything, so you can even recommend a particular dish at a restaurant in Taipei and have the photos to go along with it.

4) In step 3, we ask for a few sentences about why that place or activity really stands out to them. After the recommendation has been submitted, we use the Google Language APIs to detect the language of the recommendation, which we can later use to filter content by your language, and we hope to someday integrate the ability to translate recommendations into your language of choice.

Its a very simple and fast process for the user making the recommendation, but the result is a recommendation with address, phone number, map, and photo that is really useful to another user looking to discover something new.

We've built our whole product around the Google APIs, and feel like we're just scratching the surface of what's possible. We're planning to let users add other information (like related websites, searches, news, etc.) using Google's APIs as well.

We'll be at Google I/O on May 27-28 talking about what we've done so far, and will hopefully have a few new uses of the Google APIs to show off at that time. Please come say hello -- we'd love to hear your feedback on nextstop, or share tips on using the Google APIs. You can also check out some of the places recommended near the Moscone center, or add a few of your own!

Carl Sjogreen (co-founder,

[Gd] Google Developer Products Help Connect With America

| More

Google Code Blog: Google Developer Products Help Connect With America

Last Thursday was a momentous day for citizen participation in government. As you may have heard, President Obama hosted the first online Town Hall meeting with questions submitted and voted on via the internet. The Developer team at Google is honored that two of our technologies, App Engine and Google Web Toolkit, played a role in making this possible.

Google Moderator, built with App Engine and Google Web Toolkit, allows users to submit and vote on questions collaboratively. Originally developed for Google company meetings, it's now available for anyone to use -- but being featured on offered an unprecedented level of potential traffic and attention. We are thrilled that, thanks to scalable hosting provided by App Engine, Moderator successfully handled traffic from tens of thousands of simultaneous visitors.

During the 48-hour open voting period, the site peaked at 700 hits per second, and 92,934 people submitted 104,073 questions and cast 3,605,984 votes. In total, over one million unique visitors visited the site before the town hall. Even while the site was featured on major news outlets and even the Google homepage the other 50,000 apps built on App Engine were fully supported and experienced no adverse effects.

Since the front-end of Moderator was written using GWT, most user interaction with the site was handled via AJAX requests made from the browser to the server. This enabled a very responsive UI while at the same time keeping bandwidth down. It also made it easy to make some last-minute adjustments to the UI, while ensuring that the JavaScript was compatible with all browsers and all platforms.

As would be expected when a website is utilized by the White House and is featured in the media, there were dramatic, and sometimes unforeseen, upswings in traffic. The graph below shows some of the major surges in load to which App Engine adapted. Conventional web hosting strategies demand the pre-provisioning of enough servers to handle load. Sometimes, as was the case with Moderator on, accurate traffic estimates can be difficult to develop ahead of time. Fortunately, since Moderator runs on App Engine, all servers and resource allocation were handled automatically. With App Engine, you never need worry whether you've set up enough machines...we'll automatically spin up new servers as traffic grows.

If you haven't tried App Engine yet, we encourage you to join the 150,000 developers who have already built highly scalable web applications on top of Google's computing infrastructure. To learn more, visit and make plans to attend our sessions at I/O at the end of May.

By Mike Repass, Product Manager, App Engine

[Gd] Signing changes in the iGoogle sandbox

| More

iGoogle Developer Blog: Signing changes in the iGoogle sandbox

In case you haven't seen the announcement on the OpenSocial blog, some changes to the way iGoogle's REST and RPC endpoints verify requests will be going live today, on the developer sandbox. If you're using a client library (Java, PHP, Python, Ruby), the latest versions will be compatible with these changes.

To ask questions about the client library changes, please check out the client libraries group. As always, for other questions, see the iGoogle developer forum.

Posted by Dan Holevoet, Developer Programs

Thursday, April 2, 2009

[Gd] Important OAuth signing changes coming to a container near you

| More

OpenSocial API Blog: Important OAuth signing changes coming to a container near you

Although OAuth and OpenSocial make a powerful combination, it's important for developers to know specific implementation details for each container. If you're a developer using the OpenSocial REST and RPC protocols, either with the client libraries or by rolling-your-own implementation, we wanted to let you know about two fundamental changes coming to Shindig which are intended to simplify the implementation and use of OAuth.

First, using content-type: application/x-www-form-urlencoded in any client to server requests will be strictly prohibited. Instead, we recommend using application/json, application/xml, or application/atom+xml.

Second, in addition to the current method of body signing (which treats the entire body as a query parameter), a new implementation will be made available called the request body hash. Developers should use one method or the other, not both, on any given request. When available, the client libraries will default to using the request body hash.

Here's a bit of background on these changes:

In order to verify that requests sent by developers to OpenSocial containers are actually coming from a trusted source, they are cryptographically signed. The container verifies signature to check that the request originated from the developer and to ensure that the details of the request have not been intercepted or modified by a third party.

In most cases, this turns out just fine, but incompatibilities and inconsistencies arise when you happen to send a request containing "&" or "=" characters in the body, such as this request to update appdata:


When such a body is sent along with a content-type of application/x-www-form-urlencoded, Java Shindig (following the Java servlet spec) assumes that the "&" and "=" characters delineate key/value pairs of form data (it's x-www-form-urlencoded after all). When these parameters are reordered and put together as part of the OAuth signing process, the new signature will not match the one sent by the developer (who treats the request body as one giant parameter instead of several, as intended). Thus, the request fails.

However, when the content-type of the request body is properly disclosed (application/json in this case), Java Shindig will treat the body as one parameter, thereby avoiding any conflicts with either the spec or the "&" and "=" characters. In addition, support for the request body hash does away with the non-standard behavior of putting the request body into the signature base string, substituting a hash in its place. It's quite elegant, and far simpler from an implementation standpoint.

For more history and discussion, see this thread in the OpenSocial and gadgets spec group.

What this means for you as a developer:

If you've been dreading the part where I say "go implement this in your code," fear not. We've released new versions of each of the client libraries (Java, PHP, Python, Ruby) which support the changes, while maintaining backwards compatibility.

Starting today, the iGoogle and orkut sandboxes are incorporating these changes to let you start testing right away

If you have any questions on the client library changes, feel free to ask in the client libraries group.

Posted by Dan Holevoet, Google Developer Programs

[Gd] GWT Community Updates

| More

Google Web Toolkit Blog: GWT Community Updates

It's about that time again.  We've had a lot of activity in the community since the last update that we'd like to share. Check them out below:

Community announcements

Spreading the word: The community is lucky to have a number of active members who blog, present and contribute to GWT. They are often a great resource for more news about GWT than can be tracked in our own single blog. Check out some of these GWT gems below:

  • onGWT: maintained by Didier Girard, it's constantly updated with tidbits of news relating to GWT.
  • Roughian Examples : Ian Bambury has created a site that gives a different take on how GWT components fit together. There is also a free email course available!

IT Mill Toolkit 5.3.0 production release ready: The folks at IT Mill have worked hard to create IT Mill Toolkit - a set of technologies and tools that allow you to develop Ajax applications using Google Web Toolkit based, server-side binded widgets. Check out their latest production release announcement for more details.

GWT Articles section revamped: We've been working on updating and enriching articles on various GWT topics. The latest addition treats the topic of testing methodology using GWT. Please check out the new articles and let us know what you think of them. Also, if there is a topic that you are an expert on that you would like to write about, get in touch with us.

More fun stuff

Google I/O

: Google's developer conference is just around the corner. If you're planning on attending, you're still in time for early bird registration prices! There are going to be some great GWT sessions presented at this year's conference that you won't want to miss. We're hoping to see you there!

[Gd] Google Code Search, with more freshness and features

| More

Google Code Blog: Google Code Search, with more freshness and features

From the day we launched, the most popular request we've gotten has been to crawl code more regularly and to update our our index more frequently. Today we're happy to announce that Google Code search will automatically crawl and index version controlled repositories (unless requested otherwise by code repository owners) at least once a week. To help you know when a search result was last indexed, the search results crawled within the last week will have a last crawled date to give you an idea of how fresh the results are.

In addition, we have improved how we display search results. As an extension to our 'Outline' mode, certain search results will now have a snippet that displays the structure of a class, instead of the regular code snippet. Search results from different versions of the same package are now grouped and indented based on versions of that package. For example, search for package:classpath JFrame.

And, in case you missed it, we added LOLCODE support in time for April 1st.

We hope you try out these new features. Once you do, please let us know what you think.

By Dmitry Barashev & Ali Pasha, Google Code Search Team

[Gd] Ad Scheduling: it's all about timing

| More

AdWords API Blog: Ad Scheduling: it's all about timing

"There's a time for everything." This is something I've been hearing since I was a kid, but today I'm not here to tell you that you shouldn't have your dessert before your meal or play with noisy toys after dark; rather, I'd like to talk to you about whether it's really a good idea to advertise your lunch menu or your toy shop discount when your customers are sleeping.

Advertising, as is the case with most things in life, is all about timing. A lot of businesses have special advertising needs during certain times of day, and they'd like their customers to know about them at the right time.

Let's take the example of a newly opened downtown coffee shop that's looking to let people know about its great selection by advertising with AdWords. What happens when their ad runs at night? Well, people will learn about the menu, but at the wrong time. Since it's now after hours, and the place is closed, they might forget about it overnight and not visit the coffee shop the next day; all of this simply because that was the wrong time to be seeing that ad. Another example would be a toy shop running a special "lunchtime craze" deal to try to increase sales during that time of day; advertising after the event is not very useful and may even be counter-productive, as it's disappointing for people to realize that the promotion hours are over.

Fortunately, there are mechanisms built into AdWords and the AdWords API to allow you to decide when to run your ads, automatically, without requiring you to manually enable and disable them; this is called "Ad Scheduling".

Scheduling works at the campaign level, so it applies to all active ad groups and ads inside it. The AdSchedule object contains two items:
  • an "intervals" list, containing any number of SchedulingInterval objects
  • a "status" field, that enables or disables the AdSchedule

Each SchedulingInterval not only allows you to define a number of properties, such as day and starting/ending times, but also, notably, a multiplier. This multiplier is a very useful tool, as it provides a way to enable and disable displaying of the ad (by setting to a non-zero and zero value, respectively), as well as a way to increase or decrease your bids at certain times.

In our coffee shop example, to make sure the ads run mostly during opening hours, we would set displaying of ads to start a bit before opening and to end a little bit before closing:

SchedulingInterval[] days = new SchedulingInterval[6];


// Set weekday and Saturday schedule
for (int i = 0; i < style="color: rgb(63, 127, 89);">// Start at 8:45 am...
// ... and end at 7:45 pm
// Run at normal bid rates

// Closed on Sunday, so we're omitting it from the array

As for our toy shop, in order to give customers fair warning about the special lunchtime deal, advertising would start early in the morning and increase significantly during the promotion hours:

SchedulingInterval early = new SchedulingInterval();
SchedulingInterval peak = new SchedulingInterval();

// Sample schedule for Monday

// Start at 8:00 am...
// ... and run until promotion starts
// Run at normal bid rates

// Start higher bidding at noon...
// ... and run until promotion ends...
// ... at double the bid!

(And here's how you can add a campaign with scheduling in your language of choice)

With these small changes to your campaigns, you should be able to make the most out of your ads by having them show at the right time. That likely means better, more focused targeting, with higher returns, all for just a little bit of setup work; that's like eating your cake and keeping it too! Just make sure you don't do it before lunch, otherwise it'll spoil your appetite.

--Sérgio Gomes, AdWords API Team

Wednesday, April 1, 2009

[Gd] A Brand New Language on Google App Engine!

| More

Google App Engine Blog: A Brand New Language on Google App Engine!

Posted by Alon Levi, App Engine Team

It's been almost a year since we've launched App Engine with support for Python, and what a year it's been! We've gotten fantastic feedback from developers, and we've released loads of new features! When we launched, we promised support for another runtime language, and indeed this has been among the most requested features from our developers since day one.

Well, we fed Google's new CADIE Strategic Decision Maker the App Engine issue tracker, our groups, and various blog posts around the internet to help select a new runtime language for App Engine. Today we're excited to officially announce support for FORTRAN 77!

If you're an enterprise customer and want to take advantage of Google App Engine, but have a large and cumbersome legacy system, we want to make it easy for you to port to the cloud. By providing a Fortran 77 runtime, along with a familiar, easy-to-use deployment mechanism, we hope to make this process efficient and straightforward.

Want to give it a try? Download our SDK and deploy your application by mailing punch cards to:

Google App Engine, C/O APPCFG

1600 Amphitheatre Pkwy

Mountain View, CA 94043

and we'll take care of the rest! We welcome your feedback on our newest addition to the App Engine family--you can discuss it on our Google Group!


[Gd] eBay announces Selling Manager Apps beta, opens up platform to gadget developers

| More

OpenSocial API Blog: eBay announces Selling Manager Apps beta, opens up platform to gadget developers

My name is Farhang Kassaei, I am a platform architect at eBay.

We are very excited to announce that our Selling Manager (SM) suite of productivity tools is now offered as a gadget container - with the same extensibility technology behind OpenSocial. In other words, eBay Selling Manager is now OPEN as a beta platform to ALL developers. This is a great opportunity for developers to have direct access to professional sellers who manage their businesses on eBay.

With our beta platform launch today the SM sandbox is open to anyone with an eBay developer account. If you have not signed up for the eBay Developers Program yet, join for FREE at If you are already a member of our developer community, visit for all the information you need to get started.

eBay will be opening up applications within Selling Manager to all sellers later this summer so this is the perfect time to get on board and get your application user-ready and tested. Also, don't forget to attend our annual Developer Conference in San Jose this June where we’ll be offering hands-on training for Selling Manager Applications. Visit our Developers Conference web site for more details.

Now, let me tell you a bit about the Selling Manager Apps. Although the SM apps are built on top of gadget specifications, they are not the typical OpenSocial applications (for one, eBay does not have a traditional traversable social graph). The SM Apps are productivity tools for eBay sellers, such as tools that allow sellers to manage customer questions more effectively, or to handle shipping and handling of sold items, or to identify and graph marketplace trends in pricing. Like any small business, eBay sellers value tools that make them more efficient and maximize their profitability.

What is most exciting about SM Apps is that you can make money. You choose how much you would like to charge for your applications and get paid by your subscribers. eBay handles billing your subscribers, processing their payments and distributing the funds to you thorough your PayPal account.

eBay is excited to be part of the OpenSocial/Gadget community. Our goal is to make development of commercial applications as open as developing social applications. Check out our Selling Manager beta platform hub at, and make sure to let us know how you think we’re doing.

Posted by Farhang Kassaei, Platform Architect, eBay

[Gd] CADIE Says...Hello World!

| More

Google Code Blog: CADIE Says...Hello World!

The Google Developer Team is as excited as we've been in a while. Years of work have come together for today's public launch of CADIE (Cognitive Autoheuristic Distributed-Intelligence Entity). We believe CADIE is the world's first functional global-scale neuro-evolutionary learning cluster. CADIE is going to be very influential in many of our products here at Google because she scales so quickly. However, the research team that built CADIE reached out to the Developer Team here at Google early in her development because she is so proficient at writing code. CADIE was built to understand natural language and to do autonomous problem-solving. Sounds a lot like the work of a developer, doesn't it?

By reviewing all the code available on the Internet CADIE has learned how to code in Java, Javascript, PHP, C/C++/C# and Python. She is hungrily consuming all the code she can and seems to understand it all. We believe that, over time, CADIE will make the tedious coding work done by traditional developers unnecessary. We've created a page at so developers can interact with her and ask her to write some code. So go ahead and give it a shot. Remember, she was built to understand natural language, so don't worry about the format of your request.

Are you interested in seeing the amazing technology behind CADIE? We've released her code into open source, at

Interesting in becoming part of the CADIE community? Submitting a patch? Be sure to read the style guide.

Want to meet the team that built CADIE and see all of her functionality? Come to Google I/O.

By Chris DiBona, Eric Higgins, Mike Marchak and Brian Raiter, Google Developer Team

Tuesday, March 31, 2009

[Gd] Google Narratives Series: BuddyPoke

| More

Google Code Blog: Google Narratives Series: BuddyPoke

Continuing with the Google Narratives Series, we'd like to profile Google App Engine and OpenSocial developers, Dave Westwood and Randall Ho of BuddyPoke!

Dave and Randall both have backgrounds in 3D and avatars for the last 11+ years, with work in various web 3D games, facial tracking, facial animation, and mobile avatars. They've worked at five companies together - "Dave does all the technical stuff and I'm the technical artist." Simply put, they complement each other perfectly.

Q: Tell us the story of how BuddyPoke was envisioned.

A: We'd always worked for other companies, and disliked the company politics, etc, and always dreamed of just going and doing our own thing. When we saw the huge success of Slide's slide shows on MySpace, we quit our jobs and started work on a 3D pets widget. Facebook apps and OpenSocial weren't live yet and our first project failed miserably because we completely lacked a distribution model with viral channels. Fast forward a bit, and Nintendo Wii is huge with everyone making miis and talking about avatars. There was Playstation Home and Second Life. Also, the Simpsons Movie was just about to released and allowed for you to "Simsponize" yourself. We thought about the 30+ minutes people were putting into customizing their avatars, without any way of doing any cool interaction with friends. We also thought about the interesting fact that most people who installed these types of console games did it mostly for character personalization or "dress up," rather than to actually play the game. Bottom line, we knew we had to do something about it.

Facebook apps then started to take off, and OpenSocial came out. We closely watched what worked and what didn't on Facebook by looking at usage charts of the top 200 apps. After a lot of trial and error, we applied our 3D backgrounds to some of the ideas and came up with a way of doing the 3D rendering in Flash. That's when we came up with BuddyPoke.

Q: Describe your implementation and why you decided on Google App Engine.

A: During the time that we were focused on researching app usage, we noticed that most apps were struggling with scalability. Their difficulties sounded vaguely familiar with our current implementation and we knew we needed to find a platform that would help us avoid the same issue, especially since we were working on the version for MySpace. The main thing here was timing with the release of Google App Engine and the announcement of OpenSocial. All of a sudden we found ourselves able to quickly roll out our app to the various OpenSocial sites without having to worry about scaling.

Q: Tell us about your overall development experience and any obstacles you have encountered along the way.

A: When Google App Engine first came out, the big learning curve was BigTable. Our data models were horrible. Then, after watching Ryan and Brett's talks at I/O, we redid everything and it's running well now. Our only concern is the organization of our code on AppSpot - everything runs on one AppSpot site. If we knew ahead of time of our success, we would have broken the code up in groups to make updating easier. Also, our main ask is XMPP support so that we can implement chat on App Engine.

One last thing...we're thrilled about the success of BuddyPoke. The barrier to entry is so low from a developer's perspective. We never imagined having 3D characters seen by so many people, without having to even think about the technology behind them or without even having to buy a Wii.

We really enjoy hearing from developers in the community about inspiring stories, so if you have something you'd like to share, visit our online submission form. Better yet, come tell us your story at Google I/O. You can also check out Dave & Randall's cool story on the Ning blog!

Thanks Dave & Randall!

By Christine Songco, Google Developer Team

[Gd] [Libraries][Update] - Dojo 1.2.3

| More

Google AJAX API Alerts: [Libraries][Update] - Dojo 1.2.3

Dojo was updated to version 1.2.3

Monday, March 30, 2009

[Gd] Google Web Toolkit 1.6 RC2 Now Available

| More

Google Web Toolkit Blog: Google Web Toolkit 1.6 RC2 Now Available

The Google Web Toolkit engineering team is happy to announce that the second Google Web Toolkit 1.6 Release Candidate is now available from the project download page for you to try out. (The first GWT 1.6 Release Candidate was announced a couple of weeks ago on the the GWT Developer Forum.)

New Project Structure in GWT 1.6

GWT 1.6 introduces a new project structure based on the standard J2EE web archive (war) format. We believe this will make it much, much easier to add a GWT module into an existing web app or otherwise mix GWT with other technologies. For more details, check out the updated standard directory and package layout for GWT 1.6.

New EventHandler System

The event system has been updated to be more in line with Java norms, making it both easier to use and easier to write your own widgets. This also paves the way for making events easier to extend in the future. Have a look at the new EventHandler and HandlerManager classes to get a sense for how they work. We've also added new methods for triggering real native browser events.

New Widgets

The new DatePicker and DateBox widgets allow your users to select a date from a calendar. The new LazyPanel widget makes it easy to delay the creation of certain sections of your application until they are first accessed, improving startup performance.

For full details, be sure to check out What's New in GWT 1.6?, and then download the release candidate and give it a whirl. Let us know what you think in the GWT Developer Forum.


[Gd] Code Conversations Ep. 3 - Leslie Hawthorn on Google Summer of Code 2009

| More

Google Code Blog: Code Conversations Ep. 3 - Leslie Hawthorn on Google Summer of Code 2009

Google Summer of Code™ is a global program that offers student developers stipends to write code for various open source software projects. We have worked with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Since its inception in 2005, the program has brought together nearly 2500 successful student participants and 2500 mentors from 98 countries worldwide, all for the love of code. Stephanie Liu of the Developer Programs team sat down with Leslie to understand the history of the program, hear some of the many success stories and find out what's new for SoC 2009.

Leslie Hawthorn is a Program Manager for Google's Open Source Programs Office, where she's the Community Manager for Google Summer of Code. She serves on the Advisory Board of the GNOME Foundation and the Open Source Business Resource, as well as the Steering Committee for the Humanitarian FOSS Project. Her personal website is

This is the third episode in the "Code Conversations" video series on YouTube and Google Code. You can view the entire series at this link:

By Neel Kshetramade, Google Developer Programs

[Gd] Developer News

| More

Android Developers Blog: Developer News

For no particular reason other than to celebrate this particular Monday, I wanted to update developers on two Android-related news items.

If you're a developer who will be in the San Francisco Bay Area at the end of May, I hope you'll join us at the 2009 Google I/O developer conference. You might have already seen the sessions we had listed for Android, but today I'm quite pleased to let you know that we've added a few more Android-related sessions. You can find the full list plus abstracts on the Google I/O site, but here are the titles:

  • Turbo-Charge Your UI: How to Make Your Android UI Fast and Efficient
  • Pixel-Perfect Code: How to Marry Interaction and Visual Design the Android Way
  • Supporting Multiple Devices with One Binary
  • Debugging Arts of the Ninja Masters
  • Coding for Life—Battery Life, That Is
  • Writing Real-Time Games for Android
  • Android Lightning Talks

These sessions don't even include the "fireside chat" with the Core Technical Team that we have planned. We're working on still more sessions too; keep an ear to the ground on this blog and the Google I/O site for the latest info. I'm pretty excited about how the Android sessions for Google I/O are coming together. I think it's going to be a great event, and I hope to meet many of you there.

The other topic I want to mention is that our partners at HTC have uploaded a new system image for Android Dev Phone 1 owners. This new image is mostly the same as the one we mentioned earlier this month, but adds voice dialing. Note that not all features will work correctly in all countries, such as voice dialing and Google Voice Search which currently only work well for US English. Additionally, there are some features that we aren't able to make available at all in some countries. For instance, this build can't currently include Google Latitude due to privacy standards in some regions. We'll always keep the ADP1 builds as full-featured as we can, but it's important to remember that these devices are primarily intended for development, and won't necessarily have all the features included on mainstream builds.

I hope this news is useful to you. As always, happy coding!


[Gd] Android Layout Tricks #3: Optimize with stubs

| More

Android Developers Blog: Android Layout Tricks #3: Optimize with stubs

Sharing and reusing layouts is very easy with Android thanks to the <include /> tag, sometimes even too easy and you might end up with user interfaces that contain a large number of views, some of which are rarely used. Thankfully, Android offers a very special widget called ViewStub, which brings you all the benefits of the <include /> without polluting your user interface with rarely used views.

A ViewStub is a dumb and lightweight view. It has no dimension, it does not draw anything and does not participate in the layout in any way. This means a ViewStub is very cheap to inflate and very cheap to keep in a view hierarchy. A ViewStub can be best described as a lazy include. The layout referenced by a ViewStub is inflated and added to the user interface only when you decide so.

The following screenshot comes from the Shelves application. The main purpose of the activity shown in the screenshot is to present the user with a browsable list of books:

The same activity is also used when the user adds or imports new books. During such an operation, Shelves shows extra bits of user interface. The screenshot below shows the progress bar and cancel button that appear at the bottom of the screen during an import:

Because importing books is not a common operation, at least when compared to browsing the list of books, the import panel is originally represented by a ViewStub:

When the user initiates the import process, the ViewStub is inflated and replaced by the content of the layout file it references:

To use a ViewStub all you need is to specify an android:id attribute, to later inflate the stub, and an android:layout attribute, to reference what layout file to include and inflate. A stub lets you use a third attribute, android:inflatedId, which can be used to override the id of the root of the included file. Finally, the layout parameters specified on the stub will be applied to the roof of the included layout. Here is an example:



android:layout_gravity="bottom" />

When you are ready to inflate the stub, simply invoke the inflate() method. You can also simply change the visibility of the stub to VISIBLE or INVISIBLE and the stub will inflate. Note however that the inflate() method has the benefit of returning the root View of the inflate layout:

((ViewStub) findViewById(;
// or
View importPanel = ((ViewStub) findViewById(;

It is very important to remember that after the stub is inflated, the stub is removed from the view hierarchy. As such, it is unnecessary to keep a long-lived reference, for instance in an class instance field, to a ViewStub.

A ViewStub is a great compromise between ease of programming and efficiency. Instead of inflating views manually and adding them at runtime to your view hierarchy, simply use a ViewStub. It's cheap and easy. The only drawback of ViewStub is that it currently does not support the <merge /> tag.

Happy coding!


[Gd] Japan's goo home social network launches OpenSocial developer sandbox

| More

OpenSocial API Blog: Japan's goo home social network launches OpenSocial developer sandbox

My name is Eiji Kitamura, and I am the OpenSocial architect at "goo," one of the biggest portal sites in Japan with over 43 million unique visitors per month. I'm happy to announce that we've recently launched an OpenSocial developer sandbox for the "goo home" social network site (SNS).

The new goo developer sandbox is open to anyone, and we welcome developers to start building and testing OpenSocial applications on our platform. Please be advised however, that the site is in currently only in Japanese.


"goo Home" originally launched in October 2007 with the goal of making the web more social. It lets users create a profile, build relationships with friends, and share all kinds of activities through blog posts, bookmarks, locations on map, videos, pictures, restaurant reviews, etc. However, when we launched these services in 2007, the technology was proprietary. Now, they are implemented using standard OpenSocial technologies!

OpenSocial Supported Features

Here are some details of the OpenSocial API support offered by goo:
  • Full support for core OpenSocial areas
    • AppData
    • People/Person
    • Activities
  • Gadget rendering support for 'home', 'profile', and 'canvas' views
  • Extensive privacy controls on personal attributes. (ex: not returning attributes when set as private by user)
  • Specific support for viral features:
    • requestCreateActivity(with permission control)
      • MediaItem supported
    • requestShareApp
    • requestPermission (requests one time permission for profile viewer's personal information)
Note: OpenSocial REST/RPC services are not yet supported, but we expect to support them in the near future.

In addition to general support of OpenSocial application development, we've expanded the social features in the following areas:
  • Added feed import functionality for 30 external services
  • Emoji (emoticon) support
  • opensocial-jquery support (courtesy of Nobuhiro Nakajima)
Launch Timeline
  • Developer Sandbox - Available now!
  • Consumer Launch - Late April, 2009
Getting Started

All OpenSocial developers who have a basic knowledge of Japanese can get started today by registering an account at goo's developer sandbox (

On our developer site you'll also find plenty of helpful OpenSocial technical information with detailed documentation on our OpenSocial support. (Note: all content is in Japanese.)

We hope the support of OpenSocial standards in our new platform inspires new and uniquely Japanese innovations for the evolution of the social web!

Posted by Eiji Kitamura, Architect, NTT Resonant Inc.