Realtime DB design pattern for FCM token storage - and is the documentation up to date?

[Pete Huitsing]

Hello,

We saw the document at https://developers.google.com/cloud-messaging/registration - does this lifecycle stuff still apply for FCM as well as GCM? Basically we’re interested in the lifecycle of push tokens for each device.

Assuming that documentation is still relevant, is this a reasonable way to handle device tokens in FB database?

    // Push notification tokens. Every time we get a new token generated on client, push it here

    // Server/worker will send push notifications to every one of these tokens for the user

    // Server is told when a token is old via response from FCM service, and server will update/delete old token - is this true?

    // read this: https://developers.google.com/cloud-messaging/registration

    FCMTokens:

        "UUID1":

            "TOKENVALUE1":

                "lastIssued": Firebase.ServerValue.TIMESTAMP

            "TOKENVALUE2":

                "lastIssued": Firebase.ServerValue.TIMESTAMP

        "UUID2":

            ...

What’s the right way to handle expired tokens? Still in line with the GCM article above?

If we send to multiple tokens in a single FCM API call, does it tell us which ones are expired, etc, one-for-one?

Are there any example/sample firebase apps that implement FCM according to best practice?

Thanks for any insight! We’re right in the middle of this, going well so far but some confusion here.

[Kato Richardson]

Hi Pete,

I assume you want to store registration ids (instance ids). This is a totally sensible thing to do and any substantial FCM user needs to do this. The Database is a fine place to store them, perhaps as part of user profiles, etc.

Topics are good if the client wants to always send to the same group. if they want to send to specific individuals then topics are the wrong answer.

Regarding registration expiry:  You should implement the documented instance id API to get the token and also implement the onTokenRefresh() method on your clients.

Store the tokens in the DB of your choice and use those to target individual users. If you want to target large groups of users with common notifications, subscribe them to Topics.

Whenever they get a new token (because of onTokenRefresh() or their app deleting and getting a new token), you should always update the db with the latest token. This is necessary because tokens can be revoked from time to time and, in iOS, the token will change after an APNS id is successfully issued, so it's important to monitor for token refresh and update with any changes.

I hope that helps!

☼, Kato

[Pete Huitsing]

Thanks Kato,

I have some additional questions, though, on edge case:

What if our user logs in with multiple devices? An iPhone and iPad for example? We then have >1 legitimate device token per user, and legitimately want to push to >1 token per user. In this case, you can't have the client deleting the old token and saving the new one, because there are several legitimate tokens. Or, consider a user uninstalling the app, so that the app never had time to delete it's own current token.

To address these, my interpretation of the old GCM documentation (https://developers.google.com/cloud-messaging/registration) is to do the following:

1. Have the client push new tokens, as they come (from `onTokenRefresh()`, etc) into the database

2. Have our server send the push notification to EVERY token on the list.

3. The response from GCM will tell our server which tokens are valid, which are invalid, which are canonical, etc

4. Our server then cleans up the invalid ones

So then we have these questions still:

1. Is this best practice for the old GCM?

2. If so, does FCM do these same things (telling you which tokens are old, which are new, etc)

3. If so, is there any sample code of "hitting the FCM service, and parsing the response for good/bad tokens, and doing the grooming" (this would be really nice sample code to have available), or documentation about the way the response looks?

Thanks!

[Kato Richardson]

It seems reasonable to store a list of devices for each user. I hadn't thought of that, but it doesn't seem like an edge case so much as a better design. I think you'd need to have some clue which key is being utilized by each individual device as you probably need to know the old and new in order to make the refresh/updates work.

Your idea of just pushing to all and removing the invalid ones sounds like a great approach. I don't know enough about how that situation is handled by the FCM service--you may be the expert here : )--but assuming you get an error for the old device tokens, that seems solid.

1. Is this best practice for the old GCM?
2. If so, does FCM do these same things (telling you which tokens are old, which are new, etc)

No idea on this. Hopefully somebody a bit more experienced will chime in.

3. If so, is there any sample code of "hitting the FCM service, and parsing the response for good/bad tokens, and doing the grooming" (this would be really nice sample code to have available), or documentation about the way the response looks?

Great idea. I'll take that back as a feature request.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/a1c85b21-f888-49df-b657-689ad3307594%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398