I have not enough info on the GCM Topic stuff but reading your message it
sounds that we should leverage this "transparently" for the user , meaning
it just uses the UPS categories and under the hood we use the GCM topics
Like you said we have to handle the fall over if they are more than 1
million user but since we use JMS batches with counting that should not be
too hard (but Lukas should be able to give us more info on that)
On Mon, Jul 27, 2015 at 5:22 PM, Summers Pittman <supittma(a)redhat.com>
So I've got a few ideas for how to implement this, but I hope
more experienced with the platform can give some feedback before.
In UPS right now we have a concept of categories. A single UPS message
can be broadcast to a bunch of devices which are subscribed to this
category. Google now supports this for GCM on Chrome, iOS, and Android so
UPS can send a single message to GCM and GCM will broadcast that to up to a
End Quick Background
So first, how do we switch between sending a message to each device in a
category to sending a topic message to GCM?
In TokenLoader.java#L113 we are using the clientInstallationService to
build a string of deviceTokens based on the variant and message criteria.
Is there any reason we can't create a "topicToken" which will be
later by GCMPushNotificationSender? Another benefit to making this change
here is that if we have over a million subscribers to the category we can
just default to the default messaging.
There is also an open issue of whether or not we will update the clients
to filter based on what category a message was sent to. To do this we will
have to include the category information in the message when we send it to
devices going forward. In GCM a topic message includes this information.
This means that if we have over a million subscriptions in the topic we
will need to fall back to using the category information anyway.
Continuing on from the thread of falling back, it is possible for a topic
message to fail to send because there are too many subscribers. How would
UPS handle regenerating the messages as deviceToken instead of topicToken
Of course if someone has a better idea than "topicTokens" I'm all ears.
aerogear-dev mailing list