Let us know what you think

Share with us your thoughts on Google Developer Day, our APIs, and our developer program in general. Please complete our short survey (it should take less than 10 minutes) and let us know what you'd like to see from us in the future.

Looking forward to hearing from you!

Adam Sah on Google Gadgets API

Posted by Dion Almaer, Google Developer Programs

What are Gadgets?

HTML inside an XML wrapper. Anything that you can do in a web page, you can do inside a gadget. The promise is that you can write this one, run it anywhere, and you get free hosting and bandwidget thanks to Google Code project hosting and Google Pages.

What does everywhere mean?

Google Gadgets are not just about iGoogle:

Google Desktop, Max OS Dashboard, Enterprise (IBM WebSphere Portal), third party websites, ... and now maps.google.com via Mapplets.

To see this you can even add the date time clock, or a map widget.

8000 published gadgets, and over 800M page views a week.

Who writes gadgets?

A large range. From hobbyists, to professional programers, to businesses.

Anatomy of a Gadget

As simple as this.

<Module>
<ModulePrefs ... />
<UserPref ... />
<Content ..... />
</Module>

Adam shows how easy it is to get going. Hello World is simple, but you can also enter another gadget and riff of of that. The view source paradigm really kicks in here.

The API also gives you interesting functionality such as tabs, mini messages, dynamic height management, analytics, and more.

To get these features you simple <Require feature=".." />

Tech Tips

• Weekly page views are display in the Google Gadgets for your page directory.
• Simple way to embed Flash: _IF_EmbedFlash("....swf", container, { })
• Fetching remote content. Google will proxy cache. HTML, text, XML, JSON. Wrapper functions let you fetch feeds in different ways (e.g. _IF_FetchFeedAsJSON(...))
• Internationalization support: <Locale lang="de" messages="de.xml">
• Storing State: var prefs = new _IF_Prefs(); prefs.set("text", "foo")
• Caching External Resources: Google caches all gadget XML files, all requests going through _IG_Fetch methods
• Configure the gadget the way you want, and then get the code to install anywhere

Q & A

• Q. Can you get data after the gadget is initialized? Yes, and that happens by default
• Q. In what way does a gadget drive traffic to a website? Adam answers by example. The tarot.com horoscope adds a link at the bottom to point you over to their site where they can monetize you
• Q. How suitable is this as a mechanism for a B2B environment? IBM implemented this in WebSphere portal, and other enterprises are putting out gadgets to represent their products. Today the most popular gadgets are dual use (e.g. Google Calendar)
• Q. What is the portability story between the desktop and the web version? Web based gadgets are the most portable, and they run inside of desktop.
• Q. How do you handle versioning of gadgets? No version stamp in the metadata, so authors just use different XML files with the version in the URL itself. Most just upgrade in place, and handle backwards compatibility
• Q. Have you done testing on non-PC devices? Gadgets need HTML and JavaScript.
• Q. What security is built-in? Gadgets are in iframes, so gadgets can't talk to the container, and vice versa
• Q. As a gadget developer how do you get feedback about your gadget? Analytics will show you the traffic. A feedback form is on the details page of the gadget.
• Q. Do you know of any kids creating gadgets? Took bets on the top gadget authors will be. Sure enough, a 16 year old was the top author for the first 6 months.

Google Gears Fireside Chat

Posted by Dion Almaer, Google Developer Programs

The Google Gears team all got together for a nice panel.

Q. Do you have to rewrite an app

Chris Weatherall didn't rewrite the reader front-end. What made this possible was a nice separation of layers.

If you look at the ability to use web applications when you are intermittent connected (e.g. a hotel), there is a nice model too. You can

Q. Offline access and sync is big to solve. Are you looking at multiple applications on a PC. Can I have Apollo and a web browser looking at the same data

There isn't a way you do that, due to a strict security model. We maintain databases on a profile basis in Firefox. So, you can't run IE and Firefox to access the same data either.

Gears is adding three primitives to the Ajax space. You can use one or multiple depending on what you need.

Q. There is a lot of interesting brainstorming on the "right model" of building Gears applications. Will there be good developer support around the architecture questions.

We have some documentation on how it works with Reader, and it makes sense for us to add more. Groups will seed discussions which will be picked up and expanded too.

We don't have all of the answers, the we are hoping that the community is going to come up with a lot of solutions based on practice.

Q. I am glad to see the strong links between GWT and Gears. What about GData - Gears. Will there be Google supported libraries to handle GData primitives? E.g. storing GData?

I think people will build them as they need them.

Q. Your ManagedResourceStore, is it an object store?

ManagedResourceStore adds atomicity to resource storage. If you need to group versions that only make sense together, it is a great candidate for a ManagedResourceStore. You can put in anything that makes a web app (js, css, html, images, etc).

