Cloud 2 Device Messaging

grrrgrapeInternet and Web Development

Oct 31, 2013 (4 years and 13 days ago)

135 views

Staying in Sync with

Cloud
2

Device Messaging

About Me


Chris
Risner


chris@chrisrisner.com


http://chrisrisner.com


Twitter:
chrisrisner


How do we keep our apps up to date?


Goal: Get the latest data to our app.


Techniques:


Polling: the app checks the server
periodically.


Pushing: the app waits for information to
get sent to it.

What’s wrong with Polling?


If there isn’t any new data, we’re still checking


We’re using bandwidth and battery resources
that we don’t need to.


Maybe we should try Pushing!

What is C2DM?


C2DM is how we push data to our
applications.


Allows us to send a small amount of data to
any device with our application installed and
registered for C2DM.


Great for telling our app there is new data,
not necessarily for delivering that data.


Uses the same single connection for every
app on the device.

Limitations of C2DM


The device must be running 2.2 or greater.


The device must have the Marketplace installed.


Your app needs additional permissions in the
manifest.


Doesn’t include any pre
-
built UI.


Need to have a whitelisted account (more on this
later).


Message payload is limited to 1024 bytes!

What’s great about C2DM?


Your app doesn’t have to be running to
receive the message and process it.


You can display a notification however you
want.


Your application server can be written in
anything (Java, C#, PHP,
etc
)

How efficient is it?


A background service establishes and maintains a
single SSL
-
encrypted persistent TCP/IP connection.


Honors background
-
data setting.


Auto starts when the network becomes available.


Uses heartbeats to auto
-
reconnect as necessary.


Tuned for different networks.


In the cloud, Google provides a scaled farm of servers
to accept and maintain the persistent connections.


Caches session keys to minimize SSL handshakes.


Each app provides its broadcast receiver to accept
messages.

App Engine connected Android
Projects

Stores our
Auth

Token

And Device

Registration IDs

Hosts the web client and web service

that our App talks to and sends

Messages to the C2DM service

Google’s Servers that

Send messages to devices

Step 1: Get an Account


Fill out the signup form at
http://code.google.com/android/c2dm/signup.html


Your account MUST be whitelisted to use C2DM.


Need to provide the following:


App package name.


Estimated total # of messages per day.


Estimated peak messages per second.


Contact email address (your address).


A Role email address (
gmail

and NOT your email address).


Used in application as well as on your app server.

Step 2: Get your App Ready


Add the permissions, receiver, and service to
your manifest.


Create a receiver to handle registration result
and message notification.

Step 3: Register your App


Connect to C2DM from your app with the
whitelisted email address.


Get back a device registration ID (
drID
).


Send the
drID

to your app server.

Step 4: Save the
drID


Your app server needs to expose some way for
the app to say “here’s a
gmail

address and a
drID
”.


Saving the connection between
drID

and address
allows users to connect multiple devices to your
app server.


The server needs to save this somewhere for
later use.

Step 5: Get an
Auth

Token


Connect to the Google
ClientLogin

service.


Send over:


Account type


Whitelisted email address.


Email address password.


Server (ac2dm)


Source


Parse the
auth

token out of the 200 response
or handle the different errors


Step 6: Send a Message


Submit a post to
https://android.apis.google.com/c2dm/send

with
the following:


Device registration ID.


Collapse key (more on this in a second).


Data.


Auth

token


Delay_while_idle
: optional but allows you to tell
C2DM to not deliver until the device is active.


Parse the ID of the sent message or an error out
of the response.

Step 6.1: Possible Errors


Quota Exceeded


Device Quota Exceeded


Invalid Registration


Not Registered


Message Too Big


Missing Collapse Key


401


503

A Word about the Collapse Key


Used to prevent sending multiple messages
when a device comes online.


Also useful for making sure the user doesn’t
get a stale notification.


Max of 4 collapse keys “in process” for device.


Step 7: The C2DM Servers


Verifies our
Auth

Token.


Temporarily queues our message to a durable
store.


Holds the message until delivered or expired.


Replaces other messages with the same
drID

and
collapse key.


Step 7.1: More C2DM Server


Server keeps track of how many messages
have been sent per app, per device, and per
collapse key recently.


Prevents firing the radio for every message.


Protects battery life.


Protects the user from getting too many
messages.


Step 8: Delivery to Device


When the message is successfully delivered to
the app, an acknowledge response is sent
back to the server.


The Manifest file ensures that ONLY our app
receives the notification and other apps don’t.


If your
onMessage

needs to do a lot of
processing, consider using a
wakelock
.

Step X: Unregister the Device


Automatically done when app is uninstalled.


Just requires a call to the C2DM server.


Doesn’t notify your app server!

App Engine connected Android
Projects

Stores our
Auth

Token

And Device

Registration IDs

Hosts the web client and web service

that our App talks to and sends

Messages to the C2DM service

Google’s Servers that

Send messages to devices

Quotas


Quotas are assigned to sender accounts, not
Applications.


Default quota is 200,000 messages / day.


If you need more, there is a form you can fill
out to request more.

Important Things to Remember


Delivery and order of delivery isn’t
guaranteed.


There is a size limit of each message (1024
bytes)


Auth

tokens and
drIDs

can “expire”. Your app
needs to handle accepting new ones.


Demo

Demo 1
:
http://
chrisrisner.com/upload/OneDevDay2011a
-
Presentation.zip

Demo 2:
http://
chrisrisner.com/upload/OneDevDay2011b
-
Presentation.zip


Questions?