Hi, I'm Filip from the Google Chrome Apps team.
Chrome apps and extensions use familiar web technologies,
and can be installed on the desktop, or any Chrome OS
device.
These client apps have access to additional APIs
not available to ordinary web pages.
A common problem developers face,
is how to get the latest data from their server
to the client app.
Say you're building an application
to track play-by-play stats for the World Cup.
One way to get an update is by polling.
Your client can periodically check with the server
to get the latest data.
But it doesn't know when new data is available.
So sometimes it will come back with nothing,
while sometimes it will get the updates long
after the data is actually available.
That's not great.
It needlessly consumes network bandwidth, grounds
down the device's battery, and delivers a poor experience
to the user who wants to the game updates as they happen.
Good news-- chrome.gcm API allows
you to access Google Cloud Messaging
service to solve that problem.
So how can you do it better?
You can tell your World Cup tracker server
which clients need to be notified as data becomes
available, and use GCM to push the data to the right clients.
And how is that done?
Through GCM downstream messaging.
First your app registers with GCM,
indicating the sender ID of the application server, from which
it wants to receive the messages.
It receives the registration ID in return.
Next, your application sends the registration
ID to the server, followed by information
about teams or games the user is interested in.
As games progress, your server sends messages
with the right registration ID to GCM, and GCM does the rest.
Your upper extension does not even
need to be running at the time the message is sent,
because once the message is received by Chrome,
it will start your app and trigger chrome.gcm on message
event.
That's how you can make sure your users are not
going to miss that big game.
And if Chrome is offline when your server sends the message,
that's not a problem either, because when
GCM receives messages from your server,
it stores them in a queue.
Once the device is back online, GCM
delivers the queued messages, and Chrome fires chrome.gcm
on message event in your app.
If Chrome cannot be reached for a long period of time,
the messages could be dropped, either there because they
exceeded their time to live, or the queue size limit was hit.
In the latter case, a special message
will be sent to the application, triggering chrome.gcm
on messages delete event, to let you know that it happened
and allow you to handle that situation.
OK, that's downstream messaging.
Now let's talk about delivering messages from your client app
to the server.
Without GCM, your client app might be conducting the app
server through XML http requests.
But if the user doesn't have the network connection
at the moment, that request may have to be repeated many times.
Again, that's a very inefficient use of resources.
Luckily chrome.gcm API offers the ability
to send upstream messages from your app
to an application server, using the same cloud messaging
infrastructure If your user wants to follow games
of Italy's national team, you can simply call chrome.gcm send
function to send a message to the server.
The message can contain up to four kilobytes of data,
and must specify the address of the recipient, which
should be to sender ID of your application server.
Before sending a message to GCM, Chrome
stores it locally to make sure it can be retransmitted
upon failure, which can happen when the user does not
have network access or the connection is spotty.
Once Chrome is online, it attempts
to send all queued messages.
And when the GCM server confirms the receipt of a message,
Chrome removes it from the local store,
while Google Cloud Messaging infrastructure delivers
the message to the application server.
As a result you get the same benefits
of energy savings and delivery, regardless
of the network connection state of the time of sending,
as with downstream messaging.
You can find more details on how to configure your server
to enable apps through messaging online.
Just like with downstream messages,
you can make upstream messages more time-sensitive
using a time-to-live parameter.
For instance, if your user does not
get online within a few minutes or hours,
Chrome can simply expire and drop the message.
Setting time-to-live for upstream messages
has two benefits-- it allows you to manage
your applications queue size on the Chrome side,
and there is a queue size limit, and when delivery times out,
Chrome will erase chrome.gcm unsent error event, which
will indicate that the message was not delivered,
allowing your application to respond accordingly.
So this all looks great, but I'm sure you're wondering,
what's the price?
Google doesn't charge anything for GCM,
and you can start using it today.
To learn more about chrome.gcm API, please
check out our documentation page.
And remember, Google Cloud Messaging
makes building efficient real-time apps a breeze.
Give it a try.