Création des Logiciels de gestion d'Entreprise, Création et référencement des sites web, Réseaux et Maintenance, Conception
seo New GData JavaScript library enables full read and write access for your mashups 2013
Seo Master present to you:
I am really excited to see the release of the GData JavaScript Client Library for Calendar that allows you to do a lot more with Calendar GData mashups.
Developers have been able to work with our GData feeds from JavaScript for over a year, but only in a read-only capacity. There are plenty of mashups that can be done that way, but what if you want an application that ties into personal content? What if you would like to write an Ajax client that can create, update, or delete entries as well as read it?
Now you can. This release allows you full read-write access to Google Calendar from JavaScript. Instead of requiring server-side proxies to do this for you, AuthSub is fully supported from within the pure JavaScript client.
You can login by doing something similar to:
Armed with this new functionality, I can only imagine how the mashups will become richer. I can't wait to see them!2013, By: Seo Master
I am really excited to see the release of the GData JavaScript Client Library for Calendar that allows you to do a lot more with Calendar GData mashups.
Developers have been able to work with our GData feeds from JavaScript for over a year, but only in a read-only capacity. There are plenty of mashups that can be done that way, but what if you want an application that ties into personal content? What if you would like to write an Ajax client that can create, update, or delete entries as well as read it?
Now you can. This release allows you full read-write access to Google Calendar from JavaScript. Instead of requiring server-side proxies to do this for you, AuthSub is fully supported from within the pure JavaScript client.
You can login by doing something similar to:
function logMeIn() {
scope = "http://www.google.com/calendar/feeds";
var token = google.accounts.user.login(scope);
}
function setupMyService() {
var myService =
new google.gdata.calendar.CalendarService('exampleCo-exampleApp-1');
logMeIn();
return myService;
}
I got to sit down with Jun Yang, who worked on this code, and got his take on the new library:Armed with this new functionality, I can only imagine how the mashups will become richer. I can't wait to see them!2013, By: Seo Master
seo Introducing Calendar Gadgets 2013
Seo Master present to you:
You've seen them on iGoogle, in IBM WebSphere Portal, and now you can find them in your favorite online calendar -- that's right, now we're supporting Gadgets in Google Calendar! If you're a Scorpio like me, you can add this gadget that lets you check your horoscope from your calendar (don't worry, all the signs of the zodiac are supported). And if astrology isn't your thing, how about games? This Sudoku gadget was created by Alex Komoroske, one of our interns on the Docs & Spreadsheets team. If you add the gadget, you'll see that the daily puzzles get harder throughout the week.
Finally, if you like to keep up on celebrity birthdays, the birthday reminder will show you who you are idolizing that day:
But you don't have to be a Googler to create a Calendar Gadget -- we have put together new documentation to help you get your favorite Gadgets into Calendar. If you are itching to write some code, then you can use GData or ICAL to add some fancy Calendar Gadget events to your calendar. But if you're out of Red Bull and don't have the time for a late-night hacking session, then you may want to try our new "of-the-day" Calendar Gadget wizard, which makes it easy to take an existing Google Gadget and have it show up once a day, every day, just like the Horoscope and Sudoku Gadgets do.
Let us know how your experiences with Calendar Gadgets are going in the Google Calendar GData API developer forum.2013, By: Seo Master
You've seen them on iGoogle, in IBM WebSphere Portal, and now you can find them in your favorite online calendar -- that's right, now we're supporting Gadgets in Google Calendar! If you're a Scorpio like me, you can add this gadget that lets you check your horoscope from your calendar (don't worry, all the signs of the zodiac are supported). And if astrology isn't your thing, how about games? This Sudoku gadget was created by Alex Komoroske, one of our interns on the Docs & Spreadsheets team. If you add the gadget, you'll see that the daily puzzles get harder throughout the week.
Finally, if you like to keep up on celebrity birthdays, the birthday reminder will show you who you are idolizing that day:
But you don't have to be a Googler to create a Calendar Gadget -- we have put together new documentation to help you get your favorite Gadgets into Calendar. If you are itching to write some code, then you can use GData or ICAL to add some fancy Calendar Gadget events to your calendar. But if you're out of Red Bull and don't have the time for a late-night hacking session, then you may want to try our new "of-the-day" Calendar Gadget wizard, which makes it easy to take an existing Google Gadget and have it show up once a day, every day, just like the Horoscope and Sudoku Gadgets do.
Let us know how your experiences with Calendar Gadgets are going in the Google Calendar GData API developer forum.2013, By: Seo Master
seo Sidebar Gadgets: Coming soon to a Calendar near you 2013
Seo Master present to you: 
We've always believed users should have open and unencumbered access to their data, and Google Calendar is no exception. Whether through iCalendar, CalDAV, or the Calendar Data API, there are a multitude of options to access Calendar from other applications. However, developers have been asking for a way to extend the Google Calendar interface itself, and we've been listening.
Today, as part of Google Calendar Labs, we're opening up Google Calendar as a gadget container.
Gadget developers will already be familiar with most of this environment, complete with features such as OpenSocial for social networking and OAuth for working with third-party services. However, for the first time we're also providing an API to control and interact with the Calendar user interface. This means that even though your gadgets are running inside a sandbox, they are first-class elements of the Calendar user experience. In fact, many of the experiments we've made available through Calendar Labs were written using the publicly available gadget API.
We hope you'll share our excitement in opening up the Google Calendar interface. To get you started, take a look at the Sidebar Gadget documentation and sample code. If you have any questions or ideas for improvement, feel free to visit the Calendar API help group and let us know!
2013, By: Seo Master
We've always believed users should have open and unencumbered access to their data, and Google Calendar is no exception. Whether through iCalendar, CalDAV, or the Calendar Data API, there are a multitude of options to access Calendar from other applications. However, developers have been asking for a way to extend the Google Calendar interface itself, and we've been listening.Today, as part of Google Calendar Labs, we're opening up Google Calendar as a gadget container.
Gadget developers will already be familiar with most of this environment, complete with features such as OpenSocial for social networking and OAuth for working with third-party services. However, for the first time we're also providing an API to control and interact with the Calendar user interface. This means that even though your gadgets are running inside a sandbox, they are first-class elements of the Calendar user experience. In fact, many of the experiments we've made available through Calendar Labs were written using the publicly available gadget API.
We hope you'll share our excitement in opening up the Google Calendar interface. To get you started, take a look at the Sidebar Gadget documentation and sample code. If you have any questions or ideas for improvement, feel free to visit the Calendar API help group and let us know!
2013, By: Seo Master
seo Transforming Your Calendar with LuckyCal and Google's APIs 2013
Seo Master present to you: 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.
2013, By: Seo Master
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.
2013, By: Seo Master
seo HTML5 and WebKit pave the way for mobile web applications 2013
Seo Master present to you: When I first started at Google, we were building a Java ME email client for the phones of the day. It's an excellent product - still the fastest, slickest way to get your Gmail on many devices because of Java ME's widespread penetration. Yet it always bothered us that this client didn't really leverage the core strength of the desktop Gmail platform: sheer ease of access from anywhere, and constant updates and improvements. To use the client, you have to figure out how to install it and possibly navigate confusing network permission pop-up dialogs, and improvements could only be rolled out a few times a year in upgrades that required every user to download and reinstall their software.
The mobile team started thinking about how we could bring the benefits of the server-side approach to these clients. We started thinking about a world where we could deliver a GUI specified in XML to a Java ME client, enabling us to iterate on the server side and deliver new features that could delight users when they were ready, rather than on a lengthy release cycle. I was especially struck by a friend who said "What I like about Gmail is that it just constantly keeps getting better. It's like waking up to a new little present from Google each month!" We wanted our mobile users to feel the same way, so we felt the logical thing to do would be to build a general client that could be controlled by the server.
Not too long after, the team first saw the new Android browser. Still in its early stages, the Android browser was built on the latest version of WebKit and could render desktop pages with ease. The XHTML, images, JavaScript, and CSS that could be rendered on this platform presented great potential for building very high-end web applications. However, this was ages before Android was due to ship and Android would only be one of many mobile platforms.
Those drawbacks aside, we couldn't help but think that new browsers in Android's league would eventually become a reality. These powerful browsers could have the kind of functionality we needed to build top-notch, offline user interfaces that didn't need to be "installed" by users or "upgraded". Gmail could be Gmail: a constantly evolving way to handle lots of email quickly and efficiently. The only fly in the ointment was the need for Gears: users would have to download a browser plug-in, and most web browsers on mobile devices don't even support that. What we really needed was for Gears to inspire innovation in HTML itself, so that the whole web could move forward.
Enter HTML5. We're very excited about the evolving HTML5 standard because it enables mobile and desktop website designers to deliver the advantages of client-side and server side development to their users simultaneously! New APIs let web applications start offline and store data on the client. The canvas API lets you draw complex user interfaces, or you can use advanced CSS tricks to get the browser to render a rich UI. In addition, the W3C Geolocation API is being adopted and implemented by browser developers, enabling entire new categories of web applications to be built. The benefits are clear: you can develop fantastic new applications, benefit from server-side analytics and iteration to deliver features that your users want, and know that offline functionality keeps things running as the user moves in and out of coverage. Your users can enjoy fast, capable web apps that they can access from any device, without the need to copy their data from place to place or worry about installing software or being online.
We decided to build new versions of mobile Gmail and mobile Calendar on top of this functionality. First, we built a small javascript wrapper around the database functionality in HTML5 and Gears. This wrapper abstracts away the differences between the two APIs, so that our applications are supported on the broadest set of browsers possible while older browsers get updated with implementations of the new offline APIs. We noticed that we weren't the only ones thinking about this: a quick search shows that other developers saw the similarities too. The main difference between the Gears database API and the HTML5 database API is that the Gears API is synchronous, requiring separate worker threads to do the database calls, while the HTML5 database API uses callbacks and is asynchronous. With the wrapper built, we knew our code would run on all high-end mobile browsers today, and look forward to even more distribution as everybody implements HTML5.
We knew we could apply various approaches to building better experiences for Gmail and Calendar. The key principle we kept in mind is an age-old one: KISS. Simply caching responses in the database for re-use is surprisingly effective: you can get a lot of improvement with just a read-only environment. This approach worked well for Calendar, where usage is predominantly read-only and we can rely on the user being online to make edits.
For Gmail, more complexity was needed. A queue of user actions needs to be maintained in the database (in case the user runs out of battery or powers down for their flight). Later, when the device is back online, it can execute that queue of mails to send, archive or delete, and so on.
Having the ability to store your data and actions offline isn't much good if you can't start the application while offline. So besides making use of the database API, we needed a way to get the application itself loaded without an internet connection. The HTML5 specification comes to the rescue here, with an application cache that is capable of storing all resources in your web app so that the browser can load them while offline. This API has just one small drawback: once you've decided you're going to override how HTTP GET works to fetch resources from the application cache, you also commit to never issuing a GET for a resource the cache doesn't know about. The specification contains methods for extending what URIs the cache knows exist, but these entry points are not widely implemented in production browsers. Instead, it's important to use HTTP POST requests for all dynamic data, since POST requests are never cached and therefore do reach the network.
The end result is an incredible thing: a web app that loads offline, and lets you read your Gmail or view your events provided the data have previously been cached. The experience is seamless as you ride the subway or the bus through terrible coverage: your data are ready, quickly, all the time. To see the new Gmail for mobile web app, go to gmail.com from an Android-powered device or iPhone (OS 2.2.1 or above).
Of course we didn't get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we've skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we've learned so that others can take advantage of HTML5 as well. In addition, we look forward to opportunities like our upcoming developer conference, Google I/O (May 27-28 in San Francisco, CA) where we'll be hosting a few sessions, to meet you in person and share demos and know-how.
Whether or not you can make it out to Google I/O, stay tuned to the blog for upcoming posts with examples such as how to avoid making your databases too large, handle upgrades gracefully, and tune performance.
2013, By: Seo Master
The mobile team started thinking about how we could bring the benefits of the server-side approach to these clients. We started thinking about a world where we could deliver a GUI specified in XML to a Java ME client, enabling us to iterate on the server side and deliver new features that could delight users when they were ready, rather than on a lengthy release cycle. I was especially struck by a friend who said "What I like about Gmail is that it just constantly keeps getting better. It's like waking up to a new little present from Google each month!" We wanted our mobile users to feel the same way, so we felt the logical thing to do would be to build a general client that could be controlled by the server.
Not too long after, the team first saw the new Android browser. Still in its early stages, the Android browser was built on the latest version of WebKit and could render desktop pages with ease. The XHTML, images, JavaScript, and CSS that could be rendered on this platform presented great potential for building very high-end web applications. However, this was ages before Android was due to ship and Android would only be one of many mobile platforms.
Those drawbacks aside, we couldn't help but think that new browsers in Android's league would eventually become a reality. These powerful browsers could have the kind of functionality we needed to build top-notch, offline user interfaces that didn't need to be "installed" by users or "upgraded". Gmail could be Gmail: a constantly evolving way to handle lots of email quickly and efficiently. The only fly in the ointment was the need for Gears: users would have to download a browser plug-in, and most web browsers on mobile devices don't even support that. What we really needed was for Gears to inspire innovation in HTML itself, so that the whole web could move forward.
Enter HTML5. We're very excited about the evolving HTML5 standard because it enables mobile and desktop website designers to deliver the advantages of client-side and server side development to their users simultaneously! New APIs let web applications start offline and store data on the client. The canvas API lets you draw complex user interfaces, or you can use advanced CSS tricks to get the browser to render a rich UI. In addition, the W3C Geolocation API is being adopted and implemented by browser developers, enabling entire new categories of web applications to be built. The benefits are clear: you can develop fantastic new applications, benefit from server-side analytics and iteration to deliver features that your users want, and know that offline functionality keeps things running as the user moves in and out of coverage. Your users can enjoy fast, capable web apps that they can access from any device, without the need to copy their data from place to place or worry about installing software or being online.
We decided to build new versions of mobile Gmail and mobile Calendar on top of this functionality. First, we built a small javascript wrapper around the database functionality in HTML5 and Gears. This wrapper abstracts away the differences between the two APIs, so that our applications are supported on the broadest set of browsers possible while older browsers get updated with implementations of the new offline APIs. We noticed that we weren't the only ones thinking about this: a quick search shows that other developers saw the similarities too. The main difference between the Gears database API and the HTML5 database API is that the Gears API is synchronous, requiring separate worker threads to do the database calls, while the HTML5 database API uses callbacks and is asynchronous. With the wrapper built, we knew our code would run on all high-end mobile browsers today, and look forward to even more distribution as everybody implements HTML5.
We knew we could apply various approaches to building better experiences for Gmail and Calendar. The key principle we kept in mind is an age-old one: KISS. Simply caching responses in the database for re-use is surprisingly effective: you can get a lot of improvement with just a read-only environment. This approach worked well for Calendar, where usage is predominantly read-only and we can rely on the user being online to make edits.
For Gmail, more complexity was needed. A queue of user actions needs to be maintained in the database (in case the user runs out of battery or powers down for their flight). Later, when the device is back online, it can execute that queue of mails to send, archive or delete, and so on.
Having the ability to store your data and actions offline isn't much good if you can't start the application while offline. So besides making use of the database API, we needed a way to get the application itself loaded without an internet connection. The HTML5 specification comes to the rescue here, with an application cache that is capable of storing all resources in your web app so that the browser can load them while offline. This API has just one small drawback: once you've decided you're going to override how HTTP GET works to fetch resources from the application cache, you also commit to never issuing a GET for a resource the cache doesn't know about. The specification contains methods for extending what URIs the cache knows exist, but these entry points are not widely implemented in production browsers. Instead, it's important to use HTTP POST requests for all dynamic data, since POST requests are never cached and therefore do reach the network.
The end result is an incredible thing: a web app that loads offline, and lets you read your Gmail or view your events provided the data have previously been cached. The experience is seamless as you ride the subway or the bus through terrible coverage: your data are ready, quickly, all the time. To see the new Gmail for mobile web app, go to gmail.com from an Android-powered device or iPhone (OS 2.2.1 or above).
Of course we didn't get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we've skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we've learned so that others can take advantage of HTML5 as well. In addition, we look forward to opportunities like our upcoming developer conference, Google I/O (May 27-28 in San Francisco, CA) where we'll be hosting a few sessions, to meet you in person and share demos and know-how.
Whether or not you can make it out to Google I/O, stay tuned to the blog for upcoming posts with examples such as how to avoid making your databases too large, handle upgrades gracefully, and tune performance.
2013, By: Seo Master
seo Making APIs Faster: Introducing Partial Response and Partial Update 2013
Seo Master present to you: At Google, we strive to make the web faster. Today, we’re proud to take our first big step in making APIs faster by introducing two experimental features in the Google Data Protocol, partial response and partial update. Together, partial response and partial update can drastically reduce the network, memory, and CPU resources needed to work with Google APIs.
It’s easy to understand the benefit of partial response and partial update. Imagine that you are writing a new Android calendar widget, and you want to display the time and title of the recently changed events on your Google Calendar. With the old Calendar Data API, you would request your calendar’s events feed and receive a large amount of information in response -- including lots of extra data like the attendee list and the event description.
With the addition of partial response, however, you can now use the
By including the
But say you want to also enable the widget to change the time of calendar events. With partial update, you can easily accomplish this: simply edit the data you received in the partial response and use the HTTP
Now for a quick demo. If you’re currently logged into a Google account, compare the size of your full calendar feed and your partial calendar feed. When we ran this test, our full calendar feed contained 160 kB of data while the partial feed only contained 8 kB -- the partial response successfully reduced total data transfer by 95%! Performance enhancements like this are especially apparent on a mobile device, where every byte of memory and every CPU cycle count. In nearly all clients, partial response and partial update make it more efficient to send, store, parse, cache, and modify only the data that you need.
As of today, partial response and partial update are supported in four Google APIs:
Thanks for joining us in our effort to make APIs on the web as fast and as efficient as possible!
2013, By: Seo Master
It’s easy to understand the benefit of partial response and partial update. Imagine that you are writing a new Android calendar widget, and you want to display the time and title of the recently changed events on your Google Calendar. With the old Calendar Data API, you would request your calendar’s events feed and receive a large amount of information in response -- including lots of extra data like the attendee list and the event description.
With the addition of partial response, however, you can now use the
fields query parameter to request only relevant information -- in this case, event titles and times. Constructing such a request using the fields query parameter is simple:GET http://www.google.com/calendar/feeds/zachpm@google.com/private/full?fields=entry(title,gd:when)By including the
entry argument and specifying title and gd:when, this request ensures that the partial response contains only the title and time for each event, along with a small amount of wrapping metadata.But say you want to also enable the widget to change the time of calendar events. With partial update, you can easily accomplish this: simply edit the data you received in the partial response and use the HTTP
PATCH verb to send the modified data back to the server. The server then intelligently interprets your PATCH, updating only the fields you chose to send. Throughout this entire read-modify-write cycle, the unneeded data remains server-side and untouched.Now for a quick demo. If you’re currently logged into a Google account, compare the size of your full calendar feed and your partial calendar feed. When we ran this test, our full calendar feed contained 160 kB of data while the partial feed only contained 8 kB -- the partial response successfully reduced total data transfer by 95%! Performance enhancements like this are especially apparent on a mobile device, where every byte of memory and every CPU cycle count. In nearly all clients, partial response and partial update make it more efficient to send, store, parse, cache, and modify only the data that you need.
As of today, partial response and partial update are supported in four Google APIs:
- The YouTube Data API supports partial response and partial update.
- The Calendar Data API supports partial response and partial update with Java client library support.
- The Picasa Web Albums Data API supports partial response and partial update with Java client library support.
- The read-only Sidewiki Data API supports partial response with Java client library support.
Thanks for joining us in our effort to make APIs on the web as fast and as efficient as possible!
2013, By: Seo Master