Google官方MVP Sample代碼解讀

關(guān)于Android程序的構(gòu)架, 當前(2016.10)最流行的模式即為MVP模式, Google官方提供了Sample代碼來展示這種模式的用法.
Repo地址: android-architecture.
本文為閱讀官方sample代碼的閱讀筆記和分析.

官方Android Architecture Blueprints [beta]:
Android在如何組織和構(gòu)架一個app方面提供了很大的靈活性, 但是同時這種自由也可能會導(dǎo)致app在測試, 維護, 擴展方面變得困難.

Android Architecture Blueprints展示了可能的解決方案. 在這個項目里, 我們用各種不同的構(gòu)架概念和工具實現(xiàn)了同一個應(yīng)用(To Do App). 主要的關(guān)注點在于代碼結(jié)構(gòu), 構(gòu)架, 測試和維護性.
但是請記住, 用這些模式構(gòu)架app的方式有很多種, 要根據(jù)你的需要, 不要把這些當做絕對的典范.

MVP模式 概念

之前有一個MVC模式: Model-View-Controller.
MVC模式 有兩個主要的缺點: 首先, View持有Controller和Model的引用; 第二, 它沒有把對UI邏輯的操作限制在單一的類里, 這個職能被Controller和View或者Model共享.
所以后來提出了MVP模式來克服這些缺點.

MVP(Model-View-Presenter)模式:

• Model: 數(shù)據(jù)層. 負責與網(wǎng)絡(luò)層和數(shù)據(jù)庫層的邏輯交互.
• View: UI層. 顯示數(shù)據(jù), 并向Presenter報告用戶行為.
• Presenter: 從Model拿數(shù)據(jù), 應(yīng)用到UI層, 管理UI的狀態(tài), 決定要顯示什么, 響應(yīng)用戶的行為.
  MVP模式的最主要優(yōu)勢就是耦合降低, Presenter變?yōu)榧僇ava的代碼邏輯, 不再與Android Framework中的類如Activity, Fragment等關(guān)聯(lián), 便于寫單元測試.

todo-mvp 基本的Model-View-Presenter架構(gòu)

app中有四個功能:

• Tasks
• TaskDetail
• AddEditTask
• Statistics

每個功能都有:

• 一個定義View和Presenter接口的Contract接口;
• 一個Activity用來管理fragment和presenter的創(chuàng)建;
• 一個實現(xiàn)了View接口的Fragment;
• 一個實現(xiàn)了Presenter接口的presenter.

mvp

基類

Presenter基類:

public interface BasePresenter {
    void start();
}

例子中這個start()方法都在Fragment的onResume()中調(diào)用.

View基類:

public interface BaseView<T> {
    void setPresenter(T presenter);
}

View實現(xiàn)

• Fragment作為每一個View接口的實現(xiàn), 主要負責數(shù)據(jù)顯示和在用戶交互時調(diào)用Presenter, 但是例子代碼中也是有一些直接操作的部分, 比如點擊開啟另一個Activity, 點擊彈出菜單(菜單項的點擊仍然是調(diào)用presenter的方法).

• View接口中定義的方法多為showXXX()方法.

• Fragment作為View實現(xiàn), 接口中定義了方法:

@Override
public boolean isActive() {
    return isAdded();
}

在Presenter中數(shù)據(jù)回調(diào)的方法中, 先檢查View.isActive()是否為true, 來保證對Fragment的操作安全.

Presenter實現(xiàn)

• Presenter的start()方法在onResume()的時候調(diào)用, 這時候取初始數(shù)據(jù); 其他方法均對應(yīng)于用戶在UI上的交互操作.
• New Presenter的操作是在每一個Activity的onCreate()里做的: 先添加了Fragment(View), 然后把它作為參數(shù)傳給了Presenter. 這里并沒有存Presenter的引用.
• Presenter的構(gòu)造函數(shù)有兩個參數(shù), 一個是Model(Model類一般叫XXXRepository), 一個是View. 構(gòu)造中先用guava的checkNotNull()
  檢查兩個參數(shù)是否為null, 然后賦值到字段; 之后再調(diào)用View的setPresenter()方法把Presenter傳回View中引用.

