面向plist的小白配置化iOS编程

很多时候在app团队作业时候会有这样的场景:

  • server 端小伙伴总是很忙,总是不愿意配合我们该接口
  • 我们客户端总需要重复搭建各类表单/表单型展示页,每次都要在代码里改datasource,改model等麻烦的事,哪怕框架共通写的再好也要面对重复的代码发呆
普通工作流

如果server的api返回的就是这样的数据,那说明你遭遇的是正常待遇,那如果你说,唉?不对啊,我们有特地为app服务的专属server团队,那...你可以直接拉到下面看~

每当遇到这样的场景,遭受正常待遇的我们总会想到设计下面这样个model:
<pre>struct Person
{
var id : String!
var name : String!
var salary : Double = 0
var summary : String!
var description : String!

var displayedDiscription : String  {
    return "PersonId : \(id) \n Description : \(description)"
}

var displayedSalary : String  {
    return currencyGenerator(currencyDoubleValue: salary)
}

func currencyGenerator(currencyDoubleValue : Double) -> String
{
    return ""
}

init(json : [String : Any]) {

}
}</pre>

然后为了完成上面右边的View的需求,我们会见个tableview,然后为这个亲爱的tableview做个特殊的datasource,比如这样:
<pre>func setupData() -> [String : Any]
{
let sampleSource = ["id" : "10000", "name" : "Fish", "salary" : 5000 , "summary" : "fff", "description" : "sss"] as [String : Any]
let person = Person(json : sampleSource)
return ["Name" : person.name,
"Salary" : person.displayedSalary ,
"Summary" : person.summary ,
"Desciprtion" : person.displayedDiscription]

}</pre>
后续的就不看了,大家也都猜得出。

我们辛辛苦苦做完了,上线了结果隔壁产品同学说,
呀,我们想加个字段,加一行手机号之类的东西,
呀,我们还想拿掉那个summary,感觉没什么用,
哎呀呀,我们还要调整个顺序,把Salary放到最下面...

呀呀呀,呀你妹啊 T_T 你以为这改动很简单么,要加字段,要加xxx,要发版本上appstore...

那回过头想想每次这样做,我们的心会不会很累?可能server 端的同学会觉得这就是我们要做的事,可是重复写这些code,每次要改那么多分散的地方,我们会不会很累?我们不觉得累,我们的xcode都会累呢。

所以我们静下心来看下上面那个View,其实我们可以在每行都找到共通特征:
比如左边有个title,右边有个value,
那我们是不是可以有个Row的对象,里面有2个属性:key和value,
key就是左边显示的文案,value是动态变化的
所以有了这样的对象:
<pre>struct ConfigRow
{
// left title
var key : String!

// right title
var value : String!

}</pre>

那是不是如果我们有了5个这样的对象,就能满足上面那个View里的结果了呢,当然你可以选择创建5个ConfigRow,然后凑成个数组作为datasource。但是这个做法,依旧很笨,依旧要改代码;

这时候,传说中的plist就要登场了,

我们是不是可以把这5个对象放在plist中,然后做一系列反序列化的方法把plist构建成我们要的数组datasource是不是就好了呢?因为这一系列方法肯定是共通的,所以每次做新类似内容,我们只需要建立个新的plist,然后调用共通方法构建datasource,然后调用应该已经可能被共通抽离出来的tableview构建方法,这样就能完成这样个简单模块的编写了。
最重要的是,每次有文案修改,你只需要修改plist中内容就行了,这样哪怕是别的不是负责你这个模块的开发者来协助,他也能很快完成,毕竟字他总认识~

但是,我们需要对上面的Row进行下扩展,我们还需要加上颜色和排序的属性,来随意控制相应的属性:
<pre>struct ConfigRow
{
// left title
var key : String!

// right title
var value : String!
var sortOrder : Int = 0
var color : String = ""

}</pre>

当然你还可以新增别的,比如左边title的样式属性,右边的value的样式属性等等等。


plist配置

这样,一个白板就构建完了,我们的tableView上已经华丽的自动出现了那些固定文案,比如左侧的所有label,或者顺序/颜色;但是,最重要的右边文案从哪来填充呢?

这里提供个最简单的path方式,我们在plist中每个row的displayValue的默认值写成对应的json中的key值,比如name的displayValue就填value,然后在cell的设置row的方法中:
<pre>leftTitle.text = model.value(forKey : row.displayValue)</pre>

这样的思路就能解决白板填充的问题了,如果需要存下值的化,我们最终的ConfigRow可以变成这样:
<pre>struct ConfigRow
{
// left title
var key : String!

// right title
var value : String!

// json中对应的key值
var valuePath : String!

var sortOrder : Int = 0
var color : String = ""

}</pre>

valuePath就是我们可以写死的key值,而从json中获取来的数据可以塞到value中,这样保存着也方便以后用

再扩展下,比如这是个填写型表单页

填写表单plist

也是一左一右的构造,只是右边是个输入框了,我们针对输入框做了一系列属性来控制,比如

  • 右边框的样式,可能是输入,也可能是日历,也可能是选择,这些通过枚举后在共通框架中实现就行了
  • 输入限制的正则表达式regex
  • 输入框键盘的样式:数字/字母等

同时我们把单个Row的cell相应属性也抽到了plist中修改:

  • cell的identifier重用标示,其实也就等于你可以指定当前Row用什么样的cell来显示
  • cell的segue,因为我们用的是storyBoard跳转,所以可以通过segueIdentifier来直接在tableView的didSelect方法中进行跳转,当然别的跳转方式也可以支持哟,就看需求了
  • cell的高度height,如果不需要自动计算的或者手动计算的话,我们直接把cell的高度也放在了ConfigRow中进行修改,这样controller中写死的东西又少了

当然还有别的功能就不一一列举了。

其实这一整套是很简答的思路设计,重点核心就是我们去掉了业务对象化的思路,而是采用了针对View的单行进行对象化,即原本纵向的考虑变成了横向,真正站在tableView的角度想他需要什么。
这样的设计可以把我们从修改代码的常规逻辑中抽离出来,其实每次我们只需要改相应的plist,也能完成看似很简单其实真的很简单的问题,何不尝试一下呢?

当然,之前提到,如果你有一个很好的专门服务的server服务团队,这套plist就可以放在服务端,这样他们也可以通过配置文件来直接配置表单了;而server端哪怕没有这个条件,我们也可以把这些配置放在我们工程中,这样每次开发时候也方便我们修改了。

当然,这期中最有问题的应该就是上面的valuePath这一段了,如果遇到复杂的需求需要同一个位置显示多个字段拼接的,比如:
Description = ID + Descprition
的显示该怎么办呢?
下期中会介绍专门为这个需求而诞生的工具 CodingForP,
https://github.com/SpiciedCrab/CodingForP
到时候我们就能明白这有多有趣了。

推荐阅读更多精彩内容