What are Push Notifications?
A notification is a message that pops up on the user’s device. Notifications can be triggered locally by an open application, or they can be “pushed” from the server to the user even when the app is not running. They allow your users to opt-in to timely updates and allow you to effectively re-engage users with customized content.
Push Notifications are assembled using two APIs: the Notifications API and the Push API. The Notifications API lets the app display system notifications to the user. The Push API allows a service worker to handle Push Messages from a server, even while the app is not active.
The Notification and Push API’s are built on top of the Service Worker API, which responds to push message events in the background and relays them to your application.
How Push Works?
The first step is to “subscribe” a user to push messaging.
Subscribing a user requires two things. First, getting permission from the user to send them push messages. Second, getting a PushSubscription from the browser.
A PushSubscription contains all the information we need to send a push message to that user. You can “kind of” think of this as an ID for that user’s device.
Before subscribing a user you’ll need to generate a set of “application server keys”, which we’ll cover later on.
The application server keys, also known as VAPID keys, are unique to your server. They allow a push service to know which application server subscribed a user and ensure that it’s the same server triggering the push messages to that user.
Once you’ve subscribed the user and have a PushSubscription, you’ll need to send the PushSubscription details to your backend / server. On your server, you’ll save this subscription to a database and use it to send a push message to that user.
How much secure is the transaction?
The data you send with a push message must be encrypted. The reason for this is that it prevents push services, who could be anyone, from being able to view the data sent with the push message. This is important given that it’s the browser who decides which push service to use, which could open the door to browsers using a push service that isn’t safe or secure.
When you want to send a push message to your users you need to make an API call to a push service. This API call would include what data to send, who to send the message to and any criteria about how to send the message. Normally this API call is done from your server.
Who and What is the Push Service?
A push service receives a network request, validates it and delivers a push message to the appropriate browser. If the browser is offline, the message is queued until the the browser comes online.
Each browser can use any push service they want, it’s something developers have no control over. This isn’t a problem because every push service expects the same API call. Meaning you don’t have to care who the push service is. You just need to make sure that your API call is valid.
To get the appropriate URL to trigger a push message (i.e. the URL for the push service) you just need to look at the endpoint value in a PushSubscription
How the Application Works?
Integrating GCM in your application enhances user experience and saves both battery power and data usage as the application no longer needs to poll the server. Google now also allows developers to set ‘topics’ to their apps in which users can choose the subjects they are interested in getting notified. i.e. Topic Messaging. This allows your app server to send messages to those devices which have subscribed to a particular topic. For example, users of sports app could opt for “score” updates and can receive the notifications of matches.
REG_ID or Registration token – When the client app registers with the GCM, it sends the reg token back to the client which is later on used to send the GCM message to the device. There is one difference when messaging to Apple devices. For iOS one needs to connect to an APNS server to get a token which is then used to get the GCM token.
MESSAGE_ID – When a message is received by the GCM, it sends a unique GCM message identifier in response message to the client server. When the message id is received by the server from GCM, it does not mean that the message was delivered to the device. It simply indicates that it was accepted by the GCM for delivery.