Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[馃悰] setBackgroundMessageHandler does not work on IOS > 17 and react native 72.2 #7548

Closed
alexstock1 opened this issue Jan 5, 2024 · 9 comments
Labels
Help: Needs Triage Issue needs additional investigation/triaging. Impact: Bug New bug report Type: Stale Issue has become stale - automatically added by Stale bot

Comments

@alexstock1
Copy link

alexstock1 commented Jan 5, 2024

Hi all,
after the update to react 0.72.2 and react native firebase 18.5.0,
(I have made everything that was written in the instructions and checked everything a couple of times, and i use use_frameworks! :linkage => :static) setBackgroundMessageHandler does not work on IOS > 17 at all when the app is minimized (Background mode), on Android everything works as expected

below you can find the requested body

{
  "to": "",
  "content_available": true,
  "priority": "high",
  "notification": {
    "body": "Test body",
    "title": "Test title",
    "sound": "default"
  },
  "data": {
    "type": "chat_message",
    "sound": "default"
  }
}
@alexstock1 alexstock1 added Help: Needs Triage Issue needs additional investigation/triaging. Impact: Bug New bug report labels Jan 5, 2024
@aliyilmazdev
Copy link

Hi, could you solve the problem? @alexstock1

@mikehardy
Copy link
Collaborator

If you include a notification block and a data block it is considered a "mixed" content message

the message will not trigger a background handler ever as it will instead (at the deeper firebase-ios-sdk layer) trigger a user-visible notification (but not start your app! no handlers called!).

If the user interacts with the message it will open your app and trigger onNotificationOpened with message contents that include the data block

I believe our documentation here may not be accurate and it conflicts slightly with upstream 馃 - it would require some testing to see. The difficulty with testing is that there are a lot of conditions to meet in order for the test to be accurate

  • setBackgroundHandler needs to be passed an async function that does no UI updates and returns a Promise
  • the JSON needs to be perfect with priorities etc
  • the device needs to have background refresh enabled and otherwise deliver the message - verified by watching device logs while plugged into developer machine via Xcode console on running app or Console.log

Upstream docs state this, which makes me think the behavior you observe is by design:

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

When in the background, apps receive the notification payload in the notification tray, and only handle the data payload when the user taps on the notification.

Copy link

Hello 馃憢, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

@github-actions github-actions bot added the Type: Stale Issue has become stale - automatically added by Stale bot label Feb 27, 2024
@dhaivatkhanpara
Copy link

I am also facing this issue.

@github-actions github-actions bot removed the Type: Stale Issue has become stale - automatically added by Stale bot label Mar 3, 2024
@rawatnaresh
Copy link
Contributor

setBackgroundMessageHandler does work if the payload you sent is correct. I was facing the same issue but got it working with following payload

Generating Remote notification Apple Docs

{
  "message": {
    "topic": "my-tpoic", // or token
    // Shouldn't contain notification block, as it is data only message
    "data": {
      "title": "Background notification 1",
      "body": "Background Notification 1",
    },
    "android": {
      "priority": "high"
    },
    "apns": {
      "headers": {
       // apns-priority should be 5 when apns-push-type is background
        "apns-priority": "5", 
        "apns-push-type": "background"
      },


      "payload": {
        // To send a background notification, create a remote notification with an aps dictionary that includes only the content-available key
        "aps": {
          // The background notification flag
          "content-available":1
        }
      }
    }
  }
}

You can test this using Rest API or Google OAuth Playground

If you would like to test this using OAuth Playground then

  • Authorize https://www.googleapis.com/auth/firebase.messaging API
  • Exchange auth code for token
  • Select method POST and set request URL to https://fcm.googleapis.com/v1/projects/{PROJECT_NAME}/messages:send
  • And paste this as request body
{
  "message": {
    "topic": "topic-name-or-token",
    "data": {
      "title": "Background notification 1",
      "body": "Background Notification 1",
    },
    "android": {
      "priority": "high"
    },
    "apns": {
      "headers": {
        "apns-priority": "5",
        "apns-push-type": "background"
      },
      "payload": {
        "aps": {
          "content-available":1
        }
      }
    }
  }
}

As this is a background message and won't show any notification alert. If you would like to show an alert you can use notifee

messaging().setBackgroundMessageHandler(async remoteMessage => {
  // Update local storage
  // And Display notification if necessary
  return notifee.displayNotification({
    title: remoteMessage.data.title,
    body: remoteMessage.data.body,
    data: remoteMessage.data,
    android: {
      channelId: 'channel_id',
      smallIcon: 'ic_notification',
      color: '#000060',
    },
  });
});

Hello @mikehardy, Do you think this is the correct way to show notification alert for background notifications?

In my app I have a requirement to show notification count and notification alert. Adding a notification block in FCM displays an alert but I cannot update local storage and sending data-only message updates the local storage but no notification alert unless I display an alert using notifee.

Also, I don't think its reliable to depend on setBackgroundMessageHandler to trigger alert as we cannot predict its execution. Eg. Sometimes it delays the execution until the app is open.

I was thinking of sending two different notification to solve this issue.

  • Notification with data only block to trigger local update
  • and another notification with notification block to show alert.

But sending two different notification for a single thing doesn't sound good either. Please let me know your thoughts.

@mikehardy
Copy link
Collaborator

@rawatnaresh I think this is a fine way to go about it for android only, on iOS the delivery of data-only messages is unreliable and you must not count on it for your features. I would use this for your android device tokens or topics android is subscribed too

For iOS you want to send a notification block as it is the only way to guarantee delivery. You will need to use a notification extension helper if you want side-effects besides just showing the notification and you'll need to be very careful to have rapid execution so you fit in the small execution timeslice iOS will give you on the way to posting the user-visible notification

@rawatnaresh
Copy link
Contributor

Thanks for the suggestion. I'll look into Notification Extension helper

@DeepakSharma04
Copy link

Hi, Can anyone help me to solve this issue #7715

Copy link

Hello 馃憢, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

@github-actions github-actions bot added the Type: Stale Issue has become stale - automatically added by Stale bot label Apr 27, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help: Needs Triage Issue needs additional investigation/triaging. Impact: Bug New bug report Type: Stale Issue has become stale - automatically added by Stale bot
Projects
None yet
Development

No branches or pull requests

6 participants