实时个人资料、推送通知、结构
我想知道是否有人能够大致解释一下应用程序如何像LiveProfile 是实现的吗？
消息如何通过网络从一台设备推送到另一台设备。他们如何知道他们想要将其发送到的设备的地址？是否有 IP 和 LiveProfile PIN 的映射？
是HTTP吗？仅使用一般技术就可以极大地帮助我提高对 Android 和移动工程这方面的理解。
I was wondering if anyone would be able to explain roughly how an application like LiveProfile is implemented?
How do the messages get pushed over the network from one device to another. How do they know the address of the device they wish to send it to? Is there a map of IPs and LiveProfile PINs?
Is it HTTP? Just the general technology used would be a great help in improving my understanding of this aspect of Android and mobile engineering.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道那个特定的应用程序，但有几种可能性。
其中之一是 Google 实验室的 C2DM：http://code.google.com/android/c2dm/
另外，请查看这篇文章。它有一个非常详细的解释： http://tokudu.com /2010/how-to-implement-push-notifications-for-android/
这是另一个包含有用信息的信息：http://blog.boxedice.com/2010/10/07/android-push-notifications-tutorial/
I don't know about that specific app, but there are several possibilities out there.
One is Google Labs' C2DM: http://code.google.com/android/c2dm/
Also, check this post. It has a very detailed explanation: http://tokudu.com/2010/how-to-implement-push-notifications-for-android/
Here is another one with useful info: http://blog.boxedice.com/2010/10/07/android-push-notifications-tutorial/
作为 LiveProfile 的联合创始人，我可以更多地了解我们所做的事情。
LiveProfile 是在 C2DM 可用之前发布的。事实上，市场是分散的，许多人仍在使用 Android v2.0 及更低版本。因此，我们结束了实施我们自己的基于推送的解决方案。
我们的解决方案是始终与我们的服务器保持持久的套接字。当一个用户向另一个用户发送消息时，该消息会通过我们的服务器进行路由，然后我们决定该消息应该发送给谁。如果持久套接字已连接，那么我们将数据推送给它们。如果用户当前未连接，我们将数据存储在队列中，用户将收到连接上的所有消息。
更新： Google I/O 2009 的演讲是一个很好的资源，其中详细介绍了电池寿命、网络/CPU 如何影响电池寿命等。 youtube.com/watch?v=OUemfrKe65c" rel="nofollow">http://www.youtube.com/watch?v=OUemfrKe65c
As a co-founder of LiveProfile I can shed a bit more light on what we've done.
LiveProfile was released before C2DM was available. Infact the market was fragmented and many were still using Android v2.0 and below. For this reason we ended implementing our own push based solution.
Our solution is a persisted socket to our servers at all times. When a user sends a message to another user, it gets routed through our servers and we decide who it should go to. If the persisted socket is connected then we push the data to them. If the user is not currently connected, we store the data in an queue and the user will receive all the messages on connect.
Update: A good resource is a talk from Google I/O 2009 which goes into detail about the battery life, how network / CPU effects it, etc. http://www.youtube.com/watch?v=OUemfrKe65c