引言
如果用常见于web开发中的MVC模式来开发Android,由于Controller控制器的责任常常会落在Activity身上,导致Activity变得臃肿,对UI层和业务层的单元测试有很大的不便。所以我们来看看MVP模式。
为什么使用MVP
看一下如果不用MVP模式,Android项目会如何:
Android_mvp_view_data.jpg
你会发现View和Model层交互的很乱,这就导致数据层和UI层的单元测试很麻烦。
我们看一下MVP模式:
android_mvp.jpg
你会发现Android项目结构非常的清楚,这在开发中势必会事半功倍。、
MVP职责
- View:负责绘制UI元素,用户交互
- Presenter:用于View和Model交互,处理业务逻辑。
- Model:负责数据的提供
Google 官方MVP示例分析
下载:示例
我们分析的是todo-mvp/ - Basic Model-View-Presenter architecture.
看下项目结构:
google_mvp_basic.jpg
结构说明:
| 目录 | 说明 | 常用工具 |
|---|---|---|
| androidTest | UI测试 | Espresso/automator |
| androidTestMock | UI测试mock数据支持 | Mockito |
| src | 实现代码 | |
| mock | 业务层单元擦拭mock数据支持 | Mockito |
| test | 业务层单元测试 | Junit |
src下的tasks代码
BaseView->抽象出View,提取公共行为
public interface BaseView<T> {
/**
* 使用fragment作为view时，将activity中的presenter传递 给fragment
* @param presenter
*/
void setPresenter(T presenter);
}
BasePresenter->抽象出Presenter
public interface BasePresenter {
/**
* 页面初始化的时候做的事情，根据业务决定是否需要
*/
void start();//加载数据，一般在View的onResume()中执行。
}
契约类:TasksContract->用于View和Presenter交互的管理
public interface TasksContract {
interface View extends BaseView<Presenter> {
void setLoadingIndicator(boolean active);
void showTasks(List<Task> tasks);
...
}
interface Presenter extends BasePresenter {
void result(int requestCode, int resultCode);
void loadTasks(boolean forceUpdate);
...
}
}
Activity在MVP中作用
mvp_activity.jpg
从上面的代码你会看到Fragment 即View和Presenter的创建,从中可以看出Activity的职责:
- 负责建立View和Presenter的交互关系。
Model仅和Presenter建立关系
你会发现只有Presenter调用Model层,而View和Model毫无关系。
总结
- MVP模式将UI代码与业务层进行解耦,将UI又与Model层进行分离,增强了可测试性。
- 多实践,多揣摩。
