Hello there.
My name is Subir, and I lead the cloud messaging team at Google.
Today, I'm going to talk about some of the awesome APIs
that Google Cloud Messaging or GCM provides.
GCM provides a root set of APIs to send messages
from a server to an application efficiently and reliably.
I want to thank all the developers using Google Cloud
Messaging, because it really helps
the ecosystem by minimizing the impact your application has
on battery life, radio wake ups, and network signaling.
Let's quickly look at some of the APIs required to use GCM.
To use GCM, an application needs a Registration ID.
Use this Registration ID to send messages
to a particular device.
Multicast lets you send messages to up to 1,000 recipients
with a single request.
And you can set Time To Live on each request
to tell GCM went to expire the message.
So what's new in 2014?
Today, I'll cover three key features
that GCM provides-- XMPP-based Cloud Connection
Server, Upstream Messaging, and User Notifications.
In 2013, we opened these APIs to a limited set of developers.
Since then, we've added a bunch of new features with these APIs
and made them faster and more robust.
We saw a tremendous response and interest from developers
around these APIs.
And I'm really excited to announce
that these services are now open for all developers.
Let's talk about GCM's XMPP point,
also known as Cloud Connection Server.
Cloud Connection Server, or CCS, provides
a persistent, asynchronous, bidirectional connection
to our GCM servers.
This is a very powerful service as it provides
a virtual connection between your server and your user's UCM
connected devices.
This connection can be used to reliably send and receive
messages.
Here's how you can connect to CCS.
I'm using the simple XMPP library in Python
to connect to CCS.
As you can see, gcm.goobleapis.com is the URL
and 5235 is the port.
You simply need to connect to this end point
and authenticate using your project's API key.
The next step is to start sending messages.
These messages include a JSON payload
that contains a target, application data, and a Message
ID.
Since sending via XMPP is asynchronous,
this ID uniquely identifies an XMPP connection.
So when CCS sends an ACK back to your server,
it will use this Message ID to identify the message.
Therefore it is important that this Message ID is not
only unique, but also present in the request.
Let's take a look at what an ACK or a NACK for this message
looks like.
Message Type would indicate an ACK a NACK.
In case of a NACK, there's an error code
to describe what went wrong.
So when implementing a CCS connection,
here is what you need to know.
We allow a maximum of 100 connections per sender,
and the maximum outstanding messages per connection
is also 100.
Our improved error handling lets you
know more precisely what went wrong.
Here is an example of a control message describing
that a connection is draining.
What this message means is that the sender should not
send any more messages on this connection.
Any new messages on this connection
will get back a NACK with an error code
indicating that the connection is draining.
We have also added new codes for other types of errors,
like JSON parsing, et cetera.
So what we learned so far is that with XMPP end point,
GCM provides the ability to have a persistent, bidirectional
connection to your servers.
We also saw how to send messages down
to a device using this connection.
Next, we will take a look at an awesome Upstream Messaging
API that lets you send messages from the application
on a device to your server.
We have made a lot of changes to make
Upstream Messaging fast and reliable.
And I'm happy to say that it's now open to all developers.
So let's take a look.
Since the connection between the device and GCM already exists,
its a low latency send, as no new handshake is needed.
These messages are saved locally if the device is offline,
and are sent when we have a connection.
We use the same Reliable Message Queue technology
that we use for Downstream Messages.
So if we lose a connection to your server,
we will deliver the messages once the connection
is re-established.
We will delete your messages once we
get an ACK from your server.
A order to receive an Upstream Message,
your server should be connected to CCS.
Here's an example on how to send the message using Google Cloud
Messaging APIs.
Just set the Project ID as the destination,
and we will deliver the message to your server.
You can send and also set Time To Live in the API call.
This is what an ACK looks like.
Once again, since the response is asynchronous,
Message ID is used to identify the message.
Here are some things to keep in mind
when using Upstream Messaging.
No pending messages on a connection more than 100.
We will delete your messages if your server fails
to connect for more than 24 hours.
We will also allow a maximum of 20 unACKed Upstream Messages
from a single device.
So ACKing is required.
And similar to Downstream Messages,
the maximum payload size allowed for upstream is 4K.
Here's a lot of my favorite new APIs in GCM-- Delivery
Receipts.
When sending messages to a device,
a common request from developers is
to get more insight into the state of the message
and to know if the message was delivered.
For example, you are writing a messaging app
and would like to show your sender
if their message was delivered.
With CCS, you can do that now.
We are adding this new feature called Delivery Receipts.
Here's an example on how you can request
a receipt for a message.
In the JSON payload of the message,
you just set the new field Delivery Receipt
Requested to True.
By default, the value is False.
Here is a Receipt Message.
This message will have a new Message ID.
From will be set to gcm.google.apis.com,
and type as Receipt.
There are four fields that we add in the response data--
message status, original Message ID, time of send,
and the Registration ID of the original message.
Nowadays, users have multiple devices
and hence receive notifications multiple times.
This can reduce notifications from a useful feature
to an annoyance.
Thankfully, GCM provides a convenient way
called User Notifications to reach all devices for a user
and help you synchronize notifications, including
dismissals.
I'll talk more about dismissals in a bit.
With User Notifications you can target it all devices
belonging to a user with a single request.
This is a very powerful API and allows
you to be smarter about your notifications.
I'll give you a couple of examples.
You can set a short TTL so the notification will only
be sent to a device that is currently connected.
Another example is to use option of Delay While Idle.
Imagine your user has a phone that they
use all day and a tablet that sits idle at home.
By setting the Delay While Idle and a TTL,
you can send the notification only
to the phone that is actively used.
Pretty useful, right?
To send messages to all devices for a user,
you need a Notification Key.
The Application Server can get a key
by adding or removing registration
to the Notification Key name.
Let's see how you can get a Notification Key.
Here is the endpoint to get a key and the HTTP header.
The request is authenticated using your project's API key.
So first thing, we add a registration to a Notification
Key, you can do a Create.
And then if the user stores the app on another device,
you can use an Add.
And important field is the Notification Key Name.
For us, it's just a unique identifier
that you use to identify this user.
The actual username is not relevant.
So please use a hash.
It needs to be unique for an user.
Here's an example of how you can send
a message to all devices for a user.
The only difference is that instead of sending a message
to a Registration ID, we now send it to a Notification Key.
Now let's assume a user on one device acts
on the notification, and we want to dismiss this
from all other devices.
How do we do it?
With Upstream Messaging, we can send a message
to a Notification Key and GCM will deliver the message
to all of other registrations in this key.
This way, you can tell other devices
to dismiss a notification as it is already
handled on one device.
In addition, you can also send this message
to your Application Server by sending
Get to a Project ID in a separate Upstream Message.
Here is an example.
As you can see, the two fields in the Upstream Message
is set to a Notification Key.
This will make GCM send this message
to all other devices that are part of this key.
User Notifications is available on both HTTP and XMPP.
It allows a max of 20 registrations
per Notification Key.
And of course, the key name in the request
should be unique to a user.
Before we end, I'd like you to please check out our updated
documentation for all GCM APIs and services.
As always, it's available at this link here.
Thank you for watching.
And I hope you are excited to use these new APIs
and services, and enjoyed this video.