[aerogear-dev] FCM topic: use on alias as well ?

[Daniel Passos]

On Tue, May 30, 2017 at 2:33 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Tue, May 30, 2017 at 11:27 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>> On Tue, May 30, 2017 at 4:04 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> on FCM related push, we do, in our client SDK, automatically subscribe
>>>> a client to an annoymous topic, matching our immutable variant ID.
>>>>
>>>> If users are specifying categories, we do map those into topics as well.
>>>>
>>>> This is the related code in our Android SDK:
>>>> https://github.com/aerogear/aerogear-android-push/blob/maste
>>>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/and
>>>> roid/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>>>
>>>> How do people feel about doing that for the alias as well ?
>>>>
>>>> In the past we did not do it, since topics used to be a more restricted
>>>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>>>> even limiting the number of max. subscribers?
>>>>
>>>> However, that changed, and I think it would be nice if we just use the
>>>> topics for each alias of the app as well. This would speed up the time to
>>>> deliver the push request to the FCM backend, since the UPS would no longer
>>>> need to look up the device, a push, regardless how many devices, means one
>>>> small HTTP to Google, per alias (aka topic)
>>>>
>>>> Any thoughts ?
>>>>
>>>
>>> So there is a concept of "device groups" in FCM which are devices owned
>>> by the same logical user.  I think that might be a more interesting knob to
>>> twist than more stuff on a topic.
>>>
>>
>> any link ? ;-)
>>
>>
>
> So I think I might be overstating and misremembering, but this :
> https://firebase.google.com/docs/cloud-messaging/android/
> device-group#sending_upstream_messages_to_device_groups looks promising.
> Basically if I am reading the doc right I can send a message from one
> device to the others using device groups, and this message could be a read
> receipt that closes the other notifications when it is received.
>

I think you are right, it isn't some UPS should but, it's something device
will do.
More detail in the video => https://youtu.be/gJatfdattno?t=675



>
>>> Also we might want to start considering how we can handle keeping
>>> notifications in sync across devices.  FCM has capabilities for sending
>>> "read receipts" to other devices to dismiss notifications that were handled
>>> on a different device and I think it leans on the device group APIs I
>>> mentioned to do that.  But this is all based on my feeble memory ;)
>>>
>>
>> for sure, something we could do in the future, with a new server
>> component. i dont want ups to keep track of all of that.
>>
>> ideally push just sends push... and writes status to kafka, than others
>> read and do what they want, e.g. metrics, sync etc
>>
>>
>>>
>>>
>>>>
>>>> NOTE: There is a general limit of topic abuse, but that's on the app
>>>> instance (see [1]), so our APP Developers need to make sure they don't go
>>>> crazy w/ a gazillion of categories ;-)
>>>>
>>>> -Matthias
>>>>
>>>>
>>>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/28dae86c/attachment.html