GCM Topics or Downstream Messaging

Question

I'm trying to add GCM to my app which is one of those general social apps with feeds, posts, comments. Think facebook.

I read the post for Sending Messages to Topics: https://developers.google.com/cloud-messaging/topic-messaging which says:

Based on the publish/subscribe model, topic messaging supports up to one million subscriptions per app.

1 million subscriptions to a topic is actually very little.

That could be used up quickly if one subscribes to different posts. For example, with facebook, each time you comment on your friend's post, its a subscription. When the next person comments or likes the post, you get a notification from it.

I'm now considering whether using GCM Topics is actually a good idea. To get around the limitation, would it be better for me to rather use the normal downstream messaging as that seems like it has no quota: https://developers.google.com/cloud-messaging/downstream

I'm confused about one thing in the downstream messaging though - Each time you send a downstream message, you make a POST request:

HTTP POST Request

https://gcm-http.googleapis.com/gcm/send Content-Type:application/json Authorization:key=AIzaSyZ-1u...0GBYzPu7Udno5aA

{ "data": { "score": "5x1", "time": "15:10" }, "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1..." }

In this post, we are told that these are the message options available when sending downstream messages to client app: https://developers.google.com/cloud-messaging/http-server-ref#downstream

The "to" part is REQUIRED by google.

To multicast the downstream message, you would also need to specify an Array of Strings for the "registration_ids".

This parameter specifies a list of devices (registration tokens, or IDs) receiving a multicast message. It must contain at least 1 and at most 1000 registration tokens.

If I was to multicast a message to person A, B and C, I would put the A,B and C's registration token into the "registration_ids" array, but what would I put into the "to" part of the request?

Answer 1

Topic vs. Downstream

The "1 million subscriptions"-limitation really makes topic messaging more or less pointless. I only used it in an app with a rather small target group, there I use it for sending general notifications sent to all clients. In that particular use case it was very nice to have, because this way I did not have to care about saving registration ids.

In your case, I think the target group will be larger, thus you will need downstream messages for most notifications in order to keep number of subscriptions within the limit.

And, in case you have a webapplication too (like Facebook), then you would have to subscribe for the topic in your webapp as well, which is not possible as far as I know, but linking the post with your user´s normal id would not be a problem and via that you automatically would know the reg-ids of all users who liked/commented a post when someone else changes the post somehow.

And one last hint on that: Think of a user who already commented a post and hence being a "subscriber" of that post. When you use topics and that user comments the post a second time he/she would get a notification that someone commented on the post (which is quite pointless) and you would not be able to exclude him/her from that notification triggered by him-/herself. Hence you would need a topic per user and per post which in turn would be quite the same like just using the user´s registration-Id.

My conclusion: Topic messages are only helpful if you have a small app / target group and when using, you need to make sure that there is no way that a user could retrieve a notification with information he obviously won´t be interested in.

Downstream Params

As stated in the docs, to is used for a notifcation with either a single recipient or for topic notifications. As soon as you have multiple reg-ids you need the registration_ids. You will retrieve a server error from GCM when trying to trigger a notification with both params set:

Must use either "registration_ids" field or "to", not both

(Couldn´t find it in the docs, just tried it out)