《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」中的位置

忽然間，感受舒服蠻多了。