Android C2DM: Part 2 (Lifecycle)

In Part 1 of this blog series we have seen C2DM overview. Today in this blog we will explore C2DM in details. We will see C2DM architecture and C2DM workflow.

C2DM Architecture

Below diagram explains high level C2DM architecture

Components
Three parties are involved in this C2DM architecture 

• Mobile device running C2DM based Android app

• Third Party app server will send push message to device through C2DM server

• C2DM server receives messages from third party app server and sends to mobile device/app

Credentials
Different credentials passed between these parties while transferring C2DM message to authenticate involved parties and make secured data transfer between them. These credentials explained below

• Sender ID/Email used in C2DM signup process and is associated with application’s developer

• Application ID (package name) ensures messages are delivered to correct application

• Registration ID issued by C2DM server is uniquely represents app running on specific device

• Google User Account for at least one logged in user on device

• Auth token required to get authorized access to Google services like C2DM

C2DM Workflow

Above diagram shows C2DM workflow in detail starting from C2DM registration to actual message delivery. These workflow steps grouped into three processes/categories as given below

• C2DM setup

• Sending message

• Receiving message

Below sections gives more details about these three processes

C2DM Setup

• C2DM signup - App developer has to sign up for C2DM service before implementing C2DM in his app. In signup process, he has to provide his app ID (package name) and Role Account Email ID. Generally, white listing of your account and getting developer quota is very quick. This is one time process for each application.

• C2DM registration - Android app registers itself for C2DM service by firing registration intent (com.google.android.c2dm.intent.REGISTER). App includes additional parameters in this intent like sender (Email ID used in C2DM signup process) and app (package name).

• Get Registration ID - Android app has to register broadcast receiver for registration intent (com.google.android.c2dm.intent.REGISTRATION). Google will send this intent upon successful registration.

• Send registration ID to third Party App Server - Application has to send registration ID received from C2DM server to third party App server. We recommend sending device ID along with registration ID so that third party app server can update it into its database against device.

• Storing registration ID - Third party app server stores or updates registration ID received from Android app in a database. App server uses this ID for sending message to Android apps.

• Unregistering C2DM - When Android app does not want to receive C2DM message any more then it can do by calling unregister intent. In response C2DM server will send response which app can use to notify user about un-registration.

Sending message

• Get Authentication Token - App server can get the authentication token by providing sender ID (Email ID) and password to Google’s client login service. You can get this token via any http tools or command line tools like curl. However, we recommend you to get the authentication token programmatically because over a time this might be changed.

• App server initiates message sending - App server makes post request to Google’s C2DM server. This request includes auth token and registration ID. This request also contains payload data (key-value pairs) and collapse key (used to collapse group of like messages when device is offline). If C2DM server receives optional parameter delay_while_idle from app server in above request, it will not send message immediately if device is in idle.

• C2DM server validates credentials - C2DM server will validate credentials received from app server by sending those details to Google authentication service.

• Queue the message - Once credentials validated C2DM server queues the message.

• Initiate message delivery - C2DM server initiates message delivery by sending request to C2DM messaging server.

• Message Delivery - If targeted device (decided based on registration ID) is online then C2DM messaging server delivers message to it. After successful delivery, messaging server removes it from message queue.

Receiving message

• Receive message - Android device running registered app receives message from C2DM server. Android system extracts key/value pairs from message payload. It then broadcasts the receive intent (com.google.android.c2dm.intent.RECEIVE) with extra parameters.

• Process message - Application’s broadcast receiver receives intent along with additional information like account name and message. Application processes this data for further usage.

In Part 3 of this blog series we will see error handling, comparison with other push technologies and list of demo applications.

Update : Google has deprecated C2DM and replaced it with GCM. Please read more about GCM here.

Android C2DM: Part 1 (Overview)

Today we will be exploring Google’s own cloud based push technology called C2DM (Cloud to Device Messaging) available for Android platform. C2DM helps third party Android app developers to receive push notifications sent by their application server.

Before getting into C2DM details let’s see why push is required.

Why Push is required?

Most mobile solutions have client-server architecture where mobile apps frequently need to download updated data from server. In some situations server need to push some short messages to mobile client like notification regarding new app update or event. For these kinds of features, we can use polling or push mechanism.

In polling mechanism, mobile app pings server periodically and checks if any new data is available for download. Polling is easy to implement and works well in most of the situations but tricky part is selecting the frequency for polling. Polling rarely can make data on device stale and polling frequently can create stress on server and network. This approach is not suitable for mobile devices as it uses precious network bandwidth more and so battery consumption will be more.

Other alternative is push mechanism for which we can follow two different implementation approaches. First approach is using proper push bearer, a network mechanism that can deliver unsolicited messages to devices. SMS and Blackberry’s proprietary push solution are the examples of push bearer. Second implementation approach is to simulate this technology by opening TCP connection to the push server. As we know TCP streams are full duplex (having pair of byte streams, one following each direction), server can push data to device anytime provided stream is active.

Most Smartphone platforms like iOS, Blackberry, Windows Mobile have their own push technology. Android OS was exception till its Froyo release as Android’s framework does not has support for push technology and app developers have to use open source alternatives like MQTT, Urban Airship and Deacon. With Froyo release, Android received support for Google’s own cloud based push technology known as C2DM.

C2DM Overview

