[MUSIC PLAYING]
Hi, my name is Reto Meier, and I'm a tech lead for Google's
Android Developer Relations team.
One of the most effective ways you have at your disposal for
optimizing the efficiency of your data transfers is
eliminating user-driven updates.
That means doing everything you can to eliminate the
Refresh button within your app.
The most common reason people hit Refresh is because they
don't believe your app is displaying up-to-date
information.
If you're using some form of client side polling, they're
probably right.
In fact, every time you create a repeating alarm to pin your
server to check for updates, Sundar kills a Bug Droid.
Stop the slaughter and use Google Cloud Messaging to have
your server notify your app when there is data ready to be
downloaded, or even include the new data in the message
payload itself.
If you're using polling, you're forced to balance data
freshness with the resulting battery drain.
The more often you poll for updates, the lower latency
between the data changing on the server and your app
displaying those updates.
But turning on the radio to check for those updates, also
drains the battery.
That's the worst of both worlds, when what you actually
want is no latency and as little
battery drain as possible.
Google Cloud Messaging helps you do this by offering a way
to send messages from your server to any installed
instance of your app.
As a result, you can stop polling, which will improve
battery life and also improve the freshness of your app.
Once configured, you can transmit messages to a
specific app installation or multicast messages to multiple
recipients.
These messages can be simple tickles notifying your app
that there's new data ready to download, or it can include
the new data within the message payload.
In this Dev.Byte, I focus on how to use Google Cloud
Messaging to perform more efficient data transfers.
The details for setting up your GCM client and server are
detailed comprehensively in the documentation.
That said, it helps to understand the GCM data flow.
It starts with your app on each device registering itself
by sending a registration message to the GCM
infrastructure.
In return, it will be sent a registration ID, which will
uniquely identify that instance of your app running
on that particular device.
You actually send this identifier to your server,
typically along with a separate identifier that you
can use to identify a particular user or
installation.
Your sever now has a way to send messages to a specific
app or a specific user via the Google Cloud Messaging
infrastructure.
Anything from breaking news, updated sports scores, and
your email messages, or an updated list of news articles.
This is enough to eliminate the need for polling and
ensures you never turn on the radio to communicate with the
server that has nothing new to download.
So your information architecture now needs to
determine the urgency of reflecting each server change
in your app.
You can set up your server using either HTTP or CCS using
XMPP, and it captures payloads as JSON or plaintext.
Here we're using JSON to create a message starting with
the registration IDs to which we want to
transmit our message.
By default, your app will receive GCM messages, even if
it's not running and the phone is on standby.
You can help minimize battery drain by setting
delay_while_idle to true, indicating that your message
doesn't need to be sent immediately, if the device is
on standby.
Instead, these messages will be queued until the device
becomes active.
In fact, if you also set a collapse key, only one message
will be sent when the device does become active.
The collapse key is any arbitrary string that the GCM
service can use to collapse a queue of messages addressed to
the same device.
So when the device comes online or becomes active, it
receives only one message.
There's no guarantee that the message the queue collapses to
will be the most recent one you sent, so these messages
are known as send-to-sync and are best suited to update
tickles that tell your app simply that there is new data
ready to download.
You can go a step further and set a time loop before queued
messages expire using the time-to-live parameter.
This determines how many seconds the GCM service should
keep your message before canceling it.
By default, this is set to four weeks, but you can
dramatically reduce this for messages you know will be out
of date or replaced over a shorter time period, which is
a particularly useful feature for messages with payload
data, included in the form of an optional JSON object, whose
fields represent key value pairs of data.
Each message can store up to 4K of data, which will be
delivered as strings within the intent bundle of received
GCM messages as you can see here.
These non-collapsible or message-with-payload messages
are more than a synced tickle.
They're used when you need to deliver every message, because
every message has different content.
Notifications are a great example of how you may use
these payload messages.
By including the current weather details, commentary
and score after a touchdown pass, or breaking news
headlines and summaries within the payload of the GCM message
itself, you're able to update your users immediately with
nominal incremental battery impact.
It is possible to use these collapsed keys with payload
messages, but because the delivery of order isn't
guaranteed and the collapsed message isn't guaranteed to be
the last one received, you need to be careful not to
display outdated information.
If non-collapsible messages with payloads aren't going to
provide a specific improvement to the user experience,
send-to-sync messages are a better option, as they put
less of a burden on the device battery.
For example, if your server notifies your app every time
there is a new article or message, it only needs to
receive one message telling it that it's time to sync up,
which you can do using a sync adaptor to initiate the sync,
preferably bundling a number of batch transfers together,
as described in my Dev.Byte on batching, bundling, and using
the sync adaptor.
Using Google Cloud Messaging allows you to totally
eliminate client-side polling from your applications.
Implemented correctly, you can configure the messages
transmitted to have as little impact on the battery as
possible, using techniques like short-time-to-live
parameters, collapse keys, and the delay-while-idle parameter
to limit the number of messages which are actually
transmitted to your app.
By keeping your apps constantly up to date, you can
minimize latency and help eliminate the Refresh button.
Used with sync adaptors and pre-fetching, you can
dramatically improve the battery
efficiency of your apps.