最近发现再也无法忍受越来越臃肿的Activity代码,越来越来混乱的Activity层的代码,投入到了MVP的怀抱。目前来看MVP的架构还是很适合Android的,在这里记录一下一点心得,希望都给想用MVP的人一点帮助。
老的MVC架构
刚开始接触Android的时候会觉得Android的整个代码架构就是一个MVC。
- M : 业务层和模型层,相当与javabean和我们的业务请求代码
- V : 视图层,对应Android的layout.xml布局文件
- C : 控制层,对应于Activity中对于UI 的各种操作
看起来MVC架构很清晰,但是实际的开发中,请求的业务代码往往被丢到了Activity里面,大家都知道layout.xml的布局文件只能提供默认的UI设置,所以开发中视图层的变化也被丢到了Activity里面,再加上Activity本身承担着控制层的责任。所以Activity达成了MVC集合的成就,最终我们的Activity就变得越来越难看,从几百行变成了几千行。维护的成本也越来越高
新的MVP架构
- M : 还是业务层和模型层
- V : 视图层的责任由Activity来担当
- P : 新成员Prensenter 用来代理 C(control) 控制层
MVP与MVC最大的不同,其实是Activity职责的变化,由原来的C (控制层) 变成了 V(视图层),不再管控制层的问题,只管如何去显示。控制层的角色就由我们的新人 Presenter来担当,这种架构就解决了Activity过度耦合控制层和视图层的问题。
一个demo
理念终归要用代码来实现,来看一个很典型的例子,打开一个有列表的Activity界面,请求数据然后刷新界面的过程。先来看看工程的架构
我分了MVC 和 MVP2种写法的目录,MVP与MVC不同就在于多了2个结构presenter和view。
这里业务层大家就公用了一个biz,先来看看相同的biz 也就是业务层
RequestBiz
声明了一个接口,带有请求数据业务的方法
public interface RequestBiz {
//请求数据业务
void requestForData(OnRequestListener listener);
}
RequestBiziml
请求的实现类为了模拟网络请求,开启了一个会sleep2秒的线程,然后装填请求的数据,通过OnRequestListener 接口回调出去,与我们平时开发的方式一致。
public class RequestBiziml implements RequestBiz{
@Override
public void requestForData(final OnRequestListener listener) {
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(2000);
ArrayList<String> data = new ArrayList<String>();
for(int i = 1 ; i< 8 ; i++){
data.add("item"+i);
}
if(null != listener){
listener.onSuccess(data);
}
}c