做者:Gabriel Theodoropoulos,原文連接,原文日期:2016-01-27
譯者:bestswifter;校對:Channe;定稿:numbbbbbhtml
「推送通知?喔,不!」。是的,這就是我被叫去實現一個 iOS 應用中的推送通知功能時,腦海中閃過的第一念頭,並且我相信大家也曾經有過這樣的想法。這不是由於推送通知很難使用,而是在可以測試推送一條單獨的通知前有不少步操做須要完成,這些操做步驟最終幾乎把全部開發者弄得暈頭轉向。不過咱們再堅持一下子,從頭開始把事情想明白。ios
在應用不在運行時,咱們常常須要把用戶的注意力吸引過來。正如咱們所知道的那樣,這能夠經過 通知 實現。做爲一名 iOS 開發者,你應該知道 iOS 支持兩種類型的通知:本地通知和推送通知(或者叫遠程通知)。在以前的例子中,通知由應用本身 註冊 並 管理,這種通知很容易實現。事實上,你能夠在這裏和這裏找到一些先前介紹本地通知的教程。web
推送通知不是由應用本身預先計劃的。它們由另一個服務(叫作 Provider)觸發,一般狀況下是 web 服務器,這些通知每每同時發往多個設備。有了推送通知,應用開發者能夠在須要的時候給用戶發送消息,消息既能夠在隨機的時間點被髮送,也能夠按計劃時間發送,消息主體能夠是默認的或自定義的。維基百科頁面是一份很好的資源,它提供了一些關於蘋果推送通知的基本信息。編程
每個推送通知由 provider 通過一條強制指定的路徑發往一個或多個目標設備。這條路徑必須通過 Apple Push Notification Servers,或者簡稱 APN servers。實際上,這些服務器會爲推送通知規劃路徑,從而發往正確的設備。一般狀況下,消息在由 provider 發送給服務器的幾秒鐘內,被服務器投遞給目標設備。簡而言之,遠程通知的生命週期能夠總結以下:swift
Provider >> APN servers >> 目標設備數組
我建議你查閱官方文檔,文檔中有不少有用的細節,介紹了推送通知的工做原理。xcode
在應用能夠收到推送通知以前有幾步配置工做,這些步驟整體上能夠被分爲兩步:編程方面的準備和建立各類證書、描述文件(provisioning profile)等。編程部分很容易,它只是幾段必須添加到項目中的標準代碼。容易引發混淆的是第二步,這些操做須要在不一樣的地方被執行,好比 Mac 上的鑰匙串訪問程序,Xcode 項目和 Apple Developer Member Center 網站。服務器
除此之外,遠程通知能夠被分爲兩種,一種是 沙盒 通知,這種通知能夠在開發階段使用,所以它能夠用於調試。另外一種是 實時 通知,這意味着它只能在產品發佈階段使用。若是你成功的在應用中接收到了沙盒通知,而且正確的執行了此前提到的各類操做,那麼就能夠放心的認爲實時推送通知也能夠正常使用了。毫無疑問,Apple 爲發送沙盒通知提供了專門的測試服務器,這並非由生產環境下的 APN 服務器負責的。併發
這篇教程的目的很簡單:咱們但願爲一個 demo 應用實現推送通知功能,併發送一些沙盒通知以確保通知推送功能正常運行。但願下次你爲應用添加推送通知功能時,這篇教程能幫上你。最重要的是,實現推送通知功能事先須要各類繁瑣的配置,這篇教程能夠指引你走出這種困境。app
在正式開始一篇教程以前,我老是會給出一些信息,介紹將要實現的 demo 應用。我常常會提供一個初始項目,不過此次不會。
要想建立這篇教程的 demo,你只須要在 Xcode 中建立一個新的 iOS 項目就能夠了。你不須要額外添加任何內容或控制,由於這個項目並不是用來測試應用內的功能,它只是做爲一個通知推送的目標。
你能夠隨便給項目起個名字,好比我把它命名爲 PNDemo。
因此在這一步中,咱們建立了一個新的 iOS 項目,咱們繼續接下來的步驟。
重要提醒:
在開始講解這篇教程的細節概念以前,我必須說明清楚,基於某些會遇到的狀況,我作了一些假設。咱們約定:
你有一個付費的開發者帳戶,或者至少可以獲取一個這樣的帳戶。
在 Apple Developer Member Center 網站中已經至少有一個 iOS Development Certificate,不然你能夠看一看這篇文章,若是你須要使用 Code Signing Request (CSR) 文件,請閱讀下一部份內容來學習如何建立它。
你明白我在這篇文章中所說的推送消息僅僅是指 Apple 公司的推送消息。
你明白當我說「蘋果開發者網站」時,我其實指的是「Apple Developer Member Center」網站。
你知道通知的載荷(payload)是什麼(內容、角標、聲音以及其餘數據),而且知道如何處理它們。查看這篇文章能夠複習關於通知的知識。
既然你已經建立好了 demo 項目,那麼暫時先把它擱置一下子,準備進行整個流程的第一步。咱們的目標是建立一個 Certificate Signing Request (CSR) 文件,這個文件稍後將被用於建立推送通知的 SSL 證書。
在這一步中,你須要使用 Mac 上的 鑰匙串訪問 應用。你可使用 Launchpad 或 Spotlight 來找到並打開這個應用。若是你不熟悉這個應用,不要無心中刪除任何已有的文件。
打開 鑰匙串訪問 應用後,以下圖所示,依次打開這些菜單 鑰匙串訪問 > 證書助理 > 從證書頒發機構請求證書,以下圖所示:
在打開的窗口中,你必須填寫 User Email Address 和 Common Name。除此之外,還須要選中 Saved to disk 選項,這樣你能夠把文件保存到磁盤中,這個文件稍後在蘋果開發者網站上會用到。
點擊 Continue ,你能夠選擇這個 CSR 文件的文件名和存儲位置。我把這個教程中建立的全部文件都保存在一個新建的文件夾中(文件夾的名字是 PNDemo Files,我但願你也這麼作),CSR 文件名使用的是默認的文件名。
當你看到一條消息,提示你的證書請求文件已經被建立時,點擊 完成 按鈕,而後你就…完成了。咱們剛剛申請並保存的這個證書將被用於在蘋果開發者網站上爲其餘證書籤名。
咱們的下一步操做是在蘋果開發者網站上建立一個新的 App ID。這個 App ID 是將你的應用和其餘應用區分開來的惟一標誌,它能夠幫助 APN 服務器正確的規劃發送通知的路徑。實際上,你將會看到咱們會把這個 App ID 和其它幾樣東西關聯起來:一個用於推送通知的新證書,一個容許咱們在測試設備上運行應用的描述文件。
先完成最重要的事,咱們前往 Apple Developer Member Center,輸入用戶名密碼後登錄。而後點擊 Certificates, Identifiers & Profiles 連接,因而你會跳轉到合適的頁面。
進入到新的頁面後,點擊 iOS Apps 那一節中的 Identifiers 連接。
你會看到 App IDs 選項是事先就選中的(在左側菜單的 Identifiers 目錄中),在主窗口中列出了全部已存在的 App ID 。咱們新建立的 App ID 也會被添加到這個列表中,不過首先得點擊右上角的加號按鈕。
如今,咱們要爲 demo 建立一個新的 App ID,對新手來講,咱們須要填寫兩部份內容:
新 App ID 的描述介紹。在這個例子中,你輸入的內容並非很重要,不過最好仍是要作到語言清晰,具備實際意義。
應用的 Bundle ID,你能夠直接從 Xcode 項目中複製並粘貼到這裏。
你會發現,在這兩個值之間還有一個須要設置的值,它叫作 App ID Prefix。一般狀況下,你不須要修改這裏的默認值,可是若是你確實須要選擇一個不一樣的前綴,也別猶豫。在這篇教程中,我選擇使用默認值。
在這一步中,你要記住一個很重要的細節:實現通知推送功能須要選擇 explicit App ID,由於這個 App ID 必須匹配某個具體的 Bundle ID。在這種狀況下,蘋果不容許咱們使用通配的 App ID(以星號 * 結尾的 App ID)。不管應用具備怎樣的特色,我我的老是認爲使用 explicit App ID 比通配 App ID 更好。這樣會讓你在 App ID 列表中,很清楚的區分開每個 App ID。
設置好以上內容後,向下滾動網頁到 App Services 區域。在全部提供的服務的底部,勾選 Push Notifications 選項,在你開始下一個操做前務必反覆檢查,確保這個選項確實已經被選中。
接下來,點擊 Continue 按鈕並等待確認頁面出現。檢查全部的信息是否都正確無誤,而後點擊 Submit 按鈕提交信息。若是你檢查到錯誤,能夠回退到前面的頁面,修改任何一個有錯的值。
在最後一步中,你會看到 Registration Complete 頁面,只要點擊 Done 按鈕便可,你會看到新的 App ID 已經被添加到 App ID 列表中。
注意到沒有,儘管此前在建立 App ID 時咱們勾選了 Push Notifications 服務,可是它在 Development 和 Distribution 模式下都被標記爲 Configurable 而不是 Enabled。這說明咱們還須要進行一些額外的操做,將通知推送服務切換到合適的狀態。
在這個教程中,咱們不會在生產環境中測試推送任何通知,也就是徹底不涉及 Distribution 模式。出於這一點考慮,咱們只會配置 Development 模式下的推送通知。不過接下來的操做對於 Distribution 模式下的配置徹底適用。在一個實際的應用中,你顯然須要配置 Distribution 模式,不然在應用上架 App Store 後,推送通知的功能就會失效。
如今,咱們點擊列表中剛剛建立的 App ID,在展開的服務列表中,點擊 Edit 按鈕進行下一步操做。
向下滑動到 Push Notifications 一節,你會發現兩個按鈕,分別用於建立開發環境和生產環境下的 SSL 證書。由於咱們只關心 Development 模式,因此點擊下圖中的第一個按鈕:
「好久」之前經過鑰匙串訪問建立的 Certificate Signing Request 文件是時候登場亮相了。接下來,咱們首先點擊 Continue 按鈕。若是你尚未建立 CSR 文件,這幾條教程會教你如何建立它。
接下來,點擊 Choose File… 按鈕並找到你在第一步中建立的 CSR 文件。若是你沒有修改文件的默認名字,那麼你要找的文件的名字就是 CertificateSigningRequest.certSigningRequest
。
最後,點擊藍色的 Generate 按鈕,以下圖所示:
棒!你已經成功建立了一個新的證書,它能夠在 development(sandbox)模式下推送通知。如今你須要把它下載下來,而後添加到鑰匙串(Mac 上的鑰匙串訪問應用) 中,因此接下來你須要點擊 Download 按鈕。
你剛剛下載的文件名是 aps_development.cer
。在 Downloads 文件夾中找到它,雙擊打開這個證書並將它添加到 Keychain Access 的證書列表中。
重要提醒: 雙擊打開 .cer 文件並將它添加到鑰匙串訪問中時,請確保它被添加到登陸而不是系統或其餘鑰匙串中。若是加入的鑰匙串有錯,你只須要把證書拖動到登陸鑰匙串中便可。這對下一步操做很重要。
把證書添加到 KeyChain 中後,右鍵點擊這個證書,而後選擇 Export 「…」 選項
導出格式要選擇成 .p12 文件,而後點擊 Save 按鈕。
若是你不想設置密碼,能夠直接點擊 OK 按鈕跳過這一步。若是你設置了密碼,那麼就要記住它或者把它寫在某個地方,不然一旦忘記了密碼,這個文件也就沒用了。
在這個教程中,咱們不會用到這個導出的文件。但若是你想在遠程服務器上(好比 Parse)測試推送通知功能,你就須要在推送第一條通知之前提供 .p12 格式的文件。因此目前你把這個 .p12 文件和其餘文件一塊兒保存着就好。這一步的關鍵在於你可以意識到開發模式下建立 .p12 文件的方法一樣適用於生產環境。
首先,我須要說明這一步僅對測試沙盒模式的推送通知有用,在實際的生產環境下不須要這一步。如今,咱們去蘋果開發者網站上註冊用於測試的設備,若是你曾經註冊過設備,也就是列表中能夠找到這個設備,那麼你能夠跳過這一步。
假設你如今是第一次添加設備,首先你須要將物理設備與 Mac 鏈接,而後在 Xcode 中打開 Window > Devices 菜單,在打開的窗口中列出了全部的物理設備和模擬器。
在左側選擇你的設備,你會在主窗口中看到更多細節。注意到其中有一項是 Identifier,它的值是一長串數字和字母,雙擊選中這個值並複製。
如今,返回蘋果開發者網站,點擊 Devices 目錄下的 All 選項,全部被註冊過的設備都顯示在主窗口中。要想新增一個設備,你須要點擊右上角帶有加號(+)圖標的按鈕。
在新打開的表格中,首先在 Name 文本框中輸入設備名稱(好比 Gabriel’s iPhone 6S 或 My lovely iPad)。而後把以前複製的設備的 identifier 填寫在 UUID 文本框中,這一步就完成了。
點擊 Continue 按鈕,在下一步中須要確認因此填寫的信息都準確無誤。搞定以上這些後,點擊 Register 按鈕完成註冊。
你能夠驗證是否成功的註冊了設備,只要再次點擊 Devices 目錄下的 All 選項,而後逐條查找你剛剛輸入的設備名便可。
在蘋果開發者網站上的最後一個任務是爲開發環境建立一個描述文件。它將會用於爲應用提供代碼簽名。注意,在把應用上傳到 iTunes Connect 並使用 TestFlight 或上架 App Store 以前,你須要建立發佈環境的描述文件(Distribution provisioning profile)。它的使用方法和你將要學到的開發環境的描述文件的使用方法相似。
在蘋果開發者網頁上,點擊 Provisioning Profiles 目錄下的 Development 連接,主窗口中會顯示出全部已存在的描述文件。稍後,咱們新建的描述文件也會添加到這裏。
你能夠經過點擊右上角的加號(+)按鈕建立一個新的描述文件。在新打開的表格中,點擊選擇 iOS App Development選項(第一個選項)。注意,若是你建立的是用於發佈應用的描述文件,就應該選擇底下第二個區域中的選項(很大多是 App Store)。
選擇了合適的選項後,點擊 Continue 按鈕開始下一步操做。
如今,咱們要把這個描述文件與應用對應的 App ID 關聯起來。你須要在下拉菜單中查找並選擇正確的 App ID。
接下來,你須要把你的 iOS Development certificate 導入到描述文件中(假設你至少有一個證書)。若是像下圖所示那樣,有多個證書而且不肯定該選擇哪個,一種簡單的方法是勾選 Select All 選項導入全部的證書,這一步就完成了。
接下來是選擇將要運行應用的設備,請確保沒有漏選任何用於測試推送通知的設備。選擇好後再次點擊 Continue 按鈕。
最後一步是爲描述文件文件命名,將它與其餘文件區分開來。我把它叫作 PNDemo Development Profile,你能夠根據本身的喜愛隨便起名。
點擊 Generate 按鈕並等待下一個頁面出現。當新的描述文件建立完成後,你就能夠下載它了。以下圖所示:
你只須要根據以上這些圖片的指示去操做便可,而後雙擊打開並安裝剛剛下載的文件。若是你按照個人方式命名,那麼你的文件名會是 PNDemo_Development_Profile.mobileprovision。
從這一步開始,咱們就和蘋果開發者網站說再見了。把目光轉移到咱們的項目上來,這裏咱們須要完成兩個任務:
首先咱們要在項目中開啓推送通知功能,這樣設備才能接收到通知。雖然這是很基礎,很簡單的一步,可是相信我,不少開發者都會忘記啓用推送通知功能。
咱們須要正確設置應用的 code signing 和 provisioning profiles。注意,接下來的操做都會在 Development 模式下進行,咱們徹底不會涉及生產環境。可是這二者很是相似,因此在應用上線前你能夠仿照這裏的步驟完成生產環境下的配置。
在 Xcode 中打開應用,選擇 Project 導航欄中的項目。請確保你處於 General 標籤下,而後點擊 Team 下拉控件,選擇正確的 team。
若是你的 Team 列表空空如也,那麼你得前往 Xcode > Preferences… 菜單,在 Accounts 標籤下新增一個 Apple ID。你須要輸入正確的用戶名和密碼並點擊 Add 按鈕完成添加。這一步的細節已經超出了本教程的探討範圍,所以若是你拿不許怎麼作,這個連接中的文章會一步一步指導你。成功添加 Apple ID後,關閉偏好窗口並返回 General 標籤,選擇合適的 Team。
接下來,點擊 Capabilities 標籤,找到 Push Notifications 這一節,你只須要打開開關便可。
正如截圖中的信息所示,一旦啓用推送通知功能,在 Info.plist 文件中就會自動添加相應的權限。
如今打開 Build Settings 標籤,找到 Code Signing 這一節。展開 Provisioning Profile 字段,而後點擊 Debug 這一行中的 Automatic。在展開的列表中有你的開發者帳戶下全部的描述文件,你須要選擇你上一步下載並安裝的那一個。
由於咱們沒有建立發佈應用時用到的描述文件,因此咱們無需設置 Release 這一行中的值。不過當你在蘋果開發者網站上建立並下載發佈應用時用到的描述文件後,你須要採起與這裏相同的操做。
你能夠在描述文件字段上面找到 Code Signing Identity 字段。若是它沒有展開,你能夠點擊左側的箭頭展開它。這一步的操做和剛纔相似,點擊 Debug 欄中的默認值 iOS Developer (或 iPhone Developer),而後在彈出的列表中選擇合適的身份證實。以下圖所示:
在實際應用中,別忘了在 Release 欄中設置 Distribution 模式下的身份證實。
如今,點擊 General 標籤左側的 Target 選項,選擇 Project:
找到 Code Signing 這一節,重複以前的步驟。首先選擇 Debug 模式下的描述文件,而後設置好正確的 Code Signing Identity。
到目前爲止,項目中的配置都結束了,如今咱們須要寫幾行代碼了。首先,咱們讓應用自身向 iOS 系統註冊接收推送通知,並指定咱們但願接受的通知的類型(好比角標,聲音或警告信息)。
事實上,咱們會用到上述全部類型的通知,這也是咱們的在這一步的切入點。打開 AppDelegate.swift
文件,在 application(_:didFinishLaunchingWithOptions:)
方法的 return true
前面添加下面兩行代碼:
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool { // Override point for customization after application launch. let notificationTypes: UIUserNotificationType = [UIUserNotificationType.Alert, UIUserNotificationType.Badge, UIUserNotificationType.Sound] let pushNotificationSettings = UIUserNotificationSettings(forTypes: notificationTypes, categories: nil) return true }
咱們首先指定應用中會用到的通知類型,而後建立一個 UIUserNotificationSettings
類型的對象。咱們使用這個對象向系統註冊推送通知。若是出於某些緣由,你不想使用上面這個數組中全部種類的通知,只要刪除掉不想要的便可。
如今,咱們將這些可能用到的推送通知的類型告知系統,而且註冊接收推送通知:
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool { ... application.registerUserNotificationSettings(pushNotificationSettings) application.registerForRemoteNotifications() return true }
儘管以上幾行代碼都很重要,但最後一行纔是設備可以接收推送通知的關鍵。這一部分中添加的四行代碼是一段標準代碼,因此你幾乎能夠把它們用在你的全部項目中。我是說幾乎,由於總會有須要修改通知類型的時候。
註冊推送通知是很關鍵的一步,但這只是咱們要作的編程工做的一半。另一些與編程有關的任務是實現一些代理方法,這樣你的應用才能在接收到通知時作出正確響應。咱們一個個看這些方法:
首先,咱們要實現 application(_: didRegisterForRemoteNotificationsWithDeviceToken:)
方法。它在應用成功註冊推送通知後調用。一般狀況下,第二個參數相當重要,它包含了每一個設備獨有的一個 key,咱們把這個 key 稱爲 device token。在實際使用中,你須要把 device token 發送給服務器。這裏的服務器是推送消息的最初發起方,它把 device token 和其餘必要信息發送給 APN 服務器。這就是爲何 APN 服務器可以知道通知的接收者是哪臺設備。
Device token 的格式是這樣的:< XXXX XXXX XXXX XXXX XXXX >。一般狀況下,在發送給服務器以前,你須要對它進行一些格式轉換,好比移除 「<" 和 ">」字符或者移除字符串中間的空格。不過最終始終何種格式仍是取決於服務器如何處理 device token。一些服務提供商會爲你提供框架,以便你集成並處理推送消息(如 Parse),若是你打算使用他們的解決方案,那麼框架的使用指南會告訴你如何實現格式轉換。
無論怎麼說,因爲咱們在本篇教程中不會使用真正的服務器,你只須要了解以上知識並在實際的應用中進行正確操做便可。目前咱們只打算把 device token 輸出到控制檯中。咱們須要知道它的值,這樣待會兒才能測試推送通知。下面是咱們的實現代碼:
func application(application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: NSData) { print("DEVICE TOKEN = \(deviceToken)") }
咱們不能確保註冊推送通知必定是成功的,這個過程可能由於多種緣由而失敗。因此,實現下面這個方法也很重要,在這個方法中咱們能夠處理註冊失敗的狀況:
func application(application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: NSError) { print(error) }
固然,你須要根據應用的邏輯或需求來進行適當的錯誤處理。
正如你所知,當應用不在前臺運行時,推送通知會出如今設備上。但不少時候,應用會在運行時收到推送通知。在這種狀況下,做爲一名開發者,你須要用適當的方法處理接收到的通知。在 demo 中,咱們只是把收到的信息輸出到控制檯裏。但在實際的應用中,你絕對不該該這麼作。
下面是對應的代理方法的實現:
func application(application: UIApplication, didReceiveRemoteNotification userInfo: [NSObject : AnyObject]) { print(userInfo) }
你還能夠根據應用的具體需求,使用更多的代理方法,不過這就不是本文所討論的內容了。UIApplicationDelegate 協議的文檔能夠參考這個連接,你能夠從中找到更多有關遠程通知的方法。考慮到這篇教程的目的是指導你實現推送通知的功能,瞭解以上三個代理方法就足夠了。
測試推送通知曾經是一件很麻煩的事,由於這隻有一種解決方案。要麼從頭開始寫一個命令行腳本,要麼找一份已有的腳本並根據本身的應用和設備進行修改。時至今日,這個方案依然行得通,但在 Mac App Store 上已經出現了一些專門用於測試推送通知的應用。沒錯,這就是咱們將要使用的方案。
使用 Mac 上的應用來測試推送通知的好處在於,它提供了用戶界面(GUI)給咱們填寫必要的數據(好比 device token 或推送通知的證書)。並且這些應用隱藏了「無聊」的編程部分,好比鏈接到 APN 服務器。實際上,在大多數此類應用中,你只須要指定如下三樣東西:
用於接收測試通知的目標設備的 device token;
推送通知證書的保存路徑;
推送通知的載荷(消息、角標數字和聲音)。
在這個部分中,我會向你們展現兩款應用。不過首先要澄清的是:此舉徹底不是爲了推廣這些應用。你即將看到的這兩款應用,以及 Mac App Store 上其餘同類的應用,在我看來是都是能夠簡化工做、節省時間的簡單的工具。基於以上邏輯,咱們繼續這篇教程,來看看如何成功的推送第一條通知。
第一個要推薦的應用叫 APN Tester Free,你能夠在這裏找到它。這是一個免費下載的應用,藉助這個應用你能夠快速的測試推送通知。
如上圖所示,你須要把 device token 複製到 Device Token 文本框中(不帶「<"和">」字符)。你只要運行一次 demo 就能夠很容易地在控制檯中看到 device token。你應該會看到以下圖所示的結果:
首次運行應用時,系統會詢問你是否容許接收遠程通知。顯然,若是你想要測試接收通知就必須選擇容許。
在 Payload 文本框中,你須要填寫推送通知的細節內容。好比你但願接收一條消息,顯示角標數字並播放默認的聲音,你應該這樣寫:
{"aps":{"alert":"Hello from AppCoda!","badge":1, "sound": "default"}}
若想獲取更多有關通知載荷和全部可設置的值的信息,請訪問官方文檔。
在填寫正確的 Certificate 信息時,你須要點擊 Browse 按鈕,在磁盤中查找開發模式下的推送通知證書(這顯然是在 Gateway 的值被設置爲 Development 時的操做)。提醒你一下,這個證書的名字應該是 aps_development.cer(除非你修改了文件名)。找到證書並導入到應用中後,你會在控制檯中看到一條消息,告訴你 .cer 文件已經被成功的加載了。
設置完以上內容後,你就已經準備就緒,能夠推送通知了,你要作的僅僅是點擊 Push 按鈕。這時你會在應用的控制檯中看到推送通知被髮送的消息,若是推送失敗,控制檯中一樣會有紅色的文字提示。
若是你按照教程,一步一步的進行操做而且沒有漏掉任何步驟,那麼你將會收到第一條推送通知
你徹底能夠反覆發送通知,這樣你能夠看到在設備鎖屏時、打開通知中心時、甚至是應用運行時等不一樣狀況下,通知是如何出現的。若是在應用運行時收到通知,你會在 Xcode 的控制檯中看到以下輸出:
除此之外,你還能夠本身修改角標數字,開啓或關閉通知的聲音。經過這些嘗試,你能夠確保全部的配置都正確無誤。
另外一個我打算向你展現的應用是一個叫作 Easy APNs Provider 的程序,你能夠在這裏找到它。這是一個免費應用,它有一些額外的選項可供設置,所以你能夠嘗試設置推送通知更加高級的功能(好比額外的數據)。
使用這個應用時,首先點擊 Add tokens… 按鈕並把 device token 添加到應用中。在彈出的模態視圖中,把 token 複製到第一個文本框中,同時務必確保你已經刪掉了「<"、">」字符和空格。若是格式有誤,token 就沒法被添加到應用中。完成這一步後點擊 Add 按鈕,你會看到 device token 已經被添加到窗口的底部。你還能夠選擇點擊 token 的左側,爲它起一個名字,而後點擊 Confirm 按鈕完成。
接下來,點擊 2. Choose Certificate file按鈕,再次找到 aps_development.cer 文件並把它導入到應用中。成功導入後你會在按鈕的旁邊看到證書文件的名字。
確保右下方的下拉控件中被選中的值是:gateway.sandbox.push.apple.com,而後點擊 3. Connect to:按鈕。在顯示狀態的文本框中,你會看到應用已經成功的鏈接上了 APN 服務器。
如今是時候準備推送通知的載荷了,咱們把目光轉移到應用窗口的右上角,選擇你想測試的選項。爲了最好的演示通知效果,你能夠選擇 Content,badge 和 sound 選項。而後在下面的表格中填寫 title,content 和 badge 的值,這裏的值能夠隨意設置。若是你想看到載荷的原始模式(JSON 模式),能夠點擊 Raw 標籤,不然就使用當前這種更容易處理的模式。
最後,點擊 5. Send APN 按鈕來發送通知,幾秒鐘內你的設備就會接收到這個通知。
正如我在這一步開始的時候所說,你並不是只能選擇以上這兩個工具。你能夠去 Mac App Store 中找找其餘的軟件,它們或許可以更好的實現你的需求。
在這篇教程中,咱們經歷了不少步驟,執行了許多不一樣的操做。若是你讀到了這裏,而且成功的在沙盒模式下推送了通知,那麼你徹底有理由相信在實際應用中,實時通知推送也會正常工做。你只須要遵循文中列出的操做指南,將它們應用於 Distribution 模式而且補上文中沒有處理的部分便可。舉個例子吧,你須要編輯你的 App ID 並建立發佈應用時用到的 SSL 證書,還須要建立 Distribution 模式下的描述文件,固然還得在項目的 Build Settings 中使用合適的代碼簽名。不管如何,我都但願本文可以幫助你理清思路,弄清楚配置通知推送的步驟,最終幫助你更快的完成任務。下回再見!
本文由 SwiftGG 翻譯組翻譯,已經得到做者翻譯受權,最新文章請訪問 http://swift.gg。