先前在《iOS delegation vs. notification》提到我偏好 delegation, 這篇稍微修正一下對兩者的觀點。
開發 iOS 和 Android 以前我只有寫 Web 的經驗, 沒有寫圖形應用程式的經驗 (硬漢工程師就是要用 CLI 啊!!)。之前只覺得開發 Web 很容易上手, 不過跨瀏覽器很煩。最近多了一些 iOS 開發經驗, 才體會到為什麼 Web 這麼好寫, 個人認為的原因有二:
- 透過 AJAX 做 model 的操作, 預設就有成功或失敗的 callback。UI 明確知道目前 model 的狀態, 要不要反應是另一回事, 至少預設就有能力針對非同步操作提供 UI 回饋。
- DOM 的架構很容易存取到所有 UI 元件。一來 DOM 是全域變數, 二來有 id、class 等屬性方便索引到目標 UI 元件, 任何時間任何一行程式碼都可以一行取得目標 UI。
換句話說, 寫網頁可以輕鬆得知 model 狀態變化, 得知變化時還可以輕鬆地改變任何相關的 UI 元件。
反觀寫圖形應用程式時, 離上述兩點相當地遙遠, 寫起來綁手綁腳的。或許是出於類似的需求, iOS 有提供 NSNotificationCenter 協助 observe 和 dispatch event。
於是, 透過 NSNotificationCenter 這個全域變數, 我們可以
- 讓 model 透過 NSNotificationCenter 告知狀態變化, 或是寫一個 model delegate 做這件事。
- 讓有需求的 UI 元件透過 NSNotificationCenter 觀察事件變化。
如此一來, 減輕不少實作負擔。不過如同 When to use Delegation, Notification, or Observation in iOS 所言, notification 過於彈性會造成一些問題。個人認為配合一些規範, 像是使用 header 檔定義 notification name 和 user info 的 key, 不要直接用 string, 應該是不錯的選擇。
備註:
- 為簡化起見, 上述關於網頁的連結是以 jQuery 為例。
- 漸漸覺得全域變數不是那麼糟的東西, 需要考量它的優缺點來使用, 而不是預設就想盡辦法避免全域變數。
- UIView 也有提供用 tag 搜尋 subview 的方法 (viewWithTag), 像是 DOM 用 id 搜尋一樣。
沒有留言:
張貼留言