android 适合mvp模式,Android中的MVP：如何使Presenter层系统化？
MVP(Model View Presenter)模式是著名的 MVC(Model View Controller)的衍生物，并且是 Android 應(yīng)用程序中管理表示層的***的模式之一。
這篇文章***發(fā)表于 2014 年 4 月，從那以后就一直備受歡迎。所以我決定更新它來解決人們心中的大部分疑慮，并將代碼轉(zhuǎn)換為 Kotlin 語言形式。
自那時起，架構(gòu)模式發(fā)生了重大變化，例如帶有架構(gòu)組件的 MVVM，但 MVP 仍然有效并且是一個值得考慮的選擇。
什么是 MVP 模式?
MVP 模式將 Presenter 層從邏輯中分離出來，這樣一來，就把所有關(guān)于 UI 如何工作與我們在屏幕上如何表示它分離了開來。理想情況下，MVP 模式將實現(xiàn)相同的邏輯可能具有完全不同且可交替的界面。
要明確的***件事是 MVP 本身不是一個架構(gòu)，它只負(fù)責(zé)表示層。這是一個有爭議的說法，所以我想更深入地解釋一下。
你可能會發(fā)現(xiàn) MVP 被定義為架構(gòu)模式，因為它可以成為你的應(yīng)用程序架構(gòu)的一部分。但你不應(yīng)當(dāng)這樣認(rèn)為，因為去掉 MVP 之后，你的架構(gòu)依舊是完整的。MVP 僅僅塑造表示層，但如果你需要靈活且可擴展的應(yīng)用程序，那么其余層仍需要良好的體系架構(gòu)。
完整架構(gòu)體系的一個示例可以是 Clean Architecture，但還有許多其他選擇。
在任何情況下，在你從未使用 MVP 的架構(gòu)中去使用它總是件好事。
為什么要使用 MVP?
在 Android 開發(fā)中，我們遇到一個嚴(yán)峻的問題：Activity 高度耦合了用戶界面和數(shù)據(jù)存取機制。我們可以找到像 CursorAdapter 這樣的極端例子，它將作為視圖層一部分的 Adapter 和 屬于數(shù)據(jù)訪問層級的 Cursor 混合到了一起。
為了能夠輕松地擴展和維護(hù)一個應(yīng)用，我們需要使用可以相互分離的體系架構(gòu)。如果我們不再從數(shù)據(jù)庫獲取數(shù)據(jù)，而是從 web 服務(wù)器獲取，那么我接下來該怎么辦呢?我們可能就要重新編寫整個視圖層了。
MVP 使視圖獨立于我們的數(shù)據(jù)源而存在。我們需要將應(yīng)用程序劃分為至少三個不同的層次，以便我們可以獨立地測試它們。通過 MVP，我們可以將大部分有關(guān)業(yè)務(wù)邏輯的處理從 Activity 中移除，以便我們可以在不使用 Instrumentation Test 的情況下對其進(jìn)行測試。
如何實現(xiàn) Android 當(dāng)中的 MVP?
好吧，這就是它開始產(chǎn)生分歧的地方。MVP 有很多變種，每個人都可以根據(jù)自己的需求和自己感覺更加舒適的方式來調(diào)整模式。這主要取決于我們委托給 Presenter 的任務(wù)數(shù)量。
到底是該由 View 層來負(fù)責(zé)啟用或禁用一個進(jìn)度條，還是該由 Presenter 來負(fù)責(zé)呢?又該由誰來決定 Action Bar 應(yīng)該做出什么行為呢?這就是艱難決定的開始。我將展示我通常情況下是如何處理這種情況的，但我希望這篇文章更是一個適合討論的地方，而不是嚴(yán)格的約束 MVP 該如何應(yīng)用，因為根本沒有“標(biāo)準(zhǔn)”的方式來實現(xiàn)它。
對于本文，我已經(jīng)實現(xiàn)了一個非常簡單的示例，你可以在我的 Github 找到 一個登錄頁面和主頁面。為了簡單起見，本文中的代碼是使用 Kotlin 實現(xiàn)的，但你也可以在倉庫中查看使用 Java 8 編寫的代碼。
Model 層
在具有完整分層體系結(jié)構(gòu)的應(yīng)用程序中，這里的 Model 僅僅是通往領(lǐng)域?qū)踊驑I(yè)務(wù)邏輯層的大門。如果我們使用 鮑勃大叔的 clean architecture 架構(gòu)，這里的 Model 可能是一個實現(xiàn)了一個用例的 Interactor(交互器)。但就本文而言，將 Model 看做是一個給 View 層顯示數(shù)據(jù)的提供者就足夠了。
如果你檢查代碼，你將看到我創(chuàng)建了兩個帶有人為延遲操作的 Interactor 來模擬對服務(wù)器的請求情況。其中一個 Interactor 的結(jié)構(gòu)：
class?LoginInteractor?{
...
fun?login(username:?String,?password:?String,?listener:?OnLoginFinishedListener)?{
//?Mock?login.?I'm?creating?a?handler?todelay?the?answer?a?coupleofseconds
postDelayed(2000)?{
when{
username.isEmpty()?->?listener.onUsernameError()
password.isEmpty()?->?listener.onPasswordError()
else->?listener.onSuccess()
}
}
}
}
這是一個簡單的方法，它接收用戶名和密碼，并進(jìn)行一些驗證操作。
View 層
View 層通常是由一個 Activity(也可以是一個 Fragment，一個 View，這取決于 App 的結(jié)構(gòu))，它包含了一個對 Presenter 的引用。理想情況下，Presenter 是通過依賴注入的方式提供的(比如 Dagger)，但如果你沒有使用這類工具，也可以直接創(chuàng)建一個 Presenter 對象。View 需要做的唯一一件事就是：當(dāng)有用戶操作發(fā)生時(比如一個按鈕被點擊了)，就調(diào)用 Presenter 中的相應(yīng)方法。
由于 View 必須與 Presenter 層無關(guān)，因此它就需要實現(xiàn)一個接口。下面是示例中使用到的接口：
interface?LoginView?{
fun?showProgress()
fun?hideProgress()
fun?setUsernameError()
fun?setPasswordError()
fun?navigateToHome()
}
接口中有一些有效的方法來顯示或隱藏進(jìn)度條，顯示錯誤信息，跳轉(zhuǎn)到下一個頁面等等。正如上面所提到的，有很多方式去實現(xiàn)這些功能，但我更喜歡羅列出最簡單直觀的方法。
然后，Activity 可以實現(xiàn)這些方法。這里我向你展示了一些用法，以便你對其用法有所了解：
class?LoginActivity?:?AppCompatActivity(),?LoginView?{
...
override?fun?showProgress()?{
progress.visibility?=?View.VISIBLE
}
override?fun?hideProgress()?{
progress.visibility?=?View.GONE
}
override?fun?setUsernameError()?{
username.error?=?getString(R.string.username_error)
}
}
但是如果你還記得，我還告訴過你，View 層使用 Presenter 來通知用戶交互操作。下面就是它的用法：
class?LoginActivity?:?AppCompatActivity(),?LoginView?{
private?val?presenter?=?LoginPresenter(this,?LoginInteractor())
override?fun?onCreate(savedInstanceState:?Bundle?)?{
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_login)
button.setOnClickListener?{?validateCredentials()?}
}
private?fun?validateCredentials()?{
presenter.validateCredentials(username.text.toString(),?password.text.toString())
}
override?fun?onDestroy()?{
presenter.onDestroy()
super.onDestroy()
}
...
}
Presenter 被定義為 Activity 的屬性，當(dāng)點擊按鈕時，它會調(diào)用 validateCredentials()方法，該方法將會通知 Presenter。
onDestroy() 方法亦是如此。我們稍后將會看到為什么在這種情況下需要通知 Presenter。
Presenter 層
Presenter 充當(dāng)著 View 層和 Model 層的中間人。它從 Model 層獲取收據(jù)并將格式化后數(shù)據(jù)返回給 View 層。
此外，與典型的 MVC 模式不同的是，Presenter 決定了當(dāng)你在與 View 層交互時會做何響應(yīng)。因此，它將為用戶每個可執(zhí)行的操作提供一種方法。我們在 View 層中看到了它，這里是代碼實現(xiàn)：
class?LoginPresenter(var?loginView:?LoginView?,?val?loginInteractor:?LoginInteractor)?:
LoginInteractor.OnLoginFinishedListener?{
fun?validateCredentials(username:?String,?password:?String)?{
loginView?.showProgress()
loginInteractor.login(username,?password,?this)
}
...
}
MVP 模式存在一些風(fēng)險，常常被我們忽略的最重要的問題是 Presenter 永遠(yuǎn)依附在 View 上面。并且 View 層一般為 Activity，這就意味著：
我們可能會由于長時間的運行的任務(wù)而導(dǎo)致 Activity 的泄漏
我們可能會在 Activity 已經(jīng)被銷毀的情況下去更新視圖
首先，倘若你能夠保證能夠在合理的時間內(nèi)完成你的后臺任務(wù)，我將不會過于擔(dān)心。將你的 Activity 泄漏 5-10 秒會讓你的 App 變得很糟糕，并且解決方案通常很復(fù)雜。
第二點反而更讓人擔(dān)心。想象一下，你花費 10 秒鐘時間向服務(wù)器發(fā)送一個請求，但用戶卻在 5 秒鐘后關(guān)閉了 Activity。當(dāng)回調(diào)方法正在被調(diào)用并且 UI 被更新時，App 將會崩潰，因為 Activity 正在銷毀中。
為了解決這個問題，我們可以在 Activity 中調(diào)用 onDestroy() 方法并清除 View：
fun?onDestroy()?{
loginView?=?null
}
這樣我們就可以避免在任務(wù)結(jié)束時間與活動銷毀時間不一致的情況下調(diào)用 Activity 了。
總結(jié)
在 Android 中將用戶界面層與邏輯層分離并不簡單，但 MVP 模式可以更加輕易地防止我們的 Activity 最終淪為高度耦合的、包含了成百上千行代碼的類。在大型應(yīng)用開發(fā)過程中，將代碼管理好是很有必要的。否則，對代碼的維護(hù)和擴展都會變得很困難。
如今，還有其他的代替方案比如 MVVM，我將會創(chuàng)作新的文章來對 MVVM 和 MVP 做比較，并幫助開發(fā)者遷移。所以請繼續(xù)關(guān)注我的博客!
【編輯推薦】
【責(zé)任編輯：未麗燕 TEL：(010)68476606】
點贊 0
總結(jié)
以上是生活随笔為你收集整理的android 适合mvp模式,Android中的MVP：如何使Presenter层系统化？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： com.android.dazhihui
- 下一篇： Android source开发环境搭建