setBackgroundMessageHandler behaviour appears inconsistent with docs

[jamie-unmind]

Hi there,

We are using @react-native-firebase/messaging 10.8.0 to send Notification+Data messages for iOS and Android.

According to the docs here, setBackgroundMessageHandler should be called when the application is in a Background or Quit state. However, we are experiencing some behaviour that is inconsistent with this.

When the application is backgrounded:

• For iOS, we have to set contentAvailable: true in the apns section of the message in order to trigger `setBackgroundMessageHandler. The docs seems to suggest this should only be the case for Data only messages?

{
      notification: {...},
      data: {...},
      apns: {        
        payload: {
          aps: {
            contentAvailable: true
          }
        }
      }
}

When the application is quit (ie: user swipes it away):

• For Android, we have to set priority: "high" in the android section of the message in order to trigger `setBackgroundMessageHandler. The docs seems to suggest this should only be the case for Data only messages?

{
    notification: {...},
    data: {...},
    android: {
        priority: "high"
    }	
}

• For iOS, setBackgroundMessageHandler appears to never be triggered. This issue comment seems to suggest that once an iOS app is swiped away, setBackgroundMessageHandler cannot be triggered. However, this matrix in the docs suggests that setBackgroundMessageHandler can be called in a Quit state, where Quit is defined as "When the device is locked or application is not active or running. The user can quit an app by "swiping it away" via the app switcher UI on the device." (source here). Is it possible to clarify which is the expected behaviour?

Let me know if you need any more background info.

[mikehardy]

The FCM payload you are sending appears to be mixed (contains both notification and data chunks)

I believe for mixed payloads, the notification chunk is the important part, and it means that the firebase-ios-sdk / firebase-android-sdk will handle it and should post a device-local notification without ever giving control to your code - no handlers called

If/when the user interacts with the device-local notification in a way that opens your app, I believe that you will see it as an initial notification?

[mikehardy]

Unless I am mistaken mixed payloads do not trigger handlers on delivery. They only pop a notification center local notification. I think our docs - the table you linked - is not correct unfortunately 😱

https://firebase.google.com/docs/cloud-messaging/concept-options#notification-messages-with-optional-data-payload

[jamie-unmind]

Ah ok, does this mean we'd be reliant on our native code to track when a mixed payload message is received?

Is it unadvisable to use contentAvailable: true and priority: "high" to try to force our background message handler to trigger with a mixed payload message?

[mikehardy]

I'm not sure if the native SDKs give you any hooks in mixed payload messages - another way of saying, I don't know if what you would like to do is in the universe of possible things. Could be, I just don't know. There is quite a lot of information about analytics related to messages on the google firebase documentation site though, might have what you need already?

I don't believe the attributes you mention matter if it has a notification payload but this is subtle and I'd defer to any upstream docs from Google and/or Apple.

[jamie-unmind]

@mikehardy thank you for these clarifications!

If we were sending a data-only message to an iOS device with contentAvailable: true, should our background message handler be triggered even if the app has been closed & swiped away?

[mikehardy]

That case (swiped away, which is known as "force quit" most of the time I think) is one of the unreliabilities of data-only messages. iOS takes that as an explicit signal by the user to stop running the app, and acts accordingly: it will not run the app again until the user starts it again. No data-only messages will be delivered, no handlers will be called.