Thursday 28 May 2009
Facebook StumbleUpon Twitter Google+ Pin It

Google I/O 2009 - Day 2 Recap

Despite a late night letting loose at the After Hours party, developers managed to wake up in time for the early morning Day 2 keynote (after having been promised yet another exciting surprise). This morning, we unveiled an early look at Google Wave, a new collaboration and communication product. Lars and Jens Rasmussen and Stephanie Hannon presented the vision behind Google Wave and a live demo of it in action. All Google I/O attendees will receive developer sandbox accounts to test out and build on the Google Wave APIs.

To see Google Wave for yourself, check out the video of this morning's keynote:



We'll leave you with a few more I/O photos, starting off with last night's After Hours party:


Yesterday evening after I/O, developers let loose and relaxed at the After Hours party. Food, drinks, music, and games were enjoyed by all.


One of the attractions at the Developer Playground area of the party. The Playground featured individuals & organizations doing creative projects with technology, art, games, music.


Enjoying one of the arcade games at After Hours.


Mike Relm performed during the evening, as well as DJ Scotty Boy.


Day 2's keynote opened with Steven Canvin from LEGO® talking about the evolution of MINDSTORMS to an open source approach.


Google Wave co-founder Lars Rasmussen talks about the vision behind the product.


Brothers Lars and Jens Rasmussen co-founded Where 2 Technologies, which was acquired by Google and eventually became Google Maps.


Stephanie Hannon, Google Wave's lead product manager, wows the audience with a live product demo.


The Google Wave team watches the keynote from the front row. The team is based in Sydney.


A view from the video crew desk. Videos and presentations from I/O sessions will be published on code.google.com/io in the coming days - stay tuned.


A developer picks up his Android phone.


The Sandbox interview room. The Google developer relations team conducted interviews with 3rd Party Sandbox exhibitors and will be posting them on the Google Code YouTube Channel in the coming days.


A happy Aussie fish and kangaroo greet developers dropping by Office Hours for Google Wave.


We hope to see you next year!

Chrome Experiments at Google I/O

Google I/O is well underway, and we're excited that we've been able to highlight some Chrome Experiments at the event. During the keynote on Wednesday, we opened with the following video. Matt Waddell from our Developer team composed the music playing in the background. We're posting a subtitled version of the video, so you can enjoy the song in all it's HTML5 glory.



We've loved the experiments we've received so far and encourage you to check out the ones listed below:
We're continually updating Chrome Experiments to feature new and crazy JavaScript experiments, so keep submitting!

Mercurial Now Available to All Open Source Projects

About a month ago we announced Mercurial support for early testers. Today, we are happy to announce that all Project Hosting users can create a new Mercurial project and convert their existing projects from Subversion to Mercurial

We also want to thank the projects that helped us test support for Mercurial. Projects like Clojure-Dev and Spice of Creation helped us discover new usage patterns and fix several unforeseen issues. Unlike our mature Subversion implementation, there are still a few issues/features that we are working on. 

We therefore encourage everyone to be familiar with what is supported before picking Mercurial.

Please let us know if you have any feedback or find any issues. If you're coming to Google I/O, be sure to come meet us in person and hear our talk about Mercurial on Bigtable this Thursday at 3:45pm-4:45pm in Moscone West - Room 5. We have Mercurial SWAG!

Hello World, Meet Google Wave

This morning at Google I/O we are unveiling a developer preview of Google Wave, a new collaboration and communication product. Google Wave introduces a new platform built around hosted conversations called waves--this model enables people to communicate and work together in new and more effective ways. On top of that, with the Google Wave APIs, developers can take advantage of this collaborative system by building on the Google Wave platform. We want to expand upon that platform, which is why we've put together the initial draft of the Google Wave Federation Protocol, the underlying network protocol for sharing waves between wave providers.

Yes, that's between wave providers: anyone can build a wave server and interoperate, much like anyone can run their own SMTP server. The wave protocol is open to contributions by the broader community with the goal to continue to improve how we share information, together. If you're interested in getting involved, here are a few things you should check out on www.waveprotocol.org:
This is just the beginning. To help potential wave providers get started, our plan is to release an open source, production-quality, reference implementation of the Google Wave client and server, as well as provide an open federation endpoint by the time users start getting access.

We're eager to hear your feedback, so please tell us about your interest, and drop a note on the technical engineering forum with your feedback.

Beyond the federation protocol, you may also be interested in learning more about the Google Wave APIs, as described on the new Google Wave Developers blog.

Wednesday 27 May 2009
Facebook StumbleUpon Twitter Google+ Pin It

Google I/O 2009 - Day 1 Recap

Day 1 of Google I/O was an action-packed endeavor, shared with an excited community of developers on the ground learning about developing web applications with Google and open technologies, and showcasing some of their best apps.

