Todo-mvp源碼體驗

你們好，我是蒼王。

如下是我這個系列的相關文章，有興趣能夠參考一下，能夠給個喜歡或者關注個人文章。

[Android]如何作一個崩潰率少於千分之三噶應用app--章節列表

或者你已經看過了google官方相關的MVP樣例。

google官方樣例

這系列的章節內容，將會帶你們分析google官網這個架構的好東西。

適合Android入門一年半左右的同窗學習。

這一節咱們將由最簡單的Todo-mvp給你們分析。

Todo-mvp的樣例，實際上是一個簡單的記事App。

一.文件目錄

從文件目錄咱們很簡單的看

addedittask:編輯記事界面

data：數據架構設計

statistics：記事編輯

tasks:記事首頁

util:工具類

base:基本接口

這裏簡單分析一下目錄裏面，基本就是每一個Activity爲獨立的文件夾，而後數據文件夾裏面分爲遠端和本地，而後base的文件都放在主目錄中。

二.基本的Activity裏面的MVP架構

請認真觀看官網的這張架構圖

基礎mvp架構圖

圖示中很是清楚的說明了MVP的基礎架構，Presenter和View之間能夠相互操做，數據交流，Model（模塊）此處是離開Activity的所有圖示都算是Model數據層，能夠看到，其實經過一個REPOSITORY來管理數據存儲，Remote data source和Local data source表明遠端（網絡）和本地（SQL）的數據來源。

MVC和MVP最大的區別在於，MVC中M和V是能夠通訊交流，而MVP中M和V是無法直接交流的。

Base的View

Base的Presenter

很明顯都是以接口的方式來利用組合來作公共的基礎接口。

咱們以TaskActivity爲例

其模塊內都把View和Presenter再次封裝到TasksContract統一的接口容器裏面。

View接口中，是定義全部更改界面須要的方法。

而Presenter接口中，定義全部控制邏輯的方法。

其簡單圖示關係

Base架構圖

MVP是經過接口的方式來解耦，因此View和Presenter都是經過接口來解耦。

在TaskActivity中

初始化TasksFragment，其繼承了Contract的View，而初始化了TaskPresenter，其會繼承Contract的Presenter。

繼承View

繼承Presenter

就正如架構中的這個黃色部分了

注意初始化的時候Presenter的時候是傳入了Model和View的模塊，那麼纔可以讓Presenter做爲內容控制者來統籌全局

TasksRepositroy至關於數據提供者（Model），其自己也是經過接口來解耦，而TasksContract.View至關於界面顯示（View），也是接口。

而後View經過setPresenter的方法來，讓其和Presenter相關關聯。（View和Presenter是能夠相互關聯的）

三.數據層架構

數據層架構

從這個圖能夠很清楚看明白數據層是經過REPOSITORY做爲入口，分別獲取遠端數據和本地數據的。

其類圖以下，這樣看應該比較清晰一點吧。

TaskDataSource是基礎接口，作成基礎接口，

這裏的TasksRemoteDataSource只是用一個Map存儲來模擬遠端的存儲，實現TasksDataSource的接口。

而TasksLocalDataSource 用的是本地的數據來存儲數據。

最主要的TasksRepository就是作出包裝給統一的接口給外部調用。

能夠清晰的看到初始化的時候，會傳入遠端的對象和本地存儲的的對象。

而後外包統一的接口給外部調用，以getTasks的方法爲例

遠端調用的方法，也是經過LoadTasksCallback回調。

這裏看了數據層運用的，看起來是簡單的封裝，其實算是外觀模式加接口的變種。

其封裝好裏面調用的多個類流程代碼，經過一個接口類，讓外界調用它的流程。

四.關於測試用例

國內如今不少公司之前的開發習慣都不會很注重自動化測試用例，由於自動化用例，須要些測試代碼。可是國外的研發，很是重視測試，並且有本身一套的測試流程。測試用例，極可能就是研發本身寫出來的。

國內大致上，如今也愈來愈注重測試了，特別大型App。

這裏順便經過這個todo-mvp 順便也給你們普及一些測試代碼的相關知識吧。

testCompile是聲明本地測試的依賴，androidTestCompile是聲明Instrumented測試依賴。

對於單元測試，須要預先了解如下內容

Android Studio的test和AndroidTest

AndroidJUnitRunner：一個兼容Junit4的Andriod單元測試框架

Mockito：單元測試利器

Espresso：支持UI測試的單元測試框架

P層：不須要任何Android環境，所以使用Junit測試便可

V層：使用Google強大的Espresso進行UI的測試

M層：涉及到數據庫相關操做，所以須要依賴Android環境，使用AndroidJUnitRunner進行測試

View層

職責：MVP模式下，View層終於揚眉吐氣了，View自己該作的事情都能作了，好比UI佈局，數據渲染，點擊按鈕交互等等

測試方式：以正常小QA的測試思惟方法，就能夠來定義這一層的測試方式，測試過程當中須要真機或模擬器，並作真實的操做。

測試選型：依賴於Android環境，用谷歌強大的Espresso+AndroidJUnitRunner，Espresso用於模擬和驗證各類各樣的UI操做，代碼存放於AndroidTest中。

Presenter層：

職責：這一層是拉皮條的，負責M和V層的對接，因此有較少的處理輸入輸出的機會，他只用來控制邏輯，去調用相應的Model和View的邏輯。

測試選型：他的職責決定了他不多去斷言輸入輸出，測試邏輯覆蓋的路徑是否正確便可，所以他與Android環境無關，用Junit+Mockito測試便可，代碼存放於test中。

Model層

職責：負責數據的存取，數據可能來自於網絡、數據庫和內存

數據庫增刪改查：需測試數據存取的準確性，依賴Android環境進行測試，所以使用AndroidJUnitRunner，代碼存放於androidTest中

網絡請求：不測試真實的網絡請求，但提供了Fake供其餘層調用測試。

封裝的門面類：決定了數據的來源和去向是來自於本地數據庫 or 網絡 or 內存，此爲真正對其餘層暴露的Model類。此類不作數據準確性的驗證，只作mock測試，驗證覆蓋路徑。UT選型Junit+Mockito，代碼存放於test中。

這裏想深刻了解有關測試的內用能夠看Android官方MVP項目單元測試。

我創建了一個關於Android架構學習的羣，裏面能夠進一步進行組件化學習和架構思想的的交流。

羣號是316556016，也能夠掃碼進羣。我在這裏期待大家的加入！！！

這一節就介紹到這裏了。

下一節將會介紹下一個MVP架構的內容，敬請期待！！！