7

While working with Firebase and Device Groups, I was testing the case in which the token (registration id) changes (for example after reinstalling the app) but my logic failed because after reinstalling the app i have no more way to know the previously stored token .

The problem is that now I have a device group with two "ghost" registration ids that I don't know anymore because they changed.

I know the group get removed after every member has been unregistered but i don't know the registration ids to unregister them manually.

What can I do?

Is there a way to retrieve the members of a device group or deleting it at once?

Also, what is a good way to manage the case in which the token gets refreshed ?

AL.
  • 36,815
  • 10
  • 142
  • 281
MaX
  • 489
  • 7
  • 18

1 Answers1

7

I know the group get removed after every member has been unregistered but I don't know the registration ids to unregister them manually. What can I do?

When you send a message to a device group, you'll receive a response that contains a success and failure parameters. 0 value for `failure means that the messages we're queued properly in the FCM servers.

It there were failed messages, the list of registration tokens that failed will be in the response, where the advise is to retry sending the message. Referring to the docs:

Sending downstream messages to device groups

Sending messages to a device group is very similar to sending messages to an individual device. Set the to parameter to the unique notification key for the device group. See Message types for details on payload support. Examples in this page show how to send data messages to device groups in HTTP and XMPP protocols.

HTTP POST Request

https://fcm.googleapis.com/fcm/send
Content-Type:application/json
Authorization:key=AIzaSyZ-1u...0GBYzPu7Udno5aA

{
  "to": "aUniqueKey",
  "data": {
    "hello": "This is a Firebase Cloud Messaging Device Group Message!",
   }
}

HTTP Response

Here is an example of "success"— the notification_key has 2 registration tokens associated with it, and the message was successfully sent to both of them:

{
  "success": 2,
  "failure": 0
}

Here is an example of "partial success" — the notification_key has 3 registration tokens associated with it. The message was successfully sent to 1 of the registration tokens only. The response message lists the registration tokens that failed to receive the message:

{
  "success":1,
  "failure":2,
  "failed_registration_ids":[
     "regId1",
     "regId2"
  ]
}

When a message fails to be delivered to one or more of the registration tokens associated with a notification_key, the app server should retry with backoff between retries.

However, before you perform a retry, you could first verify if the FCM token is still valid (either by using dry_run or the Instance ID Server API). If it shows that the device is no longer valid (usually NotRegistered, you should then remove that token from the device group and from your App Server (or move it to a trash logs or something).

Also, what is a good way to manage the case in which the token gets refreshed?

If the token gets refreshed (through onTokenRefresh()), the thing to do is to find the old token the user has and replace it with the new one, applying the changes where it matters (which is also mapping the device groups).

Also see my answers here and here. Some details might be helpful.

Community
  • 1
  • 1
AL.
  • 36,815
  • 10
  • 142
  • 281
  • Wow very clever to leverage the failed ids! i didn't think about that. Regarding how to manage the refresh of the token i came across one of your answers: [link](http://stackoverflow.com/questions/40140201/handling-refresh-tokens-for-fcm-device-groups/40158260#40158260) , is it still valid? would you recommend the ANDROID_ID, the MAC address or any other particular id to univocally identify a device? This looks helpful but maybe too overpowered [link](http://stackoverflow.com/questions/5088474/how-can-i-get-the-uuid-of-my-android-phone-in-an-application) – MaX Apr 20 '17 at 07:13
  • Yup. That's still valid. :) For the ANDROID_ID part, I actually suggested using the ANDROID_ID in [one of my answers](http://stackoverflow.com/a/43176326/4625829) as well. However, if your app has a login function, where users have to register, I would suggest using the userID (depending on what you use) that you have there. I think it's simpler that way. – AL. Apr 20 '17 at 07:17
  • hey sorry to bother you again but i noticed a very strange behavior while implementing the solution to deal with the refresh of the token: if the previous token was the only member of a device group, after getting refreshed it is invalidated but the group keeps existing and somehow the new token gets added to it. i can even successfully remove the new token from the group thus deleting it, or i can notify the group "waking it up" and making it to auto remove itself. does it make any sense?!? – MaX Apr 20 '17 at 16:18
  • Hey MaX. Interesting, I haven't really encountered that behavior before. I'll give it a test once I get back (*tis the weekend*). Do share any developments. Cheers! :) – AL. Apr 21 '17 at 00:19
  • I almost forgot about this. Hi @MaX. Sorry wasn't able to look into this behavior yet. Will try it as soon as I can though. Cheers! – AL. Apr 27 '17 at 03:10
  • Don't worry @AL. ! I really appreciate your help and dedication. since this looks like a very peculiar behavior i was thinking about posting another question about that, what do you think? – MaX Apr 27 '17 at 07:50
  • I think that would be great. It's also a chance for other devs to look into it and possibly answer it too (if they've already encountered the same behavior). Thanks MaX. :) – AL. Apr 27 '17 at 07:56
  • 1
    for reference http://stackoverflow.com/questions/43675411/unexpected-behavior-when-refreshing-token-of-a-user-who-is-the-unique-member-of – MaX Apr 28 '17 at 08:20
  • About: "When a message fails to be delivered to one or more of the registration tokens associated with a notification_key, the app server should retry with backoff between retries." It may sound a very dumb question, but what should be retried?, the whole operation (sending to the device group again) or sending to each indivitual failed registration (token) individually? – Juan Apr 16 '19 at 21:52
  • 1
    @Juan In my perspective, I think the retry should be to the failed tokens. If the retry is made to the actual device group, it could pose as a duplicate to the previous ones that were successful. – AL. Apr 17 '19 at 09:47