Here are a few highlights from our keynote speech:
  • Google Web Elements is launched: Adding Google products to your website or blog has never been easier.
  • App Engine for Java is now out of preview and open for signups
  • Google Web Toolkit 2.0 previewed upcoming new features, including in-browser debugging and developer-guided code splitting (also known as runAsync())
  • Android Developer Challenge 2 launched: Win awards for building great apps on Android
  • Google Latitude on iPhone 3.0 was previewed
Check out a video playlist of this morning's keynote:


Since a picture is worth a thousand words, we thought we'd recap the 1st day of I/O with photos captured throughout the day:


In case attendees had trouble finding Moscone West, they were directed to look for the life-sized Google Maps pin placed right in front of the entrance.


I/O 2009 had higher attendance, but registration went much more smoothly this year.


An attendee checks out the I/O agenda board. Product stickers were distributed to attendees to stick on their conferences badges to identify fellow attendees with similar product interests.


Eric Schmidt greeted developers and kicked off the keynote


Vic Gundotra takes the stage to talk about "a more powerful web, made easier."


Vic welcomes Jay Sullivan, VP of Mozilla, while also thanking Mozilla and the larger developer community for tireless efforts towards new web standards. Jay gave a glimpse of Firefox 3.5 features.


Michael Abbott, SVP of Palm, talks about why the web is the platform and Palm webOS.


A view from the audience.


We gave all Google I/O attendees a limited edition Android-powered device in order to encourage and facilitate further application development on the Android platform, and provided a preview of Donut features.


Office Hours are a new addition to I/O, where attendees can drop in and bring questions for Google engineers. View Office Hours schedule.


Alon Levi speaks on his App Engine session, From Spark Plug to Drive Train: Life of an App Engine Request.


At the Google Web Toolkit Fireside Chat - members of the GWT team listen to audience question.


Anybot struck up conversation and hung out with developers.


View of the Developer Sandbox from the escalator.


Enjoying a complimentary chair massage.


Developers crashed on bean bags, taking a break to check email and get some work done.


The Street View trike roamed the halls.


A developer pondering what to grab from the drink coolers, available throughout Level 2 for attendees to quench their thirst.


Developers enjoyed bins of chocolate covered raisins, M&Ms, pretzels, trail mix, and other goodies throughout the day.

To follow the latest at Google I/O, check out twitter and twazzup. Stay tuned for Day 2!

Bringing Visualizations One Step Closer to Developers

At Google, many teams use the Visualization API to create charts and visualizations of their data - both for external and internal products.

The Visualization API wire protocol has been made available publicly so that anyone can connect their data on the web to the list of powerful visualizations available (from Google and third parties) since late last year.

However, internal developers at Google had access to our complete code base for implementing data sources with full query capabilities and more. We felt that the whole web community should also enjoy the same benefit, so yesterday we released a full open source Java library that lets developers expose their data (publicly or to select users) for visualizations, charts and dashboards with a fraction of the effort required previously. This is the first complete free Java package for implementing a Visualization API data source - complete with a full implementation of the API's query language - and it joins our growing list of other tools and data source implementations by third parties and Google.

While we were at it, we also took the opportunity to bring our developer community many more goodies. Most notably:
  • We're launching new versions of the wire protocol and query language, including improved security features for sensitive data.
  • We're launching a generic image chart that provides access to all our popular Chart API's charts and their options through the simple but robust Visualization API JS interface (without the limitation on data quantity imposed on the Chart API URL length limitation).
Check out the full list of new stuff on our What's New page.

We will be reviewing the Java library and many of the new features in our sessions at Google I/O. If you can't make it be sure to check out our full documentation, where we will also post the videos from the sessions.

Introducing Google Web Elements

Inspired by the convenience of embeddable YouTube videos, Google Web Elements build on favorite products like Google Custom Search (a Google-powered search engine that automatically tailors itself to your site), Google Docs, and Google News to easily add richness and interactivity to your website with the simplicity of copy and paste. Each element is designed to help you get started quickly without spending time on the deep technical details. Yet behind it all, Google Web Elements are powered by Google's scalable and flexible developer APIs, offering a world of customization just beneath the surface, keeping up with your site as it grows.

Adding Google Web Elements to your website is as easy as visiting the homepage, choosing the ones you like, and customizing them to fit your page. For example, the News element adds headline news about the topics you choose to any page. Just go to the News element page and use the wizard to update the live preview as you change the topics and pick the best size for your site. When you like what you see, simply copy the short embed code and paste it into the HTML of your page.



The Conversation element, powered by Google Friend Connect, makes it easy to start a discussion about nearly any topic. Without writing a single line of code, you can add the Conversation element and visitors to your site can share comments and videos with each other. You can also choose to open the conversation up to the whole world, where every page discussing the same topic will participate in a truly global conversation.



