1

FCM registration generates a registration token that is associated with the device and not a particolar user. So, how to handle two common scenarios:

  • Logout: A logged in user is supposed to receieve notification, until he logs out
  • Switch user: If after logging out a new user logs in, it should have a different registration token that does't interfeer with the previous one.

This is an old documentation (from GCM)

Developers should never unregister the client app as a mechanism for logout or for switching between users, for the following reasons:

A registration token isn't associated with a particular logged in user. If the client app unregisters and then re-registers, the app can receive the same registration token or a different registration token.

Unregistration and re-registration may each take up to five minutes to propagate. During this time messages may be rejected due to the unregistered state, and messages may go to the wrong user.

Of course GCM now is deprecated, but it is likely that the same rules described here applies.

So, what are the possible ways for handling the two aforementioned scenarios? I could not find anything in the documentation.

GVillani82
  • 17,196
  • 30
  • 105
  • 172

1 Answers1

0

I think this is a common situation. Here is one way to handle it or here is how things at my end are handled.

In the Login API, I use the following to generate a new FCM token and that is sent every time in the Login API

Firebase.messaging.token.addOnSuccessListener { fcmToken -> }

So whenever a new Sign-In or Login is performed, the fcmToken goes in its own keys and replaces the already existing one at backend.

Coming to logout situation now. When we log-out, we call this code to delete the token associated with device thus ensuring no more notifications are received when logged-out.

Firebase.messaging.deleteToken()

Further more as another level of check in the FirebaseMessagingService onMessageReceived method call, we have added a check to see if user is already logged in or not then and only anything else is performed.

che10
  • 2,176
  • 2
  • 4
  • 11
  • So basically the backend changes the mapping user <--> token. If you login with user1 and the generated token is token1, then the backend will keep that association in the db. If then you logout and log-in with user2, then even if the token generated is the same, you change the association in the db to user1 <--> null and user2 <--> token1 ? – GVillani82 Jun 09 '21 at 08:51
  • If I login with `user1` and generate `token1` that passes on to backend and they keep track of it user1 to token1. When I logout, `token1` gets deleted. If I try to login again with `user2` new `token2` is generated and those get linked as in user2 to token2. If I logout again, the token gets deleted again. Whenever I relogin with any user the new token replaces the one at backend. – che10 Jun 09 '21 at 08:54
  • 2
    But are you sure that a new token is always generated? Cause based on that old documentation there is no guarantee about that. – GVillani82 Jun 09 '21 at 08:55
  • @GVillani82 store token in sharedpref – aryanknp Jun 09 '21 at 08:58
  • I understand your concern. You might want to check this [link out](https://firebase.google.com/docs/reference/android/com/google/firebase/iid/FirebaseInstanceId). The class in question is deprecated now, but you can see the situations under which the `token` or `instanceId` is stable and whenever you delete the token a new unique one is generated as far as I know @GVillani82 – che10 Jun 09 '21 at 09:00
  • Thank you @che10 I will take a look at that – GVillani82 Jun 09 '21 at 09:00
  • @GVillani82 https://stackoverflow.com/questions/45386448/when-to-register-an-fcm-token-for-a-user please check the top answer and its 2nd point. it seems you have the same problem about getting token of new user. – Muhammad Zahab Jun 09 '21 at 09:12
  • Thanks @MuhammadZahabAhmadKhan. I saw that answer, but I am still not sure about what he says: "Then the new user signs in, they will then get a new token.", cause the documentation doesn't say that, and the old documentation (GCM) explicitally says that the same token may be generated. – GVillani82 Jun 09 '21 at 09:20
  • @GVillani82 have you checked the link which I have posted in my answer. Its very detailed. Please have a look, it might be resolved your problem. – Muhammad Zahab Jun 09 '21 at 09:23
  • https://stackoverflow.com/questions/37974658/how-to-put-multiple-project-number-sender-id-in-google-services-json/37981412#37981412 Look at this too. – Muhammad Zahab Jun 09 '21 at 09:27
  • @MuhammadZahabAhmadKhan that's something different. There they are talking about multiple senders – GVillani82 Jun 09 '21 at 09:28
  • 1
    @GVillani82 I think you will be fine. Deleting a token will generate a new unique one and thus as long as you delete it on logout and make sure the backend replaces the token received on every login. You will be fine and will be able to support multiple users. – che10 Jun 09 '21 at 09:30
  • Ok, I will give it a try @che10 You also handle the `onNewToken` I guess. I am also wondering if calling `Firebase.messaging.token` multiple times will not affect the generated token, once a token is already available. Correct? – GVillani82 Jun 09 '21 at 09:32
  • I believe so @GVillani82 You can also probably test this hypothesis by generating token again and printing it to log. As I said in [this link](https://firebase.google.com/docs/reference/android/com/google/firebase/iid/FirebaseInstanceId) it mentions the scenario under which the token remains stable and unless it is one of those situations the token will still be the same. – che10 Jun 09 '21 at 09:35