前言

通過Protocol去封裝入?yún)ⅲㄆ搅巳雲(yún)⒅g的差異。

今天這篇依然圍繞一個我遇到的業(yè)務(wù)場景，給大家提供一種思路——使用enum抹平數(shù)組元素差異。

業(yè)務(wù)場景

我先說明一下業(yè)務(wù)場景：

頁面是一個有限可以滑動的的頁面(后面我們會分析到其實無限或者有限都無所謂)

頁面的每一個子View都是和后臺返回的數(shù)據(jù)綁定，其JSON大致可以理解為下面這種形式：

{
    "aPart":{
        "some":""
    },
    "bPart":[
        {
            "label":"",
            "value":""
        },
        {
            "label":"",
            "value":""
        }
    ],
    "cPart":[
        {
            "iconUrl":"",
            "text":"",
            "functionType":""
        },
        {
            "iconUrl":"",
            "text":"",
            "functionType":""
        }
    ],
    "dPart":{
        "name":"",
        "age":""
    },
    "deviceType":"",
    "serviceAble":""
}

業(yè)務(wù)需求如下：

• aPart對應(yīng)aView，bPart對應(yīng)bView，cPart對應(yīng)cView，dPart對應(yīng)dView，可以如此窮舉下去
• 每個part的JSON結(jié)構(gòu)可能都不相同
• 后臺下發(fā)JSON的時候，會根據(jù)用戶賬號的情況，返回不同數(shù)據(jù)，比如aPart的業(yè)務(wù)沒有，后臺會返回"aPart":null，App的aView需要隱藏，存在可能多個part都返回為null的情況，比如"bPart"和"cPart"都為null的情況，那么App的bView和cView需要隱藏。

那么問題來了，iOS端如何構(gòu)建一個可以靈活配置的界面？

用什么控件

使用UIScrollView的分析

作為開發(fā)App頁面的第一點，選取合適的控件是非常重要，因為控件決定了最終數(shù)據(jù)源的形式。

因為后臺數(shù)據(jù)返回的并不是一個JSON數(shù)組，同時又是有限的數(shù)據(jù)，很多人優(yōu)先會考慮通過UIScrollView去進行頁面的構(gòu)建，我一開始也是這么想的，但是麻煩的是這一點：

后臺下發(fā)JSON的時候，會根據(jù)用戶賬號的情況，返回不同數(shù)據(jù)，比如aPart的業(yè)務(wù)沒有，后臺會返回"aPart":null，App的aView需要隱藏。

也就是說你把aView、bView、cView、dView貼在了scrollView上面之后，需要根據(jù)后臺的數(shù)據(jù)隱藏頁面，甚至更新布局邏輯，每一個view都有2種情況，假設(shè)后臺有4個業(yè)務(wù)數(shù)據(jù)，那么那就是2的4次方——32種可能。

其實僅隱藏還是顯示非常簡單，但是如果是使用SnapKit布局，那么更新view的布局，可能就并不是特別好了，同時如果這個頁面后續(xù)還有新的業(yè)務(wù)數(shù)據(jù)，那么就子view會繼續(xù)增加，維護成本也會越來越高。

所以，到此使用UIScrollView的方案，別否決了，并不是說它不能構(gòu)建，而是成本有些高，而且不夠靈活。

所以剩下的只剩下一種選擇了——使用通過數(shù)據(jù)源綁定UI的UITableView。（備注：其實使用UICollectionView和UITableView都一樣，只是多一個瀑布流布局而已）。

使用UITableView的分析

使用UITableView的優(yōu)勢：

完完全全通過數(shù)據(jù)去驅(qū)動頁面，頁面是否顯示完全通過有無數(shù)據(jù)決定。

但是數(shù)據(jù)源相較普通模型有著更加嚴格的數(shù)據(jù)格式——數(shù)組！

而且數(shù)組的每個元素最好都是相同的數(shù)據(jù)類型，因為如果使用[Any]這樣去表達一個數(shù)據(jù)源，成本太高。

好了，既然我們定下了使用UITableView來進行頁面構(gòu)建，那么剩下的難點也就來了——如何將后臺的數(shù)據(jù)加工成為一個好用的數(shù)據(jù)源？

加工數(shù)據(jù)

將后臺數(shù)據(jù)加工成為一個數(shù)組并不難，關(guān)鍵是統(tǒng)和數(shù)據(jù)類型才是難點。

在上一篇文章里面，我通過Protocol去統(tǒng)和了Model與[String: String]，在這次情況下面可不可行呢？

protocol EraserConvertible {}
struct Response: Codabel {
    let aPart: APart?
    let bPart: BPart?
    let cPart: CPart?
    let dPart: DPart?
}
struct APart: Codabel, EraserConvertible {}
struct BPart: Codabel, EraserConvertible {}
struct CPart: Codabel, EraserConvertible {}
struct DPart: Codabel, EraserConvertible {}

我們回頭看看這個JSON，你不得不認清這樣個現(xiàn)實，每個Part都是獨立的，完全看不到任何關(guān)聯(lián)，如果想要做類型一致，EraserConvertible這個協(xié)議很難滿足。