Model實現(xiàn)細節(jié)

• Model只有一個類, 即TasksRepository. 它還是一個單例. 因為在這個應(yīng)用的例子中, 我們操作的數(shù)據(jù)就這一份.

它由手動實現(xiàn)的注入類Injection類提供:

public class Injection {

    public static TasksRepository provideTasksRepository(@NonNull Context context) {
        checkNotNull(context);
        return TasksRepository.getInstance(FakeTasksRemoteDataSource.getInstance(),
                TasksLocalDataSource.getInstance(context));
    }
}

構(gòu)造如下:

private TasksRepository(@NonNull TasksDataSource tasksRemoteDataSource,
                        @NonNull TasksDataSource tasksLocalDataSource) {
    mTasksRemoteDataSource = checkNotNull(tasksRemoteDataSource);
    mTasksLocalDataSource = checkNotNull(tasksLocalDataSource);
}

• 數(shù)據(jù)分為local和remote兩大部分. local部分負責數(shù)據(jù)庫的操作, remote部分負責網(wǎng)絡(luò). Model類中還有一個內(nèi)存緩存.
• TasksDataSource是一個接口. 接口中定義了Presenter查詢數(shù)據(jù)的回調(diào)接口, 還有一些增刪改查的方法.

單元測試

MVP模式的主要優(yōu)勢就是便于為業(yè)務(wù)邏輯加上單元測試.
本例子中的單元測試是給TasksRepository和四個feature的Presenter加的.
Presenter的單元測試, Mock了View和Model, 測試調(diào)用邏輯, 如:

public class AddEditTaskPresenterTest {

    @Mock
    private TasksRepository mTasksRepository;
    @Mock
    private AddEditTaskContract.View mAddEditTaskView;
    private AddEditTaskPresenter mAddEditTaskPresenter;

    @Before
    public void setupMocksAndView() {
        MockitoAnnotations.initMocks(this);
        when(mAddEditTaskView.isActive()).thenReturn(true);
    }

    @Test
    public void saveNewTaskToRepository_showsSuccessMessageUi() {
        mAddEditTaskPresenter = new AddEditTaskPresenter("1", mTasksRepository, mAddEditTaskView);

        mAddEditTaskPresenter.saveTask("New Task Title", "Some Task Description");

        verify(mTasksRepository).saveTask(any(Task.class)); // saved to the model
        verify(mAddEditTaskView).showTasksList(); // shown in the UI
    }
    ...
}

todo-mvp-loaders 用Loader取數(shù)據(jù)的MVP

基于上一個例子todo-mvp, 只不過這里改為用Loader來從Repository得到數(shù)據(jù).

todo-mvp-loaders

使用Loader的優(yōu)勢:

• 去掉了回調(diào), 自動實現(xiàn)數(shù)據(jù)的異步加載;
• 當內(nèi)容改變時回調(diào)出新數(shù)據(jù);
• 當應(yīng)用因為configuration變化而重建loader時, 自動重連到上一個loader.

Diff with todo-mvp

既然是基于todo-mvp, 那么之前說過的那些就不再重復(fù), 我們來看一下都有什么改動:
git difftool -d todo-mvp

添加了兩個類:
TaskLoader和TasksLoader.

在Activity中new Loader類, 然后傳入Presenter的構(gòu)造方法.

Contract中View接口刪掉了isActive()方法, Presenter刪掉了populateTask()方法.

數(shù)據(jù)獲取

添加的兩個新類是TaskLoader和TasksLoader, 都繼承于AsyncTaskLoader, 只不過數(shù)據(jù)的類型一個是單數(shù), 一個是復(fù)數(shù).

