Understanding Push Notifications

Push Notifications can be a valuable feature for mobile applications to support. Even if the mobile application is not running, Push Notifications can send a short message to the user that some type of data is available for a mobile application.  In order to implement Push Notifications in your applications, you need to understand the components involved and the mechanics of how Push Notifications work.
The major components involved in push notifications are described the table below.
Component
Location
Notes
Mobile App
Mobile device
Mobile applications integrate push notifications into their feature set.
Notifications Manager
Mobile device
This is the device's operating system module or component(s) that facilitate and manage push notifications, across all applications on the device.
Provider
App server
This is your application's back-end server(s) that generate push notifications for a mobile app.
Push Notification Service
Vendor servers
Push Notification Service such as APNs, GCM, or MPNS


Push Notification Services

Push Notifications are sent by your application servers to a cloud-based, vendor-specific Push Notification Service, which then forwards it to devices on that platform. 
All of the major players in mobile have their own Push Notification Services that drive notifications for their platform.  Well-known services include:


Setting up the Provider

The term "Provider" in the Push Notification architecture can be confusing.  The Provider is actually part of your application; it is the business logic code that generates notifications related to your application. Providers are typically implemented in the application servers of your solution. Providers are set up with digital certificates that enables them to generate notifications and send them over a secure channel to the Push Notification Service.  

For Apple's Push Notification Service, the process is as follows:


Connectivity between the Device and the Push Notification Service

A common question about to Push Notifications is how the Push Notification Service is able to locate the device, given that network connectivity of the device is constantly changing as the user moves around. Through the device-side notifications manager (for example, iOS Notification Service), each device establishes an accredited and encrypted IP connection with the Push Notification Service and receives notifications over this persistent connection.  This connection is maintained by the notifications system on the device as connectivity changes.

For Apple Push Notifications, the system uses TLS peer-to-peer authentication as follows:

  1.  The devices initiates a TLS connection with Apple Notification Services.
  2. Apple Notification Services returns its server certificate to the device.
  3. The device validates the server certificate and sends its device certificate to Apple Notification Services.
  4. Apple Notification Services validates the device certificate then the TLS connection is established.


Each installed (and registered) application on the device has a specific token/ID that enables the notification service to uniquely identify it.  For APNs, obtaining the device token occurs as follows:

  1. The application on the device registers to receive notifications.  The application should always ask for a device token by registering with the push service each time it is launched.  The system receives the registration request from the application, connects with APNs and forwards the request.
  2. APNs generates a device token using information contained in the unique device certificate.  This also contains an identifier of the device.  APNs encrypts the device token and returns it to the device.
  3. The device then returns the device token to the requesting application.
  4. The application delivers the generated device token to its provider.



Prior to iOS 7, the device token is the same for all installed applications.  Starting with iOS 7, the device token is different for every installed application on the device.

The ID issued by Google Cloud Messaging for Android (GCM) is called a Registration ID.  For versions lower than Android 4.0.4, the mobile device must include at least one Google account.


Notification Contents

The notification is a short message consisting of two pieces of data (1) the device token and (2) and the payload.  As described above, the device token contains information to locate the device on which the application is installed.  The payload is a JSON-defined property list that specifies how the user of an application on a device is to be alerted.
Below is an example of a notification payload:
{
“aps” : {
            “alert” : {
                  “body” : ”This is the alert to be displayed to the user.”,
                  “action-loc-key” : ”PLAY”
            }
      “badge”:5,
“sound”:”bingbong.aiff”
},
“custom1” : “custom 1 data”,
“custom2” : “custom 2 data”
}


Provider Implementation

Every time the Provider sends a notification to APNs for delivery to a device, it needs to send the device token it got from the application.  APNs decrypts and verifies the device token then sends the notification to the device.

The APNs Feedback Service gives the Provider information about undelivered notifications. As previously mentioned, the Provider should regularly check the Feedback Service to get the list of devices that always have failed delivery attempts and stop sending notifications to these devices.

Labels: , ,