iOS项目之模拟请求数据
当工期比较紧的时候,项目开发中会经常出现移动端等待后端接口数据的情形,不但耽误项目进度,更让人有种无奈的绝望。所以在开发中,我们常常自己做些假数据,以方便开发和UI调试。然而做假数据方法不同,效率和安全性都各不同,有时稍有不慎,还会产生很大的bug。因此本文拟结合我在贝聊的开发经验,讲一讲我们组在iOS开发中曾经用过的做假数据的方法及其优劣。
为方便下文的说明,本文主要以贝聊家长版app发现首页的热门帖子列表的实现为例。热门帖子列表的样式如下图:
这是比较常见的列表,用常用的UITableView
实现即可,但需要自定义一个的UITableViewCell
的子类ExploreTableViewCell
。项目中,ExploreTableViewCell
并没有用xib实现(因为xib日后不好修改,且代码复用性差),而是通过SnapKit
用纯代码布的局,具体的布局代码大致如下:
1
|
import UIKit
|
源码中写死数据是最便捷的假数据做法,项目很赶时,为最快速的看到UI效果,一般都会采取这种假数据方式。比如在上述热门帖子列表示例项目中,为查看整个ExploreTableViewCell
的布局效果,在titleLabel
等subview
的设置位置,直接写死假数据。
1
|
//...其他代码
|
源码中写死假数据虽然方便,但稍有不慎就容易直接上线上环境(因为测试在测试时一般都会有数据,假数据被遮盖了),演变成一个有可能非常严重也有可能很轻的bug(贝聊就切实出现过这样的bug,而且还是个影响广泛的大bug),为安全起见,所有写死的假数据都应该包在条件编译宏内。
1
|
//...其他代码
|
包在条件编译宏内,就可以保证不污染正式环境的代码,从而保证安全性。
在源码中写死假数据,有以下三个缺点,
DEBUG
环境的调试。model
,最后通过model
给各个UI组件填充数据。而在源代码中写死假数据,直接打乱了数据的正确流通,这会使得整个开发的逻辑是颠倒的,不但使开发更容易出bug,而且逻辑流的切换带来的开发效率和开发感受都很差。较好的假数据方式,应该尽可能的不污染源代码,不扰乱正常的数据流通,而且能集中管理。在研究单元测试时,我无意中发现stub某个页面请求数据的网络请求即可达到这种完美的假数据效果。
首先按正常的流程开发整个功能,(在开发中,我总是倾下于先创建Model,而不是先写UI)
整个功能开发按照有真实网络请求进行,但事实上并没有网络请求,因为后台并未搭好,没关系,先按照后台给出的接口和数据格式定义,创建一个本地JSON文件。对于本文的示例(假定只有列表数据)来说,文件名暂为hotTopics.json
,内容大致如下(贝聊发现首页实际上有很多其他元素,网络请求返回的JSON也比这个复杂的多):
1
|
{
|
然后在ViewController
中stub
本ViewController
中所有的网络请求,我在开发中用的是OHHTTPStubs,大致的代码如下:
1
|
class ExploreViewController: UITableViewController {
|
注意所创建的JSON文件一定要加到项目目录中。添加完上述代码后,path为/explore/hotTopics
的网络请求将被stub,返回的数据将是所指定JSON文件中的数据,这样就跟真实的网络请求没有任何的区别了。而且利用OHHTTPStubs还可以模拟网络请求失败、网络请求超时以及throttle
等各种网络请求状态,从而更全面的调试UI和整个功能。
利用stub做假数据可以真实的做到基本不污染代码、集中管理和完全真实的数据流通流程,与在源码中写死这种方式相比,近乎完美。然而当你真正用过一段时间后,你会发现,这种方式还是有一个致命的缺点和一个不那么重要的缺点。
如果能做到每改动一下数据,然后刷新一下就可以看到了,像网页一样,而且真的一点都不污染代码,那就是完美的解决方案。
如果只是想做到,每改动一下数据,然后刷新以下就可以看到了,像网页一样,Xcode的动态注入是可以的,现在比较流行的是injectionforxcode和dyci-main两个库。利用单元测试的网络请求stub做假数据,然后结合动态注入,理论上应该可以做到实时刷新,但事实上injectionforxcode和dyci-main的体验都是很糟糕的,时灵时不灵,我用过两次后,基本就不想碰了,我宁愿编译慢一点,当然我从来没有用动态注入去做假数据的实时刷新,但我觉得应该是个方案。
但这个方案即使可行,也还是会污染代码,并不算特别彻底的方案。真正彻底的方案,与用stub拦截网络请求的思路相同,只是要将网络请求的拦截放到整个APP外,有两个方案可行。
第一种就是本地自己搭个服务器,然后把开发时需要拦截的网络请求地址改为自己搭建的服务器地址,然后返回自己自定义的JSON数据。但这种方式也有三个缺点:
第二种就是利用现有的网络代理软件,直接拦截对应的网络请求,然后返回本地写好的JSON数据。我最终采用的这种方案(因为我嫌配置服务器麻烦)。将APP中所有的网络请求都代理给网络代理,然后指定特定的网络请求返回本地JSON数据。这种方案的好处不言而喻,
我常用的网络代理就是Charles,相信大家都有耳闻。Charles有个maplocal
的功能(在工具菜单下),如图:
mapLocal的设置也很简单,在Location一栏填上所要拦截的网络请求的host、path或者完整的URL,然后在LocalPath一栏选择对应的本地JSON文件即可,记得勾选启动。
这样简单的设置后,所指定的网络请求都会返回本地对应的JSON文件数据。然后你将发现这种假数据之完美,简直让人窒息。
编译后,如果想改变一个数据,看看对应的UI,直接去改变本地JSON文件,然后下来刷新一下,你会发现显示的数据就是刚刚改动的数据,简直要感动哭了。
但事实上这种方式还是有一个小小的缺点,即Charles与Shadowsocks不能同时开着,因为Charles不支持父代理。搞编程开发,为方便查阅资料,FQ软件会一只开着,但这样Charles就不能开着,想用的话,又要先退出Shadowsocks,再打开Charles,这让我很头疼。最后只能在真正写完所有的逻辑和UI后,关闭Shadowsocks,打开Charles,集中调试。
=============2017-03-04更新开始===============
文章发出后,不少读者反馈,
=============2017-03-04更新结束===============
一路试下来,其实只有第一种源码中写死和最后一种网络代理两种假数据方式最常用,虽然第一种缺点最多,但方便快捷,最后一种虽无任何缺点,但启动还是有点麻烦。
写了这么多,还是希望对大家有所启发。
(本文转载自轻墨,看了这篇文章受益匪浅,于是分享给大家。注重作者原创,已注明原文链接,点击上面标题可跳转!)
添加一个Demo:模拟请求数据
优质内容筛选与推荐>>