Embed Size (px)
Citation preview
Staying in Sync with Cloud 2 Device Messaging
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
Used to se
nd Messa
ges
Registers and Receives
Messages
Stores our Auth TokenAnd Device
Registration IDs
Hosts the web client and web service that our App talks to and sendsMessages 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
Used to se
nd Messa
ges
Registers and Receives
Messages
Stores our Auth TokenAnd Device
Registration IDs
Hosts the web client and web service that our App talks to and sendsMessages 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.zipDemo 2: http://chrisrisner.com/upload/OneDevDay2011b-Presentation.zip
Questions?
