androidmvp架構

⑴ 如何實現自己的Android MVP框架

MVP模式可以分離顯示層和邏輯層，所以功能介面如何工作與功能的展示可以實現分離，MVP模式理想化地可以實現同一份邏輯代碼搭配不同的顯示界面。首先要澄清就是MVP不是一個結構化的模式，它只是負責顯示層而已，任何時候都可以在自己的項目結構中使用MVP模式。

⑵ Android 中 MVC、MVP 和 MVVM 對比

MVC、MVP和MVVM是常見的三種架構設計模式，當前MVP和MVVM的使用相對比較廣泛，當然MVC也並沒有過時之說。

MVC (Model-View-Controller, 模型-視圖-控制器)，標準的MVC是這個樣子的：

簡述：

缺點：

MVP (Model-View-Presenter) 是MVC的演化版本，幾個主要部分如下：

簡述：

解釋：

優點：

缺點：

MVVM 是 Model-View-ViewModel 的簡寫。和 MVP 模式相比，MVVM 模式用 ViewModel 替換了 Presenter ，其他層基本上與 MVP 模式一致，ViewModel 可以理解成 是 View 的數據模型和 Presenter 的合體。MVVM 就是將其中的 View 的狀態和行為抽象化，讓我們將視圖 UI 和業務邏輯分開。

簡述：

缺點:

參考：

⑶ 如何一步一步實現Android的MVP框架

實現Android MVP框架

一個經典的 Android MVC 框架項目的代碼結構

⑷ 如何實現自己的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採用哪種軟體設計模式都是為了達到如下目的，找到合適的加以運用就是最好的：易於維護易於測試松耦合度復用性高健壯穩定------------------------------------------------------------------------------------以上內容均參考互聯網，希望以上知識對您有所幫助，

⑸ 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);

}

⑹ 如何使用MVP架構搭建Android應用程序

Afinal是一個Android的IOC，ORM框架，內置了四大模塊功能：FinalAcitivity, FinalBitmap, FinalDb, FinalHttp。通過FinalActivity，可以通過註解的方式進行綁定UI和事件。通過FinalBitmap，可以方便的載入Bitmap圖片，而無需考慮OOM等問題。通過FinalDB模塊，通過一行代碼就可以對Android的SQlite資料庫進行增刪改查。通過FinalHttp模塊，可以以Ajax形式請求Http數據。

⑺ 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 Architecture（中文官方文檔）——MVVM、DataBinding、Lifecycle、Room、LiveData

官方文檔地址： https://developer.android.google.cn/jetpack/docs/guide

Android Architecture推薦使用MVVM架構：

其中，文檔中特別提到了：

簡單來說， 並不是 說MVVM就是最好的結構，而是好的架構必須滿足以下兩點：

個人理解只是換了種說法，實質上和之前的MVC、MVP架構一樣，最終目標還是為了滿足 程序設計六大原則 。一個好的結構設計，必然是 低耦合、高內聚、易於測試和維護 的。不管是MVC，MVP還是MVVM，其目標都是一致的。

⑼ Android：一個完整app開發流程

可選MVP，MVVM

本app基於mvp架構。除了mvp架構的文件。
還包含下面的文件夾：
ui （下面根據Activity劃分）
widget （自定義dialog等）
base （BaseActivity，BaseFragment）

有側滑欄，tab的一般用fragment

設置sw-360dp,sw-480dp等不同的dimension目錄，根據百分比計算dp值。

bindview使用butterknife，不同組件通信使用EventBus，定時使用RxJava，崩潰收集bugly

按鈕樣式：
使用selector

按鈕背景色，包括顏色和圓角

使用ConstraintLayout，直接使用標注的值來做，最簡單，不要用百分比。使用layout_constraint，layout_margin完成所有布局。

在AndroidStudio直接肉眼布局，Android可以選擇不同的解析度機器，水平或者垂直進行預覽

配置sdk版本
配置abi

使用藍湖進行圖片的協助。提供m,h,x,xx等不同解析度的圖片

⑽ Android MVP架構思想和實現

MVP Demo地址戳這里👇