Native Android & iOS Firebase Notifications (Google Cloud Messaging) — Product Owner Cheatsheet

When creating digital products is usually needed to send notifications to our users. In this “Product Owner Cheatsheet” you will learn the basic knowledge to think and create products notification based.

You can always read the oficial documentation to have the latest version.

[Read More] Google Cloud Messaging Firebase documentation

Be creative. Everything can be done in several ways and each one has its pros and cons.

To make it easier to explain I’ll use a fake News App as example. Presenting problems with some possible solutions.

ThinksNews App briefing and User Stories

ThinkNews is an app in which the user can read recent news and posts classified by categories. The user can also save posts for later.

User stories

1. Each user subscribed to a category should recieve a notification when a new post is published within.
2. A user with an unfinished saved post should be notified after exactly 1 day.

Overview of the notification system

Before starting to explain how to complete those user stories, let’s take a look on the basic architecture and concepts.

Conceptual schema of the client-backend-firebase system

On the upper schema we can identify 3 main actors:

The CLIENT

Representing “the user” device, the installed app, the app instance with the Firebase Android or iOS sdk installed.

Responsabilities

• Retrieve the FCM Token from the Firebase Android and iOS sdk and send it to the backend.
• Send the changes in “interests” made by the user in the app UI. (Suscribe and unsuscribe)
• Show the notifications and customize them if its desired.

The BACKEND

Representing “the brain” of the system, with databases, files and APIs…whatever.

A lot of business logic can take place in this place.

Responsabilities

• Recieve and store the tokens received from the app.
• Recieve and store user interests. (Subscriptions / Unsubscriptions)
• Suscribe FCM tokens to topics when user “subscribes” in the app.
• Delete FCM tokens from topics when user “unsubscribes” in the app.
• Send messages to topics or tokens depending on the business case.

The FIREBASE CLOUD

FCM Architecture

Acting as “the postman”, delivering to “the user” the messages orchrested by “the brain”.

Responsabilities — but we don’t need to do anything

• Send the messages to users and devices when the backend ask for it.
• Keep stored the tokens suscribed to a token.

[Read More] FCM Architecture

So, based on some user actions (subscriptions, likes, follow…) the backend, based on business logic will send notifications back to users.

Those notifications can be sent using two methods: by TOKEN or by TOPIC. Based on the business requirements we will use one or another.

And, as we need to make it work in both iOS and Android, we will need to look closely on each platform as their behavior is not exactly the same.

Previous concepts

FCM token

• Is the token we use to identify the app. Like an adress for mailing.
• Is the id representing the app installed on the device in Google’s eyes. Each app instance has a different token.
• We will use the FCM token to identify to who send which notifications.
• This token is born in the client APP so you will need to send it to your backend to store it.
• This token can exipre whenever Google decide. In this case onTokenRefresh() method will be triggered on the client, enabling the client to send the new token again to the backend.
• Notification permissions must be granted to retrieve Firebase token.
• This token has no need to be related to a specific user.

Topic

• Topics are entities with meaning inside Google Firebase
• Is an entity created to subscribe tokens in it.
• Topics are agnostic to the content architecture or business logic.
• FCM Tokens can be suscribed into to topics.
• In our example app, the categories (like Politics, Travel, Sport ) are topics in which users can “subscribe”.
• We can also suscribe tokens in topics representing age ranges, so we will have also the topics (…, 18–25, 26–43, 44–55, …).
• We can have topics representing two or more kinds of grouping (category, age, city…)
• Topics are identified with a free string. So be aware with the naming.
• Limitation 1: Each FCM token can be subscribed to no more than 2000 topics.
• Limitation 2: You can suscribe max 1000 tokens to topic in each batch request. But then you can make another request. The worst scenario is that you make so many requests that FCM responds with an 429 RESOURCE_EXHAUSTED error. If you reach that limit, good job, you have a huge user pool (hire me)!

[Read more] Firebase topics

Audience

• Is a definition created by me to explain the concept “combination of topics” found in Firebase Docs in order to make it easier to internalize.
• We can send messages to an audience created by a combination of topics using this kind of logical operations: "'TopicA' in topics && ('TopicB' in topics || 'TopicC' in topics)" . More info
• The audience represents the batch of users we will impact with our notifications.
• A topic itself is an audience.
• An audience has business value itself.
• Examples: Politics is an audience; Politics && 18–24 years is also an audience.

You can also use a new topic instead this logical grouping by suscribing the people suscribed in Politics and 18–24 in a new topic called Politics_AND_18–24 . But then you will need to keep the logic in your backend. But then operations can’t be done in the fly. And more topics are created.

Whether to send by token or by topic

We have both possibilities, by token we can send a different message by user, but this also means that we will make a request to Firebase to achive it. Otherwhise, using the topic method we will send one request by notification.

Having this in mind we can think about a couple of examples:

2- If you have 2 users with an interest each and you send one notification by day:

Dont worry, you can go by token but:

By token: The request rate will be 2/day — total: 2 * day

By topic: First day: 1 request to suscribe + 1 request to send to topic — total: 1 + 1 * day

3- If you have 1000 users with an interest each and you send one notification by day:

By token: The request rate will be 1000/day — total: 1000 * day

