首先讲框架之前,要问自己一个问题,为什么要用到框架?框架的使用能给自己的开发带来什么好处?
在撰写代码时,会发现随着代码越来越多,理清代码的逻辑越来越困难,且想尽可能的少些Activity。且随着迭代轮次的增多,功能也会随之增删,这时候如果没有一个好的架构,在迭代过程中程序将会被破坏,工作展开极其困难。
MVP框架又是什么?
在撰写代码时,要避免创建神类。即避免创建无所不知,无所不能的上帝类。如果一个类需要花费时间从其他类中通过Get()和Set()检索数据(也就是说,需要深入业务并且告诉它们如何去做),所以是否应该把这些功能函数更好的组织到其它类而不是上帝类中。Activity就是上帝类,随着Activity代码量随时间不断增加,最后会成为一个无法重用的组件的集合。上帝类的维护成本很高,很难理解正在进行的操作,并且难以测试和扩展。
Activity中同时存在业务逻辑和UI逻辑,不仅造成Activity臃肿,且导致数据绑定等操作变得复杂,所以我们首先要解决的一个问题就是分离关注点,而MVP架构正是个中翘楚。
MVP模式将Activity中的业务逻辑和UI逻辑分离开来,让Activity只做UI逻辑的处理,其他业务逻辑由Presenter层处理,这带来了如下优点:
MVP代表Model
,View
和Presenter
View层:负责处理用户事件和视图部分的展示,即显示数据的地方。得到数据后,数据传递到view层,显示数据。同时view层的点击事件等处理也在这里出现,真正的数据处理在model层中处理。在Android中,它可能是Activity或者Fragment类。
Model层:
负责访问数据,即单纯的处理数据,不接手其他任务。数据可以是远端的Server API,本地数据库或者SharedPreference等。
Presenter层:
是连接(或适配)View和Model的桥梁。M层获得数据后交给P层,P层再交给View层。同理,View层的点击事件等处理通过P层去通知M层,让其进行数据处理。
在MVP中,View和Presenter是一一对应的(MVVM是一对多的)
MVP分离了view和model层,Presenter层充当了桥梁的角色,View层只负责更新界面即可,这里的View我们要明白只是一个viewinterface,它是视图的接口,这样我们在做单元测试的时候可以非常方便编写Presenter层代码
三层之间的调用顺序为view->presenter->model不可反向调用!不可跨级调用!
model层如何反馈给Presenter层?Presenter如何操控View层?如下图所示
底层不会直接给上一层做反馈,而是通过View,Callback为上级做出了反馈,这样就解决了请求数据与更新界面的异步操作。图中View和Callback都是以接口的形式存在。
View中定义了Activity的具体操作,主要将请求到的数据在界面中更新之类
Callback中定义了请求数据是反馈的各种状态:成功,失败,异常等
base
:存放app的基类common
:存放异常常量,接口,公用的东西bean
:用来存放定义的数据contract
:连接V层和P层的一个契约包parser
:存放一些json等字符串的解析presenter
:P层,负责连接V层和M层,中心管理器。ui
:这个包下面主要存放一下跟UI相关的部分
activity
:存放Activity类fragment
:存放Fragment类adapter
:适配器类utils
:存放工具类widget
:存放自定义的一些组件MVP架构的中心思想是面向接口编程,调用层使用接口对象,去调用接口方法,实现层去实现接口方法,并在调用层实例化。
在MVP架构中:我们要把MVP层的接口方法抽象出来,同时分别写出三个接口的实现类(V层一般是activity或者fragment继承view层接口),其中V层持有P层的接口对象,P层持有V层与M层的接口对象,M层为P层提供数据。三者之间形成了MVP架构,三者之间通过P层相互连接。
这里我们先实现一个简单的MVP架构
interface View {
//显示数据
void showData(String str);
}
interface Presenter {
//通知model要获取数据并把model返回的数据交给view层
void getData();
}
interface Model {
//获取数据
String doData();
}
public class TestPresenter implements TestContract.Presenter {
private TestContract.Model model; //持有M层接口对象
private TestContract.View view; // 持有V层接口对象
public TestPresenter (TestContract.Model model, TestContract.View view) {
this.model = model;
this.view = view;
}
@Override
public void getData() {
view.showData(model.doData());
}
}
public class TestModel implements TestContract.Model {
private static TestModel model = new TestModel();
public static TestModel getInstance() {
if (model== null) {
model= new TestModel ();
}
return model;
}
@Override
public String doData() {
return "mvp架构";
}
}
public class TestActivity extends AppCompatActivity implements TestContract.View {
private TestContract.Presenter mPresenter;
private TextView mDownload;
private TextView mShowData;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mPresenter = new TestPresenter(TestModel.getInstance(),this);
mDownload = (TextView) findViewById(R.id.download_data);
mShowData = (TextView) findViewById(R.id.show_text);
mDownload.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
mPresenter.getData();
}
});
}
@Override
public void showData(String str) {
mShowData.setText("幺幺最爱宝宝");
}
}
这里就实现了一个简易的MVP架构,三层之间的调用顺序为view->presenter->model
前述的MVP模式会存在一些问题,其代码冗余量大,且存在内存泄漏的问题,应用请求网络数据时需要等待后台反馈数据后更新界面,但是请求过程中Activity因为某种原因被销毁了,Presenter收到后台反馈并调用View接口处理UI逻辑时,因为Activity已经被销毁了,就会引发空指针异常。
解决这个方法,我们可以将P层与V层绑定起来,每次调用View前都知道宿主Activity的生命状态
public interface TestContract {
interface View {
//显示数据
void showData(String str);
}
interface Presenter {
//通知model要获取数据并把model返回的数据交给view层
void getData();
void detach(); //与view解绑
}
interface Model {
//获取数据
String doData();
}
}
public class TestPresenter implements TestContract.Presenter {
private TestContract.Model model;
private TestContract.View view;
public TestPresenter (TestContract.Model model, TestContract.View view) {
this.model = model;
this.view = view;
}
@Override
public void getData() {
if (isViewExist(view)) {
view.showData(model.doData());
}
}
@Override
public void detach() {
view = null;
}
//判断View是否被销毁
private boolean isViewExist(TestContract.View view) {
return view != null;
}
}
@Override
protected void onDestroy() {
super.onDestroy();
mPresenter.detach();
}
这样子我们就解决了内存泄漏的问题。这种情况下的MVP模式基本上是比较完整的,但是还是不够好。应用中肯定不只一个模块,每个模块都对应着一个V层和P层,这样每个Presenter中都要定义绑定解绑方法,造成代码冗余。因此我们可以抽取一个基类来做这些事情,这就引申出了我们的小康版MVP模式
public interface BaseView {
}
public class BasePresenter<T extends BaseView> {
// V层的引用
protected T mView;
public BasePresenter(T t) {
this.mView = t;
}
/**
* 判断是否与View建立连接
*/
public boolean isViewAttached() {
return mView!= null;
}
/**
* 销毁View 避免P层在View销毁的时候还持有View对象
*/
public void destroy() {
mView = null;
}
}
/**
* 数据详情获取
*/
public interface DownloadDataContract {
interface View extends BaseView {
void hideLoading(); // 隐藏正在加载的进度框
void showData(String data); // 数据请求成功,调用此接口显示数据
void showFailureMessage(String msg); // 数据请求失败,提示失败原因
void showErrorMessage(); // 数据请求异常,提示异常原因
}
abstract class Presenter extends BasePresenter<View> {
public Presenter(View view) {
super(view);
}
public abstract void onSuccess(String data); // 数据请求成功
public abstract void onFailure(String msg); // 数据请求失败
public abstract void onError(); // 数据请求错误
public abstract void onComplete(); // 数据请求结束
}
}
public class DownLoadDataPresenter extends DownloadDataContract.Presenter {
public DownLoadDataPresenter(DownloadDataContract.View view) {
super(view);
}
@Override
public void onSuccess(String data) {
if (isViewAttached()) {
mView.showData(data);
}
}
@Override
public void onFailure(String msg) {
if (isViewAttached()) {
mView.showFailureMessage(msg);
}
}
@Override
public void onError() {
if (isViewAttached()) {
mView.showErrorMessage();
}
}
@Override
public void onComplete() {
if (isViewAttached()) {
mView.hideLoading();
}
}
}
public class MainActivity extends AppCompatActivity implements DownloadDataContract.View {
private DownLoadDataPresenter mDownloadDataPresenter;
private TextView mDownloadDataTv;
private TextView mShowDataTv;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mDownloadDataTv = (TextView) findViewById(R.id.download_data);
mShowDataTv = (TextView) findViewById(R.id.show_text);
mDownloadDataPresenter = new DownLoadDataPresenter(this);
mDownloadDataTv.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
mDownloadDataPresenter.onSuccess("you are the best");
}
});
}
@Override
public void hideLoading() {
}
@Override
public void showData(String data) {
mShowDataTv.setText(data);
}
@Override
public void showFailureMessage(String msg) {
}
@Override
public void showErrorMessage() {
}
}
一般情况下,对于大多数项目来说,小康版的MVP模式都可以很好的处理遇到的问题,且代码结构和复用性良好,当然了,这里还有一些不完美的地方可以优化,这里就可以引申出我们的富豪版MVP模式。
对于富豪版的MVP模式,主要的实现方式,是高级抽象-使用注解,工厂模式,代理模式,策略模式整体解决代码冗余,内存泄露、Presneter生命周期以及数据存储问题。
关于顶级富豪版的MVP模式待更新。。。。。