iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 7
0
Mobile Development

諸神黃昏下的 iOS 工程師系列 第 7

D7 - 專案檔案結構亂糟糟,只好 cmd+Q ?

  • 分享至 

  • twitterImage
  •  

讓我們切分各種畫面邏輯區塊,讓我們專案結構一目瞭然

? 隕石小故事

雖然這個情況不是在隕石開發的時候遇到的,但是還是能夠說明一下 XD。之前在接手一個算是小有規模的專案時,在開啟他的 Main.storyboard 時,Loading 的彩球就開始瘋狂地轉,Mac 的風扇也開始運轉,Loading 結束之後看到的 Storyboard 彷彿是一個蜘蛛網 ?,看到散落在各地的 viewController 以及他們之間可怕的 Segue 連線,並且專案的資料夾管理也是非常複雜,很難馬上找到該個文件,如此一來在開發上就遇到了一個障礙。

Overview

因此,如果我們可以了解每個檔案應該在哪個功能資料夾中,那我們在搜尋及區分檔案應該在哪個資料夾時會非常快速。而在多人合作的情況下也能減少理解的困擾,其他人能夠透過資料夾的名稱以及結構名稱,找到需要處理的檔案項目。在分開處理功能時也能夠減少衝突。


開始管理

|資料夾結構

我們能夠以專案整體的架構,像是 MVC、MVVM...。來大致區分每個文件的位置,而其他的額外功能,像是網路請求,我們可以將它獨立放在 Service 或 Networking 的資料夾中,而 Extension、SubClass 跟 Helper 也能夠讓他們獨立在一個資料夾。

你可以在網路上找到各種管理專案結構的文章,但我自己區分結構是參考這篇 StackOverflow 的文章

而每個資料夾大致管理的功能為:

  • Helper: 包含第三方的 Class/Framework、Bridging Class(橋接器、基於 Swift 項目中的 Objective-C 的 class)
  • Service(Store): 包含 Web 服務程序(登入驗證、HTTP Request/Response)
  • Extension: 任何 class 的 Extension 內容。
  • Model: 創建一個 singleton Class 來保存數據,Web Service Response 的解析和存儲數據也在這裡完成 。保持 Modal 不能改變,使用它將 API 的內容轉換為我們的應用程序。Swift 使用 struct 來確保不變性,並使用 Codable 來執行 JSON -> Modal 的映射。
  • View: 包含 Storyboard、LaunchScreen、XIB 和 View class。並製作一個子資料夾 Cells,其中包含 UITableViewCellUICollectionViewCell 等。
  • Controller: 包含與 UIElement 相關的邏輯和程式碼,像是一個 UIButton 的 reference 和點擊操作。
  • Supproting Files: 這邊忘了當初看哪邊學的 xD,其中大部分會放 AppDelegate、Assets.xcassets,Info.plist。而有些人也會把 LaunchScreen 放在其中。

|管理 Storyboard 與其 ViewControllers

有些人可能會以為一個專案只能有一個 Storyboard 來做為開發(當初的我),但是如果只有一個 Storyboard 的情況下來開發,你的畫面可能就會像是我上面提到的蜘蛛網的狀況。因此,我們能夠透過處理的功能不同,建立不同的 Storyboard。

像是如果我們的專案有下列幾個主要功能:

  • 主頁
  • 登入頁
  • 商店頁

而這時候我們就能建立這幾個 Storyboard:

如此一來我們就能區分這些大功能了,而我們可以在各自的 Storyboard 建立所需的 ViewController。

同時我們也可以在 Modal, View, ViewController 資料夾中用該 Storyboard 名稱來建立子資料夾,並且建立所需文件。

|重構蜘蛛網 Storyboard

如果我的 Storyboard 已經是蜘蛛網了怎麼辦??

放心,我們可以選擇我們 Stroyboard 一些想要切割的 ViewController,點選 Editor 選擇 Refactor to Storyboard...:

而這時我們可以把這些 ViewControlelr 切割到一個新增的 Storyboard 上:

按下確定之後,我們的 Cart 這個 ViewControlle 會被搬移到剛剛所新增的 ShoppingCart.storyboard 上,而我們的原本在 Storyboard 上有 Segue 連線的地方會出現 Storyboard Reference:

而他就是引用我們某個 Storyboard 上的 ViewController(也就是原有的 Cart):

而我們也能夠自己建立一個 Storyboard 的 reference,來連線到其他 Storyboard 的 ViewController:

而這邊如果 Referenced ID 留空的會是該 Storyboard 的 Initial ViewController,而如果想要引用特定的 ViewController 的話就必須設定 Referenced ID,也就是引用的 Storyboard ID。


|額外補充:要 Storyboard 上建立還是新增一個 Xib?

有時候會碰到需要新增某個畫面,但是這個畫面是要新增在某個 Storyboard 還是建立一個 Xib 呢?如果以我的經驗來說,我會思考以下兩點:

  • 是否需要重複使用?
  • 畫面屬於誰(Storyboard)

如果需要重複使用的話,其實就可以直接建立一個 Xib 比較方便處理,如此一來無論是在哪個 storyboard 上面都能夠重複利用,常見的就是 Cell,以及客製化 Alert 和 Loading 畫面。

而如果這個畫面在哪個畫面都有可能出現,像是: 側邊欄或是快捷選單,對我們來說就是一個需要重複使用的畫面,因此我也會選擇 Xib 來處理。而畫面如果只會出現在某個流程中或畫面中,你也能夠直接在該畫面的 storyboard 中新增即可,因為它不會出現在其他畫面中。

而如果畫面是一段流程的話(第一次打開 App 的引導頁)的話,我們也能夠建立一個 Storyboard 來處理這個導覽頁。


Summary

其實不知道發什麼梗圖,只好發這張
最近剛好碰到了「有了需求,但沒有 deadline」
沒想到過幾天聽到 deadline 出現了,但就是兩個禮拜後 ?

這邊文章來提供一些專案結構管理的方式,以及整理跟重構 Storyboard 的方式,透過這些方式不僅能夠在獨立開發時管理好檔案,讓每個區塊專注於該功能開發。同時,再多人合作是也能夠減少衝突,每個人在各自的開發項目上處理。

如果有更好的專案結構管理方式,也歡迎與我分享。


上一篇
D6 - 讓我們在啟動畫面(Launch Screen)做一些怪怪的事吧
下一篇
D8 - 抱歉我不是動畫師,是工程師
系列文
諸神黃昏下的 iOS 工程師31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言