《iOS「通告機制」及由其引出的對「架構模式」、「設計模式」的理解，ios訊息推送機制

《iOS「通告機制」及由其引出的對「架構模式」、「設計模式」的理解，ios訊息推送機制

說明：為了區別「本地通知」與「推播通知」這兩種iOS中提醒使用者，可見的「通知」，本文所將Notification翻譯為「通告」。它們的詳細區別，可參考《iOS開發系列--通知與訊息機制》一文。

實踐遇到的問題：

最近在維護公司的一個項目中，遇到這樣一個報錯：-[GlobalManager addAlbum:]: unrecognized selector sent to instance

經排查，原因如下：以前同事在利用「通告機制」在GlobalManager類中把「自己/self」註冊為「觀察器」(用了addObserver: selector: name: object:方法)，但是沒有在註冊觀察器的類(GlobalManager類)中實現selector參數中的方法(他在其他類實現了)。所以就報上述錯誤(其實報錯中字面也說得挺明白的，只是總意會不到英文中的那個意思)。

解決：將 selector參數的方法寫在當前類中。或者刪除註冊「觀察器」的代碼，即不報這個錯。

再經過後來的查閱資料，得出結論：如果用addObserver: selector: name: object:方法向「通告中心」註冊「觀察器」，第二個參數，即selector:中的方法，必須在當前類中實現，如果寫在其他類，就會報上述錯誤。詳見圖一：

擴充：另一個註冊觀察器的方法
另外，註冊觀察器還可以用另外一個方法：
addObserverForName: object: queue: usingBlock:
這個是利用block的形式進行「回調」，代碼更簡潔、直觀。而上面的方法是「利用@selector關鍵字傳遞SEL類型的函數名」進行「回調」。

圖一：註冊「觀察器」

插播：「回調/callback」

上述「通告機制」，涉及到「回調」這個概念，因為維基百科上面的定義有點抽象，我自己理解就是：某段代碼/函數，需要由特定使用者事件來觸發，就是「回調」，沒有這個事件，就不會執行這段代碼。術語就是「通過『函數指標』調用的函數」。
而根據《Objective-C Programming 2nd Edition》這本書，iOS的回調，分為四類：
1.目標－動作對/Target-action；
2.輔助對象/Helper objects；(包括「委託/delegates」、「資料來源/data sources」)
3.通告/Notifications；
4.Block。
這裡只簡單複述iOS回調的幾種類型，至於何種情況用何種回調，可以看書中介紹。(我自己也需要更多實踐去體驗。)

詳解：「通告機制」

可以看到，第三種回調：「通告」，就是我們上面應用的「通告機制」。它是基於「觀察者模式」的。
「通告機制」在代碼層面，涉及兩個類：NSNotification類及NSNotificationCenter類，它們都定義在“NSNotification.h”檔案中。

NSNotification類：
代表「通告」的內容載體有三個屬性：name(通告的名稱)，object(通告的寄件者/誰發送這個通告)，userInfo(通告的附加資訊/參數)
此外，NSNotification類及它的擴充類(category)還有5個初始化/執行個體化「通告」的方法，詳情可在Xcode中查看。

NSNotificationCenter類：
是通告系統的中心，用於擷取通告中心、註冊、移除觀察器、發送通告。有8個方法。詳情可在Xcode中查看。

 

因此，我們可以總結「應用「通告機制」的步驟」：

1.註冊觀察器。
這一步解決誰觀察通告中心，觀察通什麼通告，觀察通誰的通告，接到通告後執行什麼方法這些問題。
註冊觀察器的方法
addObserver: selector: name: object:
addObserverForName: object: queue: usingBlock:

2.實現selector中的方法或block中的代碼
這一步具體實現接到通告後執行什麼動作。

3.向通告中心發布/post通告。觸發回調， 實現最終要的效果。(此步驟可選)
注意，這裡由誰發送通告(在哪個類中寫發送通告代碼)，要看觸發事件是在哪個控制器類中。
另外，如果觀察一些系統通告，如UIDevice的這四種「通告」(UIDeviceOrientationDidChangeNotification、UIDeviceBatteryStateDidChangeNotification、UIDeviceBatteryLevelDidChangeNotification、UIDeviceProximityStateDidChangeNotification)，則由系統自動發布通告，無需自己實現。

發布通告的方法：
postNotification:
postNotificationName: object:
postNotificationName: object: userInfo:

4.將註冊為觀察器的對象移出通告中心
可用方法：
removeObserver:
removeObserver: name: object:

 

範例：

在工程中AppDelegate類中，添加以下代碼，可觀察/監測是否有物體接近螢幕。

1 UIDevice *device = [UIDevice currentDevice]; 2 // 開啟近身監視功能 3 [device setProximityMonitoringEnabled:YES]; 4 5 // 註冊觀察器 6 [[NSNotificationCenter defaultCenter] addObserverForName:UIDeviceProximityStateDidChangeNotification 7 object:nil 8 queue:[NSOperationQueue mainQueue] 9 usingBlock:^(NSNotification *note) {10 NSLog(@"有物體接近螢幕了");11 }];近身監測功能的實現

 

  

擴充：「架構模式/Architectural pattern」與「設計模式/design pattern」

到此，對「通告機制」的基本原理，具體實現有了一定瞭解。不過在研究「通告機制」的時候，接觸到「觀察者模式」，繼而又接觸到「設計模式」及「架構模式」，一下子資訊量太大，感覺如墜雲中，只見樹木，不見森林。於是又研究了一陣(主要參考維基百科的資料)，總結並畫出二，感覺能大概從宏觀上把握這些概念了。(不知有無謬誤，如有發現，還請斧正，謝謝。)

 

圖二：對「架構模式」及「設計模式」的理解

 

而關於「MVC模式」及「觀察者模式」在整個「軟體設計模式/Software design patterns」中的位置，則如三：

圖三：「MVC」及「觀察者模式/Observer」在整個「軟體設計模式/Software design patterns」中的位置

突然間，感覺舒服蠻多了。