AsyncTaskLoader是基于ModernAsyncTask, 類似于AsyncTask,
把load數(shù)據(jù)的操作放在loadInBackground()里即可, deliverResult()方法會將結(jié)果返回到主線程, 我們在listener的onLoadFinished()里面就可以接到返回的數(shù)據(jù)了, (在這個例子中是幾個Presenter實現(xiàn)了這個接口).

TasksDataSource接口的這兩個方法:

List<Task> getTasks();
Task getTask(@NonNull String taskId);

都變成了同步方法, 因為它們是在loadInBackground()方法里被調(diào)用.

Presenter中保存了Loader和LoaderManager, 在start()方法里initLoader, 然后onCreateLoader返回構(gòu)造傳入的那個loader.
onLoadFinished()里面調(diào)用View的方法. 此時Presenter實現(xiàn)LoaderManager.LoaderCallbacks.

數(shù)據(jù)改變監(jiān)聽

TasksRepository類中定義了observer的接口, 保存了一個listener的list:

private List<TasksRepositoryObserver> mObservers = new ArrayList<TasksRepositoryObserver>();

public interface TasksRepositoryObserver {
    void onTasksChanged();
}

每次有數(shù)據(jù)改動需要刷新UI時就調(diào)用:

private void notifyContentObserver() {
    for (TasksRepositoryObserver observer : mObservers) {
        observer.onTasksChanged();
    }
}

在兩個Loader里注冊和注銷自己為TasksRepository的listener: 在onStartLoading()里add, onReset()里面remove方法.
這樣每次TasksRepository有數(shù)據(jù)變化, 作為listener的兩個Loader都會收到通知, 然后force load:

@Override
public void onTasksChanged() {
    if (isStarted()) {
        forceLoad();
    }
}

這樣onLoadFinished()方法就會被調(diào)用.

todo-databinding

基于todo-mvp, 使用Data Binding library來顯示數(shù)據(jù), 把UI和動作綁定起來.

說到ViewModel, 還有一種模式叫MVVM(Model-View-ViewModel)模式.
這個例子并沒有嚴格地遵循Model-View-ViewModel模式或者Model-View-Presenter模式, 因為它既用了ViewModel又用了Presenter.

mvp-databinding

Data Binding Library讓UI元素和數(shù)據(jù)模型綁定:

• layout文件用來綁定數(shù)據(jù)和UI元素;
• 事件和action handler綁定;
• 數(shù)據(jù)變?yōu)榭捎^察的, 需要的時候可以自動更新.

Diff with todo-mvp

添加了幾個類:

• StatisticsViewModel;
• SwipeRefreshLayoutDataBinding;
• TasksItemActionHandler;
• TasksViewModel;

從幾個View的接口可以看出方法數(shù)減少了, 原來需要多個showXXX()方法, 現(xiàn)在只需要一兩個方法就可以了.

數(shù)據(jù)綁定

以TasksDetailFragment為例:
以前在todo-mvp里需要這樣:

public void onCreateView(...) {
    ...
    mDetailDescription = (TextView)
root.findViewById(R.id.task_detail_description);
}

@Override
public void showDescription(String description) {
    mDetailDescription.setVisibility(View.VISIBLE);
    mDetailDescription.setText(description);
}

現(xiàn)在只需要這樣:

public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    View view = inflater.inflate(R.layout.taskdetail_frag, container, false);
    mViewDataBinding = TaskdetailFragBinding.bind(view);
    ...
}

@Override
public void showTask(Task task) {
    mViewDataBinding.setTask(task);
}

因為所有數(shù)據(jù)綁定的操作都寫在了xml里:

<TextView
    android:id="@+id/task_detail_description"
    ...
    android:text="@{task.description}" />

事件綁定

數(shù)據(jù)綁定省去了findViewById()和setText(), 事件綁定則是省去了setOnClickListener().

比如taskdetail_frag.xml中的

