Apple Notification push Service (APNS) Key Features Summary

1. If APNs attempts to deliver a notification and the device is offline, the notification are stored for a limited period o F time, and delivered to the device when it becomes available.

If the user's phone is not on the line, there may be no signal or shutdown, APNs will store and forward, and so on when the user online and then send

2.Only one recent notification for a particular application is stored. If multiple notifications is sent and the device is offline, each new notification causes the prior notification Discarded. This behavior of keeping only the newest notification are referred to as coalescing notifications.

If the user is not on the line, the notification is merged and only the latest one is retained. If you send the user two notifications, but the user feedback that only received one, then it is likely that the user was not on the line, APNs's merge strategy takes effect, only keep the latest

3.If the device remains offline for a long time, any notifications this were being stored for it is discarded

4.The maximum size allowed for a notification payload are-bytes; Apple Push Notification Service refuses any Notification that exceeds this limit.

This is important, payload, which is the last JSON generated, not more than 256 bytes. If it is exceeded, it is recommended to remove some unnecessary parameters, the alert, that is, the number of words to reduce the message

5.don ' t repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack.

6.IF you send a notification that's accepted by APNs and nothing is returned.

Send successful wood to return, only send failed to return

7.IF you send a notification that's malformed or otherwise unintelligible, APNS returns an Error-response packet and Clos Es the connection. Any notifications this sent after the malformed notification using the same connection is discarded, and must be Rese Nt.

This is very important, if there is error-response, then this notice will need to be re-sent. There are a lot of open-source libraries, in the Apple notifications are not detected error-response, if you accidentally use, then users are likely to feedback "Why not notice ah"

8.THE notification identifier in the "error response indicates the last notification this was successfully sent (actual Back is the ID of the notification that the error occurred). Any notifications your sent after it has been discarded and must be resent. When you receive the This status code, the stop using this connection and open a new connection.

This is a supplement to the previous one, if something goes wrong, you need to close the current connection and reconnect again. The notification ID that is returned in Error-response can help us find out which one is wrong so we know which ones need to be re-sent.

9.When A push notification cannot is delivered because the intended app does not exist on the device, the feedback service Adds that device's token to its list.

APNs's feedback service returns the token--device_token of those devices that have been uninstalled. Store these tokens, next time you don't have to send them, you can save a bit of resources. Note that the feedback interface reads once, APNs clears its list, and the next time it reads, it returns the newly generated device_token between the two reads.

It is only by making sure that we understand the rules of Apple push and know some of the shortcomings of our push.