zpush--NETTY4 Implementation-based Apple notification push Service (APNS) Java Client

Simply say the implementation of Apple Notification Push Service (APNS) client some of the areas to note:

• Use long connections;
• Sanbox server is useless, debugging directly with the "gateway.push.apple.com" domain name;
• For the wrong notification, Apple will respond to an error response, there is a identifier, in this identifier after the notification 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, re-send again;

• For a device, the APNs server only stores a single notification, so if the device is not in line, continuously send multiple messages, the back will overwrite the front;
• Apple's documentation mentions that you can set notification's priority = 5, specifically what you don't understand. The actual test is when the screen is turned off and is received only when the power is saved. If the screen is on, the message will not be received. And this kind of news is no sound hint. It doesn't seem to make much sense.

Characteristics:

• Support for the third version of Notification push, which is command = 2. Most of the current Java clients support Command = 1, or second edition.
• Support SSL handshake successful return, can call Pushmanager.start (). sync (); Wait for the handshake to succeed;
• Maximum retry send, internal automatic processing re-connect, error re-send mechanism;
• Support Configuration Rejectlistener, that is, the notification is rejected by the Apple server callback interface;
• Support Configuration Shutdownlistener, that is, when the shutdown, there is no message processing the callback interface;
• Support the sending of statistical information;
• Implement component separation, you can use pushclient,feedbackclient to write some flexible code;
• Notification senders can define their own settings to send the queue, their own flexibility to handle blocking, timeouts and other issues.
  

Exposing the queue to the sender is strictly a bad design. Because in shutdown, it is possible that other threads are still put notification into the queue. But because the APNS protocol itself, including the message push mechanism itself is an incomplete, considering the sender processing congestion, the convenience of the message backlog, so the queue exposed to the sender.
Code Address: Https://github.com/hengyunabc/zpush
Example:

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); }}