- 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).
Friday, April 3, 2009
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
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, nextstop.com)
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 WhiteHouse.gov 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.
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 WhiteHouse.gov, 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 code.google.com/appengine/ and make plans to attend our sessions at I/O at the end of May.
By Mike Repass, Product Manager, App Engine
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
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
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:
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!
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
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;
// 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:
(And here's how you can add a campaign with scheduling in your language of choice)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!
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
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!
OpenSocial API Blog: eBay announces Selling Manager Apps beta, opens up platform to gadget developersMy 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 http://developer.ebay.com/join. If you are already a member of our developer community, visit http://developer.ebay.com/smapps 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 http://developer.ebay.com/smapps, and make sure to let us know how you think we’re doing.
Posted by Farhang Kassaei, Platform Architect, eBay
Are you interested in seeing the amazing technology behind CADIE? We've released her code into open source, at code.google.com/p/cadie
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
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.
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
Monday, March 30, 2009
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.
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.
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 http://www.hawthornlandings.org.
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: http://www.youtube.com/view_play_list?p=633DD2FE10E46955
By Neel Kshetramade, Google Developer Programs
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!
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.
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
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:
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:
View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();
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 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.
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
- 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
- requestPermission (requests one time permission for profile viewer's personal information)
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)
- Developer Sandbox - Available now!
- Consumer Launch - Late April, 2009
All OpenSocial developers who have a basic knowledge of Japanese can get started today by registering an account at goo's developer sandbox (http://developer.home.goo.ne.jp/).
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.