我最近了解到iPhone应用程序能够接收几乎即时的通知。
这是以推送通知的形式提供的,这是一种定制的协议,可以保持与iPhone的数据连接,并向应用程序发送二进制数据包,它会以极快的速度弹出警报,从服务器应用程序发送到手机应用程序的响应时间为0.5 - 5秒。这是作为数据而不是SMS发送的,以非常非常小的数据包作为数据计划的一部分收费,而不是作为传入消息。
我想知道,如果,使用Android,有一个类似的设施,或者是否有可能实现接近这个使用Android api的东西。为了澄清,我将相似定义为:
不是短信,而是一些数据驱动的解决方案
尽可能的实时
是否可扩展,即作为移动应用程序的服务器部分,我可以在几秒钟内通知数千个应用程序实例
我欣赏的应用程序可以拉基于,HTTP请求/响应风格,但理想情况下,我不想轮询那么严重,只是为了检查通知;除此之外,它就像滴漏数据计划。
我一直在研究这个问题,jamesh推荐的PubSubHubBub不是一个选项。PubSubHubBub用于服务器到服务器的通信
"I'm behind a NAT. Can I subscribe to a Hub? The hub can't connect to me."
/Anonymous
No, PSHB is a server-to-server
protocol. If you're behind NAT, you're
not really a server. While we've
kicked around ideas for optional PSHB
extensions to do hanging gets ("long
polling") and/or messagebox polling
for such clients, it's not in the core
spec. The core spec is
server-to-server only.
/Brad Fitzpatrick, San Francisco, CA
Source: http://moderator.appspot.com/#15/e=43e1a&t=426ac&f=b0c2d (direct link not possible)
我得出的结论是,最简单的方法是使用Comet HTTP push。这是一个简单且易于理解的解决方案,但它也可以用于web应用程序。
XMPP是一个很好的解决方案。我在一个支持推送的、实时的Android应用程序中使用过它。XMPP功能强大,高度可扩展,易于集成和使用。
有很多免费的XMPP服务器(尽管出于礼貌,您不应该滥用它们),还有一些开源服务器可以在您自己的机器上运行。OpenFire是一个很好的选择。
你想要的库不是上面提到的Smack,而是aSmack。但是请注意,这是一个构建环境—您必须构建库。
以下是我对XMPP解决方案对电池寿命的影响进行的计算:
The Android client must maintain a persistent TCP connection by waking up periodically
to send a heartbeat to the XMPP server.
This clearly imposes a cost in terms of power usage. An estimate of this cost is
provided below:
Using a 1400mAh battery (as supplied in the Nexus One and HTC Desire)
An idle device, connected to an 3G network, uses approximately 5mA
The wake-up, heartbeat, sleep cycle occurs every 5 minutes, takes three seconds
to complete and uses 300mA
The cost in battery usage per hour is therefore:
36 seconds 300mA = 3mAh sending heartbeat
3600 seconds 5mA = 5mAh at idle
4:95 + 3 = 7:95mAh combined
A 1400mAh battery lasts approximately 11.6 days at idle and 7.3 days when
running the application, which represents an approximate 37% reduction in
battery life.
However, a reduction in battery life of 37% represents the absolute worst case
in practice given that devices are rarely completely idle.