Push Notifications & Your Business Logic: What Firebase doesn’t tell you

by Lavinia Bertuzzi, iOS developer at OverApp (https://www.overapp.com)

Abstract

Firebase Cloud Messasing is an extremely powerful and simple to use product by Google for sending messages and notifications. It is part of a huge growing ecosystem of integrated tools that is called Firebase. It offers a powerful console, a ready-made integration with a host of other tools such as A/B Testing and Predictions.

It does not offer specific features for the management of users who share the same device and log in and log out of it and for those who at the same time want to receive their own notifications and decide what types of content to receive through them. The developer must therefore think about his own solution.

The focus of our article

We leave all the details related to the Firebase setup on the various platforms to the numerous tutorials available on the net. Instead, we want to discuss the solution we have adopted for a product that we have developed and that uses FCM. This forced us to deal with some problems in particular: deal with multiple users who can utilize the same device or may have different settings on different devices and who could receive different types of notifications.

Firebase does not provide specific features to deal with this scenario and you may find useful to read something regarding the solution we adopted.

Our product uses a custom back-end server that implements all the logic for registering, activating, logging in the user, returning any content.

Also, there is a scheduled tool that cyclically verifies the users who have to be notified, and establishes which types of content will be sent with push notifications. Then it interfaces with FCM for delivery.

The database

We have created some tables on the DB:

• A table containing personal information about the user, such as name, phones, address etc.
• A table containing information about the sessions of the users, where we store bearer tokens generated at login for each user.
• A table containing information about installations.

Tokens and installations

When the user installs and executes the app, Firebase returns a token.

The app stores it in the application sandbox (using UserDefaults on iOS or SharedPreferences on Android) in order to have it available when needed and for future logins. When the user logs in for the first time, the app calls a Login API that receives:

• the credentials of the user;
• an empty parameter called InstallationID;
• information about the device and OS version;

This API executes all the checks to validate the credentials, if they are valid, it creates a session and saves a bearer token to the corresponding table.

Finally, because we passed an empty installation ID, it generates a GUID and stores it in the Installations table together with the bearer token Id.

This new Installation ID represents the current installation of the App on a device in the same way the Firebase token does.

The Login API returns a response containing info about the user’s Session and the new installation Id and stores these values (to use them for further logins of the user).

To complete the login procedure, we need to execute the Assign API that pairs the user (the bearer token), the firebase token and the Installation ID.

At this point our back-end can easily identify the user and the device in use and eventually ask FCM to send notifications.

If the user logs out, the app calls the Logout API that searches the user session id in the Sessions table marking it as expired, then searches the same value in the installations table, setting it to null.

The scheduled tool that takes care of requesting FCM to send notifications takes into consideration only users who have a record in the installation table that is paired with installation id, firebase token and userSession Id.

If a different user, with his own credentials, logs in the app, the installationID and the firebase token still remain the same. After the user’s credentials are validated by the login call, another bearer token is generated identifying the user with the active session.

In this way if a user logs out and another one tries to login (or if more than one users are logged in to your app), we know which one has an active session.

Firebase token expiration

The firebase token, although in very limited circumstances, can expire. Refer to the official documentation for the necessary details.

If the Firebase token changes, it is not possible to identify the device that the user is logged to.

As a result, the back-end is no longer able to provide FCM with the correct and valid token that identifies the user’s device to send notifications to

Fortunately, the FCM SDK is well designed and automatically manages the reception on a new refreshed token that we store as a new token every time it changes and communicate to the back-end with a call to the Assign API.

Push notification targeting

Among the requirements for our product there was also the possibility for the user to select the type of content to receive via notifications. For example, he had to be able to enable the reception of reminders and disable the sending of pushes for different types of information. Again, FCM doesn’t offer any feature by the way.

We have adopted a very simple solution in this case. We have added a table in the DB where all the users preferences are stored in the form of key/value pairs.

Here is an example:

In this way we have the possibility to access the single settings in a very easy way and it is very simple to add new settings that may become necessary in the future. Then, we have linked the single setting not only to the user id, but also to the installation id.

By doing so the user who shares his account on two different devices (a smartphone and a tablet for example), can choose to receive a certain type of message on one device but not on the other.

Conclusion

Firebase Cloud Messaging is a great tool for delivering messages to users running your web site or mobile applications.

It does not provide features to deal with notifications targeting or other topics described in the incipit of this article. The developer must write his own solution as discussed above.

We hope these concepts may be useful for you! 😄

Thanks to Davide Fin for his contrib.

by Lavinia Bertuzzi, iOS developer at OverApp (https://www.overapp.com).