Q. Multiple Computers: How portable is the data?

It depends on what you need. This is where synchronization comes in. In theory, you could take the SQLite store and move it around. Think of yourself as providing a web app that can do a little more and you will probably not run into too many issues.

Q. Host Proof Hosting: I want users to be able to store data at their machine, but save it encrypted at the server. Can we do this?

This is a good use case for the WorkerPool, since encryption/decryption is slow, and you don't want to block the browser UI thread.

Q. If I am working on a mobile application, what is the minimum footprint to support Google Gears?

Obviously, the application is key, depending on the amount of work that you do on the client. SQLite is very stingy in general, so we think that it will scale down fairly well. The Opera team will have more to say on this.

Q. Full text search. How well does it do? Do you need to store a full corpus?

We have the author of the full text search in the room. Currently it is targeting at what you expect at the clients, so it handles multiple inserts really well. The indexing is on the local client. Compared to Lucene our insert performance is good, and query performance is a little worse.

Q. How married are you to SQLite, and are you looking for other options?

SQLite was tremendously appealing an suited all of our needs. Rather than abstract on top of the database, we thought it would be better to expose the full database.

Q. Is there anything else that you would like to add to SQLite

So far full text search and FTS3 is the area of active work. Also, segmentation and normalization in non-english words. We are hoping to use ICU for the localization piece.

Q. WorkerThread: How expensive is it to create and send messages to these threads?

We don't have detailed measurements. The goal is: When you have long running operations, then you have a candidate to fire of a WorkerThread, and isn't about creating millions of them.

Q. Is there a threat of a thread going crazy?

When you unload a page the thread dies, but there isn't a programatic way to kill it yet.

Q. What are the three next most important things to put into browsers?

We will be busy making what we have out there really good, and working with the standards bodies to make this happen.

Douglas Crockford popped up to say that he thinks the three next things are: Security, security, security.

One fruitful research area is synchronization. We are excited about the second wave.

YouTube APIs: Where We Are and Where We're Going

Posted by Dion Almaer, Google Developer Programs

Dave Parker of the YouTube team talked about the YouTube APIs:

What can you do with YouTube APIS today?

• Search videos by tag / category
• Get a users public profile, friends, and favourites
• List featured and popular content
• Fetch playlists

RSS Feeds: Quick and Easy

You can get access to a lot of content, for yourself or other users, and also common feeds for the most viewed etc.

REST and XML-RPC

These are the core APIs, which offer a lot more functionality that you can in a read-only feed. Dave compares the REST and XML-RPC approaches for some examples. Although the request is different (XML-RPC has a standard XML request format, whereas REST just uses HTTP), the response is very similar. The result is a response XML document with metadata that you can then use.

Dave shows us a thumbnail view application that was developed by a third party API developer. As always, the cool stuff comes from you.

Dave walked us through the various methods that map to the high level "what can you do today" items.

Dave has the nice side effect of having cool YouTube videos that he can use as part of his demos. Much nicer than if you were demoing work from a bank... here he can show sleepy kitten.

Google AJAX Search API

There are Google APIs that also access the YouTube content. Dave created an AJAX Search video bar on the fly, and showed us some snoring puppies. This component searches across YouTube and Google Video.

The Future

Google Data APIs are coming. The benefits here are that client libraries are available, support is all over. You should expect to see new search calls, filters, and we are investigating how to open upload and write functionality.

The Video Category Search Demo uses an early version of these new apis. The entire demo is written in client-side JavaScript using the JSON output.

Q & A

• Q. Can I control the thumbnail instead of the first frame? A. It is being worked on.
• Q. When can I sell my videos on YouTube? A. Working with partners to get all types of video into the service. This morning we announced a partnership with EMI. For content creators, the model is advertising based.
• Q. Is there a JS API to control the flow of video, e.g. syncing to a particular area in the video. A. On the list! An underused feature is autoplay="on|off".
• Q. Will you allow direct access to the video file? A. Focusing on the embedded player. The player could then be embedded in your own application
• Q. Are you going to provide more video data? A. Yes. Thinking about how to show more about a creators audience and such.
• Q. Can you help me upload? A. We have partnered with mobile providers, camera devices, etc.
• Q. You can search metadata, but how about searching the video content itself (voice recognition etc) A. This is why being part of Google is good for us.
• Q. I am interested in location information. Is there a road map for geotagging, and deep tagging? A. Today there is an unspecified geo field, but there you get content like 'my bedroom' as well as full addresses or lat/lng. We are doing work to get better here: "Show me video from 5 miles around me"
• Q. Do you have video editing in the pipe? A. Excited about crop and red-eye style edits, which isn't easy.
• Q. Are you enabling photos and videos to live together? A. Nothing to announce now, but Active sharing was just released on the TestTube, and we are looking at doing more things in this field

