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.
Related
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.
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?
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.
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.
I am planning to implement Android push notification serivce for an app that might require receiveing even two messages per device per second. I would like to know if GCM Push messaging is the way to go or should I stick to SyncAdapter or some other technology? Single device will receive up to few thousand notifications per day. Message size will be very small to 4kb limit is fine.
If it is critical that all of the messages reach the device and none are lost, GCM alone is not the right choice, since in case GCM server would temporarily lose connection with a device, there's a limit to the number of messages that would be stored for later delivery for that device in the GCM server.
Therefore, if you have to update your app that frequently, you should probably keep an open connection between your server and your app, and load data from the server periodically.
Though the GCM server limits the number of messages that will be stored for later delivery in the case of a device disconnect, you can always create a collapse_key.
According to GCM documentation, if there is already a message with the same collapse key (and registration ID) stored and waiting for delivery, the old message will be discarded and the new message will take its place (that is, the old message will be collapsed by the new one).
Essentially, if you only need the most recent push notifications rather than all prior sent, GCM is acceptable for sending push notifications with high frequency.
You can read more about this in the GCM Advanced Topics.