Firebase high priority message when app is on foreground - android

I am using FCM messages on my android project. I have read this info on developer page;
High priority messages on Android are meant for time sensitive, user visible content, and should result in user-facing notifications. If FCM detects a pattern in which messages do not result in user-facing notifications, your messages may be deprioritized to normal priority.
I just want know , must we show user-facing notifications even if app is on foreground? if we do not show notification when app is on foreground (any activity is visible) May it cause any deprioritization?

Related

How do I send a high priority inbox style notification on Android using FCM?

I want to send a high priority notification to Android devices using FCM and have it displayed in the system tray as an Inbox style notification.
FCM does not allow you to configure the Android notification style server side, so I must send the send the android system notification client side, to use NotificationManager API to send an inbox style notification.
The only way to do this without an automatic default style notification is to use FCM data messages. But the Firebase Flutter docs (I am trying to implement a solution for this on Android Native and Flutter, but a Android Native solution will suffice) indicate that data messages are low priority...
From the flutterfire docs:
As mentioned above, data only messages are classed as "low priority".
Devices can throttle and ignore these messages if your application is
in the background, terminated, or a variety of other conditions such
as low battery or currently high CPU usage.
You should not rely on data only messages to be delivered. They should
only be used to support your application's non-critical functionality,
e.g. pre-fetching data so the next time the user opens your app the
data is ready to be displayed and if the message never gets delivered
then your app still functions and fetches data on open.
So it seems, based on the premises presented here, that it is impossible to send a high priority inbox style notification on Android. Is this correct?
I think you still can. Even though data message is normal priority by default, you can still manually set it to high as stated in the doc.

FCM: Is data message delivery really less reliable than notification message delivery?

Question
I have come across some voices stating that FCM data message delivery is less consistent compared to that of notification messages. Does anyone have direct experience or can point me to resources exploring the issue? Or is a notification message just a collapsible, high-priority data message that the Firebase SDK handles automatically?
https://stackoverflow.com/a/49998176
FCM data message not received in Android when the application is in background
About FCM's notification message and data message type, which has better receiving rate
The question does not consider the case of force quitting the app. In this scenario, both types of messages will not be delivered (to my knowledge).
Background
I am writing a new Android SDK for a push service provider (similar to OneSignal). The SDK should handle the display of push notifications by default, optionally the client app can handle incoming pushes itself.
The actual delivery is of course done by Firebase Cloud Messaging (on devices running Play Services). So there are 2 types of messages to choose from on FCM: data vs notification messages.
As data messages are consistently handled by the registered FirebaseMessagingService (provided there is no notification key in the payload), this should be the way to go for the SDK. [See documentation] So far, I have not been able to produce a situation in which a data message was not delivered (foreground or background).
By setting the priority in Message, We can reflect the delivery.
You have two options for assigning delivery priority to downstream messages on Android: normal and high priority. Delivery of normal and high priority messages works like this:
Normal priority. This is the default priority for data messages. Normal priority messages are delivered immediately when the device is not sleeping. When the device is in Doze mode, delivery may be delayed to conserve battery until the device exits doze. For less time-sensitive messages, such as notifications of new email, keeping your UI in sync, or syncing app data in the background, choose normal delivery priority.
When receiving a normal priority message on Android that requests a background data sync for your app, you can schedule a task with WorkManager to handle it when the network is available.
High priority. FCM attempts to deliver high priority messages immediately, allowing FCM to wake a sleeping device when necessary and to run some limited processing (including very limited network access). High priority messages generally should result in user interaction with your app or its notifications.
See Set and manage message priority topic in FireBase Documentation.
For More details you can prefer this link
For Displaying the Notification You Can Prefer this link
Best Of Luck In Advance.

Difference between the two types of FCM push notification payloads (notification vs data) and when do they arrive to Android FirebaseMessagingService?

