I'm migrating to Firebase Cloud Messaging, and I have one doubt.
My application must show the login screen when launching, and if the user performs login in another account, I must stop send notifications for the older user.
What's the best way to do that?
Can I force the application to renew the token?
Or should I update the token's owner in my base by my own?
Inside application You should renew Instance ID token and forget about the old one if You don't want to get notifications being sent to the old token. On every logout and login just take new Instance ID and update Your external database (in case Your application logic need it) with information about new token being assigned to that user :) There are no limits for generating new tokens and You cannot reuse once dropped tokens.
Renewing token is just calling getToken() again.
This is the best approach because InstanceID is in fact assigned to the "application instance" so in case of app reinstall on device or removing cache by user You'll have to get new token anyway.
In one of the apps I developed, I handled it on my app cloud.
Cloud had two tables, a table with device ids a user is logged in with and another with instance ids assigned to devices.
What you can do is, as user logs out from a device, remove that device id from users device list and as a new user log in you add a device id to his devices.
When sending notifications you can devices with tokens and everything else will streamlined
Related
This question already has an answer here:
When to register an FCM token for a user
(1 answer)
Closed 4 years ago.
Is a firebase token ID based on the device's characteristics, such as IMEI for phones, MAC for PC, etc.. ?
My primary concern is the following:
Multiple users use a given device to access the same app ( Think FB ).
User 1 logs to the app and Firebase provides a token ( E.g. FirebaseInstanceId.getInstance().getInstanceId() ).
User 1 does a logout
User 2 logs in.
Is the same Firebase registration token from #1 going to be used now for User 2?
Is a new firebase ID generated for User 2 or is this something that needs to be handled manually by the app itself?
I have the feeling that this is more a responsibility of the app developer where they monitor who logs in and so forth and the old registration ID is cancelled while a new one is generated for this new login ?
Just to clarify - I only use Firebase Cloud Messaging and nothing else from Firebase so I will be managing the notifications from my own server. This means that I will be storing the Firebase registration IDs in my own database to know for which Firebase Registration ID to generate a notification (e.g. user receives a message from another user), for example.
According to the Firebase Docs:
The registration token may change when:
The app deletes Instance ID
The app is restored on a new device
The user uninstalls/reinstall the app
The user clears app data.
This means the token won't change when user 1 logs out. A work-around would be calling deleteInstanceId() on user log out. This will delete the current Instance ID and a new Instance ID will be generated asynchronously if Firebase Cloud Messaging auto-init is enabled.
Please note that the docs also mention this is a blocking function so do not call it on the main thread.
I have some doubts about implementing Firebase Cloud Messaging in my app.
My app is a chat similar to whatsapp and facebook messenger. Right now every time someone logs in I register the token and relate it to the user. So if someone wants to chat to an user the app searches the Db for the user ID and there I have his token.
I'm able to register the device token but I'm not sure when should I do that.
In my chat users register through a mail/password signup and is possible that an user could login in other device.
For example:
User Frehley uses a Galaxy 8 and is able to chat and receive notifications in his device using the token. But lets say that he loges in another device. I need to register the token again and relate it to him right?
So, maybe I'm wrong but the best moment to register the token is every time the user logs in and replace it in the DB. Right?
Now, lets say two users (Frehley and Stanley) uses the same Galaxy 8 to login, the token will be diferent everytime the login or it is the same for every single device?
This all depends on the use-case:
If the same user is logged in to two devices, do you want them to receive the notification on both devices? If so, you'll need to store multiple device tokens per user and send the notification to each token for the targeted user. You could also use a device group to identify the devices for a single user. From those docs:
With device group messaging, you can send a single message to multiple instances of an app running on devices belonging to a group. Typically, "group" refers a set of different devices that belong to a single user
If you want the user to only receive the notification on the device that they were last using, you'll have to associate a single token with each user and overwrite that when they start the app on a device. Not that this is not necessarily when they log in, but more likely when the app detects that they're authenticated.
If a different user uses the same app on the same device (using the same device profile), you probably want to stop sending to the device token. The most robust way to do this is to remove the association between the previous user and the token, but that may require that you keep a mapping from token to UID. An easier way is to delete the device token when a user signs out. Then the new user signs in, they will then get a new token.
I know this has been discussed before, but the only solution I found (canonical IDs) don't work in my scenario.
Scenario:
User installs App and registers with his user account A
User gets push notifications meant to be delivered to this specific user account A
User uninstalls the app
User reinstalls the app
User registers with a different user account B
Now notifications are delivered for both user accounts. From my understanding, using cannonical GCM Reg IDs would only consolidate those IDs and prevent sending duplicate notifications. In this case the App gets notifications for a different user that shouldn't be delivered at all.
Is there any fix for that? Only thing I can think of would be actively deregistering when uninstalling the app, but in another thread I read, it's not possible to execute code on deinstallation.
From my understanding, using cannonical GCM Reg IDs would only consolidate those IDs and prevent sending duplicate notifications.
That's one way of looking at it, but on a simpler note, Canonical IDs are like saying "old ID you used is expired, delete it (if you saved it) and use me instead".
The thing that makes this a bit odd is that, when the user uninstalls the app, the InstanceID should be invalidated. (see the docs here).
What I think you can do to make sure that tokens are deleted, you can call deleteInstanceId() to revoke all tokens, then re-register.
But to make sure that the message is for the intended user, you can refer to what is stated in the docs (first one similar to what #Ak9637 said):
To make sure that messages go to the intended user:
The app server can maintain a mapping between the current user and the registration token.
The client app can then check to ensure that messages it receives match the logged in user.
You can simply check ,when registering in your tokens database,when u receive token of user B , just check if it is already associated with any user or not, if it is simply nullify that field and save the new token to new user.
As token identifies the device not the user.
If you wish to take total autonomy and control of notifications related to your app, You should use data notifications instead of message notifications , this will avoid the OS handling the notifications instead of your app
I want to store FCM token in my android app user's table in database when user register to the app . When i want to send notification to specific user then i will fetch Token from corresponding row and send push notification.But i am confused that whenever app user logout from his app and register new account from same device ,then there will be two row and hence two Token for same device on database. How to handle such case? What happen to old Token in device? please anyone can help me??
The Instance ID token used to send FCM messages represents the instance of and app on a device. The current user of the app would not affect the token that represents the app instance. Uninstalling and reinstalling the app would cause a new token to be generated but not for in app behaviour like switching users.
You should still remove the mapping of the token to the user on logout and add a new mapping with the same token to the user that logs in but it will be the same token.
I probably feel this may help you,
When user logs out clear his device token and make him Logout so that he won't be able to receive the updates and hence only one user at a time can get the updates
I'm a bit confused about how to manage registration ids for all app installations.
In the app server database I have a User table and a UserDevice table. Every User may have many UserDevices. Each UserDevice have a registration id. So when a user should be notified I send the message to all the registration id's for all the devices of the user.
But when the application is reinstalled, Android is updated or something else happens that causes the registration id to change, the app will send a new registration id to our app server. But I have no way to know if this is a new device or if an existing UserDevice should be updated with the new registration id.
How is this supposed to be handled? My first thought is to send a persistent hardware ID as well as the registration ID, but perhaps there is a better way?
You don't have to worry about this. If the user does reinstall the app and the token is refreshed just add it to the users list of tokens (keeping the old one for now).
next time you send a notification to this user it will fail on the token that is no longer used. Now all you have to do when you get the fail reply from google is remove that token from your devices table.
Remember if you fail to send to a token for reasons such as invalidRegID or NotRegistered then the GCM will/has unregistered that token so it is no good so it needs to be removed from your list otherwise you will get in googles bad books for repeatedly sending to the same failed token. So remove ones that fail.
when my apps start i always check to see if the device is registered if it is I send the same token to my app server just incase it somehow got deleted.
Hope this helps
You could take a look at GCM's Device Group feature, which is explicitly intended for the "one user, many devices" problem:
https://developers.google.com/cloud-messaging/notifications
I use PushSharp and there I can use the different event handlers that are defined to handle subscription changes or expirations. The source code is available on github https://github.com/Redth/PushSharp/blob/master/PushSharp.Android/Gcm/GcmPushChannel.cs
You can probably apply the same logic to your application.