->其实
这篇文章可以看成是<<App研发录>>的读书笔记
->此外
这里还涉及到xml解析,有不熟悉的,可以参考 https://blog.csdn.net/xia09222826/article/details/28441529,蛮不错的
背景
眼见项目进程紧凑的一逼,但是,后台却接口都还没弄出来,咋整?这时候就想到了曾经看到的<<App研发录>>里面有这么一段.然后鼓捣鼓捣,开发可以继续走了....
1.后台约定Response框
虽然具体的接口以及返回数据没有敲定,但这并不影响我们将后台的哥们忽悠进这样一个圈内:
2.自己YY一个专用的"服务器孵化器"
毕竟那么多接口啊,所以为了以后长久的发(tou)展(lan),还是得封一个基类.
3.开启业务服务器
一个基于基类的服务器就这样诞生了,快速,简单,还可以自己做主,到时候和后台定接口的时候,可以做到一步到位,当然,如果后台是个妹子,你要故意多对几次,也是可以的.
以上基本就搭建好了一个本地可测"接口",心里瞬间开心了,基本功能能满足了......
但是,作为一个开发者,特别是一个优(lan)秀(duo)的开发者,我们还可以再进一步,把这个逼格提高一点
4."租"个"中介"
写个xml文件: url.xml,放在res/xml目录下,定义如下:
最重要的是Key,通过这个东西找到对应的节点,然后就可以操作了
,当然,最好是把这个定义成一个对象,就更便于操作了
有了xml,有了xml对应的Bean类,自然就有xml解析类的
在这个基础上,我们建立一个中间类进行操作,通过判断mockClass是否存在,就可以进行本地接口或者后台接口的配置,当然,如果弄一个boolean参数,表明选择net 还是本地,那也是可以的,这里就不做演示了
5.开心的玩耍
以上解决之后,就可以开心的进行接口测试了
关于别的接口,可以同理参照...
这里,还有点说明下:
由于自己写的接口,与<<app开发录>>中的返回数据不一样,导致解析会出问题,所以,最好将返回的数据也通过onSuccess暴露出来,如果解析没问题,那么就直接用Bean,如果有问题,也方便直接手动解析,这样避免出现调用三方别的接口出现返回与所定参数不一致导致的解析问题,颇有种"定制"的感觉.
以上就是本次分享的内容,仅代表个人意见,有不同的意见,欢迎交流