IOS Study Notes 33-Apple push mechanism APNs (1)

Push is a good solution for traffic consumption and power consumption caused by polling. on Android, although Google provides GCM (previously C2DM ), however, it is basically useless in China. Android applications basically set up push servers or use third-party push platforms. For example, Sina Weibo uses third-party push platforms (non-advertising ). Today, I want to learn the basic principles and workflow of Apple's Push Notification service (APNs.

 

The basic principle of Apple's Push Service APNs is that Apple uses its own dedicated push server (APNs) to receive the information that needs to be pushed from our own application server, push to the specified iOS device, and then the device notifies our application. The device notifies the user of a new message in the form of a notification or sound. The premise for pushing is that the device with our application needs to register with the APNs server. After successful registration, the APNs server will return a device_token to us, after obtaining the token, we send the token to our app server. When a message needs to be pushed, our app server will package the message in the specified format, then, the device device_token is sent to the APNs server. Because our application and APNs maintain a TCP-based persistent connection, APNs pushes new messages to our device, then a new message is displayed on the screen. The entire process is basically like this. Let's take a look at the flowchart of device registration APNs:

 
 

Complete the following steps:

1. Device connects to the APNs server and carries the Device serial number

2. The connection is successful. After APNs is packaged and processed, the device_token is generated and returned to the registered Device.

3. The Device carries the obtained device_token and registers it with our app server.

4. register the Device to be pushed on the APNs server and our own application server.

The execution sequence is as follows:

 
 

One thing we should mention here is that the communication between our device and the APNS server is based on the SSL protocol TCP stream communication, and the two maintain a persistent connection between them. After successful registration from the APNS server, be sure to send device_token to our app server, because the Prime Minister is our app server (medium Provider) during the push process) package the messages to be pushed in the specified format (as mentioned later) with device_token and send them to the APNS server. Then, the APNS server pushes the messages to our devices.

Now, the device registration process is complete, and the next step is how to push the device:

 
 

The push process follows the steps below:

1. first, an application with the push function is installed. Our devices connect to the Apple push server when there is a network. During the connection, APNS verifies device_token, maintain a persistent connection after the connection is successful;

2. Provider (our own server) receives the message to be pushed and sends it to the APNS server in combination with the device_token of the push device;

3. The APNS server pushes the push information to the specified device_token device;

4. The device notifies our application after receiving the PUSH message and displays and prompts the user (sound and pop-up box)

For more intuitive procedures, refer:

 

It shows the complete path for our App server to push messages to our App. In fact, what we actually push is the APNS server, our own application server only informs the apple server of the messages to be pushed. As for how to maintain the message queue or ensure that messages can be pushed to a specified device, these are all done by Apple APNS.

 

As mentioned above, the process of packaging device_token and push messages is as follows:

 
 

The displayed message body is the message structure sent by our server (Provider) to the APNS server. After APNS verifies that the structure is correct and extracts the information, then, push the message to the specified device. This struct includes five parts. The first part is the command identifier, the second part is the length of our device_token, and the third part is our device_token string, the fourth part is the length of the push message body (Payload), and the last part is the real message content, which contains the basic information of the push message, such as the message content, number in the upper-right corner of the application Icon and the playing sound when the PUSH message arrives. Next, let's take a look at the structure of Payload (message body:

 
 

Listen audio files, such as Didi's voice when QQ receives new messages in the background when the mobile phone locks the screen.

 

In this case, how can we change the message pushed after we detach the application from the device. We know that when we detach an application from a device, we cannot receive the messages pushed by the Provider. However, how can we let APNS and providers know that they do not push messages to the device that has uninstalled the application? To solve this problem, Apple has also helped us solve it, namely the Feedback service. This is part of APNS. APNS will continuously update the Feedback service list. When our Provider sends the information to APNS and pushes it to our device, if the device cannot push messages to the specified application, a feedback message is reported to the APNS server, which is recorded in the feedback service. In this way, the Provider should regularly check the list of Feedback services, and then delete the device_token recorded in its own database in the Feedback list, so as not to send push information to these devices. The process of connecting to Feedback service also uses the Socket method. After the connection is established, APNS directly receives the Feedback list transmitted to us. After the transmission is complete, the connection is closed, then, based on the latest feedback list, we update our own database and delete the device_token of devices that no longer need to push information. The data structure read from Feedback service is as follows:

 

The structure contains three parts: The first part is a timestamp, which records the time information after the device fails, the second part is the length of device_token, and the third part is the invalid device_token, we need to obtain the third part. After comparison with our database, we will delete the corresponding device_token and will not send push messages to these devices next time.

 

This article mainly introduces the basic principles of APNS and the response components and services of the apple push mechanism. The next article will introduce how to integrate the APNS service in our own projects to push messages!