809
ZPush--基於netty4實現的蘋果通知推送服務（APNs）Java客戶端
簡單說下實現蘋果通知推送服務（APNs）客戶端的一些要注意的地方：
- 使用長連接；
- sanbox服務器是沒用的，調試時直接用“gateway.push.apple.com”域名；
- 對於錯誤的Notification，蘋果會回應一個Error response，裏麵有個identifier，在這個identifier之後的Notification全都失敗；
因此發送者要緩存已經發送的Notification，最好設置Notification identifier為增長的整數序列，當收到Error response裏，從緩存裏取出比Error response的identifier要大的Notification，再次重新發送；
- 對於一台設備，APNs服務器隻存儲一條Notification，所以如果設備不在線，連續發送多條消息的話，後麵的會覆蓋前麵的；
- Apple的文檔裏有提到可以設置Notification的Priority = 5，具體是什麼意思不太明白。實際測試是當屏幕關閉，在省電時才會接收到的。如果是屏幕亮著，是不會接收到消息的。而且這種消息是沒有聲音提示的。貌似意義不大。
特點：
- 支持第三版通知推送，即command = 2。目前的絕大部分Java客戶端都隻支持command = 1，即第二版。
- 支持SSL握手成功才返回，可以調用 pushManager.start().sync(); 等待握手成功；
- 最大限度重試發送，內部自動處理重連，錯誤重發機製；
- 支持配置RejectListener，即通知被Apple服務器拒絕之後的回調接口；
- 支持配置ShutdownListener，即當shutdown時，沒有發送完的消息處理的回調接口；
- 支持發送統計信息；
- 實現組件分離，可以利用PushClient，FeedbackClient來寫一些靈活的代碼；
- Notification發送者可以自己定義設置發送的Queue，自己靈活處理阻塞，超時等問題。
把Queue暴露給發送者，這嚴格來說是一個不好的設計。因為在shutdown裏，有可能別的線程還在put notification到queue裏。
但是因為APNs協議本身，包括消息推送機製本身就是一個不完全靠譜的東東，考慮到發送者處理阻塞，消息積壓的便利性，因此把Queue暴露給發送者。
代碼地址：
例子：
public class MainExample {
public static void main(String[] args) throws InterruptedException {
Environment environment = 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);
}
}
最後更新：2017-04-03 12:56:35