C2DM is a solution to send real time notifications to user on his Android handset and most Google Services (Gmail, Market, Maps etc.) supports it. C2DM server/service takes care of all aspects of queuing and delivery of messages to target devices running developer’s target apps. C2DM also acts as an intermediary between developer’s App server and Android device.
Before moving into implementation details, we will see prerequisites for C2DM implementations, advantages and limitations of C2DM service and some guidelines for C2DM implementation.

Prerequisites

• Android 2.2+ Device or Emulator
• At least one logged in Google user on device/emulator
• Application server which can talk HTTP and connect to C2DM server
• Android application should have permissions to receive C2DM message and to make internet connection
• Developer must register on C2DM site to use C2DM for his application and to get developer quota for C2DM messages.

Advantages

• Application need not be running in background to receive push messages as those gets delivered to your app (Intent Receiver) by system using Intent broadcast.
• It does not create additional burden on network as it uses existing connection to Google services.
• Data delivery to device will always secured as device to C2DM server connection supports SSL.
• Broken connections will be re-established using heartbeat implementation.
• C2DM framework does not provide any built-in user interface to display the received push message content. C2DM framework provides full freedom to application so that it will have full control over the received raw message content. For example, the application might post a notification, display a custom user interface, or silently synchronize data.

Limitations

• Push message size limit is 1K (1024 bytes)
• C2DM framework doesn’t give guarantee about delivery or order of push messages
• C2DM sender account will have daily limit on total number of messages sent as well as messages sent per device. Currently total limit is 200,000 messages per day.

Guidelines

• When Google service is down your application will get HTTP error code 503 along with retry value. Your app should respect these kinds of errors and it should have advanced error-handling mechanism in place.
• Your solution should have its own queue mechanism in place, which will be useful when Google C2DM service returns over quota error.
• Application server should not send large data; instead, it has to send ‘tickles’ to your application telling it to download latest data from server.
• Avoid using ‘Role Account Email ID’ on device

Part 2 of this blog will cover C2DM architecture and life-cycle in details.

Update : Google has deprecated C2DM and replaced it with GCM. Please read more about GCM here.

Great Journey of Android: Part 2

In first part of this blog we have looked at all major releases, events happened till Android 2.2 Froyo release. In this part we will see what are major releases, events and milestone happened starting from gingerbread release to till the end of 2011.

December 6, 2010

Android 2.3 (Gingerbread)

• Supports new ways of communications like NFC (Near Field Communication) and SIP-based VoIP
• Support for new sensor types like Gyroscope, barometer etc.
• Adds support for rich multimedia features like multiple cameras, mixable audio effects
• Powerful Dalvik VM with optimized JIT, improved code verification and concurrent garbage collector
• Updated Media framework with AAC and AMR-WB encoding, integrated support for VP8 and WebM formats

February 9, 2011

Android 2.3.3 (Gingerbread)

• Read/write access to different types of tags like NFC-A/B/F/V, MIFARE Classic/Ultra light and NFC Forum NDEF tags
• Apps can decode rectangular region of a image
• Minor update 2.3.4 released in May 2011 includes optional Open Accessory Library as part of Google APIs Add-On

February 22, 2011

Android 3.0 (Honeycomb)

• First tablet only Android release with optimized UI designs
• New UI components like fragments, Action bar, app widgets and status bar notifications
• Support added for multi-core processor architecture
• Redesigned keyboard, improved copy/paste and visual multitasking
• Improved 2D graphics with hardware acceleration
• Improved clipboard APIs can be used to copy/paste plain text, a URI or and Intent.
• Enhancements for enterprise by supporting new types of policies like Encrypted Storage, Password Expiration and Password History
• Rich multimedia and connectivity options like HTTP Live streaming and Pluggable DRM framework

May 10, 2011

Android 3.1 (Honeycomb)

• Newly introduced MTP/PTP APIs can be used to interact directly with connected cameras and other PTP devices
• Support for different types of input sources like mice, joystick and gamepads
• New UI improvements like resizable widgets, expandable recent app list etc.

July 15, 2011

Android 3.2 (Honeycomb)

• New features for user like media syncing from SD card, view fixed size apps in compatibility zoom mode
• Developers can use new resource qualifiers to support wide range of screen sizes

October 18, 2011

Android 4.0 (Ice Cream Sandwich)

• Unified framework for tablets, phones and more
• Includes new typeface ‘Roboto’ optimized for high-resolutions with improved readability
• You can unlock your device with your face using newly introduced facial recognition technology
• Wi-Fi Direct feature allows you to connect to nearby Wi-Fi enabled device and share files
• Lock screen provides different options for launching camera, checking received messages and managing music tracks while listening music
• User can take screenshot and share it through gallery
• In-built support for Bluetooth HDP (Health Device Profile)
• Adds new controls to manage network data usage overall as well as application wise

December 6, 2011

10 Billion Downloads

• Android crosses 10 billion downloads on Android Market
• Photobucket Mobile app was the lucky 10 billionth download
• Exponential growth as it just took about 9 months to reach this milestone from 3 billion in march
• Android celebrates this milestone with 10-cent apps on Android Market for 10 days

December 16, 2011

Android 4.0.3 (Ice Cream Sandwich)

• Improvements in graphics, database, Bluetooth, spell checker and more
• Improved camera features like checking and managing video stabilization
• Accessibility refinements through improved content access for screen readers and new status/error reporting for TTS engines
• Calendar enhancements like color for events, new attendee types and states

I hope you have enjoyed reading these blogs and got enough information regarding Android’s Great Journey which is going to continue this year also. I hope in 2012 we will see more powerful Android tablets, smart phones and other devices.

First part of this blog can be read here.