所谓 MVP(Model-View-Presenter) 模式。是将 APP 的结构分为三层:
view - UI显示层
view 层主要负责:
- 提供 UI 交互
- 在 presenter 的控制下修改UI。
- 将业务事件交由 presenter 处理。
注意:View 层不存储数据,不与 Model 层交互。
presenter - 逻辑处理层
presenter 层主要负责:
- 对 UI 的各种业务事件进行相应处理。也许是与 Model 层交互,也许自己进行一些计算,也许控制后台 Task,Servic 对各种订阅事件进行响应,修改 UI。
- 临时存储页面相关数据。
注意. Presenter 内不出现 View 引用。
model - 数据层
model 层主要负责:
- 从网络,数据库,文件,传感器,第三方等数据源读写数据。
- 对外部的数据类型进行解析转换为 APP 内部数据交由上层处理。
- 对数据的临时存储,管理,协调上层数据请求。
如图示,里面的 activity,presenter,model 均为例子:
将复杂的功能分割为各层内的小问题。各层内功能单一。这样易于功能修改拓展与 Debug。
解耦的设计,独立的模块,更有利于分工开发与测试。
Activity 的异常重启
Activity 会在少数情况下被系统重启:
- 当用户旋转屏幕
- 在后台时内存不足
- 改变语言设置
- attache 一个外部显示器等。
正确的方式应该是:
Presenter 与 Activity 的绑定关系应由静态类管理。而不是由Activity管理。当 Activity 意外重启时 Presenter 不应重启。Activity 重启时,Presenter 与 Activity 重新绑定,根据数据恢复 Activity 状态。
而当 Activity 真正销毁时。对应 Presenter 才应该跟随销毁。
当内存不足时,Activity 被销毁其实是整个进程被销毁。所以 Presenter 也无能为力。还原时需要重建 Presenter。
生命周期
Activity 是一个上帝类,其实不适合作为 View。所以有些 MVP 方案将Activity 作为 Presenter。最主要在于他的生命周期牵扯太多逻辑处理业务。这些由 Presenter 负责的话情况可以改善很多。我建议将在顶级父类中将 activity 的生命周期在 Presenter 中实现一遍,然后生命周期有关的业务逻辑直接由 Presenter 来实现。
Model 的初始化
Model 不仅仅是 javabean。Model 是负责提供各类数据模型。在此基础上我将 Model 拓展为数据层提供数据交互。将 javabean 单独为数据层的一部分。
Model 层的各个 Model 一般使用单例。这样的好处在于这个唯一对象可以管理一些数据供所有上层使用。
Model 的单例对象
public class UserModel extends AbsModel{
public static UserModel getInstance() {
return getInstance(UserModel.class);
}
@Override
protected void onAppCreate(Context ctx) {
super.onAppCreate(ctx);
//初始化
}
public void login(String number,String password,DataCallback<UserDetail> callback){
//进行登录请求与回调,并保存返回账号
}
public void register(String tel,String password,String code,int gender,String nickname,StatusCallback callback){
//进行注册请求与回调
}
public void findPassword(String number,String code,String password,DataCallback<User> callback){
//进行找回密码请求与回调
}
public void certification(String number,String school,String realName,String stuCard,DataCallback<User> callback){
//进行认证请求与回调
}
public void LoginOut(){
//登出操作
}
}
既然 Model 层管理数据,并且是单例。他就有初始化的需求,比如在 APP 启动时就请求数据,记录信息,开始一个后台线程与服务器同步信息等。这些操作与 Presenter 无关。是数据层自发的的功能。所以需要在 Application 启动时进行 Model 的初始化。
但又要注意不能在 Application 的 onCreate() 进行过多操作,否则会启动时间过长。所以可考虑在启动时创建一个后台线程,将即时性不强的初始化操作放到后台线程。
Adapter 的处理
对于 Adapter 是放在 View 好还是 Presenter 好,这个问题确实难以解决。但在使用解耦的 ViewHolder 后这个问题便很明了。视图的创建与改变全由 ViewHolder 管理。然后 Adapter 仅仅处理面向ViewHolder的逻辑。
然后 ViewHolder 属于View,Adapter 属于 Presenter。参考 EasyRecyclerView
Adapter
public class PersonAdapter extends RecyclerArrayAdapter<Person> {
public PersonAdapter(Context context) {
super(context);
}
@Override
public BaseViewHolder OnCreateViewHolder(ViewGroup parent, int viewType) {
return new PersonViewHolder(parent);
}
}
ViewHolder
public class PersonViewHolder extends BaseViewHolder<Person> {
private TextView mTv_name;
private SimpleDraweeView mImg_face;
private TextView mTv_sign;
public PersonViewHolder(ViewGroup parent) {
super(parent,R.layout.item_person);
mTv_name = $(R.id.person_name);
mTv_sign = $(R.id.person_sign);
mImg_face = $(R.id.person_face);
}
@Override
public void setData(final Person person){
mTv_name.setText(person.getName());
mTv_sign.setText(person.getSign());
mImg_face.setImageURI(Uri.parse(person.getFace()));
}
}
Rx的参与
Rx 订阅发布模式在 MVP 中作用很大。可以极大简化层间通讯的处理。 View 向 Presenter 订阅数据。Presente r可以向 Model 层订阅数据。形成一个数据链。数据可以直接链式到达 View 层。优雅易拓展。
Presenter
public class QuestionShowPresenter extends BeamDataActivityPresenter<QuestionShowActivity,Question> {
@Override
protected void onCreate(QuestionShowActivity view, Bundle savedState) {
super.onCreate(view, savedState);
QuestionModel.getInstance().getQuestion(1).subscribe(this);
}
}
View
public class QuestionShowActivity extends BeamDataActivity<QuestionShowPresenter,Question> {
@Override
public void setData(Question data) {
//显示数据
}
@Override
public void setError(Throwable e) {
//显示错误
}
}
Beam
Beam是我做的一套基于MVP模式的快速开发框架。参考了nucleus。上面的示例代码都是使用了这个(为方便复制的这个框架demo代码.= =)。定义了一套开发规范。并提供了基于这套规范的Activity,Fragment,Presenter,Model等父类及控件和API等,完成APP开发过程中大量繁琐工作。并进行了一系列优化。详情看这里
示例:逗逼
注: 本文转自 jude95 的简书。
原文链接 Android应用中MVP最佳实践