How not to deal with registration_ids?

[Júlio Cesar Bueno Cotta]

Hi, I would like to know what is the best approach to send a notification to all devices of a user.

Currently every time a user execute a login I subscribe the device to something like "user_$USER_ID" topic which I think is not the best, but otherwise I would have to keep track of all users registration_ids which is troublesome since it may be outdated.

While using the approach above (subscribe to a "user" topic ) I have to send notifications to all users available to execute a task in a given period of time... which is vary dynamic and create a topic would not help. So I tried to use conditions like 'user_1 in topics || user_2 in topics', but with the current limitations of 3 conditions it is not enough for me.

Will I have to keep the registration_ids ?

Thanks.

[Júlio Cesar Bueno Cotta]

No one can give a tip about this?  Deal with registration ids seems to be needed due to the lack of abstraction FCM could offer to developers.

[Kato Richardson]

A little more patience, please. I tracked down an answer to this yesterday, but was heads-down in code and this has been my first opportunity to circle back.From one of our FCM experts:

I don't think that topics should be used as a replacement for token management, device groups seems to be the correct solution for what the developer is trying to do (have single key that represents a user). Though there will still be some key management required to keep the device group up to date. I see that it would be easier for a developer to manage a user via a topic but as the developer sees it removes the usefulness of topics when a topic is reduced to a never expiring token.

 

So to send to all devices of a user, the developer can just send to the single device group key.

I'm also vaguely cautious that there may be a limit on the number of topics you can create (I didn't verify this). So individual topics for millions of users might be problematic.

I hope that helps!

☼, 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/cd770309-571f-4c3c-be23-28c0d5c6ec33%40googlegroups.com.

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

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Júlio Cesar Bueno Cotta]

Thanks for the answer Kato, 

Sorry if I seem to be have little patience, It is just frustrating some limitations. More than solve my issues I would like to contribute to FCM community.

A read the FCM docs before asking here and I saw the device groups option, but it seems a award solution that still makes the developer manage registration ids and it has the same problems Firebase would have with topic subscriptions AND the downside that my server would need to know about registration ids.

My app is not going to hit millions of users because it is a niche app and if some very lucky day it happens I will have a team of devs working to make push segmentation in a different way. Sadly, today, I am the app/server/business guy and I have only hundreds of users and maybe thousands in the next year.  

I bet that there are a lot of other developers out there in the same situation and they  don`t need all the power that the current model may provide, but just be able to send pushes to all devices of a user and send the same push to a group of users without the need to manage the registration ids in their own system. A userId is something all systems with authentication will have, the developer already has this identifier in their side, it (normally ) does not change, it does not gets invalidated. Firebase SDK could be the place where we associate registrations_ids and userids.

I do know that topics are not originally meant to identify a user, but it works and the client/server coding is simplified. 

If FCM had the ability to set/unset the userId (not necessarily a Firebase User Id) and send push to that user it would work just like what I am doing today.

One feature that I would like to have in FCM is that I could send in one HTTP request the same push to multiple topics.

It would mean to me the ability to reach multiple users that are linked to a short period of time with a single push instead of sending multiple requests consuming network/time and process power. I could send it to multiple registration_ids, but it does change and gets invalidated.

Well, that is just my view of the problem. I know nothing is so simple as it seems in the surface, not in the developer side and not in the FCM side.

Thanks for the attention.

 

Em quinta-feira, 1 de setembro de 2016 15:18:49 UTC-3, Kato Richardson escreveu:

A little more patience, please. I tracked down an answer to this yesterday, but was heads-down in code and this has been my first opportunity to circle back.From one of our FCM experts:

I don't think that topics should be used as a replacement for token management, device groups seems to be the correct solution for what the developer is trying to do (have single key that represents a user). Though there will still be some key management required to keep the device group up to date. I see that it would be easier for a developer to manage a user via a topic but as the developer sees it removes the usefulness of topics when a topic is reduced to a never expiring token.

 

So to send to all devices of a user, the developer can just send to the single device group key.

I'm also vaguely cautious that there may be a limit on the number of topics you can create (I didn't verify this). So individual topics for millions of users might be problematic.

I hope that helps!

☼, Kato 

On Thu, Sep 1, 2016 at 9:37 AM, Júlio Cesar Bueno Cotta <julioc...@gmail.com> wrote:

No one can give a tip about this?  Deal with registration ids seems to be needed due to the lack of abstraction FCM could offer to developers.

Em terça-feira, 30 de agosto de 2016 11:35:07 UTC-3, Júlio Cesar Bueno Cotta escreveu:

Hi, I would like to know what is the best approach to send a notification to all devices of a user.

Currently every time a user execute a login I subscribe the device to something like "user_$USER_ID" topic which I think is not the best, but otherwise I would have to keep track of all users registration_ids which is troublesome since it may be outdated.

While using the approach above (subscribe to a "user" topic ) I have to send notifications to all users available to execute a task in a given period of time... which is vary dynamic and create a topic would not help. So I tried to use conditions like 'user_1 in topics || user_2 in topics', but with the current limitations of 3 conditions it is not enough for me.

Will I have to keep the registration_ids ?

Thanks.

--
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-tal...@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/cd770309-571f-4c3c-be23-28c0d5c6ec33%40googlegroups.com.

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

[Arthur Thompson]

Hi Júlio,

We do currently expect developers to manage the mapping of tokens to users, with device groups being the best way of messaging all devices registered to a single user. It is true that you have to manage the tokens, your suggestion to have the SDK provide more support with generating/maintaining device groups is interesting, thanks for that.

You can send to multiple topics (though currently limited to a few topics) using conditional topic messaging, which you noted.

Token management does allow FCM to be really flexible, usable by apps that have auth and those that do not, however your point that many developers want to a similar type of token management that it may be worth adding that to the SDK, thanks for the feedback on this. We will investigate further.