At Sencrop, we deep dived into push notifications mechanism on mobile devices, and we would like to share our findings with you!
What is a push notification?
When people talk about push notifications, it often refers to a message that is shown in the notification tray of a mobile device, like this one:
But push notification is a way bigger concept!
Some type definition first 😁
Push notification is a client-server communication mode in which the dialogue is initiated by the server.
This technique is therefore opposed to the “classic” functioning of web transactions where the customer opens a dialogue and pulls information towards him.
Push notifications are a great way to contact users because they are displayed very closely to them and they are hard to miss.
That is why they are much appreciated by product teams, in order to transmit transactional notifications (such as alerts, ...) but also by marketing teams (to promote commercial operations for example).
However, be careful to not betray the trust of users by sending them too many unwanted notifications.
Payload: Notification vs Data
There are 2 kinds of push notifications payload:
- Notification messages, sometimes thought of as display messages. These are handled automatically by the underlying SDK (FCM for example). They are easy-to-use because it self-contains everything to be able to show a message on the device.
- Data messages, which are handled by the client app. A specific logic must be written in the app, so they are less straight forward but it allows to do custom tasks (like fetching more data from a remote server, checking some conditions, triggering alerts, ...).
Technical notes:
- A message can have both fields (notification and data). In this case, a message will be displayed to the user, and the data payload will be transmitted (to be handled in background by the app).
- A notification message must use the predefined keys to be able to create a notification in the system tray of the user's device (like the title, body, the action when the user clicks on the notification, ...).
How does it works?
A push notification will go through multiple mechanisms before showing a message on the user's device (or triggering a background action).
A push notification is triggered from a trusted environnement (at Sencrop, directly from our server or from Intercom) that contacts Push Notifications Servers (Apple Push Notification server for iOS devices or Firebase Cloud Messaging server for Android devices).
We specify trusted environnement, because this server must provide the APN certificat or Firebase key to be able to contact push servers.
To be able to trigger a push notification, the server must first have a token that identified the user's device (or user's devices).
This token will be generated when the user has authorized push notifications on his device and after this will be sent to our server to be stored (in a database for example) for future use.
Technical notes:
- There are 2 types of token, APN (Apple - iOS) and FCM (Google - Android) tokens.
- Intercom directly contacts APN Server and FCM Server to send a push notification (so we must send the APN token to Intercom for iOS devices, and FCM token for Android devices)
- For our own server, we have decided to use Firebase only to send push notifications. This way Firebase contacts APN servers to send push notifications on iOS. We convert the APN token (generated on iOS devices) to a FCM token (thanks to the Firebase SDK) and this way we only have FCM tokens in our database and can contact FCM server only.
Authorization
Push notification authorization can be a bit tricky and is different on iOS and Android devices.
🤖 Android
On Android, the application declares the permission directly in its manifest (a configuration file), and the users will automatically authorize the application to push notifications when the application is installed from the store.
🍏 iOS
On iOS, the permission is not automatically delivered when the app is installed.
The application must trigger a pop-up, so users can decide if they authorizes or not the app to send push notification.
This pop-up must be triggered from code by calling a specific iOS API.
It can be:
- Directly on the application code (for example, when the user clicks on a button)
- With the help of third-party (for example from an Intercom carousel, that could help explaining why we need to authorize push notifications).
Technical notes:
- It is recommended to not show the authorization pop-up directly without explanation, at the application start for example. Because the user could decline it and it is hard to revert this decision (must be a manual action from the user in application settings) and your notifications will be just denied.
- Before iOS 12, the user could go to the settings of the application and manually authorize the application. After iOS 12, it is not possible anymore, and the user can only remove the authorization if already provided.
To sum up with an image:
Deep links
A deep link is a way to link directly to a specific location inside of a mobile app, rather than simply launching the app (or to do a specific action by the app).
Here are examples of deep links:
To be able to open the deep link, the application must register to the device that the application can handle those links.
This is done directly through configuration of the application (in the manifest.xml on Android and Universal link configuration on iOs, see links in further readings).
The app will be opened when the user clicks on the link (or if the link is in the click action of the notification), and the link will be transmitted to the app to be handled (so the app can parse the link and open the correct view, or do a specific action).
Http scheme and custom scheme
Registering the http(s) scheme, allows the application to open url usually destined to the browser. On mobile devices, it will show a pop-up to users asking if they want to open the browser or the app.
By using a custom scheme, like app://, the app will be directly opened because it is normally the only one which has registered this scheme with this package name.
Technical Notes:
- It is possible to open directly the app with a http scheme but it requires additional configuration: https://developer.android.com/training/app-links/verify-site-associations
Conclusion
You now know the basics to be able to trigger push notifications and show messages on your users’ devices. Let’s try it by yourself!
Top comments (0)