Push it harder (Part 1)
Recently, during a technical interview, I was asked about push notifications. I was expected to talk about the developer's steps to set up and handle push notifications in the app, like registering a device, subscribing to a particular topic, getting and storing a token, receiving messages. So I wanted to refresh my memory and make a small overview of this feature.
There are services like Firebase cloud messaging (FCM), OneSignal, Amazon SNS, Pusher, and others that come into play when you need to enable push notifications. I will focus on FCM as it is a very popular cross-platform messaging solution developed by Google, and, also, it is the only service I have experience with) The information bellow is a condensed form of the FCM docs.
Key capabilities
- Sending up to 4000 Kb of payload in one message
- Sending notification or data messages
- Three different ways of targetting: to single devices, to groups of devices, or devices subscribed to topics
- Analytics
- Supports Android, iOS, web
Architectural overview
There are four components in the chain of building, delivering and receiving messages (picture 1 in comments):
The notification request builder.
1. It can be a GUI-based notification composer in the Firebase console, Admin SDK or the FCM server protocols used in the trusted environment*
2. FCM backend - accepts requests, performs fanout of messages via topics, and generates message metadata, like message id.
3. Platform-level transport layer - routes the message to the targeted device and handles its delivery.
- Android transport layer (ATL) for Android
- Apple Push Notification service (APNs) for Apple devices.
4. SDK on a device.
Lifecycle flow
1. An instance of the client app registers to receive messages, obtaining a FCM token that uniquely identifies the app instance. Several additional steps are needed to register Apple devices in FCM:
1) First of all, you should get the APNs device token.
2) Register it in FCM.
3) Get FCM device token which is associated with APNs device token. So when you need to send a notification, FCM searches for the corresponding APN's device token and sends a message request to APNs. (picture 2 in comments)
2. You'd probably want to send this FCM token to your server and store it on the device.
3. Your backend decides that a certain device should get a push notification, so it takes its FCM token, composes a message, and sends this request to FCM.
4. FCM backend gets this request, generates metadata, and sends it to the platform-specific transport layer.
5. When the device is online, the message is sent to the device.
6. You're able to react to the notification in your client app by overriding certain methods (onMessage, onBackgroundMessage). App behavior when receiving messages depends on whether the app is in the background or the foreground.
7. When a user logs out, you probably want to unsubscribe him from notifications. Login -> Subscribe.
8. You'd better update your token every once in a while, so you know that the device is still active and you aren't wasting resources by sending messages to inactive users.
*Firebase cloud functions or app server
Post #49
344
- 👍 3