<CheckBox
    android:id="@+id/task_detail_complete"
    ...
    android:checked="@{task.completed}"
    android:onCheckedChanged="@{(cb, isChecked) ->
    presenter.completeChanged(task, isChecked)}" />

其中Presenter是這時候傳入的:

@Override
public void onActivityCreated(Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);
    mViewDataBinding.setPresenter(mPresenter);
}

數(shù)據(jù)監(jiān)聽

在顯示List數(shù)據(jù)的界面TasksFragment, 僅需要知道數(shù)據(jù)是否為空, 所以它使用了TasksViewModel來給layout提供信息, 當尺寸設(shè)定的時候, 只有一些相關(guān)的屬性被通知, 和這些屬性綁定的UI元素被更新.

public void setTaskListSize(int taskListSize) {
    mTaskListSize = taskListSize;
    notifyPropertyChanged(BR.noTaskIconRes);
    notifyPropertyChanged(BR.noTasksLabel);
    notifyPropertyChanged(BR.currentFilteringLabel);
    notifyPropertyChanged(BR.notEmpty);
    notifyPropertyChanged(BR.tasksAddViewVisible);
}

其他實現(xiàn)細節(jié)

• Adapter中的Data Binding, 見TasksFragment中的TasksAdapter.

@Override
public View getView(int i, View view, ViewGroup viewGroup) {
    Task task = getItem(i);
    TaskItemBinding binding;
    if (view == null) {
        // Inflate
        LayoutInflater inflater = LayoutInflater.from(viewGroup.getContext());

        // Create the binding
        binding = TaskItemBinding.inflate(inflater, viewGroup, false);
    } else {
        binding = DataBindingUtil.getBinding(view);
    }

    // We might be recycling the binding for another task, so update it.
    // Create the action handler for the view
    TasksItemActionHandler itemActionHandler =
            new TasksItemActionHandler(mUserActionsListener);
    binding.setActionHandler(itemActionHandler);
    binding.setTask(task);
    binding.executePendingBindings();
    return binding.getRoot();
}

• Presenter可能會被包在ActionHandler中, 比如TasksItemActionHandler.
• ViewModel也可以作為View接口的實現(xiàn), 比如StatisticsViewModel.
• SwipeRefreshLayoutDataBinding類定義的onRefresh()動作綁定.

todo-mvp-clean

這個例子是基于Clean Architecture的原則:
The Clean Architecture.
關(guān)于Clean Architecture, 還可以看這個Sample App: Android-CleanArchitecture.

這個例子在todo-mvp的基礎(chǔ)上, 加了一層domain層, 把應(yīng)用分為了三層:

mvp-clean.png

Domain: 盛放了業(yè)務(wù)邏輯, domain層包含use cases或者interactors, 被應(yīng)用的presenters使用. 這些use cases代表了所有從presentation層可能進行的行為.

關(guān)鍵概念
和基本的mvp sample最大的不同就是domain層和use cases. 從presenters中抽離出來的domain層有助于避免presenter中的代碼重復(fù).

Use cases定義了app需要的操作, 這樣增加了代碼的可讀性, 因為類名反映了目的.

Use cases對于操作的復(fù)用來說也很好. 比如CompleteTask在兩個Presenter中都用到了.

Use cases的執(zhí)行是在后臺線程, 使用command pattern. 這樣domain層對于Android SDK和其他第三方庫來說都是完全解耦的.

Diff with todo-mvp

每一個feature的包下都新增了domain層, 里面包含了子目錄model和usecase等.

UseCase是一個抽象類, 定義了domain層的基礎(chǔ)接口點.
UseCaseHandler用于執(zhí)行use cases, 是一個單例, 實現(xiàn)了command pattern.
UseCaseThreadPoolScheduler實現(xiàn)了UseCaseScheduler接口, 定義了use cases執(zhí)行的線程池, 在后臺線程異步執(zhí)行, 最后把結(jié)果返回給主線程.
UseCaseScheduler通過構(gòu)造傳給UseCaseHandler.
測試中用了UseCaseScheduler的另一個實現(xiàn)TestUseCaseScheduler, 所有的執(zhí)行變?yōu)橥降?

