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:
- Apple Push Notification Service (APNs)
- Google Cloud Messaging for Android (GCM)
- Microsoft Push Notification Service (MPNS)
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:
- Obtain an iOS Developer Account.
- Register an App ID and get a provisioning profile.
- Communicate with APNs over a binary interface through:
- Production: gateway.push.apple.com:2195
- Development: gateway.sandbox.push.apple.com:2195
- Establish a secure communications channel with APNs using an SSL certificate provisioned through iOS Provisioning Portal
- Compose the Push notification.
- Regularly check the APNs Feedback Service to get the list of devices that always have failed delivery attempts and stop sending notifications to these devices.
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:
- The devices initiates a TLS connection with Apple Notification Services.
- Apple Notification Services returns its server certificate to the device.
- The device validates the server certificate and sends its device certificate to Apple Notification Services.
- 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:
- 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.
- 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.
- The device then returns the device token to the requesting application.
- 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: APNs, Mobile, Push Notification