FirebaseMessaging getToken vs tokenReceived event listener

[kyllerss]

I am hoping someone can shed some light as to best practices around collecting a push notification token. My app currently invokes FirebaseMessaging.getToken() at startup to obtain the currently-registered token.

I am assuming that when a token gets refreshed and the old one needs to be replaced, the call to getToken() should be all I need. However, I also see the tokenReceived event listener, which makes me think that a token might need to be refreshed at some time other that startup time.

First question: Is the tokenReceived event listener invoked at any point in the span of the app's lifecycle where the push notification token needs to be replaced/updated - or is it simply a stylistic option for people who prefer to use event listeners?

Second question: Any best practices around how to detect when a token needs to be refreshed/updated?

Thanks!

[robingenz]

Thank you for your questions.

1. The token can change at any time. So you should use the listener in addition.
2. Not as far as I know.

[kyllerss]

Thanks!

[andrerds]

Obrigado por suas perguntas.

1. O token pode mudar a qualquer momento. Portanto, você também deve usar o ouvinte.
2. Não tão longe quanto o que sei.

Hi, is there any example of how this implementation would look, or would it require a specific logic for that? I also thought that getToken would solve everything :( .

[robingenz]

No special logic is required. At the app launch, you request the token once with getToken() and send it to your backend. Then you listen to the tokenReceived listener and if the token changes, you send it again to your backend.

[andrerds]

No special logic is required. At the app launch, you request the token once with getToken() and send it to your backend. Then you listen to the tokenReceived listener and if the token changes, you send it again to your backend.

Thanks!