由于我想在移动应用程序中建立可靠的通信,我是否可以从第三方推送服务(C2DM、APN、城市飞艇)获得推送失败报告(可能设备离线)?还是我们需要自己建造?
6 回答
Android C2DM的预期目的是作为一种省电方式,让您的服务器应用程序向移动设备发出它想要开始可靠通信的信号。
您可以构造您的消息,以便每个新的 C2DM 包含自与服务器的最后一次双向交互以来发生的所有事情(即,“来拿我所拥有的一切”)。您的交付失败报告隐含在移动设备未及时响应中(您可以这样做,因为您知道 C2DM 使用 Intent 激活您的应用程序)。
这真的比在有损介质中保证每条消息的传递更糟糕吗?好吧,更糟糕的是你还必须实现一种主要的通信方法。但无论如何您都必须这样做,因为 C2DM 仅限入站,对吗?
正如 Vinay 所说,MQTT 可能会为您提供您想要的功能。当客户端连接到服务器时,它可以向服务器注册“遗嘱”消息。如果客户端意外断开连接,服务器会将此消息发送到它被指示执行的主题。
在此方案中,您的客户端可以将消息“在线”发送到客户端//状态之类的内容,并将消息“离线”注册为同一主题的 LWT。然后,您可以拥有一个服务器本地客户端,它侦听主题 client/+/status,它会知道哪些客户端在线,哪些客户端离线。
我建议tokudu 演示不是最好的查看位置。Dale Lane 的这篇博客文章深入了解了在 Android 上使用 MQTT:http ://dalelane.co.uk/blog/?p=1599 并且在http://stephendnicholas上有一篇关于 MQTT 电源使用情况的评论(同样在 Android 上).com/archives/219
有适合 IOS 和 Android 的客户端实现,请参阅http://mqtt.org/software
没有一项服务不提供有关失败推送的报告。
失败的推送报告对 APN/C2DM/Helium 毫无意义
所有服务都旨在在任何情况下传递推送消息。如果设备现在离线,则在设备在线时推送。
此外,对于 iOS,推送消息只是给用户的通知,而不是给应用程序!
一个简单的案例来说明:假设关闭应用时收到推送。在这种情况下,将通知用户。但是,只有当用户点击该通知时,应用程序才会从推送中接收数据!如果用户点击应用程序的图标,则不会收到数据。
所以从技术上讲,推送被传递到 iOS 设备并启动应用程序,但没有传递数据。
UrbanAirhip 与 APN 和氦气
您可以考虑实现自己的推送传输。MQTT 似乎是一个不错的选择。但在这种情况下,您必须处理保活、设备休眠和电池优化。苹果、谷歌和 UrbanAirship 的工程师已经完成了所有这些艰苦的工作。
根据您的业务需求,可以更轻松地针对现有解决方案调整您的架构,然后再次重新实现推送服务。
仔细看看 UrbanAirship。事实上,C2DM 有一些限制,有时推送消息的传递时间过长。因为 UA 已经实现了他们自己的传输 - Helium,它工作得很好。Helium 是一项付费服务,但 UA 提供了良好的 SLA。
我建议推送通知 IBM MQTT 协议。这对于推送通知来说已经足够好了。从https://github.com/tokudu/AndroidPushNotificationsDemo查看演示
我做了类似的事情,我有一个数据库跟踪已知订阅者的推送队列,并在失败时进行报告。这很简单,就像这样......
The schema was like so:
pushMessages
messageID , GUID, PK
message , nvarchar (256),
expires , datetime
messageQueues
subscriberID , GUID, PK
messageID , GUID PK
failedPushMessages
subscriberID, GUID, PK
messageID , GUID PK
(subscriber table omitted)
一旦客户端成功接收到消息,客户端将 ping 回推送服务器,并通过它在推送通知中收到的唯一 queueItems ID 通知它。还会有一个每日数据库进程来检查过期的推送消息。找到后,它将在与 messageID 匹配的 queueMessages 上进行连接,然后将它们从 messagesQueues 表中删除并将它们复制到 failedPushMessages 表中。
这很容易理解和维护,但我没有其他方式的经验。
推送服务是一种有效且可靠的方式来提醒您的用户。它们甚至允许后台应用程序实时通知用户新信息。推送服务广泛应用于移动应用中的各个领域,例如天气更新、消息服务、邮件通知、优惠券服务等。推送服务不再是可选的,而是变得必不可少。