The Conversation and News elements are just two of the Google Web Elements available today. Also available are Google Web Elements for Google Calendar, Google Custom Search, YouTube Video News, Google Maps, and more. To get started, visit the Google Web Elements homepage. and please be sure to let us know what you'd like to see us work on next.

Tuesday 26 May 2009
Facebook StumbleUpon Twitter Google+ Pin It

Visualizing Your Cloud’s Data

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Jesse Lorenz from Salesforce.com.

Many companies are storing their data in the cloud, and they are looking for ways to gain insight to this data. The Google Visualization API is a great way to do just that, which is why salesforce.com has built a set of Google Visualization components for Force.com. These components enable Force.com customers and partners to quickly embed sophisticated reporting and analysis functionality in to their Force.com applications. You can even use the Annotated Time Line visualization to visualize your sales progress:


The Google Visualization component project is one of the most popular projects on developer.force.com/codeshare. Force.com partners have already begun to leverage the components to build new business intelligence apps so that Force.com users can quickly generate reports and dashboards that provide them with new insight to their data.

If you’d like to learn more about embedding Google Visualizations into your Force.com applications, this tutorial is the best place to start. It contains a walk-through of how to get started as well as links to sample code for all of the supported components. The project is open source and everyone is encouraged to contribute!

Salesforce.com will be co-presenting a session at Google I/O that will discuss how to embed the power of the Google Visualization API in Force.com business applications, and how to turn a Force.com application in to a Google Visualization data source. We hope to see you there! To learn more about developing applications on Force.com, go to developer.force.com.

Transforming Your Calendar with LuckyCal and Google's APIs

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Sanjay Vakil, founder of LuckyCal.

1.0 Introduction
LuckyCal is a new sort of calendar service that takes advantage of the web -- and about a dozen Google APIs. LuckyCal reinvents calendaring software by transforming calendars from staid repositories of information into a dynamic, anticipatory, interactive tools, making each appointment a search query and in the process changing your calendar into a concierge.

Ok, enough marketing speak! The real problem is that like anything really new and shiny, LuckyCal can can be a bit tricky to explain. The best we've been able to do is this video:



From a technical standpoint, LuckyCal subscribes to the calendars owned and published by its users and analyzes those calendars for time/date/interest information. LuckyCal uses the inferred location of the user to find events, friends, bands, and teams that are near where the user will be and which the user will find interesting. With this, LuckyCal publishes a new personalized calendar to which the user can subscribe which is full of "Lucky Events" based on the locations of the original events.

2.0 Google Calendar Data
Early iterations of LuckyCal used iCal and retrieved calendars from Google Calendar's "magic URLs". However, after some fits and starts, the team at LuckyCal switched over to using the Google Calendar Data APIs instead. We got several benefits from this: security, granularity, access to multiple calendars, repeating events and more.

Luckily, Google Calendar allows access to more of the "raw data" of the calendar. Each calendar has its own meta data and a collection of events. The calendars are represented via XML with a well-defined schema. Each individual event is also represented via XML. Using a secure mechanism (discussed later), LuckyCal can retrieve calendar and event data from the correct "feed", manipulate it, mine it, and then generate new events.

2.1 Recurring Event Feed
One of the most useful elements of using the Google Data APIs is the ability to access the same information through multiple feeds. Each feed provides a different view of the same data. While it is possible to get the native form of each event, it turns out to be much more useful allow the team at Google to do the heavy lifting to avoid some of the sharp edges of the calendars' API. In particular, one of the most useful capabilities is to avoid dealing with recurring events.

Recurring events are stored as a starting event with an "RRULE" which specifies when they are to be repeated. Unfortunately, the language that defines this repetition is baroque and difficult to understand. This is partly because it has to deal with many edge conditions: if the Geek Dad Dinner fell on Christmas, we'd probably cancel it. That exception -- that a specific instance was cancelled -- needs to captured as part of the recurring event.

Thankfully, the Google Calendar Data API "unrolls" repeating events, completely with exceptional and edge cases and then gives a view into this events for a given calendar based solely on a time range. The complex mess of recurring events is effectively hidden from the developer and we simply get a list of events that we know are occurring.

2.2 Creating new Events
As discussed earlier, LuckyCal creates new events for its users. These events are grouped together into a single new calendar so that they can easily be accessed and hidden and so that they do not detract from the primary calendar usage.

Creating new events is a good deal more difficult than reading a feed of existing events. Constructing a POST request that is correctly formatted and authenticated is tricky primarily because of escaping issues. Between the various escape characters that live in HTML, XML and the authentication encodings, it can be difficult to cleanly create an event which works.

