Why was ReactNativeFirebaseMessagingReceiver used to intercept messages instead of onMessageReceived

[imas234]

I was reading through the android implementation for the setBackgroundMessageHandler function exposed for react native and in general trying to understand what's happening when a message comes from firebase (DISCLAIMER: I do not know much about android development).

I noticed that instead of onMessageReceived which is marked no-op, there's a ReactNativeFirebaseMessagingReceiver method onReceive that gets called when a firebase remote message comes in instead.

Is there any added advantage to this method + specifically handing (high priority) data notifications via a HeadlessJsTaskService instead of using the onMessageReceived override? I'm mainly interested in whether it is more reliable in terms of the app receiving the data message and turning it into a local notification.

---

More context:

I was looking into reliably getting notifications for the app I'm working on. I noticed that on a coworker's phone, an ASUS ROG phone - the onMessageReceived would not be triggered if the app was not open or in the drawer. I hadn't seen anything like the approach used here suggested while I was looking into this topic and was wondering what the benefits of it were and if I could emulate this to have more reliable notifications.

Editing to add that I have looked into this: https://help.pushwoosh.com/hc/en-us/articles/360028478751-Android-device-cannot-receive-push-notifications-when-an-application-is-force-stopped-killed

I believe that this phone is simply putting the app in a force stop state becuase when I added the app to Auto-Start Manager, it received notifications even when swiped away from drawer.

[mikehardy]

Vendors do all sorts of "illegal" things with regard to their respect for the requirements of AOSP that are allegedly enforced by Google before you can say something is "Android". Usually in the name of power management. Usually with the side effect of rendering an app lifeless when it should wake up for some permitted external event (like an FCM JSON arriving on the phone) https://dontkillmyapp.com/

That is not in your control or firebase control unfortunately

it is possible to see if an app is in a restricted power state (and this is something available as an API here I think https://notifee.app/react-native/docs/android/background-restrictions

I'm not aware of any more reliable method of receiving messages and calling handlers than as implemented in react-native-firebase and documented on rnfirebase.io

[imas234]

Thank you for the reply. Understood your point. Hope you don't mind the follow up question, I am trying to understand the approach used here and the rationale behind it.

My question was mainly curiosity about whether the approach used in this library has any added advantage outside of being able to intercept both notification payload messages and data payload messages with a unified function.

My understanding is that onMessageReceived would not be called if a notification only payload was sent or if, a combined notification and data payload is sent, it would only be called if the user taps on the notification displayed or the app is in the foreground.

Mainly curious about whether this approach has any added benefits for high priority data payloads over onMessageReceived.

---

I was also wondering whether the app itself gets re-awakened to handle the received remote message when onMessageReceived is triggered in other libraries (https://github.com/zo0r/react-native-push-notification) but that is not in the scope of this discussion I guess.

[mikehardy]

The answers to your question are lost to time, sorry. The current approach appears to be "sufficient" and that is translated here to "invest time in other areas". You're welcome to try alternative approaches and if there is a superior one, post a PR. We merge all reasonable things where reasonable is translated as supported by available docs and demonstrated success with testing

Unsure on your second question, but it seems testable and thus possible for you to observe / answer?

[imas234]

Thanks for taking the time to answer my questions! I'll continue with my work and investigate how I can.