Introduction

A push notification is a message received and displayed on a mobile device that is linked to a particular application installed on this device. When used thoroughly, it helps by increasing user engagement and improving retention rate. There is however a word of caution, when misused (e.g., high sending rate, no customization), it can damage the user experience and foster customer turnovers. You wouldn't want to spam your users 😅.

Be aware that there are two types of push notifications :

• Remote push notifications are triggered by an external service and go through the network.
  
• Local push notifications are scheduled locally by your app and passed to the operating system. With local push notifications, you do not need to configure remote services.

In this article, we will have a look at the steps you will have to go through to implement remote push notifications. At the end of it, you will have a good understanding of how a system sending push notifications is designed. However, you will find no code in this article.I'll submit in the following weeks a second article where we will deep dive into how to implement push notification with a nodeJS server and a react-native application following the steps described below.

Know the actors

First of all, we need to understand which are the actors that intervene to send a remote notification to a device.

• A notification is associated with a given application.
• This application is installed and run on multiple user devices.
• A push notification service (PNS) is a highly secure and efficient service that propagates notifications to one or multiple user devices. We use APNs (Apple push notification service) on iOS and FCM (Firebase cloud messaging) for android.
• A provider server is responsible to build the notification and ask the PNS to propagate it to a specific list of devices. It is most of the time the server on which a part of your business logic lives.

Let the journey begin

1. Register your app to the PNS

The PNS has to know how to target your user device when it is asked to send a notification. To do so, the PNS needs a token that uniquely identifies the association of a user device and your app. To retrieve this token, you have to register your app to the PNS (1) by using the provided API of your PNS.

• On iOS, you should call `registerForRemoteNotifications()` method of `UIApplication`.
• On Android, it is done automatically by the FCM SDK.
• If you are building your app using react-native ?, some libraries implement most of the logic for you. (e.g., react-native-push-notifications, react-native-notifications)

?? It is important to register your app at each app start because the value of the token can change for multiple reasons: OS version upgrade, device restoration, other system-defined events...

As a result of this call, you will retrieve the token.

2. Associate the token to a user on your provider server

A token can be renewed periodically. At a given time, only one PNS handle is valid for a given device and app. So your provider server should keep track of each user, their list of devices (uniquely identified by a deviceID), and the current token associated with each device. You should also keep track of the OS of a given device as it will affect the PNS your provider server will have to call. Once you retrieved the token from the PNS in your app, you can send (3) a POST request to your provider server with all the necessary information:

• PNS Token
• User device ID
• User device OS
• User ID

3. Trigger a new notification propagation from your provider server

When a new business event occurs, such as the publication of a new article if you work on a newspaper app, you want to inform the users of your app about it. This is where your provider server comes into play.

The first thing to do is to build a JSON payload according to the specification of the PNS you want to target. This payload specifies how the notification should behave once received by the device. A notification is highly customizable, you can configure:

• the title
• the subtitle
• the content
• the type of sound
• the number to display in the badge of the app icon
• the importance of the notification
• custom business data that can be used later by the app (such as the article's id to open once the user clicked on the notification)
• and more...

Once this JSON payload is built, you will have to send it to the PNS. As a prerequisite, your provider server needs to establish a secured connection to each PNS it depends on to propagate notifications (in our case FCM and APNs).

• (1) Your provider server gathers the list of all the devices, their OS, and their currently active PNS handles. Then it separates the tokens depending on their associated OS, builds the notification payload to send according to the specification of each PNS, and then sends a request to all the PNS.
• (2) The PNS then propagates the received notification to every device associated with the tokens it received.
• (3) The PNS wait for receipt confirmation.
• (4) The PNS sends the response to the provider server indicating the success or the error. An error can occur for multiple reasons:
  - The PNS handle is no longer valid
  - The payload of the request is too large
  - The service is unavailable
  - see APNs documentation or FCM error code reference for more details

In a nodeJS based environment, you can use PNS SDKs to communicate with the PNS (see firebase-admin-node and node-apn for more details).

4. Customize your app behavior when the user clicks on a notification

Once your user clicks on the notification, it will open your app. You may want to customize the behavior of your app given the type of notification. For example, when you receive a push notification about a new email reception, when you press it you expect your mailing app to open and navigate to the details page of the email.

Fun fact, how a push notification is displayed depends both on the application state and on the OS. This table may help you understand how it works.

++table border="1" cellpadding="4" style="width: 100%; border-color: #99acc2; border-style: solid; border-collapse: collapse; table-layout: fixed; height: 134px;">++tbody>++tr style="height: 33px;">++td style="width: 33.3333%; height: 33px;">Application State++/td>++td style="width: 33.3333%; height: 33px;">iOS++/td>++td style="width: 33.3333%; height: 33px;">Android++/td>++/tr>++tr style="height: 33px;">++td style="width: 33.3333%; height: 33px;">Not running++/td>++td style="width: 33.3333%; height: 33px;">Notification displayed on the screen.++/td>++td style="width: 33.3333%; height: 33px;">The notification is displayed in the notification drawer and as a badge on the launcher icon. Moreover, depending on the importance of the notification, a notification can make a sound and appears as a heads-up notification (See notification importance for more details).++/td>++/tr>++tr style="height: 33px;">++td style="width: 33.3333%; height: 33px;">Background++/td>++td style="width: 33.3333%; height: 33px;">Notification displayed on the screen.++/td>++td style="width: 33.3333%; height: 33px;">Same as above.++/td>++/tr>++tr style="height: 35px;">++td style="width: 33.3333%; height: 35px;">Foreground++/td>++td style="width: 33.3333%; height: 35px;">By default, iOS will not display notifications when the app is in the foreground. However, you can configure your app to override this behavior.++/td>++td style="width: 33.3333%; height: 35px;">Same as above.++/td>++/tr>++/tbody>++/table>

Push notification SaaS

In the previous section, we had an overview of the communication flow that happens between all the actors of the system. The more observant people will have noticed that the communication between our provider server and the PNS may become the danger zone of our system. We always need to have scalability in mind as the more we have users and notifications to send, the more we will have to request the different PNS. Hopefully, a lot of services are available out there to handle that for us (e.g., Batch, Azure hub notification, OneSignal). They all have their features, but basically, they will help us to:

• handle multiple platforms and their associated PNS (e.g., iOS, Android, Windows Phone, web).
  No more multiple calls to each of your PNS, you can now communicate directly to your SaaS and it will take care of the communication to the PNS.
  

• manage push notification analytics that will be accessible on a web dashboard
• create segments of users to customize our notification delivery
• support multiple types of mobile messaging:
• Mobile Push Notifications
• Web Push Notifications
• In-App Messaging

Conclusion

I hope this article helped you better understand how push notifications work. It has been a black box to me for a long time! If you want to know how to set up a node server to send push notifications to a react-native app running on an iPhone, stay tuned for the publication of the second article of my series on push notifications  ?