Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QUERY] Why are my Android devices (sometimes) coming back as unregistered? #225

Open
2 tasks done
tkyle opened this issue Sep 16, 2021 · 1 comment
Open
2 tasks done

Comments

@tkyle
Copy link

tkyle commented Sep 16, 2021

Query/Question
This may not be the correct place to ask this question, but I'm trying to figure out an issue I'm having with Android devices using Azure Notification Hub in a Xamarin application.

In particular, I'm having an issue where my Android devices will suddenly stop receiving notifications. Sometimes this happens immediately upon app installation, and other times it can be several days after the app has been installed and they've previously been able to receive notifications.

If I take the installation id of an affected device and try to message that device using cURL it will tell me the device isn't registered. If I try to message that installation using the Azure Portal it will tell me that the message was successfully sent, but that there are no matching targets. It's as if the token has been changed or invalidated, but I wasn't aware of this change.

It has been my understanding that a token is generally only created or changed if an app is newly installed, uninstalled/reinstalled, the user clears their data, or if a phone is restored. None of these things are happening here. A user is able to receive notifications one day, and then unable to receive them the next after making no changes.

I have the FirebaseMessagingService set up in my code. I have the OnNewToken() method overriden. In this method I save the token received to the local device. After the app boots up it checks for this token and uses it to query our database to see if we have a record of this device. If we do not then we save off that device information and register the device with the Azure hub. This all seems to work as expected. I would think that if the token is being invalidated on the Firebase side that OnNewToken() would be called again and that process could start over. Is that not how it works? Do I need to explicitly check for token changes when the app boots outside of OnNewToken() being called to account for this situation?

Also, if I am correct that a devices token is being invalidated or expired for some reason, why is that? The documentation for FCM best practices in regard to tokens seems to suggest that I'd only have to worry about updating tokens every month or two to avoid stale tokens. My devices will stop receiving notifications sometimes in 24 hours or less.

Setup (please complete the following information if applicable):

  • OS: Android 10 and Android 11
  • IDE : Visual Studio
  • Version: 0.6.0

Upon posting this question I did notice that my nuget package is woefully out of date, and maybe that has somethin to do with it, but I would still like an explanation for my issue if possible.

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

  • Query Added
  • Setup information Added
@aziztitu
Copy link
Contributor

@tkyle You are correct in the fact that the tokens do not expire in a few days, and that handling the "onNewToken" method should generally be enough to account for token updates. But it is generally also a good practice to fetch the device token, and update the installation on app startup.

If you are still experiencing this issue, please provide us your namespace and hub name, and we can further look into what might be causing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants