24. Working with Cloud to Device Messaging
Does your application need to connect to a server and download data to keep its content fresh? Does the data come in at random times, as opposed to on a schedule (once-a-day news article download)? Are you considering implementing a polling mechanism so that your Android application can routinely check your application server for new content? If this is the case, you might want to look into Google’s Cloud to Device Messaging (usually referred to as C2DM) service instead, because it can save you a lot of work and results in more efficient use of the user’s device resources. In this chapter, we talk about this third-party service, which is available to Android developers when targeting devices that include the Google experience.
An Overview of C2DM
C2DM is a messaging service offered by Google that supports push-style messaging. It basically allows third-party developers like you to use a single messaging service on the device instead of creating one. The C2DM service is free to use, but it has certain requirements, quotas, and limitations you should be aware of.
C2DM is a Google Labs-style project, which means it can be changed or discontinued at any time. The Android Cloud to Device Messaging team reserves the right to change the service, quotas, and other features of C2DM at any time. That said, many of their own applications use the service, so it isn’t likely to disappear anytime soon.
The C2DM service was introduced in Android 2.2 (API Level 8). It allows users to push data to applications efficiently. Instead of your application constantly checking for new data on its application server, a notification can be initiated from the server side. This has substantial positive ramifications in terms of device power usage and application responsiveness.
Using Google’s C2DM service basically means you’re using the shared messaging channel that Google developed for its own Android applications, such as Gmail. This cuts down on the number of individual applications constantly staying “awake” in order to poll their application servers and check for new stuff.
Understanding C2DM Message Flow
Here are the basics for how the C2DM messaging process works. To push data to an application, the developer’s application server sends a simple notification to Google’s C2DM servers via HTTP using a registration token that a specific application installation received when it registered. Google’s servers handle the message delivery details, pushing the data to the user’s device when it becomes available on the network. The shared messaging channel on the user’s Android device receives the message and sends out a broadcast. Your application implements a broadcast receiver, so it can wake up, receive the message, and inspect its contents. Your application can then take whatever action is necessary, such as contacting its application server for more information or to download additional content.
Understanding the Limitations of the C2DM Service
Because this is a free service and all applications on the device use the same service to communicate with the Google messaging servers, there are a number of limitations for using C2DM. Some of these limitations include the following:
• The C2DM service requires Android 2.2 or higher.
• The C2DM service is available only on Android devices that have the Google experience. The device must have the Android Market installed, and users must be signed in to their Google account. This means that devices such as the Amazon Kindle Fire cannot take advantage of such services and so developers must use other alternatives.
• The messages pushed to the device must be simple; they are not intended to deliver the data “payload” so much as to inform an application that it has new data available so that it can wake up and retrieve that data itself, using whatever means necessary. The size limit for messages at the time of this writing is 1024 bytes.
• As with many messaging services, messages are not absolutely guaranteed to be delivered. Your application should not be reliant on any one specific message to perform its core duties. You’re better off using the service for generic messages such as, “There’s new content for the app to download,” than for specifics such as, “Download new content called ABC.” Any specifics can be handled when your application wakes up and communicates with your application’s server directly.
• As with many messaging services, the C2DM service is not intended for time-critical situations. Messages are delivered in a timely manner, but there is no time limit. Therefore, it’s not appropriate for alarm apps and the like.
• Google has imposed certain message quotas for the C2DM service in order to ensure good quality service for all users. Quotas are tied to the developer’s sender account and apply to all applications tied to that account. There are global quotas (number of messages sent to all devices in total) and device quotas (number of messages sent to a specific device) for a given time period. The default global quota for a new account is 200,000 messages a day, which is reasonable for small to midsize applications. Developers whose applications become popular and require higher quotas can request quota increases. You can find out more about quotas on the C2DM website at http://code.google.com/android/c2dm/quotas.html.
• Of course, C2DM service requires the user to have a network-enabled device. The good news is that Google has created a robust push mechanism that stores your messages to be sent to the device and is fault tolerant enough to handle sporadic network connectivity frequently experienced with mobile devices. Still, your users may incur data charges for network activity, as normal.
These limitations are pretty reasonable for most small- and medium-sized applications that are published on the Android Market. Given how straightforward the implementation is, we see no reason not to use the C2DM service. If your application user base outgrows the service, that’s a great problem to have.
If your application cannot work within these limitations, you need to use an alternative method of communicating with your application. See the alternatives discussed at the end of this chapter for some options.
Signing Up for C2DM
To use Google’s C2DM service, you need to sign up for a sender account. This is the account you use for communication between your application server and the Google C2DM services, which send the message to the client Android device. You can sign up at http://code.google.com/android/c2dm/signup.html.
When you incorporate C2DM services into your Android applications, you are subject to additional terms of service, so make sure you read the fine print carefully to ensure your application complies with the rules.
When you sign up for a C2DM sender account, you need to agree to the terms of service. You are then asked to fill out a form that describes how you, the developer, plan to use the C2DM service, including information about your application and your contact information. This form is submitted for review by the Android Cloud to Device Messaging team.
This process used to take awhile, but the last time we ran through it, we received a response within 10 minutes.
Incorporating C2DM into Your Applications
After you have registered with Google and your application has been accepted, you will receive an email detailing your sender account privileges. It might take a day or two before you can send messages through the Google C2DM servers, but you can take this time to familiarize yourself with the documentation and sample code available at the C2DM Google Project website at http://code.google.com/android/c2dm/.
Integrating C2DM Services on the Android Client Side
The basic process for integrating C2DM into your Android application is as follows:
1. Your application requires several C2DM-specific permissions.
2. If C2DM messaging is required by your application, you will want to set the minimum SDK supported by your application to API Level 8.
3. Your application must register to receive C2DM messages from a specific sender identifier.
4. The registration on the client side results in an application identifier that must be delivered to the server and stored for future use.
5. Your application must implement a broadcast receiver.
6. Your application is responsible for retrieving any data payload that is spawned by a C2DM message arriving. The message itself needs to be simple.
7. Your application must unregister to stop receiving C2DM messages.
Integrating C2DM Services on the Android Application Server Side
The process sending notifications to Google’s C2DM servers is as follows:
1. Your application server must support HTTPS. Your application server should also be able to queue message requests and ideally, perform exponential back offs.
2. Your application server needs to maintain an authentication token and refresh it occasionally.
3. To send a message to the C2DM servers, your application server must create an HTTP POST message. This message must include information about the registration identifier, auth token, message data, and message delivery behavior details.
4. The application server should be able to handle numerous response codes (successful and erroneous) from the C2DM servers.
5. Your application must unregister to stop receiving C2DM messages.
For more information on how to configure your application server for C2DM messaging, see the C2DM documentation at http://code.google.com/android/c2dm/index.html#server.
Exploring the C2DM Sample Applications
Google provides two sample applications that help illustrate how to use C2DM. One is the popular Chrome to Phone application. The other is an application called JumpNote. Both are open source. Chrome to Phone is available for download on Android Market as is its companion extension for Chrome.
Chrome to Phone allows the user to use an extension on Chrome to send a URL down to a device that runs the Android application. It does so by sending a C2DM message. The source code for all aspects of the project can be downloaded and reviewed at http://code.google.com/p/chrometophone/.
JumpNote is a notepad style online app with an Android client. C2DM is used to provide notifications to automatically synchronize the notes between the two applications. It provides a good example of a multi-platform app using Android, Google Web Toolkit, and Google App Engine. The source code and compiled binary can be viewed and downloaded at http://code.google.com/p/jumpnote/. JumpNote is also a good example of syncing.
What Alternatives to C2DM Exist?
In some cases, the C2DM service may not be right for your application. Perhaps you are targeting devices that do not include the Google experience and do not have the Android Market installed, or your application requires more intensive message traffic than the C2DM service currently allows. In this case, you are perfectly welcome to implement your own messaging solutions. Some options include:
• Implement a simple server polling solution in a background service. This works well for infrequent messages or messages that aren’t time sensitive.
• Leverage a messaging protocol such as Extensible Messaging and Presence Protocol (XMPP).
• Check the app markets your application is published through. Some third-party app markets are now publishing their own push services for use by their subscribers. For example, Amazon provides notification services as part of their Amazon Web Services SDK for Android. These services can incur fees to the developer and the user.
Summary
There are numerous third-party APIs and services that can be used to create robust and interesting applications on the Android platform. One service that can greatly improve the experience your users have with their Android devices is the Cloud to Device Messaging push service available from Google. This service allows applications to share a messaging channel, making for better battery life and more responsive applications.
References and More Information
Google Code Project: “Android Cloud to Device Messaging Framework”:
http://code.google.com/android/c2dm/
Android developers blog: “Cloud to Device Messaging”:
http://android-developers.blogspot.com/2010/05/android-cloud-to-device-messaging.html
Amazon Web Services SDK for Android: