Android push Method Comparison

When sending Android and iPhone applications, we often need to push various notification messages from the server to the mobile client in real time. The iPhone already has a simple and perfect push notification solution, however, the implementation on the Android platform is relatively troublesome. In the past few days, we have made a preliminary research on the Android push notification service.
On the Android mobile platform, Google provides the C2DM (Cloudto Device Messaging) service. At first, I was preparing to use this service to implement the push function on my mobile phone.

Android Cloud to Device Messaging (C2DM) is a service that helps developers send data to Android applications from servers. The Service provides a simple and lightweight mechanism that allows the server to notify mobile applications to communicate directly with the server, so that the server can obtain application updates and user data. The C2DM service processes transactions such as Message Queuing and distributes these messages to applications running on the target device.

However, after some research, we found that this service has a major problem:

1) C2DM is built into the Android 2.2 System and cannot be compatible with the old 1.6 to 2.1 systems;

2) C2DM depends on the C2DM Server officially provided by Google. Due to the domestic network environment, this service is often unavailable. If you want to use it well, our App Server must also be abroad, this may not be implemented by every developer;

With these two restrictions, I finally gave up this solution, however, I want to use another article to introduce the C2DM framework in detail and the corresponding setting methods of the client and App Server, which can be used for learning and reference.

As C2DM cannot meet our requirements, we need to implement the communication protocol between the Android mobile client and the App Server on our own to ensure that when the App Server wants to send messages to a specified Android device, android devices can receive messages in a timely manner. Below I will introduce several common solutions:

1) round robin: the application should be connected to the server in stages and check whether new messages arrive. You must implement communication with the server, such as Message Queuing. In addition, you also need to consider the polling frequency. If it is too slow, it may lead to delay of some messages. If it is too fast, it will consume a lot of network bandwidth and battery.

2) SMS: On the Android platform, you can intercept SMS messages and parse the message content to understand the server's intention. This is a good idea. I have seen applications that adopt this solution. The advantage of this solution is that it can achieve full real-time operations. However, the problem is that the cost of this solution is relatively high, and it is difficult to find a free short message sending gateway. For the implementation of this solution, refer to the following link: https://labs.ericsson.com/apis/mobile-java-push /.

3) persistent connection: this solution can solve the performance problem caused by polling, but it will still consume the cell phone's battery. The push service of Apple works well because each mobile phone only maintains a connection with the server. In fact, C2DM works like this. However, this solution also has shortcomings, that is, it is difficult for us to implement a reliable service on the mobile phone. The Android operating system allows you to Kill system services with low memory, so your notification service may be killed by the operating system.

The first two solutions have obvious shortcomings, and the third one is also insufficient. However, we can make up for them through good design so that the solution can work effectively. After all, we need to know that GMail, GTalk, and GoogleVoice can all be updated in real time.

 

Android push using MQTT Protocol

MQTT is a lightweight message publishing/subscription protocol. It is an ideal solution for message pushing servers based on mobile clients.

We can download the instance code of this project from here, and find a server implementation written in PHP.

The architecture is as follows:

Wmqtt. jar is the implementation of the MQTT protocol provided by IBM. You can download it from the following website. You can add the jar package to your Android application.

Really Small Message Broker (RSMB), which is a simple MQTT proxy, also provided by IBM. Port 1883 is opened by default. In an application, it is responsible for receiving messages from the server and forwarding them to the specified mobile device.

SAM is a PHP library written for MQTT. You can download it from here.

Send_mqtt.php is a PHP script that receives messages through POST and sends messages to RSMB through SAM.

Instance code:

 

You can download the instance application from GitHub. After running the application, visit the pull Push Message button in the mobile browser, and you will be able to see the notification received on the mobile phone. You can also download the android-push source code from this GitHub address, which contains the send_mqtt.php script.

 

 

Ø Android push using XMPP protocol

This is the solution I used in the project. In fact, Google's official C2DM server uses the XMPP protocol for encapsulation at the underlying layer.

XMPP is a protocol based on the Extensible Markup Language (XML). It is used for instant messaging (IM) and online detection. This protocol may eventually allow Internet users to send instant messages to anyone else on the Internet.

Androidpn is an open-source java Android push notification implementation based on XMPP protocol. It contains the complete client and server. After source code research, I found that the server is basically implemented based on another open source project openfire, but it is depressing that the androidpn documentation is written in Korean, therefore, the entire research process is basically to read the source code. Its implementation is as follows:

 

The androidpn client needs to use a java-based open-source XMPP protocol package asmack. This package is also based on the openfire's other open-source project smack, but we do not need to compile it ourselves, you can directly mount the asmack in the androidpn client. jar. The client uses the XMPPConnection class provided in asmack to establish a persistent connection with the server and use this connection for user registration and logon authentication. This connection also receives notifications sent by the server.

The androidpn server is also implemented in java. It is based on the openfire open source project. However, its Web part adopts the spring framework, which is different from openfire. The Androidpn server consists of two parts. One is the XMPP service listening on port 5222, which is responsible for communicating with the XMPPConnection class of the client. It serves as a user registration and identity authentication, and sends push notification messages. In addition, a Web server uses a lightweight HTTP server to receive users' Web requests. The server architecture is as follows:

 

The top layer includes four components: SessionManager, Auth Manager, PresenceManager, and Notification Manager. SessionManager is responsible for managing sessions between the client and the server. Auth Manager is responsible for client user authentication management, Presence Manager is responsible for managing the logon status of client users, and icationicationmanager is responsible for pushing messages from the server to the client.

The server interface is as follows, which corresponds to the above functional modules:

 

 

 

After sending the message, we can see the received message on the mobile phone:

The most

 

 

 

 

 

 

 

The biggest advantage of this solution is simplicity. We do not need to rely on the operating system version like C2DM, nor worry about the unavailability of Google servers one day. With XMPP protocol, we can further expand the Protocol to achieve more comprehensive functions.

Using this scheme, we can only send text messages at present, but it is generally enough for pushing, because we cannot expect to get all the data through pushing. Generally, push only tells the Mobile Server that some changes have taken place. When the client receives the notification, it should take the initiative to obtain the latest data from the server. This is the complete implementation of the push service.