No events for notifications displayed on background

[fgagneten]

After reading the following doc:
https://github.com/invertase/react-native-firebase-docs/issues

I could implement the notificacion services like a charm.

After a while playing with notifications I detected a scenario that I can't control:
Notification received on background.

I have a reaction when notification is received so if a specific view is displaying I refresh autommatically some content. Great, that works perfectly (on foreground) with the following event:

firebase.notifications().onNotificationDisplayed

However, It's typically while a screen is displaying, the user (wainting for a notification) put the app on background and in the meantime do something else.
When a notification is received on background, the user doesn't touch the notification but go back to the app from the recent list (and here is the problem). That view should have been refreshed when the notification was received on background. Why the screen was not updated with the reaction? Because I don't have an event to trigger the reaction when a notification is received on background (not clicked, not tapped, just received).

I would like to know how most of you can handle this can of scenario.

Thanks

[mikehardy]

I believe the solution is don't do a notification, do a data only silent push message, and use it to both update whatever your data store is, and also (using info from the data push message) pop a local notification.

[NicholasIoanJones]

I think this is the same issue we are seeing. To be clear, are you saying that when a push notification (with notification and data included) is received when the RN app is in the background - The RNFirebaseMessagingService.onMessageReceived is not triggered?
But with data only it will be triggered?
This seems counter-intuitive

[mikehardy]

I find most things with regard to native notifications APIs and cloud messaging to be a little counter-intuitive but I get through it with-and-only-with testing of each thing. I think the way you summed it up is accurate, but the main reason I do data-only is because I want local control of notifications and when you do data+notification in the same cloud message the firebase SDKs handle the notification part, which for me spreads my mental model of how notifications are displaying around and makes it less coherent to reason about. So I just cleanly split them.

Here's the table though. https://firebase.google.com/docs/cloud-messaging/android/receive#handling_messages - note the "both" in "background" matrix entry may not be what you want, whereas at least with headlessJS enabled 'onMessageReceived' is the same every single time on android, and as it bubbles up to react-native-firebase it's also the same hook each time https://rnfirebase.io/docs/v5.x.x/messaging/receiving-messages#3)-Listen-for-FCM-messages for both platforms - just seems cleaner to me this way 🤷‍♂️ - I fully understand each project has it's own needs though, that's just the way I do it

[NicholasIoanJones]

https://firebase.google.com/docs/cloud-messaging/android/receive#handling_messages

That is really helpful Mike - thank you. I still think it's crazy that 'Both' doesn't result in onMessageReceived - but understanding crazy is a big step forward!

Another gap in our understanding of this notification model is that if we query getActiveNotifications from the app when it is in the foreground, the data attributes are not present as extras on the notification. Should they be? Are we missing something? Or do we need to specify the 'click-intent' on the notification section (as another poster has recommended) in order for the data attributes to be available.
It just seems very odd that data from the sender is not just available through getActiveNotifications.
Thanks in advance for any further advice/education you can give.

[mikehardy]

glad that helped initially, for your follow-on I must say I don't know - I haven't tried to access those things. I know from crazycodeboy/react-native-splash-screen#289 (comment) that passing the intent and all it's data along is pretty easy to mess up - might be API mis-understanding or might be a bug. At least with react-native-firebase v5 I found it trivial to hack into the module install inside node_modules to instrument it in and print out internal state at key moments any time I needed to understand something. Because v6 is in a mono-repo it is a bit more difficult to hack on ad-hoc like that in a way that is then patch-able upstream but the code is still there. You could just hack in to the various native listener functions and dump their state at key moments to System.err or similar and adb logcat it to make sure thinking matches reality