Our advice is to start off with a simple, working example of simple text and slowly add complexity one step at a time: add a link, then an HREF, then a quotation, then an apostrophe and so forth. The reality is that there are many characters that end up having to be escaped and the majority of them will end up in the body of your events -- especially if those events are generated by your users.

3.0 Security
Calendar data is sensitive. Where/when people are going to be is intensively personal information. The body of events -- what you're doing there -- may be even more so. Google recognizes this and provides secure means to retrieve data and allows the user to maintain control over services that have access to their data.

Early on, LuckyCal used AuthSub to retrieve data. We've since superceded AuthSub with OAuth. The latter has the advantage of being more widely supported and of being the future of Google third-party authentication strategy.

Perhaps the most valuable characteristic of OAuth is that LuckyCal does not have to ask for -- or retain -- our users' Google Account passwords. Instead, we retain a LuckyCal-specific token which provides us access. Enabling developers to interact with Google Account information without having to convince users to trust us with their passwords is a huge advantage.

While there are a number of libraries available that implement OAuth for various languages, we ended up building our own version in Ruby. If you decide to attempt this, a useful tool to be aware of is the Google OAuth Playground which has recently been open-sourced.

4.0 Geocoding
LuckyCal works at the intersection of a Calendar -- time -- and the implied location of its users -- space. In order to find location information, LuckyCal uses Google's Geocoding facilities.

LuckyCal hands a textual description -- as found in the "where" fields in a calendar entry -- to the service and gets back a canonical name and latitude/longitude information. We also get back a measure of how accurate the information is: street, city, state, or country. This is critical to LuckyCal as it gives us a sense of whether the location is accurate enough to warrant trying to find nearby events for.

Another thing we've learned is that the Geocoder can easily get confused by extraneous information. As an example this address works perfectly:

"1600 Amphitheatre Parkway, Mountain View, CA"

But this one fails:

"Google at 1600 Amphitheatre Parkway, Mountain View, CA"

The latter is a completely reasonable example of what a user might enter in the "where" field, and it would be a shame not to be able to find that location. At LuckyCal we use some very simple algorithms to find addresses which are not canonical enough for the geocoder to recognize: we tokenize the address by spaces and commas and construct a set of new addresses that remove tokens from the front of the description until we have a match.

In this example, when "Google at 1600 Amphitheatre Parkway, Mountain View, CA" failed, we'd drop back to "at 1600 Amphitheatre Parkway, Mountain View, CA" which also fails, and then to "1600 Amphitheatre Parkway, Mountain View, CA" which succeeds.

This can lead to problems: removing the earlier section of an address can reduce its accuracy. We're lucky: LuckyCal only needs city-level accuracy.

5.0 Maps API
LuckyCal uses the Maps API to build the centerpiece of our web page showing our users what to do while they're on a trip.



Using a web-native client to view this information is wonderful -- we can render HTML directly in the info bubbles and allow users to interact exactly as they'd expect.

6.0 Conclusion
LuckyCal uses Google's APIs in a number of different ways to provide the best possible experience for our users. Given that our service pushes the envelope of what people expect calendars to do, it is gratifying to have access to a range of tools that streamline some portion of our efforts.

Friday 22 May 2009
Facebook StumbleUpon Twitter Google+ Pin It

How To Make Maps The Center Of Your UI (And How Not To)

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Sasha Aickin, Engineering Manager at Redfin.

The oldest saw in real estate is that the three most important things about a house are location, location, and location, and at Redfin we took that as our user interface mantra as well. We made a decision early on that we were going to build a dynamic AJAX web app where the Google Map wasn't just a feature of the application but was the main driver of user interaction. The map is how users tell us where they want to search and what houses they are interested in buying, and our users tell us time and again that the map is what keeps them coming back.

That being said, we've made a lot of mistakes along the way, and I thought it might be helpful if I shared a few of the lessons we've learned over the last few years about building a map-driven UI:


#1 Always Be Thinking About Speed

Rich web apps that mash up many different APIs can be incredibly powerful, but after a while you'll start to look with a gimlet eye at every new API that comes down the pike. Why? Because every new API you add makes your site vulnerable to slowdowns, and your users will punish you for slowness.

Some of these slowdowns are inevitable, but many can be avoided by clever use of code loading techniques and HTTP caching. My best advice to people who ask me what they need to know before building a fast AJAX site? Follow everything that Steve Souders does. Read his book ("High Performance Web Sites"), follow his blog, and go to every talk of his you have a chance to. You'll learn how to defend your site's speed and delight your users.

#2 Carefully Consider The Full Screen Map

One early design decision you have to make with a map-driven site is whether your site is more like an app or more like a web page. Apps don't have scroll bars, and they resize all their controls when the browser resizes. Google Docs, 280slides, and Redfin are all examples of app-like sites, as is the main Google Maps site. Web pages, on the other hand, feel like documents. You can scroll through them, they often don't resize in a dynamic way, and they remind you more of a Word document than Word the application.