Keynote with Jeff Huber: The last leg begins. California is live.

Posted by Dion Almaer, Google Developer Programs

It has been a fascinating time watching the Google Developer Day conference run across the globe.

I woke up this morning, jumped on the site, and saw this picture of where we are at:



Out East the red countries had completed their day, we had a throbbing live middle, and California was waiting to join the party, and now it is here:

We will be updating you during the day over on the California location, and we will make sure to aggregate the content here.

The community has had plenty to say about Google Gears, and we have more presentations to give today on the topic. Be sure to check the webcast schedule and join in if you can't be in San Jose itself.

I am now sitting at the keynote in the San Jose Convention Center, with building blocks on stage, and shortly Jeff Huber will be joining them.... and here he is.

Jeff starts off by welcoming everyone around the world, and talks about why we brought the event to the world instead of trying to bring everyone to California. I think it has proven to be a great decision.

Jeff then went through a brief history of Google with respect to developer products, and how Google Maps spurred on the growth of APIs from 2005 onwards, where we added a slew of APIs.

The building blocks of Open Source, Mashups, Standards, and Ads fit a new model of application development. The point isn't that you need to use all of these, but that you can put what you need together, and you can use this leverage to create applications in short order.

Integrate, Reach, Build. These are the segments that Google has found to group its developer products, and we will be showing announcements in each of these areas in the keynote itself.

Would you like to see us release these?

• jogplanner.google.com
• apartmentfinder.google.com
• moviemaps.google.com
• coolphotoeditor.google.com
• syncingservice.google.com
• certifiedusedcars.google.com

We aren't releasing these of course, because you have already created them using our building blocks. Jeff walked through some examples of these, such as Picnik, Veloroutes, Honda Used Cars, and more.

Google Mashup Editor

Paul McDonald joins the stage to show us the new Google Mashup Editor. Paul's use case is creating a mashup of products related to California State Parks. The sample starts with a simple HTML table, and with a couple of XML tags, gm:list to get a list of data, and gm:map to place that list on the map in the form of markers. He then adds interactivity with a simple gm:handleEvent that ties to the list, and finally adds a Google Base search component that ties this all in.

Creating mashups is one piece of the puzzle. The mashup editor then allows you to publish this content to Google's infrastructure. You can also publish these to iGoogle.

Jeff gets back on stage and shows off some Gadgets, and the impressive number of page views that these Gadgets are creating. They range from hobbies (arcade games, todo list) to commercial (Expedia). Gadgets are not just for iGoogle though, they are integrated all over the place.

Google Mapplets

Thai Tran takes over at this point, and introduces us to the new release in Maps and Gadgets.... Mapplets.

Thai starts off by showing an Orbitz example, that takes Maps, and makes hotel searches on it real. He then included a WeatherBug Mapplet, so you can choose a hotel based on the temperature as well as the pure location.

Google Web Toolkit

Jeff talks about the GWT community, and the impressive announcement that the toolkit reached a million downloads.

Google Gears

The key points:

• Offline access for web apps
• Cross-browser, cross-platform
• Open source
• Evolutionary approach
• Moving towards standard; working with industry partners

Othman Laraki now takes the stage and explains the Google Gears vision. The point that this is evolutionary is very important to the team.

Othman demonstrates the new Google Reader with offline support. Doing a demo where you turn off the internet is always nerve-wracking, and the network kept finding him!

Jeff then rejoined the stage to discuss the partnership with Mozilla, Adobe, and Opera. Representatives are at the event, and will be participating with the project.

Kevin Lynch of Adobe then jumped up on state and demos a Flex application (Salesbuilder). Kevin fired up a SQLite Explorer tool to query the Gears database, and he shows going offline in the application.

He then ties it into Apollo, and how you can take these applications onto the desktop.

Jeff then invited Sergey Brin to join us, and he was very curious about the blocks on stage. Sergey talked about how he thinks we are at a great time for the internet, and compared the timeline with a compiler. That magic time where a compiler can compile itself. Now, we can create internet apps with internet apps.

Jeff then wraps up the talk, calling to the community to go forth and prosper. Now on to the sessions...

Less than 30 hours...

Google Developer Day is approaching rapidly and we're very excited to see everyone in less than 30 hours! The event is completely full, and we are now closing off the waitlist. For those of you unable to make it, we are webcasting live the sessions from London and San Jose. If you happen to miss one of the webcast sessions, no worries - we will also be posting sessions from around the world to YouTube. You will find them off the session page on the website.

Lastly, if you will be joining us and happen to snap a picture or write a blog post, be sure to tag with 'GDD07' so that everyone can find it.