React-native-firebase: [QUESTION] What happens with the FCM token when two users are sharing same device? (Firebase Cloud Messaging)

Created on 28 Mar 2020  ·  7Comments  ·  Source: invertase/react-native-firebase

Hello,

I would like to know how to handle multiple users one same device.

If the USER A logs out of the app, and another USER B logs in, USER will receive notifications of USER A?

If yes, how to prevent that?

If no, how does it work?

Thanks

PS : I didn't find where to ask this question, maybe you can open Github Discussions?

Most helpful comment

PS : I didn't find where to ask this question, maybe you can open Github Discussions?

Discussions is closed beta, only available on the NextJS repo?

2 / This may happen if I would like on my friend phone then I log out, But he still receving notifications for me whereas i’m not using it anymore. What’s is the solution ?

This is still possible, just requires more manual work.

  1. The FCM token will be the same regardless, you can't prevent this... however, you should still store it on your database for both users.
  2. When you send a message to a device, you'll need to make sure it's "data-only", so FCM doesn't automatically display a notification.
  3. When the message is received (either via onMessage or setBackgroundMessageHandler) you should then read the contents of the data in the message. That data should include the users ID (or something).
  4. You then need to check whether message is for the currently signed in user (e.g. by matching the user IDs).
  5. If it is for that user, you'll have to create a local notification (for example, with Notifee).
  6. If it isn't for that user, simply ignore it.

All 7 comments

I haven't tested however I guess the token will be the same since it has no knowledge of user accounts.

The device will receive the push message, its up to you to send user related content and handle what happens when the app opens.

This seems a pretty unlikely scenario though?

@ehesp Hm, I se what you mean.

But it’s not an unlikely scenario.

1 / This may happen when a user has personal account and profesionnal account.
When he logout and login to another account, it makes sense to « keep » notifications on both because he owns them,

But

2 / This may happen if I would like on my friend phone then I log out, But he still receving notifications for me whereas i’m not using it anymore. What’s is the solution ?

PS : I didn't find where to ask this question, maybe you can open Github Discussions?

Discussions is closed beta, only available on the NextJS repo?

2 / This may happen if I would like on my friend phone then I log out, But he still receving notifications for me whereas i’m not using it anymore. What’s is the solution ?

This is still possible, just requires more manual work.

  1. The FCM token will be the same regardless, you can't prevent this... however, you should still store it on your database for both users.
  2. When you send a message to a device, you'll need to make sure it's "data-only", so FCM doesn't automatically display a notification.
  3. When the message is received (either via onMessage or setBackgroundMessageHandler) you should then read the contents of the data in the message. That data should include the users ID (or something).
  4. You then need to check whether message is for the currently signed in user (e.g. by matching the user IDs).
  5. If it is for that user, you'll have to create a local notification (for example, with Notifee).
  6. If it isn't for that user, simply ignore it.

Oh! I think TIL something new.

So you are saying the solution is to use Local Notifications instead Remote Notifications, right?

I read a lot about data-only message but didn’t find a use case.

So the flow should be this :
Device > Send Message (Data) > Device > Should I display notification? > Local Notification

Instead of
Device > Send Message (Notification + Data) > Device > No choice > Remote Notification

(I really want to try Notifee but it’s not ready on iOS... And it’s quite bit expensive « for me » as young dev, for now)

Pretty much - I'm currently working through our new docs site and messaging is fairly well documented (aside from proof reading): https://rnfb-docs.netlify.com/messaging/usage

There's a fair bit there about foreground/background handling etc, should help you.

Indeed this new docs are awesome! It’s shiny and well explained. Good jobs guys! 😍

This docs is about V6, that I tried before, but stopped because of .onMessage() was not triggered on iOS.

I know now that it was fixed and merged into a release candidate. (I guess I scared to use an non-ready package and waste time for my deadline... 🤔)

But I’m still a bit confused about « WHAT WAY » I should use to « display » remote notifications on V6 « to replace » V5 Firebase.onNotifications().

Because I can’t use Notifee right now, and didn’t find other package as good as Firebase Notifications.

I don’t know if Firebase Cloud Messaging V6, at his current state, is enough to replace V5, for iOS (📲 iOS is my only main focus).

In my case, I just want to send from device to device (at the end NEVER from console, that was just for testing) and handling logout and different users on same device.

PS : I would like to ask (into another issue) about InstanceID and Registration Token, this thing is still confused to me everywhere I read about it 😅

I know now that it was fixed and merged into a release candidate. (I guess I scared to use an non-ready package and waste time for my deadline... 🤔)

I'd use it to be honest, we spent a LONG time on it and there is a loads of fixes for iOS.

But I’m still a bit confused about « WHAT WAY » I should use to « display » remote notifications on V6 « to replace » V5 Firebase.onNotifications().

I guess this library: https://github.com/zo0r/react-native-push-notification

However, I've never used it & it's not been updated in 6 months.

PS : I would like to ask (into another issue) about InstanceID and Registration Token, this thing is still confused to me everywhere I read about it 😅

If you don't know what it's for, I wouldn't worry about it 😄

Was this page helpful?
0 / 5 - 0 ratings