Whenever an MDM server (or any app server) wants to communicate with the client app installed on a device, the server sends a notification to the device. This notification is transferred over another server known as the push notification server.
A notification consists of two components:
- The device token (in APNS), device ID (in FCM) or Notification Channel URI (in WNS).
Device token is obtained from APNs after the device registers in the APNs. This token is included with payload so that when a notification is sent, then the token identifies the app in the required device to which notification is to be sent. Since the device token is included within the payload, device token takes up some of the notification payloads.
The device token in APNs is a 64-byte hex string, and the Device ID in FCM is a 183-byte string, containing [a-zA-Z0-9_\-] (all numbers, lowercase and uppercase alphabets, and symbols like \, _ and –).
Notification in FCM is sent as JSON payloads with parameters registration_ids, data, collapse_key, delay_while_id_, time_to_live and dry_run. APNs sends notifications as string or dictionary, containing alert, sound, badge, and token. The alert contains body, action-loc-key, loc-key, loc-args and launch-image. WNS sends the notification as string.
The maximum notification payload allowed through APNs is 4 KB in iOS 8 and above. It was only 256 bytes operating systems prior to iOS 8. Keep in mind that the notification payload is the sum of notification size and device token.
Through FCM, it is also possible to send messages apart from notifications. FCM describes two different payload sizes for different functions. The maximum notification payload size allowed is 2 KB which is lowest when comparing FCM with APNs and WNS. The maximum message payload size is 4 KB.
WNS is the one that allows highest notification payload among the three, and that is 5 KB.
Both APNs and WNS works in a similar way. The notification received by the client device says “Go talk to your server”. That is, when a notification is received by the client device, then the client device directly communicates with its server without the notification server in between.
FCM has two types of implementation at app server’s side – the HTTP and XMPP implementations. HTTP implementation works in a similar way to that of APNs and WNS, but the XMPP has a different aspect. When XMPP implementation is done, then the upstream messages (messages from the client to app server), as well as the downstream messages (messages from the app server), are handled by the push notification server. In this case, it can be said that there is an improvement in reliability of service because it is possible to send acknowledgments for a notification from the client device through FCM. It is also known that FCM will send ‘success’ or ‘failure’ on successful or unsuccessful deliveries, respectively.
Since push notifications are not reliable in APNs, it is recommended that the client app acknowledges the server manually in the retrieval of notification and this acknowledgment is to be sent directly to the server from the client device. But, there is a feedback server that is used to send the notification back to the server when a particular app (the app to which notification is to be sent) was not found on a device, probably due to the app being uninstalled before the notification was received by the device.
WNS send HTTP response codes on various events in it.
HTTP Response Codes
- 200 OK – Returns when WNS successfully authenticates notification from the app server.
- 400 Bad Request – Returns when headers are incorrectly specified or is conflicting with other headers.
- 401 Unauthorized – The app server presented an invalid authentication ticket to WNS.
- 403 Forbidden – Even if the app server is authenticated to WNS, they are not authorized to send messages to the notification channel URI.
- 404 Not Found – Notification channel URI is not identified by WNS or the URI isn’t valid.
- 405 Method Not Allowed – Only POST (for Windows and Windows Phone) and DELETE (for Windows Phone) are allowed.
- 406 Not Acceptable – High rate of transferring notifications.
- 410 Gone – Attempting to send notification through an expired notification channel URI.
- 413 Request Entity Too Large – Notification payload size larger than 5 KB.
- 500 Internal Server Error – Delivery of notification failed due to an internal server error.
- 503 Service Unavailable – Server is unavailable.
Storage of notifications
What if when there is no network connectivity on a device when the app server sends a notification? Well, in that case, the push notification server stores the notification for a limited period of time and tries to send the notification repeatedly after a certain period of time until the device is available to receive push notifications. Different push notification servers have their own rules for storing notifications in such cases.
The APNs stores only one notification per app. If a second notification to the same app arrives, then the first notification is replaced by the second. The notifications are deleted if the device remains offline for 28 days.
FCM does not store notifications on a ‘per app’ perspective. Instead, it stores 100 notifications per device. Like in APNs, the notifications are stored for a maximum time period of 28 days.
WNS stores both tile notifications and badge notifications. Tile and badge notifications look similar but are actually different. A badge notification is a number from 1 to 99 and is displayed on the tile; either on the app icon or at the corner of the tile. Tile notifications are those which modifies the tiles itself or appears as a part of the tile (appear to be the app icon itself).
If queuing is enabled, then WNS can store up to five tile notifications and one badge notification per communication channel when the device is offline. Otherwise, WNS stores only one tile notification and one badge notification per channel. Communication channels are opened per app when notifications are to be sent to client devices, so ‘per communication channel’ means per app. These notifications are deleted when the device remains offline for 30 days. Even if the device receives and displays notifications, and the users do not interfere with them within three days, the notifications are no longer displayed.
Support for multiple platforms
APNs and WNS do not support multiple platforms. They are designed to work with their native platforms. But, FCM supports multiple platforms such as Android and iOS and even supports Chrome web apps.
APNs use four TCP ports, which are:
443 : Used for communicating with APNs when communication using port 5223 is not possible.
2195 : Used to send the notification to APNs.
2196 : Used for APNs feedback.
5223 : Used for communicating with APNs.
Ports 5228, 5229 and 5230 are to be used in Firebase Cloud Messaging. Google uses any of these three ports (different ports at different times). TCP port 443 should be open in the case of Windows Notification Service.
Comparison – Google Cloud Messaging (GCM) and Firebase Cloud Messaging (FCM)
GCM is the older version of FCM. Google recommends migrating to FCM, as new features will not be added to GCM. Google currently supports the latest version of GCM SDKs as migration takes time.
- The maximum number of subscribers supported by GCM was 1 million. FCM takes off this restriction, so there can be more than a million subscribers.
- SDKs are changed, so there is less need for coding. Coding for subscription and error handling are not required any more.
- Permissions were to be specified inside Android Manifest file in GCM, but in FCM, all required permissions are added automatically.
- FCM introduced C++ programming in addition to the Swift programming in GCM.
- GCM supported Android, iOS, and Chrome, and FCM will continue supporting them.
Comparison – Microsoft Push Notification (MPNS) and Windows Notification Service (WNS)
- MPNS provided native support for Windows Phone 8 and Windows Phone 8.1, and MPNS was replaced later with WNS. MPNS can also be used, but only when:
- The device was already registered with MPNS,
- Windows app is converted to Microsoft Silverlight app, and
- MPNS target Silverlight platform.