By topic: First day: 1 request to suscribe + 1 request to send to topic — total: 1 + 1 * day

If we scalate this ammount to n where n = 200K or so, our token solution will not work at his fully potential as Firebase will start to increase response time until reaching an error for quota exceed.

Well, hope its enough to realise that depending on the situation its better to use one or another approach.

So,

By topic

• Topic method allows scalability and can handle fast user growth.
• For this reason, use topic if business requirements allow this approach.
• You should use it if you want to send a messages to a group of users.
• You should use it if you have clear categories and users can suscribe to them.
• You can still customize the notification in a particular way by passing a payload to a Push notification. (Example: If you want to send a notification each day at the same hour but with different messages)

[Read More] Send messages to topics

By token

• Use it if you can’t send by topic.
• You can use it if you have few users (so you dont care about performance).
• You should use it if you need a high customized notification schedule. (Example: if you have a banking app and you want your users to be notified when a new payment is made)

You target users by their token, you can send a fully customized notification. Due to Firebase API limitations this method shouldn’t be used to broadcast.

[Read More] Send messages to registration tokens

Other ways, not common but may help to think out of the box.

A pull approach

If you are an app so big and so common and so importand and so so so.

You can schedule a method to request to your backend each x time if there’s a new message. [Read More]Android JobScheduler

This solution will be battery consuming and may not work if your App is not “white-listed” for the manufacturers. As your App may be killed after some time of inactivity.

Hybrid

You can even use a first push to trigger a pull to request information. This may break your backend if it’s not ready to hold a huge amount of requests.

Geo-based notifications

You can achieve some sort of geo-based notifications using geofencing. Ill try to write a post about it.

[Read More] Geofencing

Platform: Android vs iOS & Message type: Notification Message vs Data Message

Source: http://www.pricepony.com.my/blog/ios-vs-android/

We have two main push types that we need to choose wisely depending on the functionality we want to achieve.

• Notification Message / Display Message
• Data Message / Silent Message

[Read More] Message types

Notification Message (always visible)

You can send an always visible notification to the devices also with a custom data payload.

A default notification layout will be shown unless you override it with the custom info placed in de payload (or any process you start).

Android

If the app is on the background, depending on the OS version, the device, the battery settings … The PushNotification will arrive, but without the payload. If the app is on the foreground everything OK.

IOS

If the processing of the payload lasts more than 30 seconds the default notification layout will be shown.

Data Message (silent)

You can send a custom payload (.json) to the device without showing any notification.

Then the app can choose whether to show or not a notification. In this case, you can also customize the notification layout.

In the tests we made around 2018 those notifications barely succeed to deliver when app is in background. We discarded this method, so i have not much information.

It might be a protecting layer so you cannot spam users with hidden notifications draining batery and starting background processes.

If the app is on the foreground everything OK.

If you identify more variables or reasons that may affect the delivery, please comment below.

[Read More] Cloud Messaging concept options

[Read More] Optional data payload

[Read More] Firebase iOS Client

Customize notifications

Once the notification is recieved in the device we can modify its display by overriding the default appearence. We can use the data recieved in the payload to do so.

Starting from a simple notification like this one, we have some possibilities to make them look beauty and actionable.

Simple notification

Known possibilities

• Add buttons
• Add images
• Add a large image when expanded
• Add a long text when expanded
• Add media controls

You can find a good revision in the official docs here:

[Read More] Customize Android notifications

[Read More] Customize iOS notificaitons

Delivery Options

In the docs you can find further detailed info about more delivery options.

For me the most valuable is the possibility to colapse messages into kind-off groups.

[Read More] Collapsible messages, Priority, Message livespan…

FCM Credentials, keys and tokens

In the whole setup there’s a lot of keys and we must know wether from where they come and where they go.

• Google Service Account Credentials: To allow your backend comunicate with Firebase API. You can download this file from Google Cloud Platform Credentials in API Keys section. Will be stored in the backend
• FCM token: As seen before, to allow Google identify the device in order to send the notification. Retrieved in the client from the Firebase SDK and sended to the backend to be stored.

iOS

• IOS GoogleService-Info.plist: To allow iOS App instances retrieve a FCM token from Firebase SDK. You can download this file from Firebase project and stored in the client.
• Apple Push Notification Authentication Key: To allow Firebase send notifications to Apple.

[Read More] Setup Firebase on iOS

Android

• GoogleServie.json: The Android equivalent to GoogleService-Info.plist. Can be downloaded from Firebase and will live in the client.

[Read More] Setup Firebase on Android

Solving User Stories

1- Each user subscribed to a category should recieve a notification when a new post is published within.

To solve this situation we just need to create a topic called like the category and suscribe the FCM tokens as soon as they tap on the suscribe button in the interface.

This interest triggered in the UI will travel to the backend and then to Firebase.

Then, when a new post is published the backend will build the message and send it to Firebase with the target topic.

All users suscribed to the topic will recieve the notification.

2- A user with an unfinished saved post should be notified after exactly 1 day

In this case we should use the token approach, as the message sent to this user will not be the same than the one to send to another user and even more hard to be coincident in time.

So, when the backend determine is the time, he will send a message targeted diretly to the FCM token of the user.