民意调查与推送 - 避免推送通知的任何理由？

Question

我刚刚继承了一个Android应用程序项目作为（技术）产品经理，它使用 5秒计时器来轮询远程URL 以查看应用程序启动的某些工作是否已完成。我当然最初的反应是建议用推送/通知机制替换它，最好是Android内置的GCM，这样就可以从手机上的应用程序中删除工作并放在服务器端。< / p>

令人惊讶的是，我遇到了开发团队的阻力。一位前产品经理（我的前任）似乎明确要求实施以这种方式运作。不幸的是，他在记录他的决定方面并不是很重要，所以我现在必须试图回顾哪些原因可能导致这个决定证明改变实施的合理性。我想出了以下专业和反对名单：

Contra Push / Pro Poll

1. -
2. -
3. 实施推送通知所需的服务器端工作
4. -
5. 无法直接了解推送通知是否已成功发送
6. 扩展推送通知传递可能很痛苦

Pro Push / Contra Poll

1. 工作已从设备中移除
   • 降低带宽使用率
   • 降低电池使用量
   • 响应速度更快的应用程序和设备
2. 服务器负载降低，因为即使没有任何更改（DDOS），设备也不会每x秒轮询一次
3. -
4. 推送比5秒（当前计时器）更快（响应更快）
5. 通过对远程URL进行轮询来实现推送通知的交付证明是非常简单的（这里有意义）
6. 扩展推送通知传递是一个已解决的问题，包含许多开源项目和带有消息队列的简单实现

---

• 是否还有其他原因可以避免推送通知并对此用例使用轮询？
• 是否还有其他原因可以避免轮询并对此用例使用推送通知？
• 我忘记了其他重要的事情吗？

Answer 1

  

无法知道推送通知是否已成功发送

当然有：设备在收到推送消息后命中您的服务器。如果有效载荷大于4K，您可能还需要这样做。

  

扩展推送通知传递可能很痛苦

它适用于相当大的用户群（例如，RememberTheMilk），甚至在基于XMPP的持久套接字解决方案之前。

  

是否还有其他原因可以避免推送通知并对此用例使用轮询？

GCM没有服务级别保证。 GCM是特定于Android的;如果你正在寻找能够处理其他客户端操作系统的东西，你可以考虑使用它的包装器，如Amazon SNS。涉及第三方（如Google）的推送解决方案意味着您的原始推送消息有效负载将对这些第三方的服务器可见;如果需要考虑，请使用合适的应用级加密（应该是这样）。

  

是否还有其他原因可以避免轮询并对此用例使用推送通知？

五秒钟的民意调查让$BABY_DEITY哭了。