The full screen app style makes a lot of sense for sites like ours that use maps as their main navigation, but you can end up with a lot of user interface issues if you don't think the interaction through carefully. Before you make a full screen map UI, realize that your screen real estate is going to be severely limited, especially on laptops. Know that browser resize code can be buggy and difficult, especially if you have to support IE6. Understand that you will have to cut information you think should be in the interface for lack of space. If you have the time, create some prototypes of both app-style maps and web page-style maps and test them with users before going all-in.

#3 Make It Bookmarkable

This tip goes for all AJAX apps, but it is especially important for map-driven sites. Traditionally, AJAX apps have not been truly bookmarkable, and that has hindered both their shareability and utility. You want your users to share links to your site, and you want those links to always represent the same view on the map. If your users twitter or IM a link to your map-based site and it doesn't show their friends the same results that they are seeing, they're going to be confused at best and angry at worst. Furthermore, their friends aren't going to be exposed to your site, and you're going to miss an opportunity to create new users.

I won't lie, bookmarkability does add complexity to your app, but it's worth it. Pick up any of the many bookmarkability or back button JavaScript libraries and integrate it into your app. Your users will reward you for it.

#4 Decide How To Show Large Result Sets

If you're displaying results on a map, at some point you're going to come up against the problem of displaying many, many results on a map, and you're going to have to consider the problem of pagination vs. regionation.

Let's say you've built the ultimate map-based cafe finder, and someone searches the whole of San Francisco. San Francisco's a city that loves its hipster cafes, so you have 1000 results, but you can't possibly show those all on the map because you will confuse your users. Now you're faced with a choice: paginate or regionate?

Pagination would have you break down the results into groups of, say, 50 and show them one set at a time on the map, much the way that Google Search paginates your results. This is usually relatively easy to implement, but in my opinion it often misleads users. The typical response we've seen to paginated results on a map is that users think that they are seeing everything at once, and they get confused when a result that should show up isn't there.

Regionation, on the other hand, is the process of showing all the results on the map, but clustering them into groups so that the user can get a feel for where the results appear and zoom in to see more detail. Regionation usually provides a better user experience for large result sets but can be more work to implement. Search for "google maps clustering" to get some suggestions on how to start.

These are just a few of things we've learned over the years, and we'd love to discuss more of them with you either at the Google I/O Developer Sandbox or at the Performance Tips for Geo API Mashups session, where we'll be giving a short demo.

P.S. We've talked about Google Maps' speed previously on our developer blog, if you're interested in a little more detail.

Google I/O 2009: registration is now closed

Google I/O has sold out and general registration is now closed. If you have received a registration code, you can still register here. If you're unable to join us next week, we will post all of the videos and presentations shortly after I/O -- keep an eye out for updates on that. During the event, you can follow us on the @googleio Twitter account and on the Google Code Blog for the latest in-conference updates and announcements. And if you're coming to Google I/O, we look forward to seeing you there!

Project Hosting Tricks, part 1

If you use Google Code's open source project hosting service, you're probably already familiar with the standard features: the issue tracker, the wiki, the downloads-area, and the browseable version-control repository.

But the project hosting service is also full of cool bells and whistles that you may not have noticed before. We've compiled a fun list of these things which you can show off at your next, um, project hackathon. In this first post, we'll look at some version control gems.

Web-based Code Reviews

  • What: browse a committed change, then make comments right in the browser.
  • Example: here's a brief sample review of a changeset.
  • How to do it: Bring up a changeset in the source browser and click the "start a code review" link in the right-side bubble. Double-click on lines of code to enter comments, then click "publish your comments" when done. An email will be sent to the changeset author, and then they can reply to the comments through the same web interface.

Make Stuff Happen after a Commit

  • What: after a commit, you can automatically fire off a continuous build, make an IRC bot speak... even notify an AppEngine instance!
  • How to do it: Look for the "web hooks" section in the Administer->Source page. If you provide a URL to your server, we'll ping it with commit information after every code change. Follow the links for full details and documentation.


Descriptive Wiki Commit Logs

  • What: The wiki is stored in version control; when saving a wiki page, use a more descriptive commit message than the default "Edited wiki page through web user interface".
  • Example: Here's a wiki change with a useful description.
  • How to do it: When editing a wiki page, expand and fill out the "Commit Log" textfield.

Of course, one of the most exciting new features on our project hosting service is our nascent support for the Mercurial distributed version control system. If you're coming to Google I/O, be sure to come hear our talk about Mercurial on Bigtable!

Thursday 21 May 2009
Facebook StumbleUpon Twitter Google+ Pin It

