Modifying events with the Google Calendar API (The G Suite Dev Show)

Modifying events with the Google Calendar API (The G Suite Dev Show)

[GERMAN],, developers. Those who speak German
know that means “good day.” Speaking of days,
did you know you could use email markup and
the Google Calendar API so your apps can create calendar
events on behalf of your users? Well, it’s true. I’ve got code and
videos to prove it. But plans change. And wouldn’t it be
awesome if you could also update events when plans change
or create repeating events? Welcome to the “G
Suite Dev Show.” I’m your host, Wesley Chun. Today, we’ll show
how your apps can update existing events with a
Calendar API and, as a bonus, make them repeat, too. In the video on email
markup, I describe how it helps Gmail
automatically add events to your user’s calendars. It’s simple and doesn’t
require you to write any code. You’re only adding markup
to messages you’re already sending to users. Check out the video
and email markup docs to see how to do this
with the links down below. But as a developer, you
may want more control and not rely on another
app to do the work. What if you had a
typo in your markup? Or what if your users’ email
clients don’t process markup? No calendar event. Instead, your app can
explicitly insert events into your users’ calendars. Here’s another video
where I show you how to use the Calendar API
to set up dinner with friends. Check out the
video and blog post to review the JSON payload
use to create that event. Well, here’s a JSON payload
in Python dictionary format from that video. The event variable
is how we ask the API to create that initial
dinner invite to begin with. It’s got the event
name, the start and end times, and invitees. This entry or record is the
API resource for this event. By the way, what do you think
the R in URL stands for? Well, we’re happy that dinner
worked out, but imagine another dinner that didn’t,
leaving you with an unfulfilled calendar event. But wait, today you
got the good news that your friend got
assigned a job nearby for the rest of the year. Not only do you want to get
that dinner back on track, but also want to make
it a bi-monthly thing until the end of the year. This is the perfect feature
to update your app with. It saved the original event
ID from the dinner that didn’t work out, and
now it only needs to be updated with the new
dates and to make it repeat. The Calendar API gives you
two ways of updating events. You can either patch, meaning
updating one or more fields of the event
resource, or update, meaning recreate
the entire resource. We’ll look at both
and discuss when you’d pick one over the other. To update individual fields,
use the events dot patch method, named as such because you’re
patching the updated fields– you know, the deltas from
the original resource. In our case, we got to patch
the new date into the event. Also, we’re now using
a time zone instead of a specific offset from GMT. This allows for events to
observe Daylight Savings Time, meaning a 7:00 PM
dinner stays at 7:00 PM as we cross the fall
and spring boundaries. You can still use an offset
with a time zone if you wish, as they are independent
of each other. Something you
haven’t seen before is how to do repeating events. To do this, you need
to define what’s known as a recurrence
rule, which answers the question of
how often an event repeats. It looks somewhat cryptic, but
follows the RFC 5545 internet standard, which you can
basically decode like this. The event has a frequency
of occurring monthly but with an interval of two,
meaning every other month, till the end of the year. More info and examples at
the RFC link down below. The other alternative
to modifying an event in a calendar is update, meaning
replacing the whole thing. This is likely the best
choice if you’re updating most or all of the fields anyway. Create a new resource with all
the existing updated fields as if you were
starting from scratch. Then call events dot
update to override the whole entire resource. Since we only need to update the
date and add a recurrence rule, which of the two
choices seems better? Yep, patch, because we’re
only modifying two fields. Which you choose depends
on your situation, though, because if you want
to change the event name or have a whole new
group of friends, you’d probably choose
update since you’re changing most of the fields, right? By the way, regardless
of whether you use patch or update, in a
real app, your user may make changes from their
desktop or mobile device. And typically, you want to
avoid conflicting changes or race conditions. So we recommend using
the if-match header and an e-tag string to
uniquely identify updates. For more info on the latter,
check out the Conditional Modification page in the docs. The code’s in Python
to keep things brief, but feel free to use
the client library for your favorite language. Create a project in
the Developer’s Console with a Calendar API and enable. Then create an event in Google
Calendar and grab its ID. Check out the previous video if
you don’t know how to do that. Once you’re set, we
can go to the computer now and look at some code
to modify that event. Lines 1 through 13 is
the standard boilerplate we’ve covered in many
of our other videos. But here, pay extra
attention to line 7, which is the read/write
scope for Google Calendar, and line 13, which is where
we create the service endpoint to the Google Calendar API. As mentioned earlier, we
chose patch in this example, because we’re only
changing the date and making this event repeat. The time zone on line
15 is immediately followed by the event payload
on line 16 through 20. You need to change line
21 for your event ID. 22 and 23 send this request to
the API with a call to events dot patch. Finally, the print
call at the end gives us a receipt
showing the user the modified event, including
the newly installed recurrence rule. All right. Now let’s run this thing. Since I’ve personally
run this before, we won’t see the
OAuth 2 prompt here, but you’ll get it
on your first try. The onscreen output shows
a new event information. But as you can see, it showed
up on our Google Calendar, too. Ta-da. Obviously the script I
ran had a real event ID. But the rest of it is exactly
what we just covered onscreen– code that modifies calendar
events and making them repeat, all in about
30 lines of code. Anyway, take a look
at the deep dive post if you want to dig
into the details. Your next steps– check out the
official docs for everything you need to know. If you’re new to
the Calendar API, specifically check out the
Concepts and Overview page. The final resource is a guide
on calendar and event objects. It even covers recurrence. Armed with this
newfound knowledge, you’re now well on your
way to giving your users an even better experience
by enhancing your app with the Google Calendar API. Let us know how it works for
you down in the comments below and give us ideas
for future videos. This is Wesley Chun, and
we’ll see you upstairs in the G Suite. [MUSIC PLAYING]

10 thoughts on “Modifying events with the Google Calendar API (The G Suite Dev Show)”

  1. Got a question.

    If i want to change code so that my calendar only shows 4 days of schedules at a time

    With no scroll forward – how would I know the code to insert and where ?

    Reason I'm asking is because- I'd like to publish a 3-day schedule for folks to Schedule inside of.

    This schedule should only show openings for next 3 days only

  2. Is there any way to use the API to allow write access to a calendar that the user has only read access on? Or is there a way to programmatically add a user to a calendar via the API? I have a large number if people I need to add to a calendar (read and write access) and I am trying to do it programmatically rather than by hand. Any advice is appreciated. Thank you!

  3. I have various ideas for gcal mods, like be able to drag google task items to the calendar and vice versa.
    Have more options so, in one click, change to 2, 3, or 4 day views.
    Can I do that, alter the calendar interface with an API or something?

Leave a Reply

Your email address will not be published. Required fields are marked *