0

Does Instance ID service initiate callback onTokenRefresh() on app upgrade?

Reference doc states that "Tokens are unique and secure, but your app or the Instance ID service may need to refresh tokens in the event of a security issue or when a user uninstalls and reinstalls your app during device restoration. Your app must implement a listener to respond to token refresh requests from the Instance ID service."

  1. Can anyone confirm if token refreshing has to be handled by app or Instance ID service initiates callback onTokenRefresh() on app upgrade?
  2. If its handled by Instance ID service, how is token refresh scenario handled after upgrade if old app uses old library for gcm registration(gcm.register) and new app uses new library(Instance ID)
garnet
  • 551
  • 5
  • 12
  • the library's service will inform you when the token has changed via that callback. It is up to you to process it on your server or wherever – Tim Jun 07 '17 at 12:16
  • Hi Tim, yes, that is clear from the documentation. But, the question is will GCM registration token change on app upgrade which will in turn result in the callback being invoked? In the previous gcm library, app update had to be handled separately in app as mentioned [here](https://developers.google.com/cloud-messaging/android/legacy-regid#implementing-register-in-a-client-app). But, the new library [doc](https://developers.google.com/instance-id/) does not say anything about app update use-case. – garnet Jun 07 '17 at 12:25

1 Answers1

1

  1. onTokenRefresh() only triggers for specific reasons, where updating the app isn't one of them. See my answer here.

    The link you mentioned in the comments is the deprecated way of generating a registration token (GCM2/waaay old GCM), which is different from InstanceID generated tokens (preFCM and FCM). See Ian Barber's answer here.

  2. I'm not sure what you're asking here. The way I understand the flow is FCM identifies if the token needs to be refreshed, if yes, it calls upon the InstanceID service (separate from the client) to generate a new one. As soon as it generates the token and the app goes online, it would trigger onTokenRefresh() to let you know of the new token. What you do with the token depends on you.

Simple as that. No special scenarios AFAIK.

Community
  • 1
  • 1
AL.
  • 36,815
  • 10
  • 142
  • 281
  • Your answer to second part of question is essentially not to handle app upgrade scenario [old app uses old library for gcm registration(gcm.register) & new app uses new library(Instance ID)]. Since I couldn't find any migration guide, we went with re-registration with GCM during this app upgrade. [This](https://stackoverflow.com/questions/32835851/migrate-from-gcm-2-0-to-gcm-3-0-instanceid-api) suggests the same for c2dm to gcm3.0 migration. For subsequent app upgrades, we do not do any re-registration with GCM since it is clear from the documentation that token does not change on app upgrade. – garnet Sep 04 '17 at 15:52
  • @ian-barber Since you work at Google, could you please answer 2nd part of my question? AL. may be right. But, I could not find any official migration guide for this scenario. – garnet Sep 04 '17 at 16:03
  • If the app upgrade is from preFCM to FCM, then there's no need to handle it. Both versions use the same InstanceID service. The re-registration in the C2DM-to-InstanceID was the right approach AFAIK, since those are two different services. There is no migration guide for the tokens since you don't need to migrate them, the tokens are [backwards/forwards compatible](https://stackoverflow.com/a/42337465/4625829). – AL. Sep 04 '17 at 16:20
  • 1
    PS: You won't be able to tag a user if he hasn't interacted with the post yet, so tagging Ian Barber here won't notify him. I only use the <@username> when *styling* my answer. – AL. Sep 04 '17 at 16:22