不如做向上類型統(tǒng)和，也就是說數(shù)據(jù)源變成let dataSource = [Response]()這種形式，在tableView的數(shù)據(jù)源方法中獲取單個數(shù)據(jù)，然后在進行分析：

let dataSource = [Response]()
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let item = dataSource[indexPath.row]
    if let aPart = item.aPart {
        /// 構(gòu)建aCell
        let cell = tableView.dequeueReusableCell(withIdentifier: aCell.className)!
        /// 將aPart賦值給aCell
        cell.aPart = aPart
        return cell
    }
    if let bPart = item.bPart {
        /// 構(gòu)建bCell，
        let cell = tableView.dequeueReusableCell(withIdentifier: bCell.className)!
        /// 將bPart賦值給bCell
        cell.bPart = bPart
        return cell
    }
    .
    .
    .
}

嗯，這樣看起來非常不錯，只是每個item都包含了aPart到dPart，方案的是可行。讓我們想想有沒有更加優(yōu)雅的思路呢？

數(shù)據(jù)源的類型不同決定了不同的Cell。我們可不可以用狀態(tài)來表示？

于是乎我寫下了這樣的代碼：

enum BusinessPart {
    case a
    case b
    case c
    case d
}

數(shù)據(jù)源變成let dataSource = [BusinessPart]()這種形式，那么如何區(qū)分每個case不同的數(shù)據(jù)呢？

Swift的enum是可以帶參數(shù)的，而且單個case帶不帶參數(shù)，帶什么類型的參數(shù)都很自由。

于是乎，我們接著改造BusinessPart：

enum BusinessPart {
    case a(APart)
    case b(BPart)
    case c(CPart)
    case d(DPart)
}

這樣我現(xiàn)在就通過enum抹平的數(shù)組元素的差異，接下來只要把后臺數(shù)據(jù)架構(gòu)成為我想要的[BusinessPart]格式就好了，這里放處理邏輯：

private func process(model: Response) -> [BusinessPart] {
    var array: [BusinessPart] = []
    /// 非空才加入數(shù)組，后臺返回null，此時aPart為nil，那么aCell也不會出現(xiàn)
    if let aPart = model.aPart {
        array.append(.a(aPart))
    }
    if let bPart = model.bPart {
        array.append(.b(bPart))
    }
    if let cPart = model.cPart {
        array.append(.c(cPart))
    }
    if let dPart = model.dPart {
        array.append(.d(dPart))
    }
    return array
}

在TableView的數(shù)據(jù)源方法中這么使用：

let dataSource = [BusinessPart]()
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let item: BusinessPart = dataSource[indexPath.row]
    switch item {
        case .a(let aPart):
        /// 構(gòu)建aCell
        let cell = tableView.dequeueReusableCell(withIdentifier: aCell.className)!
        /// 將aPart賦值給aCell
        cell.aPart = aPart
        return cell
        case .b(let bPart):
        /// 構(gòu)建bCell
        let cell = tableView.dequeueReusableCell(withIdentifier: bCell.className)!
        /// 將bPart賦值給bCell
        cell.bPart = bPart
        return cell
        case .c(let cPart):
        /// 構(gòu)建cCell
        let cell = tableView.dequeueReusableCell(withIdentifier: cCell.className)!
        /// 將cPart賦值給cCell
        cell.cPart = cPart
        return cell
        .
        .
        .
    }    
}

至于這個[BusinessPart]的dataSource怎么在UITableViewDataSource中如何處理，亦或者在BusinessPart的分類中怎么處理，這個就是一個仁者見仁智者見智的問題了。

總結(jié)

到最后，這個頁面的數(shù)據(jù)加工，最后還是變成了向上還是向下統(tǒng)和的思考。

其實就是對于一個差異性特別大的數(shù)據(jù)，如何比較好的整合為一個在iOS中合適的數(shù)組問題，通過字段的全覆蓋達到模型的統(tǒng)合，抑或通過Swift中枚舉帶參的特點，抹平差異。

從代碼層面上看，兩者的代碼量差不多，但是使用enum抹平數(shù)組元素差異為我們提供一個新的解題思路，至少這是我自己思考的成果。

另外一個角度就是通過布局控件來展開，因為我看Android就是直接用一個ScrollView擼起的：

Android開發(fā)中，大部分控件都有visibility這個屬性，其屬性有3個分別為“visible ”、“invisible”、“gone”。主要用來設(shè)置控制控件的顯示和隱藏。

invisible當控件visibility屬性為invisible時，界面保留了view控件所占有的空間；而控件屬性為gone時，界面則不保留view控件所占有的空間。

因為Android這個三個屬性可以非常便利的完成隱藏還是不隱藏，以及是否保留控件所占有的空間。

而iOS可能需要不僅改變isHidden屬性，甚至連view的frame也要進行改變，成本太大了。在使用UITableView的分析已經(jīng)提到。

但是也不是不可能，比如使用FlexLib應(yīng)該可以實現(xiàn)。（備注：我自己沒用過FlexLib庫，這個有待考證哈?），但是也增加了一定的學習成本與引入了更多的庫。

參考文檔

Swift：enum你會用嗎？