$apiClient = new apiClient(); $apiClient->setUseObjects(true);
$event = $service->events->get("primary", "eventId"); echo $event->getSummary();
result = client.execute( :api_method => service.events.get, :parameters => {'calendarId' => 'primary', 'eventId' => 'eventId'}) print result.data.summary
import randomimport timedef GetResourcesWithExponentialBackoff(client): """Gets all of the resources for the authorized user Args: client: gdata.docs.client.DocsClient authorized for a user. Returns: gdata.docs.data.ResourceFeed representing Resources found in request. """ for n in range(0, 5): try: response = client.GetResources() return response except: time.sleep((2 ** n) + (random.randint(0, 1000) / 1000)) print "There has been an error, the request never succeeded." return None
Developers using the Google Apps APIs owe it to themselves to stay informed. To make it as easy as possible, we’ve adopted a standard process for making important announcements about the APIs.
All major outages or issues, although infrequent, are announced on the Google Apps APIs Downtime Notify list as quickly as possible. We also post updates and resolutions. All developers using the Google Apps APIs should subscribe.
Announcements about new APIs and features as well as best practices about the Google Apps APIs occur on the this blog. You can subscribe via e-mail (see right sidebar), using the feed, by following @GoogleAppsDev on Twitter, or by following members of the team on Google+.
If you want to hear about just the most important announcements, follow the Google Apps APIs Announcements forum. This is a low-volume list and you can subscribe via e-mail.
Lastly, you should subscribe to the individual forums for the Google Apps APIs you care about the most. A lot of technical discussion occurs in the forums and many advanced API users participate in the conversation along with Google engineers.
We recently launched a new version of the Google Calendar API. In addition to the advantages it gains from Google's new infrastructure for APIs, Google Calendar API v3 has a number of improvements that are specific to Google Calendar. In this blog post we’ll highlight a topic that often causes confusion for developers using the Google Calendar API: recurring events.
A recurring event is a 'template' for a series of events that usually happen with some regularity, for example daily or bi-weekly. To create a recurring event, the client specifies the first instance of the event and includes one or more rules that describe when future events should occur. Google Calendar will then 'expand' the event into the specified occurrences. Individual events in a series may be changed, or even deleted. Such events become exceptions: they are still part of the series, but changes are preserved even if the recurring event itself is updated.
Let's create a daily recurring event that will occur every weekday of the current week (as specified by the recurrence rule on the last line):
POST https://www.googleapis.com/calendar/v3/calendars/primary/events { "summary": "Daily project sync", "start": { "dateTime": "2011-12-12T10:00:00", "timeZone": "Europe/Zurich" }, "end": { "dateTime": "2011-12-12T10:15:00", "timeZone": "Europe/Zurich" }, "recurrence": [ "RRULE:FREQ=DAILY;COUNT=5" ] }
When added to a calendar, this will turn into five different events. The recurrence rule is specified according to the iCalendar format (see RFC 5545). Note, however, that, in contrast to the previous versions of the Google Calendar API, the start and end times are specified the same way as for single instance events, and not with iCalendar syntax. Further, note that a timezone identifier for both the start and end time is always required for recurring events, so that expansion happens correctly if part of a series occurs during daylight savings time.
By default, when listing events on a calendar, recurring events and all exceptions (including canceled events) are returned. To avoid having to expand recurring events, a client can set the singleEvents query parameter to true, like in the previous versions of the API. Doing so excludes the recurring events, but includes all expanded instances.
Another way to get instances of a recurring event is to use the 'instances' collection, which is a new feature of this API version. To list all instances of the daily event that we just created, we can use a query like this:
GET https://www.googleapis.com/calendar/v3/calendars/primary/events/7n6f7a9g8a483r95t8en23rfs4/instances
which returns something like this:
{ ... "items": [ { "kind": "calendar#event", "id": "7n6f7a9g8a483r95t8en23rfs4_20111212T090000Z", "summary": "Daily project sync", "start": { "dateTime": "2011-12-12T10:00:00+01:00" }, "end": { "dateTime": "2011-12-12T10:15:00+01:00" }, "recurringEventId": "7n6f7a9g8a483r95t8en23rfs4", "originalStartTime": { "dateTime": "2011-12-12T10:00:00+01:00", "timeZone": "Europe/Zurich" }, ... }, … (4 more instances) ...
Now, we could turn one instance into an exception by updating that event on the server. For example, we could move one meeting in the series to one hour later as usual and change the title. The original start date in the event is kept, and serves as an identifier of the instance within the series.
If you have a client that does its own recurrence rule expansion and knows the original start date of an instance that you want to change, the best way to get the instance is to use the originalStart parameter like so:
originalStart
GET https://www.googleapis.com/calendar/v3/calendars/primary/events/7n6f7a9g8a483r95t8en23rfs4/instances?originalStart=2011-12-16T10:00:00%2B01:00
This would return a collection with either zero or one item, depending on whether the instance with the exact original start date exists. If it does, just update or delete the event as above.
We hope you’ll find value in these changes to recurring events. Keep in mind, too, that these are not the only improvements in Google Calendar API v3. Look for an upcoming post describing best practices for another key area of improvement: reminders.
If you have any questions about handling recurring events or other features of the new Calendar API, post them on the Calendar API forum.
Editor's note:: 2/20/2012 - Removed references to API call which reverted changes made to an individual instance. This feature was deprecated.
We've held many Office Hours on Google+ Hangouts over the last two months, bringing together Google Apps developers from around the world along with Googlers to discuss the Apps APIs. We've heard great feedback about these Office Hours from participants, so we've scheduled a few more in 2011.
General office hours (covering all Google Apps APIs):
Product-specific office hours:
As we add more Office Hours in the new year, we'll post them on the events calendar, and announce them on @GoogleAppsDev and our personal Google+ profiles.
Hope you’ll hang out with us soon!
Editor’s note: If you’re in the SF area, join us tomorrow for our next hackathon. There are a few spots left. See Eric's note at the end of this post.
Last Thursday’s Google Apps Hackathon in New York brought together 70 developers to create cool new applications using Google Apps APIs. The varied field of talent included individual developers, small teams from companies like ShuttleCloud, and a group of technically inclined educators from the non-profit New Visions for Public Schools.
Ten Google engineers were on hand to help participants with tips and information about specific APIs. Among them, Dan Holevoet and Alain Vongsouvanh from Mountain View shared their Calendar and Contacts API expertise, while Shradda Gupta and Gunjan Sharma traveled from India to help field questions about admin and domain management APIs.
At this hackathon, competitors had two categories to choose from: building new applications using Google Apps APIs, and integrating Google Apps APIs with an existing app. The various groups entered and demonstrated a total of sixteen apps across the two categories, including:
For the new apps category, the panel of judges settled first prize on “AlphaSheet,” a simple but streamlined app using a custom spreadsheet function to fill in values from Wolfram Alpha queries. “Fareshare” took top honors in the second category for integrating Google Calendar in a mobile app that helps New Yorkers share cab rides.
It’s great to see developers join forces and have a great time hacking up new apps at events like this one. An impressive amount of knowledge-sharing occurred, and everyone walked away with new ideas and skills to take back to their work in the realms of business or education.
If you missed this event, don’t worry — the future holds more hackathons, including the upcoming event tomorrow (Dec 6th) at Google’s Mountain View, CA campus from 1:00pm - 8:00pm PST. If you’re located in Europe, we have a series of events planned over the next few months.
Yesterday, the Google APIs Client Library for JavaScript was released, unlocking tons of possibilities for fast, dynamic web applications, without requiring developers to run their own backend services to talk to Google APIs. This client library supports all discovery-based APIs, including the Google Tasks, Google Calendar v3 and Groups Settings APIs. To make it easy to get started using the JS client with Google Apps APIs, we’ve provided an example below.
After you’ve configured your APIs console project as described in the client library instructions, grab a copy of your client ID and API key, as well as the scopes you need to access the API of your choice.
var clientId = 'YOUR_CLIENT_ID'; var apiKey = 'YOUR_API_KEY'; var scopes = 'https://www.googleapis.com/auth/calendar';
You’ll also need several boilerplate methods to check that the user is logged in and to handle authorization:
function handleClientLoad() { gapi.client.setApiKey(apiKey); window.setTimeout(checkAuth,1); checkAuth(); } function checkAuth() { gapi.auth.authorize({client_id: clientId, scope: scopes, immediate: true}, handleAuthResult); } function handleAuthResult(authResult) { var authorizeButton = document.getElementById('authorize-button'); if (authResult) { authorizeButton.style.visibility = 'hidden'; makeApiCall(); } else { authorizeButton.style.visibility = ''; authorizeButton.onclick = handleAuthClick; } } function handleAuthClick(event) { gapi.auth.authorize( {client_id: clientId, scope: scopes, immediate: false}, handleAuthResult); return false; }
Once the application is authorized, the makeApiCall function makes a request to the API of your choice. Here we make a request to retrieve a list of events from the user’s primary calendar, and use the results to populate a list on the page:
function makeApiCall() { gapi.client.load('calendar', 'v3', function() { var request = gapi.client.calendar.events.list({ 'calendarId': 'primary' }); request.execute(function(resp) { for (var i = 0; i < resp.items.length; i++) { var li = document.createElement('li'); li.appendChild(document.createTextNode(resp.items[i].summary)); document.getElementById('events').appendChild(li); } }); }); }
To tie all of this together, we use the following HTML, which configures the DOM elements we need to display the list, a login button the user can click to grant authorization, and a script tag to initially load the client library:
<html> <body> <div id='content'> <h1>Events</h1> <ul id='events'></ul> </div> <a href='#' id='authorize-button' onclick='handleAuthClick();'>Login</a> <script> // Insert the JS from above, here. </script> <script src="https://apis.google.com/js/client.js?onload=handleClientLoad"></script> </body> </html>
Making requests to other discovery-based APIs, such as the Tasks API requires only small modifications to the above:
As additional discovery-based APIs are released, they’ll be automatically supported by the library (just like the Python and Ruby clients).
If you have general questions about the JS client, check out the JavaScript client group. For questions on specific Apps APIs come find us in the respective Apps API forum.
