On the evolution of iOS Push in IOS6/7/8/9

Brief Introduction

After the iOS device is installed, the app is usually asked if it is allowed to send notifications (see below), and when agreed, users will generally receive a push from an app.    For example, users receive a tweet, their favorite team wins the game, or their dinner is ready, and since the app isn't running, app can't check these events. Fortunately, Apple offers solutions to these problems. Developers can write a server-side build that replaces the client's constant testing or working in the background.

the principle of push

A secure channel is established between the APNS server where the push message goes, the device and the APNs (Apple Push Notification Service) server. On the principle of push, the following figure, detailed look here

The translation of the picture is:

1. The client registers with the APNs and obtains the token

2. APN is to pass token to client

3. Clients will send token to their own server

4. At the right time, your own server sends a push message to APNs.

5. Final APNs sent to client the evolution of IOS Push in IOS6/7/8/9

So with the evolution of the iOS version, push interaction and functionality are changing

IOS6 (to be added)

IOS7 support background push, silent push. Device does not show or ring, click to learn more

★ios7 app get system-> notification specific function is [[UIApplication sharedapplication] enabledremotenotificationtypes]

IOS8 supports more interactions with push (such as quick reply, delete single push, etc.)

When ★ios8 is released (from that point in time), the body of the push can be supported to 2k, formerly 256B

★ios8 app gets system-> notifications. The specific function is [[UIApplication sharedapplication] currentusernotificationsettings];

Changes to the interface of the developer

/* The following are the interfaces on the IOS6/7/8, unified in-(void) Application:didreceiveremotenotification: In-process/
 method 1:-(void) Application: Didreceiveremotenotification://ios6
 Method 2:-(void) Application:didreceiveremotenotification: Fetchcompletionhandler://ios7,ios8
 Method 3:-(void) application:handleActionWithIdentifier:forRemoteNotification : completionhandler://ios8,9

The general application has three kinds of states:
A) application is not started;
b application has been started, but in the background;
c The application is at the front desk.
For the above three states, ios7,8,9 calls Method 2 after receiving a message notification, which also conforms to the official document description.
Bug however, for IOS 10.0.2, when the application is in a or B state, call Method 1, when the application is in the C state, call Method 2.
In addition: If you do not do processing, iOS7 can encounter push repeat problem, solution point here in the development process, programmers how to test push here is a short code for PHP development (copy to file with PHP suffix name). Requires you to generate certificates and provisionfile. This allows you to send a push to the iOS app using this machine. The CK.PEM in the inside need to be generated by themselves. Click here to download

where the push needs attentionEvery push you make on your server will be received by the client. The answer is in the negative, push is unreliable., push notice is fire-and-forget, such as a cell phone shutdown, so natural will not receive, although Apple will try several times. IOS8, regardless of the iOS system, the push message body size adjusts to 2k, note that this is the iOS8 point of time, that is, the autumn of 2014, for now, the push limit should be 2k, no longer 256.When testing the push, distinguish between an App Store certificate and a development certificate. They can't push each other.