Injection類中提供了多個Use cases的依賴注入, 還有UseCaseHandler用來執(zhí)行use cases.

Presenter的實現(xiàn)中, 多個use cases和UsseCaseHandler都由構(gòu)造傳入, 執(zhí)行動作, 比如更新一個task:

private void updateTask(String title, String description) {
    if (mTaskId == null) {
        throw new RuntimeException("updateTask() was called but task is new.");
    }
    Task newTask = new Task(title, description, mTaskId);
    mUseCaseHandler.execute(mSaveTask, new SaveTask.RequestValues(newTask),
            new UseCase.UseCaseCallback<SaveTask.ResponseValue>() {
                @Override
                public void onSuccess(SaveTask.ResponseValue response) {
                    // After an edit, go back to the list.
                    mAddTaskView.showTasksList();
                }

                @Override
                public void onError() {
                    showSaveError();
                }
            });
}

todo-mvp-dagger

關(guān)鍵概念:
dagger2 是一個靜態(tài)的編譯期依賴注入框架.
這個例子中改用dagger2實現(xiàn)依賴注入. 這樣做的主要好處就是在測試的時候我們可以用替代的modules. 這在編譯期間通過flavors就可以完成, 或者在運行期間使用一些調(diào)試面板來設(shè)置.

Diff with todo-mvp

Injection類被刪除了.
添加了5個Component, 四個feature各有一個, 另外數(shù)據(jù)對應(yīng)一個: TasksRepositoryComponent, 這個Component被保存在Application里.

數(shù)據(jù)的module: TasksRepositoryModule在mock和prod目錄下各有一個.

對于每一個feature的Presenter的注入是這樣實現(xiàn)的:
首先, 把Presenter的構(gòu)造函數(shù)標記為@Inject, 然后在Activity中構(gòu)造component并注入到字段:

@Inject AddEditTaskPresenter mAddEditTasksPresenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.addtask_act);
    .....
    
    // Create the presenter
    DaggerAddEditTaskComponent.builder()
            .addEditTaskPresenterModule(
                    new AddEditTaskPresenterModule(addEditTaskFragment, taskId))
            .tasksRepositoryComponent(
                    ((ToDoApplication) getApplication()).getTasksRepositoryComponent()).build()
            .inject(this);
}

這個module里provide了view和taskId:

@Module
public class AddEditTaskPresenterModule {

    private final AddEditTaskContract.View mView;

    private String mTaskId;

    public AddEditTaskPresenterModule(AddEditTaskContract.View view, @Nullable String taskId) {
        mView = view;
        mTaskId = taskId;
    }

    @Provides
    AddEditTaskContract.View provideAddEditTaskContractView() {
        return mView;
    }

    @Provides
    @Nullable
    String provideTaskId() {
        return mTaskId;
    }
}

注意原來構(gòu)造方法里調(diào)用的setPresenter方法改為用方法注入實現(xiàn):

/**
 * Method injection is used here to safely reference {@code this} after the object is created.
 * For more information, see Java Concurrency in Practice.
 */
@Inject
void setupListeners() {
    mAddTaskView.setPresenter(this);
}

todo-mvp-contentproviders

這個例子是基于todo-mvp-loaders的, 用content provider來獲取repository中的數(shù)據(jù).

mvp-contentproviders

使用Content Provider的優(yōu)勢是:

• 管理了結(jié)構(gòu)化數(shù)據(jù)的訪問;
• Content Provider是跨進程訪問數(shù)據(jù)的標準接口.

Diff with todo-mvp-loaders

注意這個例子是唯一一個不基于最基本的todo-mvp, 而是基于todo-mvp-loaders. (但是我覺得也可以認為是直接從todo-mvp轉(zhuǎn)化的.)
看diff: git difftool -d todo-mvp-loaders.

