mvp框架android
㈠ 如何實現自己的Android MVP框架
前言MVP作為一種MVC的演化版本在Android開發中受到了越來越多的關注，但在項目開發中選擇一種這樣的軟體設計模式需保持慎重心態，一旦確定使用MVP作為你App的開發模式那麼你就最好堅持做下去，如果在使用MVP模式開發過程中發現問題而且坑越來越大，這時你想用MVC等來重新設計的話基本上就等於推倒重來了。要知道在Android上MVP在現在為止並沒有統一的標准或者框架，不像SSH這三個成熟穩重強而有力的三劍客支持推動著javaEE的開發，所以在運用MVP時一定要做好自己的理解，並且盡量預知自己App各模塊的需求（客戶說改改改，我們就改改改:-(）以便提前做好充分的設計工作。當然MVP既然能出現那麼必然有它的優點的，不然誰會理會這個冒出來的東西，下面就對Android中MVP做一些闡述。MVP簡介相信大家對MVC都是比較熟悉了：M-Model-模型、V-View-視圖、C-Controller-控制器，MVP作為MVC的演化版本，也是作為用戶界面（用戶層）的實現模式，那麼類似的MVP所對應的意義：M-Model-模型、V-View-視圖、P-Presenter-表示器。從MVC和MVP兩者結合來看，Controlller/Presenter在MVC/MVP中都起著邏輯控制處理的角色，起著控制各業務流程的作用。而MVP與MVC最不同的一點是M與V是不直接關聯的也是就Model與View不存在直接關系，這兩者之間間隔著的是Presenter層，其負責調控View與Model之間的間接交互，MVP的結構圖如下所示，對於這個圖理解即可而不必限於其中的條條框框，畢竟在不同的場景下多少會有些出入的。在Android中很重要的一點就是對UI的操作基本上需要非同步進行也就是在MainThread中才能操作UI，所以對View與Model的切斷分離是合理的。此外Presenter與View、Model的交互使用介面定義交互操作可以進一步達到松耦合也可以通過介面更加方便地進行單元測試。MVP結構圖MVP之ModelModel是用戶界面需要顯示數據的抽象，也可以理解為從業務數據（結果）那裡到用戶界面的抽象（Businessrule,dataaccess,modelclasses）。本文Demo為了簡單處理就直接把業務放到了對應的Model之中。MVP之View視圖這一層體現的很輕薄，負責顯示數據、提供友好界面跟用戶交互就行。MVP下Activity和Fragment體現在了這一層，Activity一般也就做載入UI視圖、設置監聽再交由Presenter處理的一些工作，所以也就需要持有相應Presenter的引用。例如，Activity上滾動列表時隱藏或者顯示Acionbar（Toolbar），這樣的UI邏輯時也應該在這一層。另外在View上輸入的數據做一些判斷時，例如，EditText的輸入數據，假如是簡單的非空判斷則可以作為View層的邏輯，而當需要對EditText的數據進行更復雜的比較時，如從資料庫獲取本地數據進行判斷時明顯需要經過Model層才能返回了，所以這些細節需要自己掂量。MVP之PresenterPresenter這一層處理著程序各種邏輯的分發，收到View層UI上的反饋命令、定時命令、系統命令等指令後分發處理邏輯交由業務層做具體的業務操作，然後將得到的Model給View顯示。演示demo動手寫起代碼來才有更好的感覺。demo很簡單,還是上個圖更直觀，輸入城市的代號，點擊按鈕獲取城市的天氣信息然後顯示出來，網路操作使用Volley框架，解析用Gson，其它的就手寫了。整個項目的包設計如下：包結構項目效果預覽包圖中明顯的三層：Model包、Presenter包、UI包，其中，三者都實現各自的結構，Model為WeatherModel、Presenter為WeatherPresenter、View為Weather，那麼具體實現類就是impl包里的了，View層的即為Activity。此外的app和util包無關緊要可以不看。可以看到採用MVP設計後項目明顯多了很多東西，這也是不可避免的，使用原始方法可以使項目開起來簡單些但是以後還有維護呢、測試呢、加功能呢、。。。entity里的實體屬性基本上對應json里的這些屬性了，代碼不貼了View裡面的介面：publicinterfaceWeatherView{voidshowLoading();voidhideLoading();voidshowError();voidsetWeatherInfo(Weatherweather);}WeatherPresenter的介面：{/***獲取天氣的邏輯*/voidgetWeather(StringcityNO);}WeatherModel介面：publicinterfaceWeatherModel{voidloadWeather(StringcityNO,OnWeatherListenerlistener);}prestener裡面還有個OnWeatherListener，其在Presenter層實現，給Model層回調，更改View層的狀態，確保Model層不直接操作View層。如果沒有這一介面在WeatherPresenterImpl實現的話，WeatherPresenterImpl只有View和Model的引用那麼Model怎麼把結果告訴View呢？當然這只是一種解決方案，在實際項目中可以使用Dagger、EventBus、Otto等第三方框架結合進來達到更加松耦合的設計。{/***成功時回調**@paramweather*/voidonSuccess(Weatherweather);/***失敗時回調，簡單處理，沒做什麼*/voidonError();}所以demo的代碼流程：Activity做了一些UI初始化的東西並需要實例化對應WeatherPresenter的引用和實現WeatherView的介面，監聽界面動作，Go按鈕按下後即接收到查詢天氣的事件，在onClick里接收到即通過WeatherPresenter的引用把它交給WeatherPresenter處理。WeatherPresenter接收到了查詢天氣的邏輯就知道要查詢天氣了，然後把查詢天氣的具體業務實現交給WeatherModel去實現同時把WeatherListener即WeatherPresenter自己傳給WeatherModel。WeatherModel進行查詢天氣業務後即把結果通過WeatherListener回調通知WeatherPresenter，WeatherPresenter再把結果返回給View層的Activity，最後Activity顯示結果。就這樣，拍磚之處請拍。End採用哪種軟體設計模式都是為了達到如下目的，找到合適的加以運用就是最好的：易於維護易於測試松耦合度復用性高健壯穩定------------------------------------------------------------------------------------以上內容均參考互聯網，希望以上知識對您有所幫助，
㈡ 安卓baseactivity怎麼封裝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框架
前言
MVP作為一種MVC的演化版本在Android開發中受到了越來越多的關注，但在項目開發中選擇一種這樣的軟體設計模式需保持慎重心態，一旦確定使用MVP作為你App的開發模式那麼你就最好堅持做下去，如果在使用MVP模式開發過程中發現問題而且坑越來越大，這時你想用MVC等來重新設計的話基本上就等於推倒重來了。要知道在Android上MVP在現在為止並沒有統一的標准或者框架，不像SSH這三個成熟穩重強而有力的三劍客支持推動著Java EE的開發，所以在運用MVP時一定要做好自己的理解，並且盡量預知自己App各模塊的需求（客戶說改改改，我們就改改改 :-( ）以便提前做好充分的設計工作。當然MVP既然能出現那麼必然有它的優點的，不然誰會理會這個冒出來的東西，下面就對Android中MVP做一些闡述。
MVP簡介
相信大家對MVC都是比較熟悉了：M-Model-模型、V-View-視圖、C-Controller-控制器，MVP作為MVC的演化版本，也是作為用戶界面（用戶層）的實現模式，那麼類似的MVP所對應的意義：M-Model-模型、V-View-視圖、P-Presenter-表示器。從MVC和MVP兩者結合來看，Controlller/Presenter在MVC/MVP中都起著邏輯控制處理的角色，起著控制各業務流程的作用。而MVP與MVC最不同的一點是M與V是不直接關聯的也是就Model與View不存在直接關系，這兩者之間間隔著的是Presenter層，其負責調控View與Model之間的間接交互，MVP的結構圖如下所示，對於這個圖理解即可而不必限於其中的條條框框，畢竟在不同的場景下多少會有些出入的。在Android中很重要的一點就是對UI的操作基本上需要非同步進行也就是在MainThread中才能操作UI，所以對View與Model的切斷分離是合理的。此外Presenter與View、Model的交互使用介面定義交互操作可以進一步達到松耦合也可以通過介面更加方便地進行單元測試。
項目效果預覽
包圖中明顯的三層：Model包、Presenter包、UI包，其中，三者都實現各自的結構，Model為WeatherModel、Presenter為WeatherPresenter、View為Weather，那麼具體實現類就是impl包里的了，View層的即為Activity。此外的app和util包無關緊要可以不看。可以看到採用MVP設計後項目明顯多了很多東西，這也是不可避免的，使用原始方法可以使項目開起來簡單些但是以後還有維護呢、測試呢、加功能呢、。。。
entity里的實體屬性基本上對應json里的這些屬性了，代碼不貼了
View裡面的介面：
public interface WeatherView {
void showLoading();
void hideLoading();
void showError();
void setWeatherInfo(Weather weather);
}
WeatherPresenter的介面：
public interface WeatherPresenter {
/**
* 獲取天氣的邏輯
*/
void getWeather(String cityNO);
}
WeatherModel介面：
public interface WeatherModel {
void loadWeather(String cityNO, OnWeatherListener listener);
}
prestener裡面還有個OnWeatherListener，其在Presenter層實現，給Model層回調，更改View層的狀態，確保Model層不直接操作View層。如果沒有這一介面在WeatherPresenterImpl實現的話，WeatherPresenterImpl只有View和Model的引用那麼Model怎麼把結果告訴View呢？當然這只是一種解決方案，在實際項目中可以使用Dagger、EventBus、Otto等第三方框架結合進來達到更加松耦合的設計。
public interface OnWeatherListener {
/**
* 成功時回調
*
* @param weather
*/
void onSuccess(Weather weather);
/**
* 失敗時回調，簡單處理，沒做什麼
*/
void onError();
}
所以demo的代碼流程：Activity做了一些UI初始化的東西並需要實例化對應WeatherPresenter的引用和實現WeatherView的介面，監聽界面動作，Go按鈕按下後即接收到查詢天氣的事件，在onClick里接收到即通過WeatherPresenter的引用把它交給WeatherPresenter處理。WeatherPresenter接收到了查詢天氣的邏輯就知道要查詢天氣了，然後把查詢天氣的具體業務實現交給WeatherModel去實現同時把WeatherListener即WeatherPresenter自己傳給WeatherModel。WeatherModel進行查詢天氣業務後即把結果通過WeatherListener回調通知WeatherPresenter，WeatherPresenter再把結果返回給View層的Activity，最後Activity顯示結果。就這樣，拍磚之處請拍。
End
採用哪種軟體設計模式都是為了達到如下目的，找到合適的加以運用就是最好的：
易於維護
易於測試
松耦合度
復用性高
健壯穩定
------------------------------------------------------------------------------------
以上內容均參考互聯網，希望以上知識對您有所幫助，
㈣ Android MVP與MVC的區別和理解
MVP架構：
View不直接與Model交互，而是通過與Presenter交互來與Model間接交互。
Presenter與View的交互是通過介面來進行的。
通常View與Presenter是一對一的，但復雜的View可能綁定多個Presenter來處理邏輯。
MVC架構：
View可以與Model直接交互。
Controller是基於行為的，並且可以被多個View共享。
可以負責決定顯示哪個View。
㈤ android mvvm和mvp哪個好
沒有那個好那個不好一說，大項目需要用到框架做以後的維護升級，小項目沒必要去強套什麼框架，反而會變得麻煩。
㈥ android mvc和mvp的區別
MVC與MVP架構特點與區別-android
http://blog.csdn.net/shareus/article/details/51481308
㈦ Android MVP架構中的Presentation層應該怎麼設計
對於MVP（Model View Presenter），大多數人都能說出一二：「MVC的演化版本」，「讓Model和View完全解耦」等等。本篇博文僅是為了做下記錄，提出一些自己的看法，和幫助大家如何針對一個Activity頁面去編寫針對MVP風格的代碼。
對於MVP，我的內心有一個問題：
為何這個模式出來後，就能被廣大的Android的程序員接受呢？
問了些程序員，他們對於MVP的普遍的認識是：「代碼很清晰，不過增加了很多類」。我在第一次看到MVP的時候，看了一個demo，看完以後覺得非常nice（但是回過頭來，自己想個例子寫，就頭疼寫不出來，當然這在後文會說）。nice的原因還是因為，這個模式的確讓代碼的清晰度有了很大的提升。
那麼，提升一般都是對比出來的，回顧下，沒有應用MVP的代碼結構。很多人說明顯是MVC么：
View：對應於布局文件
Model：業務邏輯和實體模型
Controllor：對應於Activity
看起來的確像那麼回事，但是細細的想想這個View對應於布局文件，其實能做的事情特別少，實際上關於該布局文件中的數據綁定的操作，事件處理的代碼都在Activity中，造成了Activity既像View又像Controller（當然了Data-Binder的出現，可能會讓View更像View吧）。這可能也就是為何，在該文中有一句這樣的話：
Most of the modern Android applications just use View-Model architecture，everything is connected with Activity.
而當將架構改為MVP以後，Presenter的出現，將Actvity視為View層，Presenter負責完成View層與Model層的交互。現在是這樣的：
View 對應於Activity，負責View的繪制以及與用戶交互
Model 依然是業務邏輯和實體模型
Presenter 負責完成View於Model間的交互
ok，先簡單了解下，文中會有例子到時候可以直觀的感受下。
㈧ 如何一步一步實現Android的MVP框架
實現Android MVP框架
一個經典的 Android MVC 框架項目的代碼結構
㈨ android 怎麼使用mvvm框架
MVC、MVP、MVVM
首先，我們先大致了解下Android開發中常見的模式。
MVC
View：XML布局文件。
Model：實體模型（數據的獲取、存儲、數據狀態變化）。
Controllor：對應於Activity，處理數據、業務和UI。
從上面這個結構來看，Android本身的設計還是符合MVC架構的，但是Android中純粹作為View的XML視圖功能太弱，我們大量處理View的邏輯只能寫在Activity中，這樣Activity就充當了View和Controller兩個角色，直接導致Activity中的代碼大爆炸。相信大多數Android開發者都遇到過一個Acitivty數以千行的代碼情況吧！所以，更貼切的說法是，這個MVC結構最終其實只是一個Model-View（Activity:View&Controller）的結構。
MVP
View:對應於Activity和XML，負責View的繪制以及與用戶的交互。
Model:依然是實體模型。
Presenter:負責完成View與Model間的交互和業務邏輯。
前面我們說，Activity充當了View和Controller兩個角色，MVP就能很好地解決這個問題，其核心理念是通過一個抽象的View介面（不是真正的View層）將Presenter與真正的View層進行解耦。Persenter持有該View介面，對該介面進行操作，而不是直接操作View層。這樣就可以把視圖操作和業務邏輯解耦，從而讓Activity成為真正的View層。
但MVP也存在一些弊端：
Presenter（以下簡稱P）層與View（以下簡稱V）層是通過介面進行交互的，介面粒度不好控制。粒度太小，就會存在大量介面的情況，使代碼太過碎版化；粒度太大，解耦效果不好。同時對於UI的輸入和數據的變化，需要手動調用V層或者P層相關的介面，相對來說缺乏自動性、監聽性。如果數據的變化能自動響應到UI、UI的輸入能自動更新到數據，那該多好！
MVP是以UI為驅動的模型，更新UI都需要保證能獲取到控制項的引用，同時更新UI的時候要考慮當前是否是UI線程，也要考慮Activity的生命周期（是否已經銷毀等）。
MVP是以UI和事件為驅動的傳統模型，數據都是被動地通過UI控制項做展示，但是由於數據的時變性，我們更希望數據能轉被動為主動，希望數據能更有活性，由數據來驅動UI。
V層與P層還是有一定的耦合度。一旦V層某個UI元素更改，那麼對應的介面就必須得改，數據如何映射到UI上、事件監聽介面這些都需要轉變，牽一發而動全身。如果這一層也能解耦就更好了。
復雜的業務同時也可能會導致P層太大，代碼臃腫的問題依然不能解決。
MVVM
View:對應於Activity和XML，負責View的繪制以及與用戶交互。
Model:實體模型。
ViewModel:負責完成View與Model間的交互，負責業務邏輯。
MVVM的目標和思想與MVP類似，利用數據綁定(Data Binding)、依賴屬性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一個更加靈活高效的架構。
數據驅動
在常規的開發模式中，數據變化需要更新UI的時候，需要先獲取UI控制項的引用，然後再更新UI。獲取用戶的輸入和操作也需要通過UI控制項的引用。在MVVM中，這些都是通過數據驅動來自動完成的，數據變化後會自動更新UI，UI的改變也能自動反饋到數據層，數據成為主導因素。這樣MVVM層在業務邏輯處理中只要關心數據，不需要直接和UI打交道，在業務處理過程中簡單方便很多。
低耦合度
MVVM模式中，數據是獨立於UI的。
數據和業務邏輯處於一個獨立的ViewModel中，ViewModel只需要關注數據和業務邏輯，不需要和UI或者控制項打交道。UI想怎麼處理數據都由UI自己決定，ViewModel不涉及任何和UI相關的事，也不持有UI控制項的引用。即便是控制項改變了（比如：TextView換成EditText），ViewModel也幾乎不需要更改任何代碼。它非常完美的解耦了View層和ViewModel，解決了上面我們所說的MVP的痛點。
更新UI
在MVVM中，數據發生變化後，我們在工作線程直接修改（在數據是線程安全的情況下）ViewModel的數據即可，不用再考慮要切到主線程更新UI了，這些事情相關框架都幫我們做了。
團隊協作
MVVM的分工是非常明顯的，由於View和ViewModel之間是鬆散耦合的：一個是處理業務和數據、一個是專門的UI處理。所以，完全由兩個人分工來做，一個做UI（XML和Activity）一個寫ViewModel，效率更高。
可復用性
一個ViewModel可以復用到多個View中。同樣的一份數據，可以提供給不同的UI去做展示。對於版本迭代中頻繁的UI改動，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二選擇。
單元測試
有些同學一看到單元測試，可能腦袋都大。是啊，寫成一團漿糊的代碼怎麼可能做單元測試？如果你們以代碼太爛無法寫單元測試而逃避，那可真是不好的消息了。這時候，你需要MVVM來拯救。
我們前面說過了，ViewModel層做的事是數據處理和業務邏輯，View層中關注的是UI，兩者完全沒有依賴。不管是UI的單元測試還是業務邏輯的單元測試，都是低耦合的。在MVVM中數據是直接綁定到UI控制項上的（部分數據是可以直接反映出UI上的內容），那麼我們就可以直接通過修改綁定的數據源來間接做一些Android UI上的測試。
通過上面的簡述以及模式的對比，我們可以發現MVVM的優勢還是非常明顯的。雖然目前Android開發中可能真正在使用MVVM的很少，但是值得我們去做一些探討和調研。
如何構建MVVM應用框架
如何分工
構建MVVM框架首先要具體了解各個模塊的分工。接下來我們來講解View、ViewModel、Model它們各自的職責所在。
View
View層做的就是和UI相關的工作，我們只在XML、Activity和Fragment寫View層的代碼，View層不做和業務相關的事，也就是我們在Activity不寫業務邏輯和業務數據相關的代碼，更新UI通過數據綁定實現，盡量在ViewModel裡面做（更新綁定的數據源即可），Activity要做的事就是初始化一些控制項（如控制項的顏色，添加RecyclerView的分割線），View層可以提供更新UI的介面（但是我們更傾向所有的UI元素都是通過數據來驅動更改UI），View層可以處理事件（但是我們更希望UI事件通過Command來綁定）。 簡單地說：View層不做任何業務邏輯、不涉及操作數據、不處理數據，UI和數據嚴格的分開。
ViewModel
ViewModel層做的事情剛好和View層相反，ViewModel只做和業務邏輯和業務數據相關的事，不做任何和UI相關的事情，ViewModel 層不會持有任何控制項的引用，更不會在ViewModel中通過UI控制項的引用去做更新UI的事情。ViewModel就是專注於業務的邏輯處理，做的事情也都只是對數據的操作（這些數據綁定在相應的控制項上會自動去更改UI）。同時DataBinding框架已經支持雙向綁定，讓我們可以通過雙向綁定獲取View層反饋給ViewModel層的數據，並對這些數據上進行操作。關於對UI控制項事件的處理，我們也希望能把這些事件處理綁定到控制項上，並把這些事件的處理統一化，為此我們通過BindingAdapter對一些常用的事件做了封裝，把一個個事件封裝成一個個Command，對於每個事件我們用一個ReplyCommand 去處理就行了，ReplyCommand 會把你可能需要的數據帶給你，這使得我們在Vie，具體見 MVVM Light Toolkit 使用指南的 Command 部分 。再強調一遍：ViewModel 不做和UI相關的事。
㈩ Android MVP 開發模式有哪些優缺點
android MVP開發模式的優點
1）View和Model之間的耦合度降低，使其更關注自身業務邏輯，結構清晰，維護方便；
2）便於單元測試；
3）代碼復用率提高；
4）代碼框架更適用於快速迭代開發；
android MVP開發模式的缺點
任何開發模式都是有利也有弊的，畢竟世間完美的事物還是少見的。上面提到了MVP模式的有點，那就不得不說其還存在的缺點，或者說不足更准確吧。
MVP模式的不足，主要表現在每個view都有presenter ，類相對比較多。