前言
在暑假的时候学习了一遍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 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 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 {
@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 getVuClass() {
return LoginActivityViewImpl.class;
}
}
这个就是presenter。看到我在对应的生命周期里面做了逻辑处理,并且返回他对应的view类文件。
结束语
MVP模式确实给项目维护带来了一些便捷,但是也发现,相对于小的项目会导致你的代码量迅速膨胀。所有很多人弄一些mvp的开发框架。确实我自己也想用这种新思路来倒腾一个。但是对于大型项目,这样的代码膨胀并不算什么,带来的好处绝对优于坏处。这次学习又巩固了一下我的设计模式。以一句话结尾:面对接口编程, 避免面对实现编程
未经博主同意,不得转载该篇文章