GCM主题或下游消息 [英] GCM Topics or Downstream Messaging

查看:96
本文介绍了GCM主题或下游消息的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试将GCM添加​​到我的应用中,该应用是包含Feed,帖子和评论的常规社交应用之一。认为Facebook。



我阅读发送消息到主题的帖子: https://developers.google.com/cloud-messaging/topic-messaging 其中说:


基于发布/订阅模式,主题消息传递支持每个应用程序高达100万美元的订阅。 百万订阅的主题其实很少。



如果订阅了不同的帖子,这可能会很快用完。例如,通过脸书,每次你评论你的朋友的帖子,它的订阅。当下一个人评论或喜欢这篇文章时,您会收到通知。



我正在考虑是否使用GCM主题实际上是一个好主意。为了解决这个限制,我宁愿使用正常的下行消息,因为它似乎没有配额: https://developers.google.com/cloud-messaging/downstream



我对下游消息中的一件事感到困惑尽管 - 每次发送下游消息时,都会发出POST请求:


HTTP POST请求



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


{data:{
分数:5x1,
time:15:10},to:bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1 ...}

在这篇文章中,我们被告知这些是发送下游消息t时可用的消息选项o客户端应用程序: https://developers.google.com/cloud-messaging / http-server-ref#下游



to 部分是Google要求的。



为了多播下行消息,您还需要为 registration_ids 指定一个字符串数组。


该参数指定接收多播消息的设备(注册令牌或ID)列表。它必须包含至少1个和最多1000个注册令牌。


如果我要将消息多播给人员A,B和C ,我会将A,B和C的注册令牌放入 registration_ids 数组中,但是我会将哪些内容放入请求的部分? p>

解决方案

主题与下游



100万订阅确实使话题消息或多或少毫无意义。我只在具有相当小的目标群体的应用中使用它,我使用它发送发送给所有客户端的一般通知。在这个特殊的用例中,它非常好用,因为这样我就不必关心保存注册ID了。



在你的情况中,我认为目标组会比较大,因此您需要下载大多数通知的消息,以便将订阅数量限制在限制范围内。



而且,如果您也有网络应用程序Facebook),那么你将不得不在你的web应用程序中订阅这个主题,据我所知,这是不可能的,但是将该帖子与你用户的正常ID链接不会是一个问题,并且通过你自动地知道其他人以某种方式更改帖子时喜欢/评论帖子的所有用户的注册信息。

最后一个提示:想想已经评论过帖子的用户,并因此成为该帖子的订阅者。当您使用主题并且该用户第二次评论该帖子时,他/她会收到某人发表的评论该帖子的通知(这是毫无意义的),并且您无法将他/她从他触发的通知中排除 - /她。因此,您需要每个用户和每个帖子的主题,这反过来会像使用用户的注册ID一样。



我的结论:如果您有一个小应用程序/目标组,主题消息只会有帮助,并且在使用时,您需要确保用户无法通过显然不感兴趣的信息检索通知。

下游参数



如文件所述,用于与单个收件人或主题通知的通知。只要您有多个注册ID,您需要 registration_ids 。当尝试触发两个参数设置的通知时,您将从GCM中检索到服务器错误:
$ b blockquote>

必须使用registration_ids字段或到,而不是两个

(在文档中找不到它,只是试了一下)


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?

解决方案

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)

这篇关于GCM主题或下游消息的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