去掉了TaskLoader和TasksLoader. (回歸到了基本的todo-mvp).

TasksRepository中的方法不是同步方法, 而是異步加callback的形式. (回歸到了基本的todo-mvp).

TasksLocalDataSource中的讀方法都變成了空實現(xiàn), 因為Presenter現(xiàn)在可以自動收到數(shù)據(jù)更新.

新增LoaderProvider用來創(chuàng)建Cursor Loaders, 有兩個方法:

// 返回特定fiter下或全部的數(shù)據(jù)
public Loader<Cursor> createFilteredTasksLoader(TaskFilter taskFilter)

// 返回特定id的數(shù)據(jù)
public Loader<Cursor> createTaskLoader(String taskId) 

其中第一個方法的參數(shù)TaskFilter, 用來指定過濾的selection條件, 也是新增類.

LoaderManager和LoaderProvider都是由構(gòu)造傳入Presenter, 在回調(diào)onTaskLoaded()和onTasksLoaded()中init loader.

在TasksPresenter中還做了判斷, 是init loader還是restart loader:

@Override
public void onTasksLoaded(List<Task> tasks) {
    // we don't care about the result since the CursorLoader will load the data for us
    if (mLoaderManager.getLoader(TASKS_LOADER) == null) {
        mLoaderManager.initLoader(TASKS_LOADER, mCurrentFiltering.getFilterExtras(), this);
    } else {
        mLoaderManager.restartLoader(TASKS_LOADER, mCurrentFiltering.getFilterExtras(), this);
    }
}

其中initLoader()和restartLoader()時傳入的第二個參數(shù)是一個bundle, 用來指明過濾類型, 即是帶selection條件的數(shù)據(jù)庫查詢.

同樣是在onLoadFinshed()的時候做View處理, 以TaskDetailPresenter為例:

@Override
public void onLoadFinished(Loader<Cursor> loader, Cursor data) {
    if (data != null) {
        if (data.moveToLast()) {
            onDataLoaded(data);
        } else {
            onDataEmpty();
        }
    } else {
        onDataNotAvailable();
    }
}

數(shù)據(jù)類Task中新增了靜態(tài)方法從Cursor轉(zhuǎn)為Task, 這個方法在Presenter的onLoadFinished()和測試中都用到了.

public static Task from(Cursor cursor) {
    String entryId = cursor.getString(cursor.getColumnIndexOrThrow(
            TasksPersistenceContract.TaskEntry.COLUMN_NAME_ENTRY_ID));
    String title = cursor.getString(cursor.getColumnIndexOrThrow(
            TasksPersistenceContract.TaskEntry.COLUMN_NAME_TITLE));
    String description = cursor.getString(cursor.getColumnIndexOrThrow(
            TasksPersistenceContract.TaskEntry.COLUMN_NAME_DESCRIPTION));
    boolean completed = cursor.getInt(cursor.getColumnIndexOrThrow(
            TasksPersistenceContract.TaskEntry.COLUMN_NAME_COMPLETED)) == 1;
    return new Task(title, description, entryId, completed);
}

另外一些細節(jié):
數(shù)據(jù)庫中的內(nèi)存cache被刪了.
Adapter改為繼承于CursorAdapter.

單元測試

新增了MockCursorProvider類, 用于在單元測試中提供數(shù)據(jù).
其內(nèi)部類TaskMockCursor mock了Cursor數(shù)據(jù).
Presenter的測試中仍然mock了所有構(gòu)造傳入的參數(shù), 然后準備了mock數(shù)據(jù), 測試的邏輯主要還是拿到數(shù)據(jù)后的view操作, 比如:

