⑴ Android MVP模式中，一個Activity對應多個Presenter時該怎樣抽象
View 和 Presenter 之間是有協議約束的.
假設現有V1, P1, V2, P2, 一個ActivityA對應了P1/P2的功能, 也應該說明它實現了V1/V2介面, 此時應該有PresenterA 實現了P1, P2. 這就是完整的VP的協議就對上了.
這里既然多個頁面可能用到同樣的功能, 最簡單的方式節點使用多繼承(一個Persenter實現ABCD四個介面), 這樣不管Activity實際上用的都是同一個Persenter.如果確定現在已經有實現了, 按樓上的方法實現一個代理就可以了.
實在要實現多個Presenter的話, 可以定義幾個不同的類, 來支持不同多個Presenter的擴展:
class BaseMvpActivity1<P> extent BaseActivity {
P presenter;
}
class BaseMvpActivity2<P1, P2> extent BaseActivity {
P1 presenter1;
P2 presenter2;
}
但不推薦這樣做(失去抽象, 違反依賴倒置原則); 更不推薦使用數組或List(基類使用泛型方便編譯器檢查, 數組或List在具體使用時需要做類型的強轉)
⑵ Android MVP架構中的Presentation層應該怎麼設計
先區分一下Android View、View、界面的區別
Android View： 只是繼承android.view.View的Android組件。
View：介面，用於由presenter向View實現類通信，你可以在Android組件中實現它。有時最好直接使用Activity，Fragment或自定義View。
界面：界面是面向用戶的概念。比如要在手機上進行界面間切換時，我們在代碼中可以通過多種方式實現，如Activity到Activity或一個Activity內部的Fragment/View進行切換。所以這個概念基於用戶的視覺，包括了所有View中能看到的東西。
切換界面
界面間的切換可以是兩個Fragment、兩個Activity、打開對話框、啟動新Activity等等。當然切換的具體實現原理不屬於這篇文章的內容，而進行切換操作則是Presentation層的職責。Presenter應該知道要做什麼，而它的實現類要知道怎麼完成。在這個例子中，要做的就是切換界面，完成方式就是啟動新的Activity。
但這樣會有一個問題。Presentation層是純java代碼，所以Presenter中不應該有任何與安卓相關的代碼。那怎麼完成界面的切換呢？通過抽象。這里可以寫一個只有一個navigate()方法的介面NavigationCommand。在需要時我們在Presenter中調用這個介面的navigate()方法，然後在Activity中實現這個介面。
代碼長這樣：
View層
ActivityA.java
public class ActivityA extends Activity {
@OnClick(R.id.someButton)
public void onSomeButtonClicked() {
presenter.onSomeButtonClicked();
}
ToActivityB.java
public class ToActivityB implements NavigationCommand {
private final Activity currentActivity;
public ToActivityB(Activity activity) {
currentActivity = activity;
}
@Override
public void navigate() {
currentActivity.startActivity();
}
}
Presentation層
NavigationCommand.interface
public interface NavigationCommand {
public void navigate();
}
PresenterA.java
public class PresenterA {
private final NavigationCommand toBNavigation;
public PresenterA(NavigationCommand toBNavigation) {
this.toBNavigation = toBNavigation;
}
public void onSomeButtonClicked() {
toBNavigation.navigate();
}
}
這樣我們就可以將VP兩層解耦。這里將切換到一個Activity的代碼提取出來，可以復用，我們可以通過注入NavigationCommand方法來測試Presenter，而且就算要跳轉的頁面變了，Presenter的代碼也不變。這也符合Open Close原則。
另一個問題就是當一個Presenter中出現多個NavigationCommand時，構造方法就開始變得詭異了。
public class PresenterA {
private final NavigationCommand toBNavigation;
private final NavigationCommand toCNavigation;
public PresenterA(NavigationCommand toBNavigation, NavigationCommand toCNavigation) {
this.toBNavigation = toBNavigation;
this.toCNavigation = toCNavigation;
}
}
在這里初始化Presenter的類很難搞清楚兩個NavigationCommand之間的順序，似乎只能通過名字來辨識，這里其實可以再寫一個介面繼承NavigationCommand來專門管理一類特定的切換，或者如果你使用依賴注入框架的話也可以指定參數的類型。
有時需要在切換界面時傳遞一些參數，這時就要改動一下NavigationCommand的代碼：
public interface ToScreenBNavigationCommand extends NavigationCommand {
void setMyParameterToNavigate(String parameter);
}
⑶ Android MVP 開發模式有哪些優缺點
MVP概念：
MVP(Model-View-Presenter) 是總所周知MVC模式的一個演變，主要目的都是劃分模塊職責，降低模塊耦合，易測試,提高代碼復用。
層級責任
Model:負責數據的檢索,持久化等操作。
View: 負責UI的繪制和用戶的交互。
Presenter: 作為Model和View的中間協調部分,負責兩者之間的業務邏輯處理。
MVC模式的區別
MVC模式允許View層和Model層直接通訊。
當某個View的功能很復雜的時候,View和Model的耦合度可能會很高。
MVP模式就沒有這個問題,View會抽象出來一系列操作UI的介面。
Presenter拿到的都是其他兩個層級的介面來做業務邏輯的處理，這樣不僅可以使View和Model之間的耦合度降低,還可以更易得進行單元測試。
MVP的優缺點
優點:降低耦合，層級職責更明顯，易於單元測試。
缺點:造成類數量爆炸，代碼復雜度和學習成本高，在某些場景下presenter的復用會產生介面冗餘。
⑷ 如何理解android mvp模式中的interactor
Presenter起到的其實就是一個粘合劑的角色。
它調度了UI邏輯和數據邏輯，然而UI邏輯和數據邏輯的具體實現，Presenter是不用關心的，只需要處理好如何調度，和狀態處理即可。
理解這個之前，你需要理解Model 和 ViewModel，一個Model也就是我們平常說的JavaBean，例如一個User類，它有自己的基本屬性。姓名，年齡，用戶名，密碼等等。
而ViewModel代表的是視圖的Model，例如一個登陸視圖，它的ViewModel包含用戶名，密碼。
所以Model是不能直接被視圖使用的，我們需要轉換成ViewModel的形式，然後綁定到視圖上。
你可能會說，我也可以直接綁定Model的屬性到View上，但是這樣View和Model就不是相互獨立的了，也就違背了我們使用MVP、MVVM的初衷。
Interactor的作用實際上就是獲取Model(從本地資料庫，或者是伺服器),轉換成ViewModel，回調通知把ViewModel傳遞給Presenter。
Presenter實現了Interactor的回調介面，可以接收到ViewModel的實例，此時它在回調函數裡面只需要將接收到的ViewModel綁定的View上面即可。
可以看到，在這個過程中Presenter並沒有觸及到具體的實現，只是把View 和 ViewModel進行了綁定而已。
當然你也可以把數據邏輯寫在Presenter，但是Interactor就不存在了，其實Interactor也是可以重用的
作者：面條
鏈接：http://www.hu.com/question/38528132/answer/77390722
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。
⑸ 如何實現自己的Android MVP框架
實現Android MVP框架
一個經典的 Android MVC 框架項目的代碼結構
MVP減負activity ，承擔了 view 層和 controller 層的工作
View 層的 ActivityActivity 里包含： View 層的對外介面 MainView, P層 Presenter
對外介面 MainView 文件
P層代碼
文件
DataManager.java
TaskDataSource.java
TaskDataSourceImpl.java
TaskDataSourceTestImpl.java
Android 版方案
通過新建子線程進行IO讀寫獲取數據
以主線程的 Looper 將結果通過傳回主線程進行渲染和展示。
⑹ android mvp adapter該怎麼寫
adapter一般叫適配器，所以顧名思義，它是根據不同數據模型來適配出不同的數據展示效果，而自身不需要進行相應的修改操作。
mvp 分別是 model view controller ，個人感覺adapter應該歸到controller這個部分合適。
⑺ 如何一步一步實現Android的MVP框架
實現Android MVP框架
一個經典的 Android MVC 框架項目的代碼結構
⑻ 如何一步一步實現Android的MVP框架
實現Android MVP框架一個經典的 Android MVC 框架項目的代碼結構
MVP減負activity ，承擔了 view 層和 controller 層的工作
View 層的 ActivityActivity 里包含： View 層的對外介面 MainView, P層 Presenter對外介面 MainView 文件
P層代碼
文件
DataManager.java
TaskDataSource.java
TaskDataSourceImpl.java
TaskDataSourceTestImpl.java
Android 版方案通過新建子線程進行IO讀寫獲取數據
以主線程的 Looper 將結果通過傳回主線程進行渲染和展示。
⑼ android mvp mvvm怎麼選擇 簡書
1.MVC
傳統的Android App其實都是基於MVC的，Activity，Fragment相當於C,布局相當於V,數據邏輯相當於M
隨著業務的增長Controller里的代碼會越來越臃腫，因為它不只要負責業務邏輯，還要控制View的展示。也就是說Activity、Fragment雜糅了Controller和View，耦合變大。並不能算作真正意義上的MVC。
這也是為什麼後面的MVP會引起很多開發者興趣的原因了。
2.MVP
MVP架構其實可以說與MVC的架構還是有很大的差別的，數據邏輯相當於M，Activity（負責View的繪制以及與用戶交互）相當於V ，View於Model間的交互則為P
理論上感覺區別有點抽象，可以通過下面的圖來看一看其中的區別
⑽ 如何實現自己的Android MVP框架
實現Android MVP框架
一個經典的 Android MVC 框架項目的代碼結構