{%hackmd DfWYF9cYREebVNN1eEOz-w %}

APP 架構想法
======

###### tags: `架構想法` `202209`

> ******

## Android
印象是在 2018 還是 19 年當時的想法紀錄，當時主要的想法是封裝 API，與建立三層架構。補充當時的思考方向，有去探討 APP 的開發需求，根據探討發現 APP 與使用者互動，接著很大的可能性是與後台要資料，運算後在呈現於畫面上)

11/14 那天對 Android 當時架構的想法，來自修改 07/10 的想法

**以下依照專案中的檔案結構來說明整體的架構，依序為架構內層到外層**

### api
---
note: 只提供 BusinessManager 使用!!
#### dataManager
- 統一管理使用 retrofit 有關 http 請求的動作
- 可以創造假資料
- 只判斷: 1.網路是否穩定 2.請求是否成功 3.其它需求
- 不做任何資料的處理
#### model
- 擺放所有 retrofit http 的 Interface 請求過來的 Model
#### retrofitInterface
- 擺放所有 retrofit http 的 Interface
- 目前是用 url Domain 來做區分
#### retrofitManager
- 統一管理 retrofit 所有 http 請求接口(Interface) 的實例
- 管理每個 http 請求接口 對應的轉換方式. (比如 json || String || void ...等)
---

### utils
- 這裡所有的都為靜態方法，提供給所有的類使用
- 集中管理所有的 toast, dialog, alert, 防呆, sharedPreference

### businessManagers
note: 專門提供給 activity || businessManagers 使用
- 依據功能建立對應服務的資料階層
- 統一使用 callback 來跟 activity || businessManagers 互動 (盡量) => 統一集中 AllBusinessCallback 中
- 若要使用 Thread => 使用 BaseManager 提供的方法
- 若商業邏輯 & 功能繁多
- 依職責(需求)創建 介面 || 類 來區分 目的是為了讓不同的商業邏輯在互相叫用時, 使用方式更為簡潔.
- 處理 http 請求有關 "資料加密" 或者 "商業邏輯上的轉換"
- 自己使用到的 service, model, adapter ... 等, 需在對應商業邏輯的資料階層下, 額外建立一個目錄

### baseActivity
note: 所有的 activity 都應繼承 BaseToolbarActivity 控制
- 版本強制更新提醒 => 使用 BaseUpdateCheckActivity 提供的方法
- 管控 toolbar => 使用 BaseToolbarActivity 提供的方法
- 轉圈圈提示使用者等待 => 使用 BaseUpdateCheckActivity 提供的方法

### activity
note: 不可用 api 的類，只能用 BusinessManager
- 擺放所有的 activity

### fragment
- 擺放所有 Acvitiy 使用到的 fragment

### widget
集中擺放共用的子 view

### receiver
所有廣播相關的集中放這

---

## IOS
2022/09

### 探索
想建立跟 Andorid 雷同的架構，所以開始去閱讀一些資訊。先探索主流的架構與別人的觀點。
- [# [Swift]從MVC到MVVM、Data Binding](https://penny-huang.medium.com/swift-%E5%BE%9Emvc%E5%88%B0mvvm-data-binding-bc65830f9670)
- [MVVM VS MVC：透過 MVVM 設計模式重構 MVC 應用程式 減低應用程式的複雜性](https://www.appcoda.com.tw/mvvm-vs-mvc/)
- [漫談 iOS 架構：從 MVC 到 VIPER，以及 Redux | Nelson](https://chiahsien.github.io/post/common-ios-architecture-from-mvc-to-viper-with-redux/)
- [# Massive View Controller 重構：透過依賴注入 (Dependency Injection) 減輕職責](https://www.appcoda.com.tw/massive-view-controller/)
- [MVC => MVVM](https://www.tpisoftware.com/tpu/articleDetails/1952)
- [# Massive View Controller 重構：Coordinator 模式與 Flow Controller](https://www.appcoda.com.tw/coordinator/)
- [# RESTful API 教學：用 Swift 建立屬於自己的輕量 REST 程式庫！](https://www.appcoda.com.tw/restful-api-library-swift/)

### 擷取不錯的論述
- [據估計](http://www.businessinsider.com/how-many-lines-of-code-it-takes-to-run-different-software-2017-2)，Windows 7 包含約四千萬行程式碼，而 macOS 10.4（Tiger）包含約八千五百萬行程式碼，預計這些系統可能表現的行為總量在計算上是不可能的。記得我提到過「指數式」，即復雜性接近無限時，任何具有四千或八千五百萬行程式碼的應用程式都是無限複雜，沒有人能夠知道這些應用程式可以展示的每種可能狀態或行為，我們只能盡力控制混亂。

- 請記住，即使你和團隊處理的那些「較小」應用程式，也可以輕易達到無限複雜。那麼工程師可以怎樣做？繼續學習與設計模式有關的文章、看看幫助控制_軟體複雜性_的其他工具、查詢術語「軟體複雜性 (software complexity)」並加以研究。

- 說到這裡相信你已經理解，MVC / MVVM / VIPER 其實是同一件事，它們只是工程師在 refactor 過程針對不同程式碼複雜度的規劃罷了。

- 請記住，世上沒有_完美_解決方案。不要與提倡烏托邦或主張 all-or-nothing 的人爭論。我們只是人類，都會隨著時間一直在成長，盡力而為吧。

### 想法
架構對於軟體開發是重要的一件事，近代的專案你看過了多少是沒有架構? 應該少之又少，所以架構對軟體產品的重要性不言而喻。更激進點來說選擇錯的架構，也勝過不做任何事。

有了架構不見得會影響工程師的開發質量(因為可很單純的用)，但絕對會影響未來的維護性與系統穩定性，且熟悉後會加速開發的過程，與可降低未來想導入自動化測試的難度。

架構重點就是 **降低複雜度、系統穩定性、職責分明、高可維護、降低溝通成本、專案一致性**

- 查閱幾篇文章後, 決定選擇 MVP + Coordinator
- 要再思考 layer 之間的訊息交換機制
- Coordinator 是否有需要獨**立出來? 現階段對於 IOS 轉場上的理解程度不夠高，引用該模式可能導致不正確
- 這裡打算暫時不用, 若未來轉換場景越來越複雜時優先考慮 swiftUI
- Repo API
- 不要重造輪子，我們很難做得比專門開發 "函式庫與框架" 好。只要知道如何找到好的函式庫，並且正確地封裝後引用。(如果是框架較難封裝，**用了框架並不代表你的軟體產品就不需要設計架構了...**)
- 較知名的 API 為: Alamofire
- 跟 Android 不同, 不需要去對 Alamofire 去做單例
- 只需管理
- url: 這裡可以想想 path 組成是否需要控管
- timeout
- header
- 建置 Repo API，不同語言在實踐同一件事時，作法相差甚遠。需一段磨合期。再來是磨合時會發現很多語法，需要選擇最佳方案。

### 決定 IOS APP 架構
Repo API架構: 分為三層由外而內是 **BI => Repo => OtherAPIs => API Manager**，層與層溝通用 callback 組合以 "()-> ?" + "swift swicth" 完成
- ApiManager 封裝 Alamofire 與細節
- OtherAPIs 個大功能對應的 ApiManager
- Repo 將 Other APIs 變成 properties
- 改善: callback 程式碼看起來有點阿雜，未來可以引入 rxSwift
- 封裝隔離 "光譜儀廠商 SDK"

businessManagers 參照 Android 的想法並實現。