這次的 app 需要一各訊息中心功能
不過一開始說的很簡陋，就依照最簡單的作法下去處理
結果後來因為訊息種類持續增加，前面就要加入訊息分類頁面
有了訊息分類就要顯示未讀訊息，包括在訊息分類頁面和乘載此頁面的tabbar controller
然後，因為加入了推播功能…收到推播時當然也應該要進行合理更新…
因為這些歷程，整各架構就大改四次
以下是這幾次架構的簡述
V1: 訊息展示頁面，使用 tableview controller
開啟時更新訊息，然後 insert to row
V2：訊息分類頁面，出現時更新訊息，取得未讀放到分類 icon 上
V3
由於更新訊息時是使用訊息分類頁面，反饋到 tabbar controller 更新 badge 的步驟太複雜（事件難控制）
所以改成使用 notification center 處理
然後又是一次大改..
V4
為了要支援推播，所以需要在接收到推播時更新訊息，然後用 notification center 事件更新
但是單純只改這部份的話，程式又會變得複雜
所以就把更新訊息功能單獨取出成立物件
並且修改成 程式進入前景、收到推播、進入訊息中心時更新訊息
更新後，使用notification center 通知更新頁面
這樣修改後
會有三個觸發程式更新訊息的時間點，進入前景、收到推播、進入訊息分類頁面時
事實上，前兩個應該就夠了
不過由於這個 app 是在企業內使用，有可能會在無法收到推播的環境下作業
因此加入了進入分頁時也會更新訊息的功能避免這種狀況
這些功能也從一開始存在於個別 VC 中的情況轉變成公用程式
但是因為公用程式太多太雜，最後又變成一個擁有自己參數和設定的獨立物件
在這過程中
會發現由於一開始的需求不確定，單純使用簡單的設計
但是後來隨著不斷的改進，慢慢的趨向了主流的設計模式
許多設計模式也許一開始覺得太..複雜用不上
那是很正常的
但是當功能開始複雜後，為了彼此間的整合，就會慢慢趨向許多設計模式的作法
因此，即使目前的功能簡單
但是短期內有可能大幅演進的時候
一開始多花點時間設計好架構
就可以大幅縮短日後的修改、維護所需花費的心力
而Best Practice 就是許多人在處理幾乎相同的工作時，歸納、精簡出來的實作範例
設計模式則是在處理「概念」類似的工作時，歸納出來的作法之抽象模型
沒有留言:
張貼留言