@Test
public void loadAllTasksFromRepositoryAndLoadIntoView() {
    // When the loader finishes with tasks and filter is set to all
    when(mBundle.getSerializable(TaskFilter.KEY_TASK_FILTER)).thenReturn(TasksFilterType.ALL_TASKS);
    TaskFilter taskFilter = new TaskFilter(mBundle);

    mTasksPresenter.setFiltering(taskFilter);

    mTasksPresenter.onLoadFinished(mock(Loader.class), mAllTasksCursor);

    // Then progress indicator is hidden and all tasks are shown in UI
    verify(mTasksView).setLoadingIndicator(false);
    verify(mTasksView).showTasks(mShowTasksArgumentCaptor.capture());
}

todo-mvp-rxjava

關(guān)于這個例子, 之前看過作者的文章: Android Architecture Patterns Part 2:
Model-View-Presenter,
這個文章上過Android Weekly Issue #226.

這個例子也是基于todo-mvp, 使用RxJava處理了presenter和數(shù)據(jù)層之間的通信.

MVP基本接口改變

BasePresenter接口改為:

public interface BasePresenter {
    void subscribe();
    void unsubscribe();
}

View在onResume()的時候調(diào)用Presenter的subscribe(); 在onPause()的時候調(diào)用presenter的unsubscribe().

如果View接口的實現(xiàn)不是Fragment或Activity, 而是Android的自定義View, 那么在Android View的onAttachedToWindow()和onDetachedFromWindow()方法里分別調(diào)用這兩個方法.

Presenter中保存了:

private CompositeSubscription mSubscriptions;

在subscribe()的時候, mSubscriptions.add(subscription);;
在unsubscribe()的時候, mSubscriptions.clear(); .

Diff with todo-mvp

數(shù)據(jù)層暴露了RxJava的Observable流作為獲取數(shù)據(jù)的方式, TasksDataSource接口中的方法變成了這樣:

Observable<List<Task>> getTasks();

Observable<Task> getTask(@NonNull String taskId);

callback接口被刪了, 因為不需要了.

TasksLocalDataSource中的實現(xiàn)用了SqlBrite, 從數(shù)據(jù)庫中查詢出來的結(jié)果很容易地變成了流:

@Override
public Observable<List<Task>> getTasks() {
    ...
    return mDatabaseHelper.createQuery(TaskEntry.TABLE_NAME, sql)
            .mapToList(mTaskMapperFunction);
}

TasksRepository中整合了local和remote的data, 最后把Observable返回給消費者(Presenters和Unit Tests). 這里用了.concat()和.first()操作符.

Presenter訂閱TasksRepository的Observable, 然后決定View的操作, 而且Presenter也負責線程的調(diào)度.
簡單的比如AddEditTaskPresenter中:

@Override
public void populateTask() {
    if (mTaskId == null) {
        throw new RuntimeException("populateTask() was called but task is new.");
    }
    Subscription subscription = mTasksRepository
            .getTask(mTaskId)
            .subscribeOn(mSchedulerProvider.computation())
            .observeOn(mSchedulerProvider.ui())
            .subscribe(new Observer<Task>() {
                @Override
                public void onCompleted() {

                }

                @Override
                public void onError(Throwable e) {
                    if (mAddTaskView.isActive()) {
                        mAddTaskView.showEmptyTaskError();
                    }
                }

                @Override
                public void onNext(Task task) {
                    if (mAddTaskView.isActive()) {
                        mAddTaskView.setTitle(task.getTitle());
                        mAddTaskView.setDescription(task.getDescription());
                    }
                }
            });

    mSubscriptions.add(subscription);
}

StatisticsPresenter負責統(tǒng)計數(shù)據(jù)的顯示, TasksPresenter負責過濾顯示所有數(shù)據(jù), 里面的RxJava操作符運用比較多, 可以看到鏈式操作的特點.

關(guān)于線程調(diào)度, 定義了BaseSchedulerProvider接口, 通過構(gòu)造函數(shù)傳給Presenter, 然后實現(xiàn)用SchedulerProvider, 測試用ImmediateSchedulerProvider. 這樣方便測試.

最后, 歡迎訂閱公眾號: 圣騎士Wind:

圣騎士Wind微信公眾號.png