Best practices for FCM registration token management clarification

user_9086770 0
Viewed 736

I'm reading through FCM token management best practices in the documentation (https://firebase.google.com/docs/cloud-messaging/manage-tokens) and have the following questions.

On initial startup of your app, the FCM SDK generates a registration token for the client app instance... your app should retrieve this token at initial startup and save it to your app server alongside a timestamp.

Is the recommendation here to handle the token on app launch or just the first time the app is launched on install? Because I can't imagine given how many server interactions there are in the typical life of a client process that we wouldn't just update the token every time the app is launched and call it a day instead of creating additional tasks to keep these tokens fresh.

We recommend that you periodically retrieve and update all registration tokens on your server.

Is the recommendation here to null stale tokens?

We recommend that you periodically retrieve and update all registration tokens on your server. This requires you to add server logic to update the token’s timestamp at regular intervals, regardless of whether or not the token has changed.

I don't understand what this means. Is the recommendation here to task the server with updating a token's timestamp? What does this accomplish? And is the server capable of generating a token for a client?

firebase-cloud-messaging firebase
2 Answers

According to the docs, as I understand, you have to :

On client side :

  • Store the token on your server on first launch (your server will consider that your token is valid for 2 months)
  • Update your token on server if it changes
  • Update your token at least one time each month on your server if he hasn't changed (this will refresh the token validity on your server for two months again)

Basically to implement this you can store your token and its last refresh date in a storage to see when it changes or needs to be refreshed.

On server side:

  • When a new token is registered store the token in your database and set his validity for 2 months (if the token already exist in your database then just reset his validity for 2 months again)
  • When a notification send fails, then remove the invalid token from tour database
  • Delete from your database expired tokens (token older than 2 months). You can do it periodically or before any token utilization.
user_168054110

The token is generated only when you first launch the app after install, and in some reset events. So your token will stay mostly the same, it won't change in every app launch. The timestamp is what the server will check. Maybe this will help:

First Launch

  1. Token generated, send to the server with timestamp

Regular Launch

  1. Token retrieved(same token), send again to the server periodically (2 Months?)

Now, this is where it gets hazy. As far as I understand, the server should signal the app in some way to get the token again (even if it is unchanged) to refresh the token in the server database and then refresh the timestamp.

user_81903270
Related