On Tue, May 30, 2017 at 12:27 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
On Tue, May 30, 2017 at 4:04 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
>
>
> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew(a)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 ? ;-)
> 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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev