SOFTWARE ARCHITECTURES Chapter 4 – Push Notification Services: Google and Apple Zachary Cleaver Summary The goal of this paper is to define the structure of push notification systems (PNS), and specifically to analyze the architecture of Android’s PNS’s versus Apple’s as well as to analyze the advantages and limitations of each PNS. I first discuss the basics of a push notification system, looking at how it typically works and highlighting some key features. The next three sections cover Google’s Cloud to Device Messaging system, Google’s Cloud Messaging system, and Apple’s push system. Each section will give an overview of the systems prerequisites, discuss some advantages and disadvantages about its method for sending data, and finally will cover its architectural structure. Push Notification Systems General Structure Push notification systems are similar in design to client-server models. The basic structure of a push notification system is broken down into three parts: an application that will receive data/instructions, a third party service that will provide instructions or information for the app, and a service (Google Cloud Servers, Apple Push Notification Service, etc.) that handles the exchange of information between the two (see Figure 1). Figure 1. High level architectural view. (Provided by Basavraj) History Middleware is software above the level of the operating system but that provides reusable infrastructure services that many applications can share. Notifications systems are a kind of middleware. One of the earliest Notification system specifications was specified by Object Management Group in the early 1990s. 1 SOFTWARE ARCHITECTURES Advantage The server that sends information to the application from the third party server acts as a middleman to communicate and control the rate at which data is exchanged. This allows for information to be “pushed” to a device without having to stress the device by keeping multiple applications running at once. Applications can remain off or idle on a device while the user receives a notification that new information or updates are available for a specific application. This greatly increases run time efficiency on a device by allowing the user to be in control of what apps are running while still being able to receive information from the third party servers. Google’s Cloud to Device Messaging Prerequisites In order for an Android device to receive messages from an application server, there are some basic requirements that must first be met when using the C2DM service (Basavraj) The device must be version 2.2 or higher A registered Google account must be present on the device The server that wishes to send data must be able to “talk” HTTP and connect to the C2DM server The application should have the proper permissions the receive messages from the C2DM service and be able to make an internet connection The developer of the application must register through the C2DM site to use the service Data Sent The amount of data that could be sent by Google’s first notification system was limited to 1024 bytes. Google also restricted the number of continuous messages that could be sent, as well as the number of messages a server can send to a specific device. The maximum number of messages a service could send was 200,000 per day. A drawback of C2DM is that it does not guarantee the delivery of a message to the application and it does not guarantee that the order of multiple messages will be maintained (Basavraj). Bourdeaux elaborates on this and believes in is due to the “file-and-forget” nature of Google’s service. Because of this, developers would be wary to send a notification that their app has a new message rather than sending the message itself. However, Bourdeaux pointed out an improvement at the time versus Apple’s push notification—C2DM allowed the application to be woken up rather than taking Apple’s method of simply sending a notification. This may seem like a minor feature compared to today’s services, but this development helped improve the capabilities and standards for future push notification systems. Main Sequence of Events There are five basic steps that C2DM follows according to Google’s documentation: 1. The third party service sends a message to the C2DM servers that it wishes to pass on to its application 2. The Google servers enqueues and stores the message in its database until it can be delivered if the device is currently offline 2 SOFTWARE ARCHITECTURES 3. The Google servers then pass along the third party service’s message once the recipient device comes online 4. The Android device’s system then broadcasts the message sent from the C2DM servers to the application via Intent broadcast1, checking for the proper permissions so that only the intended target application receives the message. This step “wakes up” the application, meaning the application does not need to be running in order to receive a message. 5. Finally, the application processes the message. C2DM does not specify how the message should be processed; rather, this decision is left to the third party service. This gives the application full freedom as to how the message should be processed, whether it is posting a notification, updating/synchronizing data in the background, or even displaying a custom user interface. Architecture This section looks in detail at the structure of how the C2DM service works with the application and the third party service. There are three primary steps in this structure: setting up a connection with and enabling C2DM, sending a message, and receiving a message. Figure 2 illustrates a more in-depth look at C2DM’s architecture that expands on Figure 1. 1 Intent broadcasting is Android’s method for sending and receiving information between application states within a single app or between multiple applications. Intent broadcast uses key-value pairs to pass along information, essentially acting as a local communication system on the device. See http://developer.android.com/guide/ for more information. 3 SOFTWARE ARCHITECTURES Figure 2. Lower level architectural view. (Provided by Basavraj) C2DM Registration A third party service that wishes to use C2DM servers must first signup using a unique package name or app ID to define their application, as well as an email address that is responsible for this application. This is a relatively quick process for an application, and is only required once per application. The next step is registration. A registration intent is fired off from the application to the C2DM server upon its first use. This intent (com.google.android.c2dm.intent.REGISTER) contains information like the aforementioned app ID and email that the C2DM server will use to register the application. Upon a successful registration, the C2DM server broadcasts a registration intent that supplies that application with its own registration ID. The application must then send its registration ID to the third party service, which is then stored in the service’s database. This ID will be used to facilitate communication between the application and its service; the ID lasts until the application unregisters itself if it wishes to stop receiving messages from the C2DM server (in which case a notification will be returned to the application to alert the user of this event) or if Google refreshes the ID registration for the application. Sending a Message For a third party service to send a message, it must first have a ClientLogin authorization token. This token “authorizes the application server to send messages to a particular Android application” (see Google documentation). While an application may have multiple registration IDs for each device/user that connects to the servers, only one authorization token is required for the app. The third party server then sends an HTTP Post request to Google’s servers, passing along the registration ID and the authorization token. There are a few more credentials that are passed along in the request: the payload data, a collapse key, and an optional parameter called delay_while_idle. The payload is a key-value pair that contains the message(s) being passed to the application. There is no limit to the number of key-value pairs that are allowed; however, there is a limit to message size (1024 bytes). The collapse key is a string that aggregates or collapses similar messages into a group that collect in the server if the target device is offline at the time the message was sent. This prevents too many messages from being sent to the device once it comes online by only sending the last message—it should be noted that the order of messages is not guaranteed, so the last message sent to the application may not be the last one that was stored in the queue. The delay_while_idle does exactly what its namesake implies—this tells the service whether to delay sending a message to the target device if the device is idle at the time. Once the device becomes active, the last message from each collapse key will then be sent. 4 SOFTWARE ARCHITECTURES The C2DM service then verifies the credentials of the request through its authentication service, queues the message for delivery, sends the message to the target device, and finally removes the message from its queue after a successful delivery. Receiving a Message Once the message has been received, the device’s system then extracts the key-value pairs from the payload and passes this data on to the application by broadcasting a receive intent. Finally, the data from each key is extracted by the application and processed. Since C2DM merely facilitates the exchange of information between an application and its server and does not worry about how to display the messages, personalization of display is left up to the discretion of the application.