Gmail for Mobile HTML5 Series: A Common API for Web Storage

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. Over the last few weeks we've talked about how to use the AppCache functionality of HTML5 to launch an application offline. We discussed the impact that AppCache can have on your mobile web applications, as you enable users to launch your app faster in the face of flaky or slow internet connections. This week, I'll talk about how we're using both HTML5 Structured Storage and the Google Gears Database to make devices tolerate flaky network connections.



Although these technologies allow web applications to cache user data on the mobile device and perform data modifications locally, HTML5 Structured Storage uses an asynchronous model, where the Google Gears Database uses a synchronous model. This difference makes it difficult to develop an application on top of both platforms. We dealt with this problem by creating the Web Storage Portability Layer (WSPL) for Gmail. Coming soon under a liberal open source license to code.google.com/p/webstorageportabilitylayer, WSPL provides a common API that supports an identical asynchronous programming model for both platforms by using a worker thread in Gears. Let's take a look!

The WSPL consists of a collection of classes that provide asynchronous transactional access to both Gears and HTML5 databases. It can be used to execute nested statements within callbacks, create statement templates, and optionally control the synchronous/asynchronous modes of the Gears Database Wrapper. There are five basic classes.

google.wspl.Statement - A parametrizable SQL statement class
google.wspl.Transaction - Used to execute one or more Statements with ACID properties
google.wspl.ResultSet - Arrays of JavaScript hash objects, where the hash key is the table column name
google.wspl.Database - A connection to the backing database, also provides transaction support
google.wspl.DatabaseFactory - Creates the appropriate HTML5 or Gears database implementation

Let's take a look at how we can use this API to perform a simple query, starting with the creation of a Database. Note that you'll need to provide a URL to the worker file hosted from your domain.

var database = google.wspl.DatabaseFactory.createDatabase('db name', 'http://yourdomain/dbworker.js');

You can then execute SQL statements without worrying about the specifics of HTML5 and Gears. Refer to the recent blog posts about AppCache to find steps you can follow to see your database contents using sqlite3.
var statement = google.wspl.Statement('SELECT col from test_table;');
database.createTransaction(function(tx) {
tx.executeAll([statement], {onSuccess: function(tx, resultSet) {
// Statement succeeded.

for(; resultSet.isValidRow(); resultSet.next()) {
window.console.info(resultSet.getRow()['col']);
}
}, onFailure: function(error) {
// Statement failed.
}});
}, {onSuccess: function() {
// After transaction commits, before any other starts.
}, onFailure: function(error) {
// After transaction fails, before any other starts.
}});
I've found that using the Gears database asynchronously will nicely split up the JavaScript execution, allowing event handlers and other code to execute between the callbacks. This can improve the responsiveness of your application if you're using long transactions. You can also use SQL triggers to avoid the read-modify-write pattern that causes "ping ponging" between threads -- either the main thread and Gears worker or the main thread and the HTML5 SQL thread.

That's all I'll show you for now, but you can look for more details about the Web Storage Portability Layer at Google I/O, May 27-28 in San Francisco where we'll be presenting a session on the architecture of a generic application using HTML5. We'll also be available at the Developer Sandbox and are looking forward to meeting you in person. Stay tuned for the next post where we'll talk about improving the performance of HTML5-based web applications.

Using the Google Static Maps API and HTTP Geocoder to power Lonely Planet's mobile travel guide

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Ken Hoetmer of Lonely Planet.

Lonely Planet has been using Google Geo APIs since 2006 - you can currently find them in use on destination profiles at lonelyplanet.com , in our trip planner application , in our hotel and hostel booking engine , on lonelyplanet.tv , and in our mobile site, m.lonelyplanet.com . I could talk for hours about any of these sites, but in preparation for Google I/O and my talk at the Maps APIs and Mobile session, I'll spend this post discussing our use of the Google Static Maps API and the HTTP geocoding service on m.lonelyplanet.com.

Our mobile site's primary feature is highlighting points of interest (POIs) around you, as selected by Lonely Planet. The site is browser based and targeted at a baseline of devices. This accessibility is great for on the road, but because of this choice, we can't obtain precise user locations via a location API. Instead, we've asked our users to self-select their location by entering it into a free form text field when they first arrive at the site. This location is then posted to our server, geocoded on the back end by forwarding the text to the Google HTTP geocoding API, and then used to either set the user's location or return a list of options for disambiguation.

Knowing the user's position, we then forward the position and a radius in kilometers to our Content API's POI proximity method, returning a list of points within range, in order of proximity. Once we have the POIs, we need to present them on a map, relative to the user's location. This is where the Google Static Maps API comes in. We can't rely on the availability of Flash, JavaScript, and Ajax, but the Static Maps API enables us to serve a JPEG map by simply providing our list of POI geocodes, a few bits about labeling markers, and a height / width (which we calculate per device by querying screen sizes from WURFL) as query parameters to a URL. Below the map we put a few links for switching the map between (road)map, satellite, hybrid, and terrain base maps.

