Android架构模式二:MVP
原文地址:https://upday.github.io/blog/model-view-presenter/
Android架构模式:MVP
我们的开发人员是时候考虑如何在Android应用中应用良好的架构模式了。为此Google推出了Android Architecture Blueprints项目,在这个项目中,Erik Hellman与我基于MVP与RxJava创建了一些示例。现在来看看我们是如何应用的,以及这种方案的优点与缺点。
MVP模式
以下是各个组件的角色:
- Model-数据层,负责管理业务逻辑并维护网络和数据库接口。
- View-UI层,显示数据并通知Presenter用户行为。
- Presenter-从Model中查询数据,处理UI逻辑,管理View状态,决定显示内容,并响应来自View的用户输入。
由于View与Presenter密切合作,它们需要互相引用。为了让Presenter可以使用JUnit作单元测试,View会被抽象为一个接口。Presenter与其相应View之间的关系定义在Contract接口中,使得代码更易读,两者之间的联系更易于理解。
在Android Architecture Blueprints中的MVP与RxJava
项目中的示例是一个“待办事项”应用。它允许用户创建、阅读、更新和删除“待办事项”储备,以及过虑任务列表。RxJava用于隔离主线程与执行异步操作。
Model
Model与远程和本地数据源协作,以获取和保存数据。这里正是处理业务逻辑的地方。例如,当请求任务列表时,Model会试着先在本地数据源查询。如果没用,它就请求网络,并将响应的数据保存在本地数据源中,最后返回列表。
任务查询是在RxJava的帮助下来完成的:
public Observable<List<Task>> getTasks(){
...
}
Model通过构造方法持有本地和远程数据源,这使得Model完全独立于Android类,从而便于做单元测试。例如,为了测试getTasks
从本地请求数据,我们实现以下测试方法:
@Mock
private TasksDataSource mTasksRemoteDataSource;
@Mock
private TasksDataSource mTasksLocalDataSource;
...
@Test
public void getTasks_requestsAllTasksFromLocalDataSource() {
// Given that the local data source has data available
setTasksAvailable(mTasksLocalDataSource, TASKS);
// And the remote data source does not have any data available
setTasksNotAvailable(mTasksRemoteDataSource);
// When tasks are requested from the tasks repository
TestSubscriber<List<Task>> testSubscriber = new TestSubscriber<>();
mTasksRepository.getTasks().subscribe(testSubscriber);
// Then tasks are loaded from the local data source
verify(mTasksLocalDataSource).getTasks();
testSubscriber.assertValue(TASKS);
}
View
View与Presenter一起工作,显示数据,并通知Presenter关于用户的行为。在MVP中,Activity、Fragment与自定义控件都可作为View。这里我们使用Fragment。
所有View都实现了一个可以关联Presenter的BaseView接口。
public interface BaseView<T> {
void setPresenter(T presenter);
}
View会在onResume
中调用Presenter的subscribe
方法来告知Presenter它已经准备好做更新操作。而在onPause
中调用presenter.unsubscribe()
来告知Presenter它不再接收更新操作。如果View的实现是一个自定义控件,那么subscribe
与unsubscribe
方法会在onAttachedToWindow
与onDetachedFromWindow
中调用。用户行为,如点击按钮,将触发Presenter中相应的方法,这决定了下一步流程。
我们使用Espresso来测试View。例如,要在屏幕上显示活动任务和已完成任务列表。单元测试首先会创建一些任务放在TaskRepository
中,然后启动StatisticsActivity
来检测是否正确显示:
@Before
public void setup() {
// Given some tasks
TasksRepository.destroyInstance();
TasksRepository repository = Injection.provideTasksRepository(
InstrumentationRegistry.getContext());
repository.saveTask(new Task("Title1", "", false));
repository.saveTask(new Task("Title2", "", true));
// Lazily start the Activity from the ActivityTestRule
Intent startIntent = new Intent();
mStatisticsActivityTestRule.launchActivity(startIntent);
}
@Test
public void Tasks_ShowsNonEmptyMessage() throws Exception {
// Check that the active and completed tasks text is displayed
Context context = InstrumentationRegistry.getTargetContext();
String expectedActiveTaskText = context
.getString(R.string.statistics_active_tasks);
onView(withText(containsString(expectedActiveTaskText)))
.check(matches(isDisplayed()));
String expectedCompletedTaskText = context
.getString(R.string.statistics_completed_tasks);
onView(withText(containsString(expectedCompletedTaskText)))
.check(matches(isDisplayed()));
}
Presenter
Presenter与其相应的View由Activity创建;View与TaskRepository
(即Model)的引用由构造方法传入;在构造方法中,Presenter将调用View的setPresenter
方法。以上过程可以由依赖注入框架简化,允许向Presenter注入相应的View,以降低类之间的耦合度。这个方案可以在另一个由Dagger实现的实现中找到。
所有Presenter都实现了BasePresetner接口。
public interface BasePresenter {
void subscribe();
void unsubscribe();
}
当subscribe
方法调用时,Presenter向Model请求数据,然后将UI逻辑应用于接收到的数据,最后传递给View。例如,在StatisticsPresenter
中,所有任务都是向TaskRepository
查询得到的,查询结果会用于计算活动任务和已完成任务的数量。这些数量将用作View方法showStatistics(int numberOfActiveTasks, int numberOfCompletedTasks)
的参数。
一个检测showStatistics
是否调用了正确值的单元测试是很好实现的。我们将模拟TaskRepository
和StatisticsContract.View
,然后将模拟对象作为StatisticsPresenter
构造方法的参数。以下是测试实现:
@Test
public void loadNonEmptyTasksFromRepository_CallViewToDisplay() {
// Given an initialized StatisticsPresenter with
// 1 active and 2 completed tasks
setTasksAvailable(TASKS);
// When loading of Tasks is requested
mStatisticsPresenter.subscribe();
// Then the correct data is passed on to the view
verify(mStatisticsView).showStatistics(1, 2);
}
unsubscribe
的作用是清除Presenter中的观察者,防止内存泄露。
除了subscribe
与unsubscribe
,每个Presenter也会依据View中的用户行为暴露一些其它方法。例如,AddEditTaskPresenter
会添加如createTask
这样的方法,来响应用户点击任务创建按钮的行为。这保证所有用户行为(以及随后的UI逻辑)都通过Presenter,从而可以进行单元测试。
MVP模式的缺点
MVP带来了很好的关注分离方案。虽然这确实是一个优点,但是在开发小应用时,这似乎是个不小的开销。为了减少接口数量,一些开发人员删除了Contract,以及Presenter的接口。
当把UI逻辑移到Presenter中时,一个缺陷出现在了:Presenter变成了一个拥有数千行代码的全知类。为了解决这个问题,应该更多地分割代码并记住仅创建单一职责且可作单元测试的类。
结语
MVC模式有两个主要缺点:第一,View同时持有Controller与Model的引用;第二,没有限制UI逻辑在单一的类中,而是由Controller与Model共享。MVP模式通过对View与Model解耦,并且只创建一个类处理所有与View呈现相关的事情,即Presenter(一个容易进行单元测试的类),从而解决了以上问题。
如果我们想要一个事件驱动的架构呢?View在哪里响应变化?请继续关注Android Architecture Blueprints示例中的下一个模式,以了解如何实现这一点。届时请阅读upday应用中关于MVVM模式的实现。
Written with StackEdit.
上一篇: 详解Android 传感器开发 完全解析
下一篇: gulp搭建es6报错的问题