In Firebase push notifications, the payload can be of type "notification" or "payload", but they arrive (or not) depending on whether the app is in background or not and other details. Please clarify them.
(This answer focuses on Android devices)
Firebase Cloud Messaging (FCM) push notifications can be of three types : notification, data and notification+data.
Notification messages are meant to be received by the Android operating system itself, with no intervention by the app. When received by Android, they will be shown as a notification in the tray. Some details:
The tray notification will not be shown if received when your app is in the foreground.
You can implement a FirebaseMessagingService (see the data payload for more info on this), which will receive the message if your app is in the foreground. In your FirebaseMessagingService, you can show a tray notification yourself (or do whatever you want) when you receive the message.
When sending the message, you can specify what happens when the user clicks on the notification; this can be controlled by either specifying an activity in the click_action Android-specific option (see this) or by specifying an URL in the link property and having your app configure an intent filter associated with the URL you specified.
Data messages are meant to be received by an Android service of your app. This service can, in principle (see below [*]), receive the messages when your app is in the foreground, in the background, or not running at all. Some details:
To implement the service, you have to extend FirebaseMessagingService and configure it in your app's manifest.
When you receive the message in your FirebaseMessagingService, you can decide to emit a local notification to be shown in the tray. You can do this either when your app is in the background or in the foreground, in principle (see below [*]). Of course, you may also decide to do other stuff instead (or apart) of showing the tray notification.
[*] Some phone manufacturers, especially Chinese ones like Xiaomi and Oppo, implement some mechanisms to save battery that include killing services. This means that, by default, your FirebaseMessagingService will not be running on those phones unless your app is on the foreground and, therefore, it will NOT receive your data payloads when your app is not on the foreground. There is no way around this, except if the user whitelists your app specifically. The famous apps like Whatapp or Gmail are by default included in the whitelist, but yours won't; therefore, if you rely on data payloads and you want your app to work on that kind of phones, you'd better guide your user to configure their phone to allow it; here you can see how to do it for Xiaomi (Miui) devices. This can also happen in vanilla Android devices since Android 9 (API level 28) with background restrictions, but the behaviour is opposite: your service won't be killed unless the user requests it; you can check this with ActivityManager.isBackgroundRestricted
Notification + data messages include both types of payloads. They behave exactly like notification payload-only messages:
When your app is in background, Android shows the notification in the tray. The data payload is accessible to the app if it receives the intent invocation when the user clicks (described above) in intent.extras.
When your app is in foreground, your FirebaseMessagingService receives the notification with the contents of the data payload.

About FCM's notification message and data message type, which has better receiving rate

We are choosing to use FCM's notification message or data message (only for custom designs). We already know that custom designs data message perform better than the non custom design data messages. But we are wondering if notification message can have better receive rate than data message because it is using the system to show the notification. Anyone has done any investigation?
If not, then what's the advantages the notification message type have
It's an interesting question and topic of research. I faced the same
the situation about a while ago.
According to firebase's documentation :
Notification messages are high priority by default, and
collapsible--the following message will replace the current message if
it's not delivered yet.
In the custom data type payload, you can actually pass the notification priority to high. But.....
According to this document from firebase
High priority. FCM attempts to deliver high priority messages
immediately, allowing the FCM service to wake a sleeping device when
necessary and to run some limited processing (including very limited
network access). High priority messages generally should result in
user interaction with your app or its notifications. If FCM detects a
pattern in which they don't, your messages may be de-prioritized.
Android P introduced app standby buckets which limit the number of FCM
high priority messages you can send to your app that don't result in
the user using your app or viewing a notification. If in response to
a high priority message, a notification is displayed in a way that is
visible to the user, then your app standby bucket quota will not be
consumed by that message.
And now let's talk about my personal experience. I faced the same
situation and the observations we noted with our QA were quite the
same as their documentation.
Although after setting priority HIGH in data type payload we noticed random behaviour with some custom OS phones like Oneplus, Oppo etc. While in the case of notification type payload it was consistent and we were getting notification perfectly.
So I advise that if you don't have a particular requirement to handle
the data silently in the background just go with a simple
notification payload.

Firebase push notification delay after triggering few high priority notifications

I use Firebase high priority push notifications to trigger Panic alarms in Android devices. For first few tries of push, immediately push notifications arrives and it works great. But when i keep triggering push notifications after certain amount of time slowly delay keeps increasing.
I want it to trigger immediately as it is Panic situation.
I also followed the documentation which read:
High priority: FCM attempts to deliver high priority messages immediately, allowing the FCM service to wake a sleeping device when necessary and to run some limited processing (including very limited network access). High priority messages generally should result in user interaction with your app or its notifications. If FCM detects a pattern in which they don't, your messages may be de-prioritized. Android P introduced app standby buckets which limit the number of FCM high priority messages you can send to your app that don't result in the user using your app or viewing a notification. If, in response to a high priority message, a notification is displayed in a way that is visible to the user, then your app standby bucket quota will not be consumed by that message.
Because a small portion of the Android mobile population are on high latency networks, avoid opening a connection to your servers before displaying a notification. Calling back to the server before the end of the allowed processing time may be risky for users on high latency networks. Instead, include the notification content in the FCM message and display it immediately. If you need to sync for additional in-app content on Android, you can schedule an FJD job or a JobIntentService to handle that in the background.
How can I make sure high priority messages are triggered as soon as possible? May be within a minute in all cases.
FCM attempts to deliver high priority messages immediately, allowing the FCM service to wake a sleeping device when necessary and to run some limited processing (including very limited network access). High priority messages generally should result in user interaction with your app or its notifications. If FCM detects a pattern (such as testing pattern) then your messages may be de-prioritized. Android P introduced app standby buckets which limit the number of FCM high priority messages you can send to your app that don't result in the user using your app or viewing a notification. If, in response to a high priority message, a notification is displayed in a way that is visible to the user, then your app standby bucket quota will not be consumed by that message.

Categories

Resources