前言
在暑假的时候学习了一遍mvp开发模式在android中的运用。那个时候学的时候确实觉得mvp模式做安卓开发特别清晰，代码模块分的特别清楚。但是在自己写demo的时候还是把自己有点绕晕了。因为mvp模式运用了大量的接口（面向接口编程）来实现view和model层的解耦。那时候甚至连设计模式都没看，所以一下子接触这种抽象的设计模式有点不适应。虽然说google的data-binding的不断完善会导致安卓上面mvvm模式越来越火，但是我觉得设计模式嘛，学习一下没有坏处，可以提升自己的理解力。这篇博客主要讲一种mvp的一种新尝试（将activity, fragment, adapter作为presenter）。
MVP
mvp模式与mvc模式最大的差别就是，它将view层跟model实现完全解耦。所有的数据交互都在presenter层中。view,model和presenter的交互通过接口，view和model的交互通过presenter。解耦的好处就是视图层和数据层两者互不影响，所有的逻辑都在presenter中，他作为一个中间层可以给多个view来使用。完全通过接口来解耦可以提高代码维护度。
而mvc模式则是视图层可以通过control与数据层交互也可以直接跳过control和数据层直接交互。这样大多数时候会在view层里面new出model／bean的对象来。这样就把两者耦合在了一起。
传统mvp
传统的mvp模式是将activity或者fragment作为view层，将所有的逻辑代码抽出到presenter（一个java类）。这是我暑假写的一个demo源码 传统mvp demo 。
可以通过我的项目分包看出来，每一个类实现接口，通过接口来进行抽象解耦，以及数据交互。
一种新思想
这个思想也是通过github上面一个翻译的文章看来的。因为activity中包含着context， intent，获得系统服务等等，如果把activity作为视图层就应该避免这些业务逻辑。所以将activity仅仅作为视图层有点发挥不出他的真正价值。所以我们考虑把activity，fragment，adapter来作为presenter处理逻辑，用java类文件来作为视图层。并且这样做了之后，我感觉代码的清晰度是有提升的。这是我写的demo源码：新mvp demo 。
大概思路是用一个抽象类来抽出activity中必不可少的ui代码（比如setContentView()以及初始化各种控件）。然后每一个view类文件实现扩展了view层基接口的接口，这样做的目的是为了实现view和baseacitivty之间的解耦。（这个确实倒腾了很久，因为我感觉原文章的代码有问题）。之后在抽象类里面去通过presenter返回的view文件类型，用反射获得对象并进行view的渲染。然后再在presenter中去处理逻辑。看代码吧！
/**
* Created by Zane on 15/12/5.
* 用于抽出activity中对于ui的操作代码
* 弄出两个抽象方法来保证生命周期同步
*/
public abstract class BasePresentActivity<X extends V, V extends Vu> extends AppCompatActivity{
protected V vu;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
try {
vu = getVuClass().newInstance();
vu.init(getLayoutInflater(), null);
setContentView(vu.getView());
onBindVu();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
@Override
protected void onDestroy() {
onDestroyVu();
vu = null;
super.onDestroy();
}
protected abstract Class<X> getVuClass();
protected void onBindVu(){};
protected void onDestroyVu() {};
}
首先解释这个抽象类的两个泛型。Vu是view层的基接口，代码如下:
/**
* Created by Zane on 15/12/5.
* view类的超类
*/
public interface Vu {
void init(LayoutInflater inflater, ViewGroup container);
View getView();
}
可以看到有两个方法，一个用来进行view渲染，一个是返回根视图。而泛型里面的V就是扩展了Vu的第二层接口。最后X就是实现了第二层接口的view类文件。这样做的目的就是做到解耦，防止我用传入的类文件去实例化类文件，这里应该是去实例化接口。（用X的对象去实例化V）
然后再看onBindVu()和onDestoryVu()方法，这个方法是在继承了这个抽象类的presenter里面去实现的，目的是为了达到生命周期同步。
getVuClass()方法就是要获得这个presenter对应的view类文件类型。
/**
* Created by Zane on 15/12/5.
* 为了使view类和present类解藕
*/
public interface VuLoginActivity extends Vu{
Button getButtonLogin();
Button getButtonClear();
EditText getEditTextAccount();
EditText getEditTextPassword();
void clearText();
}
这就是扩展了Vu接口的第二层接口。看到我添加了几个方法。
/**
* Created by Zane on 15/12/5.
*/
public class LoginActivityViewImpl implements VuLoginActivity{
protected View view;
protected Button buttonLogin;
protected Button buttonClear;
protected EditText account;
protected EditText password;
@Override
public void init(LayoutInflater inflater, ViewGroup container) {
view = inflater.inflate(R.layout.activity_main, container, false);
buttonLogin = (Button)view.findViewById(R.id.button_login);
buttonClear = (Button)view.findViewById(R.id.button_clear);
account = (EditText)view.findViewById(R.id.account);
password = (EditText)view.findViewById(R.id.password);
}
@Override
public View getView() {
return view;
}
@Override
public Button getButtonLogin() {
return buttonLogin;
}
@Override
public Button getButtonClear() {
return buttonClear;
}
@Override
public EditText getEditTextAccount() {
return account;
}
@Override
public EditText getEditTextPassword() {
return password;
}
@Override
public void clearText() {
account.setText("");
password.setText("");
}
}
这里代码也很简单啦！
public class MainActivity extends BasePresentActivity<LoginActivityViewImpl, VuLoginActivity> {
@Override
protected void onBindVu() {
final User user = new User();
vu.getButtonLogin().setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
String userName = vu.getEditTextAccount().getText().toString();
String password = vu.getEditTextPassword().getText().toString();
Toast.makeText(MainActivity.this, userName, Toast.LENGTH_SHORT).show();
if(userName.equals(user.getUserName()) && password.equals(user.getPassword())) {
Intent intent = new Intent(MainActivity.this, LoginSuccessActivity.class);
intent.putExtra("username", userName);
startActivity(intent);
}else {
Toast.makeText(MainActivity.this, "错误", Toast.LENGTH_SHORT).show();
}
}
});
vu.getButtonClear().setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
vu.clearText();
}
});
}
@Override
protected void onDestroyVu() {
super.onDestroyVu();
}
@Override
protected Class<LoginActivityViewImpl> getVuClass() {
return LoginActivityViewImpl.class;
}
}
这个就是presenter。看到我在对应的生命周期里面做了逻辑处理，并且返回他对应的view类文件。
结束语
MVP模式确实给项目维护带来了一些便捷，但是也发现，相对于小的项目会导致你的代码量迅速膨胀。所有很多人弄一些mvp的开发框架。确实我自己也想用这种新思路来倒腾一个。但是对于大型项目，这样的代码膨胀并不算什么，带来的好处绝对优于坏处。这次学习又巩固了一下我的设计模式。以一句话结尾：面对接口编程， 避免面对实现编程
未经博主同意，不得转载该篇文章
