目录
MVP那些事儿(5)……中介者模式与MVP的关系【知识点】
MVP那些事儿(6)……MVC变身为MVP
MVP那些事儿(7)……Kotlin实现MVP【知识点】
MVP那些事儿(8)……当MVP遇到Lifecycle【知识点】
MVP那些事儿(9)……探究MVP的最佳实践
MVP那些事儿(10)……MVVM双向绑定
MVP那些事儿(11)……基于MVVM的Architecture Components
引言
随着这几年移动互联网的快速发展,移动互联网技术也得到了推动,辅助架构设计型的框架和思想层出不穷,从井喷的2015年到现在,开发者们越来越离不开这些高性能、高效率的工具,而制造这些工具的公司或个人,也被推到神坛,受猿们的膜拜。与此同时,Google在今年的io大会上发布了自己的官方框架Architecture Components【译】,可以说是相当的应景了。时不我待,了解架构的知识,并且灵活的应用是我们程序员未来必不可少的技能,这系列文章是介绍MVP架构的,希望能对阅读此文的朋友们带来些收获。
1、如何实现一个MVP框架的基本原则,以及MVP的使用场景,是我想写这篇文章的初衷,同时也是对我自己学习的知识做一个总体的融合。
2、为了避免一上来生硬的开场,我先以一个简单的开发例子作为引子,以初学者的角度去看待问题,同时也能兼顾到初学者,到后面我们会一步步提示。所以你也可以选择直接跳转到。。。。
3、因为讲架构,多是场景描述,所以代码量比较少,习惯于通过代码理解的同学,我尽量多些并反复描述。
场景
假设实现一个商品的列表展示功能,我们首先需要一个用户界面,包含一些控件来供用户操作,比如列表展示。我们大多数情况下使用一个Fragment作为控件的载体,在Fragment中直接调用网络请求的工具并等待回调方法被执行后去刷新UI去展示数据,所以对于这个需求的代码量并不是很多。现在需求增加了,要加入下拉刷新和上拉加载更多,一般是监听这两个事件,在相应的回调中处理数据,没几行代码,依旧写在Fragment中,而需求又一次增加了,要加入排序,紧接着我们处理排序逻辑,代码依旧写在Fragment中,接着又增加需求了,加入详情页的跳转,可能跳转前要处理些业务逻辑,接着又要增加需求了,列表视图可以从宫格式转变为瀑布式,需要改变控件的样式,……接着新需求又来了,可编辑的列表项,可以删除和修改列表项,同时数据要同步到服务器,需求又来了,编辑列表项需要动画功能……直到这个时候我们回头再看看我们的Fragment,这个时候我们可能无法容忍Fragment里混乱复杂的逻辑了。
从功能性需求的角度来说,功能完整、软件正常运行,这是没有问题的,但回过头来我看了一下代码觉的并不是那么“没问题”,在不使用架构的情况下,我们无感知的将逻辑代码业务以及视图代码都堆积到了Activity当中,这样的角色可以说是相当的臃肿的,同时非常不利于未来的扩展,于是非功能性的需求需要满足:Activity优化与扩展性。
我们再梳理一下这个场景的需求列表:
1、列表展示
2、列表支持下拉刷新,上拉加载更多
3、列表要可以排序,可能会有n个条件
4、列表的item点击跳转到详情页面
5、列表展示需要多样化,瀑布流变宫格
6、列表可编辑,也许包括CURD,同时要同步服务器
7、编辑列表时,加上动画效果
下一章节,我们首先使用加入架构的方式来处理上面的需求,其中会介绍Model的定义,Controller的职责,以及它们如何通过控制反转来进行解耦,如果你对MVC有了足够的了解,可以直接跳转到MVP的章节。
网友评论