That gives us a basic map, but what if the user wants to look a little farther to the north or east? To enable this, we augmented the map with a lightweight navigation bar (north, south, east, west, zoom in, zoom out), with links to new static maps that represent a pan or zoom action. Here's how we generated the links:

Let's say our page has a static map of width w pixels, height h pixels, centered at (lat,lng) and zoom level z.
$map_link = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$lng}&zoom={$z}";
Then, we can generate north, south, east, and west links as follows (this example assumes the existence of a mercator projection class with standard xToLng, yToLat, latToY, lngToX routines):
// a mercator object
$mercator = new mercator();

// we'll pan 1/2 the map height / width in each go

// y pixel coordinate of center lat
$y = $mercator->latToY($lat);

// subtract (north) or add (south) half the height, then turn
back into a latitude
$north = $mercator->yToLat($y - $h/2, $z);
$south = $mercator->yToLat($y + $h/2, $z);


// x pixel coordinate of center lng
$x = $mercator->lngToX($lng);

// subtract (west) or add (east) half the width, then turn back into a longitude
$east = $mercator->xToLng($x + $w/2, $z);
$west = $mercator->xToLng($x - $w/2, $z);
So that our north, south, east, west links are:
$north = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$north},{$lng}&zoom={$z}";
$south = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$south},{$lng}&zoom={$z}";
$east = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$east}&zoom={$z}";
$west = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$west}&zoom={$z}";
Of course if you're serving a page knowing only a list of points and their geocodes, then you don't have a zoom level value for calculating the map links. Thankfully, mercator projection implementations often offer a 'getBoundsZoomLevel(bounds)' function, which serves this purpose (create your bounds by finding the minimum and maximum latitudes and longitudes of your list of geocodes). If your implementation doesn't provide this function, it's not complicated to write, but I'll leave that to the reader (hint: find difference in x and y values at various zoom levels and compare these to your map width and height).

As mentioned earlier, I'll be joining Susannah Raub and Aaron Jacobs to delve deeper into maps and mobile devices at Google I/O. In addition, Matthew Cashmore (Lonely Planet Ecosystems Manager) and I will be meeting developers and demoing our apps in the Developer Sandbox on Thursday, May 28. We'd love to meet you and we'll be easy to find - simply follow the noise to the jovial Welshman.

Wednesday 20 May 2009
Facebook StumbleUpon Twitter Google+ Pin It

MySpace Open Platform: Connect MySpace users to your site and to your apps

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Scott Seely, Architect for the MySpace Open Platform.

MySpace will be talking about two big things at Google I/O this year: MySpaceID and MySpace Apps.

MySpaceID delivers social functionality and experiences by linking MySpace accounts with your site. These services allow users to quickly register using their MySpace credentials as well as post status messages, publish activities into MySpace, discover friends, and view MySpace activity and profile data on your site! The users’ friends see all these updates, which drive traffic to your site and attract new users to register. By leveraging MySpace’s social graph, you add virally to the buzz about your site and increase the number of visitors to it.

For a broad overview of MySpaceID, please watch this video:



We provide SDKs for MySpaceID. You can use the SDKs or directly use our REST endpoints. We have SDKs available for a variety of languages: PHP, Python, Ruby, .NET, Java, and JavaScript. This brings the benefits of MySpaceID to a wide range of developers. The JavaScript SDK runs on the client, all other versions run on your servers. These options allow you to achieve smooth workflows and reduce implementation costs by working with the skills you use as a developer.

MySpaceID supports both OAuth and the OpenID-Auth hybrid—you choose the mechanism that makes the most sense for your scenario. Both options are exposed in our SDKs. Once a user logs in and allows your site to access their data, you have access to a wealth of their MySpace data. The MySpace endpoints support Portable Contacts and OpenSocial 0.9 REST, giving you access to plenty of information.

MySpace Apps provides developers with a canvas to create engaging social applications that are deeply integrated into MySpace. The applications are built using the OpenSocial specification, which we are evolving with partners like Google, and Yahoo!. With OpenSocial 0.9, you will see advances in markup, allowing you to remove much of your JavaScript and instead use OpenSocial Markup Language, OSML, to declare which friends you want loaded. This work all happens on MySpace’s servers, reducing calls for data and greatly improving the application experience. When you do need to contact your own servers, you can send Ajax calls through our proxies to your servers. These calls are all signed by the MySpace infrastructure so that you know the request came from a trusted source. The MySpaceID SDK allows your server to access and set MySpace user data in this scenario. So long as the user has installed your application, your servers can access their data.

These are some of the ways that MySpaceID enables you to leverage MySpace API’s off-site and let users into your site with their social media identity and data. Earlier this year, MySpace was the first social network to allow syndication of its users’ activity streams. We hope you are as excited as we are to be part of this fundamental shift in the portability of user identity and data on the Internet.

