標籤:java apns apple push notification
簡單說下實現蘋果通知推送服務(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暴露給寄件者。
代碼地址:https://github.com/hengyunabc/zpush
例子:
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); }}