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
Hosts the web client and web service
that our App talks to and sends
Messages to the C2DM service
Stores our Auth Token
And Device
Registration IDs
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
Hosts the web client and web service
that our App talks to and sends
Messages to the C2DM service
Stores our Auth Token
And Device
Registration IDs
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?