MySpace Apps and MySpaceID are a lot more than what we’ve talked about here. We invite you to find out more by attending:
  • “Building a Business with Social Apps” – Gerard Capiel, VP of Product for the MySpace Open Platform, will share his experiences on monetization of apps.
  • Developer Sandbox – Come by and see actual apps in action, try building an app on the spot, and talk to our developers.
  • Fireside Chat - Ask those hard questions, discuss approaches to problems, and think about the future with MySpace developers and the OpenSocial engineering team
We hope that you will come away convinced that MySpace is focused on empowering app owners and web site owners with the tools to succeed. See you at Google I/O!

Tuesday 19 May 2009
Facebook StumbleUpon Twitter Google+ Pin It

Guice Deuce

Two years ago, Bob Lee and Kevin Bourrillion open sourced Google Guice 1.0, a lightweight Java dependency injection framework. Guice takes the pain out of writing and maintaining Java applications big and small. Guice has gained a great deal of traction both inside and outside of Google. Almost every Java-based application at Google is also a Guice-based application; the list includes AdWords, Google Docs, Gmail, and even YouTube. Open source users run Guice in everything from file-sharing software to ATMs. They've even written two books about this Jolt-award-winning framework.

Today, we're releasing Guice 2. The minimally-sized API extensions introduced by Guice 2 will have a majorly positive impact on the size and maintainability of your code. We closely scrutinized each addition, carefully balancing maintainability and flexibility. Here are a few of my favorite new features:
  • Provider methods eliminate the boilerplate of manually-constructed dependencies.
  • Module overrides allow you to tweak a production module for a unit test or QA deployment.
  • Private modules enable compartmentalized configuration, simplifying module reuse.
Guice works with Java SE, Java EE, Google App Engine, Android, and even Google Web Toolkit (via GIN).

References
Guice 2.0 Release Notes
Downloads
User's Guide
Javadoc

Previews of I/O Sessions: Brian Fitzpatrick and Ben Collins-Sussman

You have seen the previews for I/O sessions that we have published so far (First set, Second set). This time, we have something a little different for you.

In this preview, Brian and Ben track down the elusive Genius programmer in the preview for their session, "The Myth of the Genius Programmer". Will they succeed in their quest? Will they live to tell the tale? Watch the preview to find out.

The Myth of the Genius Programmer - Brian Fitzpatrick & Ben Collins-Sussman



Keep an eye out for more previews on the other sessions at I/O in the coming soon. We can't wait to meet a bunch of talented developers and have some fun at Google I/O, on May 27-28!

Sao Paulo, Brazil: Google Developer Day Registration now open

We are excited to open registration for our third Google Developer Day event this year, to be held on June 29th in Sao Paulo, Brazil.

In the heart of Sao Paulo, you will learn about the latest with our APIs and developer tools, including Android, Google Chrome, App Engine, AJAX APIs, Maps and more. The topics will vary so you can be sure to discover new and interesting ways to use our applications. And don't forget to take part in the time set aside to socialize with fellow developers and Google engineers - it is a great networking opportunity.

Monday 18 May 2009
Facebook StumbleUpon Twitter Google+ Pin It

Who's @ Google I/O - spotlight on the Social Web

Google is making the web a more sociable place by contributing to new standards and releasing new products that make it easy to integrate your website with the social web. We've invited a few friends that are helping build the social web to Google I/O so you can learn what's coming next and what it means for you.

Learn from successful developers
Social apps can grow up fast, and some have attracted tens of millions of users. We're planning sessions to help you understand the business side of social apps, and we'll have a panel where you can pick the brains of some of the biggest social app developers in the world.




Make some new friends
There's more to a successful social app than just a creative idea. From analytics to payment processing, there's a lot of code to write beyond the core functionality of an app. Luckily, companies have been springing up to fill the needs of this ecosystem. You can meet some of these new companies in the Developer Sandbox and see how their products can make your app better (and your life easier).




Meet the containers
One of the key benefits of OpenSocial is the incredible distribution it provides to app developers. Building your app on OpenSocial makes it possible to reach hundred of millions of users around the world. We've got sessions planned to let you meet the folks building OpenSocial platforms and learn more about what kind of apps work well in different social environments.




The next generation
IBM, Salesforce.com, Oracle, eXoPlatform, SAP, Atlassian - not who you'd expect to be speaking on an OpenSocial session. Speakers from these companies will come together to talk about how the enterprise software development community is bringing social concepts and technology like OpenSocial into the enterprise.

To see all the sessions we've got planned to help you learn about the social web, go to http://code.google.com/events/io/sessions.html, and search for 'social'.

*Keep up with the latest I/O updates: @googleio.