zpush--Apple Notification push Service (APNS) based on Netty4 javaclient

Just a few things to note about implementing the Apple Notification Push Service (APNs) client:

• Use long connections;
• Sanboxserver is useless, debugging directly with the "gateway.push.apple.com" domain name;
• For the wrong notification. Apple will respond to an error response. There was a identifier in it, and the notification after the identifier all failed.

So the sender is going to cache the notification that has been sent, preferably set the notification identifier as the growing integer sequence, and when the error response is received, remove the error from the cache Response identifier to big notification, again send again.

• For a single device, Apnsserver only stores one notification. So suppose the device is not in line. Send multiple messages in a row. The back will cover the front;
• Apple's documentation mentions the ability to set notification's priority = 5, in detail what it means is not clear. The actual test is when the screen is turned off and then received when the power is saved. If the screen is on, it will not receive the message. And there are no sound prompts for such a message. It doesn't seem to make much sense.

Characteristics:

• Support for the third version of Notification push, which is command = 2. The vast majority of javaclient now support Command = 1, the second edition.
• Support SSL handshake successful return, can call Pushmanager.start (). sync (); Wait for the handshake to succeed.
• Maximum retry send, internal self-treatment of the re-connection, error re-send mechanism;
• Support Configuration Rejectlistener, that is, notify the callback interface after appleserver rejection;
• Supports configuration of Shutdownlistener, that is, when shutdown, there is no callback interface for message processing to be sent out.
• Support the sending of statistical information;
• The separation of components enables the use of pushclient. Feedbackclient to write some flexible code.
• The notification sender is able to customize the settings sent by the queue to handle congestion on its own. Timeouts and other issues.

  
  

Exposing the queue to the sender is strictly a bad design. As in shutdown, it is possible that other threads are still put notification into the queue.

However, due to the APNS protocol itself, including the message push mechanism itself is a not completely reliable stuff. Given that the sender handles the congestion and the message backlog is convenient, the queue is exposed to the sender.

Code Address: Https://github.com/hengyunabc/zpush
Examples:

public class Mainexample {public static void main (string[] args) throws Interruptedexception {environment ENVI        Ronment = environment.product;        String password = "123456";        String KeyStore = "/HOME/HENGYUNABC/TEST/APPTYPE/APP_TYPE_1/PRODUCTAPNS.P12";        Pushmanager Pushmanager = new Pushmanagerimpl (keystore, password, environment);        Set a push queue blockingqueue<notification> queue = new linkedblockingqueue<notification> (8192);        Pushmanager.setqueue (queue);        Waiting for SSL handshake success Pushmanager.start (). sync ();        Build a notification String token = "5f6aa01d8e3358949b7c25d461bb78ad740f4707462c7eafbebcf74fa5ddb387";                Notification Notification = new Notificationbuilder (). Settoken (token). Setbadge (1)        . setpriority (5). Setalertbody ("xxxxx"). Build ();        Put notification into the queue queue.put (notification);TimeUnit.SECONDS.sleep (10);        Get statistic info Statistic statistic = pushmanager.getstatistic ();    SYSTEM.OUT.PRINTLN (statistic); }}

zpush--Apple Notification push Service (APNS) based on Netty4 javaclient