Regarding push notifications, iOS push is mainly implemented through the server. For the relevant process, please refer to the following two articles:
List of jar packages introduced in the article:
- bcprov-jdk16-145-1.jar
- commons-io-2.0.1.jar
- commons-lang-2.5.jar
- javapns-jdk16-163.jar
- log4j-1.2.16.jar
The most comprehensive introduction is this blog:
http://tanqisen.github.io/blog/2013/02/27/ios-push-apns/
The overall process is shown in the following figure:
The roles involved are:
- Provider: the application's own server;
- APNS: Short for Apple Push Notification Service, Apple's PUSH server;
-
After the OS device is connected to the network, it will automatically maintain a long TCP-like link with APNS, waiting for the arrival of APNS push messages;
-
When the application starts, register the message push, and obtain the unique device identifier deviceToken registered in APNS of the device and upload it to the application server (ie Provider);
-
When a message needs to be pushed to the application, the Provider packages the push content and the deviceToken that receives the push message in the format specified by APNS and sends it to APNS;
-
After APNS receives the message sent by the Provider, it searches for the device specified by deviceToken. If the device has established a connection with APNS, it immediately pushes the message to the device. The message is pushed to the device. Please note that Apple does not guarantee that the push will be successful;
-
After the device receives the push message, the iOS system will determine which application the push message is sent to based on the SSL certificate, and then start the corresponding client.
In the above process, there are two key steps that need to be handled by yourself: 1. The client obtains the deviceToken and uploads it to the Provider; 2. The Provider sends a push message to APNS. Both of these steps require Apple's push certificate authorization. Here's how to generate a push certificate and Provisioning Profile.
Additional dependent jar packages in pom.xml:
<!-- Apple Push Notification Related Dependencies -->
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk16</artifactId>
<version>1.46</version>
</dependency>
<dependency>
<groupId>com.github.fernandospr</groupId>
<artifactId>javapns-jdk16</artifactId>
<version>2.3.1</version>
</dependency>
The code to send the message notification looks like this:
String deviceToken = "xxxxxxx";
//Identifier of the pushed iphone application
PushNotificationPayload payload = new PushNotificationPayload();
payload.addCustomAlertBody("通知!");
payload.addBadge(1);
payload.addSound("default");
PushNotificationManager pushManager = new PushNotificationManager();
Device device = new BasicDevice(deviceToken);
String certificatePassword = "123456";
InputStream keyStoreFileInputStream = this.getClass().getClassLoader().getResourceAsStream("push.p12");
//Note: The last parameter indicates whether the request is a production environment. If the configured certificate is the certificate used for testing, please modify this parameter to false
pushManager.initializeConnection(
new AppleNotificationServerBasicImpl(keyStoreFileInputStream, certificatePassword,
true));
pushManager.sendNotification(device, payload);
pushManager.stopConnection();
Sending a message notification involves deviceToken (each device is different for each app), certificate file (keystore), and verification password, and then you can normally send notifications to the corresponding app.
The push of the iOS system (APNS, that is, Apple Push Notification Service) relies on one or several system resident processes to operate and is global (take over the message push of all applications), so it can be regarded as independent of the application and is a device Communication with Apple's servers, not the app's provider server. In your example, Tencent QQ's server (Provider) will send a notification to Apple's corresponding servers (APNs), and then relay it to your devices (Devices). When you receive the notification and open the app, it starts to receive data from the Tencent server, which is the same as what you saw in the notification before, but through two different channels.
Android, on the other hand, is more like a traditional desktop computer system. Each application that needs to be pushed in the background has its own separate background process to communicate with its own server and exchange data. In addition, Android also has GCM (Google Cloud Message) similar to APNS, which is optional for developers and not mandatory, but Google's services, you know.
It is better to use a third-party system directly to develop it yourself. It is not cost-effective~ It is time-consuming and labor-intensive, and the effect is not necessarily good. Find a reliable third party and go directly to download a document for use, which is convenient. I don't know what you think. After comparing several companies, our company uses a third-party Jiguang push to achieve this purpose. The corresponding Java SDK address:
http://docs.jpush.io/server/java_sdk/
.
Go to register first. After logging in, you can create a new application. After the application is created successfully, you can view the specific details under the application information:
Application Information
| AppKey | xxxx | |
| Master Secret | xxxx | |
| Date created | 2016-03-17 13:10 | |
| Last Modified | 2016-03-17 13:10 |
The documentation of Jiguang Push is relatively comprehensive, starting from the FAQ:
http://docs.jpush.io/guideline/faq/
If we do not store user equipment and other data on the server, then we will lose the ownership of all registered devices, and we can only send notifications manually through the relevant pages of Jiguang push. In view of this, we still need to set the corresponding backend. data table to process all registered users.
The overall process of push service is as follows, taking iOS as an example (android is relatively simple and does not require APNS service role)
The overall process is as follows:
- The mobile terminal of the device APP sends the information required for registering the device to Jiguang Push, including deviceToken, mobile phone number (used for SMS notification of the paid version), etc.;
- After registering Jiguang push related services, provide device information to the back-end service, and the registered Jiguang id and mobile phone number are used for back-end storage;
- Backend services need to persist related data;
- If the message notification mechanism is triggered, one method can be done through the web page provided by Jiguang Push, and the other is through the JPush API directly in the back-end service according to the user's mobile phone number/registration id/device alias;
- After Jiguang Push Service receives the notification, it needs to send the message to APNS (Apple Push Notification Service);
- APNS sends a message to the mobile device according to the device token, and clicks it to start the application.
The server-side API is mainly divided into the following parts:
1. Push
Send push notifications to a device or class of devices;
If the server uses Java as the development language, you can refer to the Java SDK section:
http://docs.jpush.io/server/java_sdk/
You need to register the appKey, masterSecret and other information related to Jiguang Push ID.
JPushClient jpushClient = new JPushClient(masterSecret, appKey, 3);
// For push, all you need do is to build PushPayload object.
PushPayload payload = buildPushObject_all_all_alert();
try {
PushResult result = jpushClient.sendPush(payload);
LOG.info("Got result - " + result);
} catch (APIConnectionException e) {
// Connection error, should retry later
LOG.error("Connection error, should retry later", e);
} catch (APIRequestException e) {
// Should review the error, and fix the request
LOG.error("Should review the error, and fix the request", e);
LOG.info("HTTP Status: " + e.getStatus());
LOG.info("Error Code: " + e.getErrorCode());
LOG.info("Error Message: " + e.getErrorMessage());
}
The related documents and APIs of JPush are relatively convenient. The creator mode (Builder) is widely used, which can quickly create push objects and push platforms.
2. Report
The Report API is used for various statistical query related functions. The Received API takes msg_id as a parameter to obtain the delivery statistics of the msg_id. If an API call pushes many objects (such as a broadcast push), the statistics returned by this API will continue to increase as clients continue to deliver. Delivery statistics for each push message are retained for up to one month. That is, after the push request is initiated, it will be kept for one month from the time of the last push delivery record. If there is a new delivery during the retention period, it will be kept for another month from the new delivery time.
If we want to count the information, we need to record the msg_id of the information after sending the message.
3. Device
The Device API can be used to query, update, and delete the tags and alias information of the device on the server side. If you don't want the tags, aliases and other information of the APP client and the server side to cover each other, consider updating only on the client side or the server side.
http://docs.jpush.io/server/rest_api_v3_device/
However, the Device API on the server side can only modify device tags and alias information, and the functions are relatively limited, so the registration of most functions can only be performed on the client side.
4. Schedule
At the API level, it fully supports the scheduled sending function, which is a relatively independent task execution module,
http://docs.jpush.io/server/rest_api_push_schedule/
.
Unfortunately, JPush's Java SDK does not involve Device, and Schedule-related clients can be used directly. If you want to use this function on the server, you need to implement some functions by referring to the source code of JPush Java SDK.