Reputation: 1311
From the official documentation I understand that the way it works is something like this:
What if at the same time this user installs app on the other device - should I store multiple tokens per user on the app server? If yes - that means there should be something like checking for which ones are expired?
Upvotes: 23
Views: 18904
Reputation: 1032
What I am doing is similar to what you mentioned. I am storing multiple tokens per user in Firestore. And whenever I send the message using those tokens from my backend/cloud functions, I just delete/invalidate the ones that are expired.
Check out this simple answer to invalidate the expired tokens: How to invalidate 'expired' Firebase Instance ID Token
I am using this schema to store the tokens
{
"user_id_fk": <firebase auth user id>,
"fcm_tokens": [
<token 1>,
<token 2>,...
]
}
I am sending the user Id and token to firestore whenever user does a login or registers, if the token doesn't already exist in the "fcm_tokens"
list above, in database. For each user id there will be only 1 document in the collection in Firestore.
This strategy should handle all the cases like when user uninstalls the app without logging out, logs in to multiple devices etc.
Upvotes: 0
Reputation: 524
Graykos, You can do sth like this:
Each time a user have a new login, get a new token from google, and when logout delete that token (Edit note: Close app & run it again, not called a new login and it's not create a new token). So if user login from multiple device/browser OR multiple user login from one device/browser one after the other, you can nicely handle all of that.
in this way "multiple user login from one device/browser one after the other", all of them have the same token (so delete and renew for each login)
As Andres SK mentioned in the first comment of your question, you can delete the token when failure happen (maybe the lost device that user cannot logout from).
Upvotes: 3
Reputation: 407
I came across the same problem, How I tried to solve this is to maintain a data structure like this. And save this data to my notifier server's database.
type UserToken struct {
UserId string
Tokens []DeviceToken
}
type DeviceToken struct {
DeviceName string
Token string
}
Whenever you get a new device token from firebase just replace the existing one with new one for that device.
And for the web part I think storing the last one is enough.
Upvotes: 1
Reputation: 111
I have a similar situation and found out the following error response code when trying to send to an expired token:
{
"error": {
"code": 404,
"message": "Requested entity was not found.",
"status": "NOT_FOUND",
"details": [
{
"@type": "type.googleapis.com/google.firebase.fcm.v1.FcmError",
"errorCode": "UNREGISTERED"
}
]
}}
My app server accepts multiple tokens per user assuming they use multiple devices. When sending a new message, I will try to send it to all tokens related to the user. Those that return this error will be deleted so future message will only be sent to active tokens.
Upvotes: 1
Reputation: 585
I also came across the exact challenge and had to resolve to a solution: Storing each token for the user against the device id. It's interesting enough to know that this function in fact exists in the firebase messaging method. But more surprising is the fact that there's no documentation to handle such scenario. https://firebase.google.com/docs/reference/android/com/google/firebase/iid/FirebaseInstanceId.html#getId()
Summarily, while sending the new token to the server, also send along the device id returned by the getId() method and use it to enforce uniqueness of token per device.
And to also apply this solution while taking advantage of device grouping feature of FCM, you can make a server request on the FCM group, in order to delete the old token on that device-id before replacing it with the new.
Upvotes: 12
Reputation: 37768
What if at the same time this user installs app on the other device - should I store multiple tokens per user on the app server?
Yes. A user could have multiple devices, a case where Device Groups are commonly used.
If yes - that means there should be something like checking for which ones are expired?
If a token expires, a callback is triggered (onTokenRefresh()
for Android), from where you'll have to send the new token to your App Server and delete the old one corresponding to the user/device.
Upvotes: 5