Receiving old push token after app reinstall

[axylophon]

Hi,

i have discovered a problem at least on iOS. I have not tested it on Android if the behaviour is the same. If I undestand it correctly the push token should change at each app installation.

1. Install the app for the first time. We have an onboarding process where we ask for notification permission, access the push token and send it to our backend. Everything is working fine here. See #175.
2. Uninstall the app
3. Install the app. We are still logged in because the SecureStorage is used and the data is synced with the Keychain.
4. We check via the IVersionTracking of Maui if it is the first app start. If yes we redirect directly again to our notification onboarding, access the push token and send it to our backend. But we always get the "old" push token which was used in the last install. This token is not working anymore. If we delay accessing the push token or do it at the next app start we are mostly getting the "new" push token which is working fine.

Why is directly after the app start the old push token delivered? Does it take some time until it is updated? Is there maybe an event to get notified if the push token changes? That would be a nice addition and would increase robustness.

Some additional information:

We are using a .NET MAUI Blazor Hybrid App. All of the logic is happening inside the Blazor application and we communicate with Interfaces to enable for example accessing the push token.

We additionally access the push token every 7 days when starting the app and send it to our backend. Google recommends 30 days.

Kind regards Alex

[YaroslavG]

@axylophonI I had the same issue. The problem was solved by the fact that I called the method too early to get the device token. I moved this method to another place and my problem was solved!

[TobiasBuchholz]

The token gets generated by the native sdk and in the documentation you can read the following regarding to its changing behavior:

Also, it's important to save the token to the server and update the timestamp whenever it changes, such as when:

The app is restored on a new device The user uninstalls/reinstall the app The user clears app data.

So I think the behavior you are describing isn't related to the Plugin.Firebase package. But you can try @YaroslavG proposal to solve the problem.

Furthermore there is already the TokenChanged event that gets invoked when the fcm registration token has changed: https://github.com/TobiasBuchholz/Plugin.Firebase/blob/d32f3c12c3264ae599e9065dd82ea7641e0e6f98/src/CloudMessaging/Shared/IFirebaseCloudMessaging.cs#L52

[axylophon]

Ah thanks for the event. If we have more problems in the future regarding outdated tokens we will try to use this event for our token updates.

In the meantime we will delay updating the token to mitigate the issue.

Still it is weird that the same token is delivered after the app reinstall.

[angelru]

@axylophon Does this plugin work correctly with a blazor application from what I see? I imagine you create the UI with blazor, right?

[axylophon]

Hi,

yeah we have a Blazor Hybrid application. In the Maui Mainpage is one BlazorWebView which hosts a full Blazor application.

We use Interfaces and DI to get the access token for example via a service or control the permissions. Sending the access token to our Backend is then done inside the Blazor Application.

[angelru]

@axylophon And how is performance going? Is there any delay in the user interface when using Blazor? I know these questions are outside of this question, but I was curious. Since .NET MAUI has some design limitations

[axylophon]

I have no comparison to normal Maui applications.

Performance is fine at the moment. I think it is faster than WASM Blazor in normal browsers.

We had the most issues with the WebView. We had some problems with permissions (JS camera access) and opening links. But we solved that so far.

Another issue is the navigation interaction between Maui and Blazor (Android Back Button, Close...).

Also you have less freedom with animations.

The rest were normal Web rendering issues like in the Browsers.

[andyzukunft]

Just adding my two cents: It sounds to me as this is not an issue of the library. If you receive an outdated token after reinstallation this seems to be an issue with Google (at least: mostly).

Can you elaborate what "delay" means specifically? I myself retrieve the token as soon as the app starts however I also subscribe to the TokenChanged-event. I would need to test if this works properly after a reinstallation.

Is there a reason it should not be retrieved on every app start?

[axylophon]

Hi, the delay we use currently is ~20 seconds. After that timespan i saw less outdated tokens after the reinstall.

Google recommends in its documentation a token update every 2 months. "There is no benefit to doing the refresh more frequently than weekly".

We need to call our backend to store the token. Also I am not sure if there is any impact/network call if calling the GetTokenAsync method at each start?

[andyzukunft]

Does "token refresh" mean they provide a new token? If not querying for an updated token every 2 months would be ... far too late?

I would assume GetTokenAsync() does get the current token from FCM - so there should be network traffic but this shouldn't be a problem.

I store the provided token at the backend as well. However the mobile app stores the token on in Secure Store - after retrieval of a token from FCM (on startup, on change) I know if it is changed from the last one and only a new one is re-submitted to the backend.

[axylophon]

This is the documentation:

https://firebase.google.com/docs/cloud-messaging/manage-tokens?hl=en#ensuring-registration-token-freshness

The token should normally never change. Only when reinstalled, reinstalled on a new device or data is cleared by the user.