推播、本地推播、EKEvent的比較

 

因為最近同事的案子有用到「通知使用者」，這種功能天天都在做。整理一下以前的作法，大概有遠端推播、本地推播、行事曆事件這三種。這三種各有他使用上限制跟優缺點，因為這種需求很頻繁，為了日後不要再說明一次，所以寫了這篇：

遠端推播（push、remote notification）

用push來叫他感覺怪怪的，因為所有跳出一個通知的東西應該都可以叫做push，一般書裡寫的推播指的就是這種，怎麼做不再綴訴：

一般使用流程如下：

1.打開app，在appDelegate裡的didFinishLaunchWithOption或becomeActive裡寫我要用推播

2.會在didRegisterRemoteNotification收到由APNS傳來的deviceToken，把token去頭去尾後，去跟自家的PNS(Push Notification Server)註冊，至少會把deviceToken這個參數傳出去。可以看得出來我在這邊多傳了一個phoneID

3.PNS排好schedule，時間到訊息送出

4.裝置收到推播，點選推播後會自動進入appDelegate的didReceiveNotification裡，進入之後要怎麼處理就是各自app的事了

圖片來源：raywenderlich.

需要注意的點如下：

1. development會有一組deviceToken、distribution會有一組deviceToken。所以AdHoc跟AppStore的provision拿到的deviceToken會是一樣的
2. deviceToken會過期，時間由APNS來決定，過期後APNS會再給device一個deviceToken，所以在第二步註冊的時候應該還要傳UDID或mac address這種唯一且固定的identify
3. 如果把development的deviceToken不小心傳到distribution的清單裡面，那distribution群發推播跑到那組development的deviceToken時會halt。

常發生的問題：

1.我明明排定某個時間要送出推播，為什麼我收到推播的時間是2個小時甚至更久以後？

• 因為送出推播的時候一定是由自己的PNS送出給APNS叫他送出推播，如果今天是一個群發推播，然後註冊的用戶有500萬個，但是自己的PNS一個小時只能處理10萬個request，全部處理完要兩天！那就一定會delay。甚至有些PNS上面要處理的APP不只一個，要處理10幾個APP的排程，那就很不適合放某個時間一定要跳出來的通知。

2.原本可以用的推播，某一天就不能用了？

• 憑證過期，再做一個就好了！
• 從同一個bundle ID做出兩個以上provision，砍到剩一個就好了！

3.推播傳到一半就停止不傳了？

• development的deviceToken不小心混到distribution的清單裡面，找出來，砍掉！（至於怎麼找嘛....）

優點：

1. 管理者想看到接下來要推的是什麼東西的話，後台的schedule裡面一定會有。
2. 如果不想要自己架PNS的話，有一些推播的service可以使用，我之前用過AirShip，還不錯，測試時不用付費，上架後要付費才能傳推播。大陸有一家叫極光推送，不用錢！但我不敢用

缺點：

1. 沒網路GG，APNS會保留一段時間，等裝置可以上網的時候再補推
2. 我們拿到使用者註冊推播後，沒有去偵測使用者有沒有刪除APP的話，群發推播的時候會有一堆發送失敗，也會拖慢排程發送的時間。不過這點應該不叫缺點，而是一定會發生又忘記做的事。

Reference:
Troubleshooting Push NotificationsiOS Push Notifications: Best Practices
Apple Push Notification Services Tutorial