C2DM Cloud Push Solution
Google offers the C2DM (cloudto Device Messaging) service on Android mobile platforms. Android Cloud to Device Messaging (C2DM) is a
A service used to help developers send data from a server to an Android application. The service provides a simple, lightweight mechanism that allows the server to notify the mobile
Use the program to communicate directly with the server to obtain application updates and user data from the server.
The main problem with this solution is that C2DM needs to rely on Google's C2DM server, which is often unavailable due to the domestic network environment.
MQTT protocol for Android push
The use of the MQTT protocol for Android Push is also a solution. MQTT is a lightweight message publishing/subscription protocol that implements mobile client-based message push
The ideal solution for the server.
Wmqtt.jar is an implementation of the MQTT protocol provided by IBM. We can download the project from here (Https://github.com/tokudu/AndroidPushNotificationsDemo)
Instance code, and can find a server-side implementation (https://github.com/tokudu/PhpMQTTClient) written in PHP.
RSMB implementing push capabilities
Really Small Message Broker (RSMB), is a simple MQTT proxy, also provided by IBM, with the view address: HTTP://WWW.ALPHAWORKS.IBM.COM/TECH/RSMB.
Open port 1883 by default, which is responsible for receiving messages from the server and forwarding them to the specified mobile device. SAM is a PHP library written for MQTT. I
You can download it from this http://pecl.php.net/package/sam/download/0.2.0 address.
XMPP protocol for Android push
Google's official C2DM server is also packaged using the XMPP protocol. XMPP (Extensible Communication and Presentation Protocol) is an Extensible Markup Language (XML)-based protocol that
It is used for instant messaging (IM) as well as on-line probing. The agreement may eventually allow Internet users to send instant messages to anyone else on the Internet.
ANDROIDPN is a Java open source Android push notification implementation based on the XMPP protocol. It contains the full client and server side. But there are some shortcomings:
1) For example, when the time is too long, it will never receive the push message.
2) The performance is not stable enough.
3) If the message is pushed out of the server, it is no longer managed, regardless of whether the message successfully arrives on the client phone.
If we want to use ANDROIDPN, then we need to do a lot of work, need to understand the XMPP protocol, understand the implementation mechanism of ANDROIDPN, need to debug internal bugs.
The main three ways::::
1. Use the SMS service, which is the server-side send SMS, and then the mobile client listens for SMS messages.
2. Use polling to proactively obtain data from the network.
3. The use of long connections, in general, the main data is pushed to rely on this way for data push.
Android Push Scenario analysis (MQTT/XMPP/GCM)
Scenario 1, using GCM services (Google Cloud Messaging)
Introduction: Google launched the cloud messaging service, the second generation of G2DM.
Pros: Google offers services, native, and simple, without the need to implement and deploy the server.
Cons: Android version limit (must be greater than 2.2 version), the service is not stable in the country, users need to bind Google account, limited by Google.
Scenario 2, using the XMPP protocol (OpenFire + Spark + Smack)
Introduction: The communication protocol based on XML protocol, formerly known as Jabber, has been standardized by the IETF International Organization for Standardization.
Advantages: The protocol is mature, strong, extensible, is mainly used in many chat systems, and has open source Java version of the development example ANDROIDPN.
Disadvantage: The protocol is more complex, redundant (based on XML), charge flow, charge power, and the cost of deploying hardware is high.
Scenario 3, using the MQTT protocol (for more information see: http://mqtt.org/)
Summary: A lightweight, agent-based "Publish/subscribe" mode message Transfer Protocol.
Advantages: The protocol is concise, small, scalable, and provincial traffic, power saving, has been applied to the Enterprise Domain (reference: http://mqtt.org/software), and has a C + + version of the service-side components RSMB.
Disadvantage: not mature enough, achieve more complex, service-side components RSMB not open source, the deployment of hardware cost is high.
Scenario 4, using the HTTP round robin method
Summary: Get the latest news from the HTTP server-side interface (WEB service API) on a timed basis.
Advantages: Easy to implement, strong controllability, low cost of deployment hardware.
Disadvantage: Poor real-time.
Instant Messaging technology-Push Technology protocol Solutions