前言
MVP模式是Android官方推荐的架构模式，可使视图与数据层完全解耦。本文旨意封装在MVP模式中的基类如Activity，Fragment，Presenter类。
以下内容建议在了解了mvp模式的读者阅读，如果还有对mvp架构模式有疑问的，请看我的另外一篇文章《Android MVP架构模式初窥门径》
为什么需要封装？
-
减少类似代码，使父子类代码结构优雅。
app中普遍有设计BaseActivity，BaseFragment基类，将mvp中view层的类似代码也抽取到其当中，无疑是更好的选择。 -
优化代码编写步骤。
完成封装之后，得首先编写Model类，其次Presenter类，最后才是View类，符合“从数据下手”思想，在编写View类时不会有无从下手的错觉。
说完了基类封装mvp模式的优点，下面开始我们来看看代码中是如何实现的。
- BaseModel
由于model层大多是数据跟业务逻辑处理，个个model接口与实现类可以说是层出不穷，下面只抽取大部分model类都会遇到的场景，即访问网络的失败回调。
public interface BaseModel{
void onFailed(String error);
}
- BaseView
BaseView相对来说更加灵活，一千个读者心里有一千个BaseView。所以下面只给出参考案例。
public interface BaseView{
void onLoaded();
void onLoading();
void onLoadFailed(String error);
}
- BasePresenter
在presenter层中，我们一般要从外获取对应view层以及model层的实例，从而在该类中进行各种操作，为了追求更直接，省去转型的封装方式，我们使用泛型来规定BasePresenter中的view及model实例字段。
public abstract class BasePresenter<T,E>{
public T mModel;
public E mView;
public void setVM(T t,E e){
this.mModel = t;
this.mView = e;
}
}
- BaseActivity / BaseFragment
在视图层中我们不难发现，在该模式下的activity/fragment中都会有对应presenter的引用，通过该引用设置view层接口。这一块转个方向也是可以抽取封装的，同样用泛型代替。
public abstract class BaseActivity< T extends BasePresenter, E extends BaseModel> extends Activity {
public T mPresenter;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(getLayoutId());
this.initPresenter();
this.initView();
}
public abstract void initPresenter();
public abstract void initView();
public abstract int getLayoutId();
}
public abstract class BaseFragment< T extends BasePresenter, E extends BaseModel> extends Fragment{
public T mPresenter;
public View mView;
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
super.onCreate(inflater,container,savedInstanceState);
mView = inflater.inflate(getLayoutResource(), container, false);
mPresenter = TUtil.getT(this, 0);
this.initPresenter();
this.initView();
return mView;
}
public abstract void initPresenter();
public abstract void initView();
public abstract int getLayoutResource();
}
为了子类能够灵活的使用或不使用mvp模式，presenter引用的初始化交给需要设计成mvp模式的部分子类（第二个this指实现了BaseView接口）去处理：
...
@Override
public void initPresenter(){
//需要设计成mvp直接加下句代码 不需要则不理会
mPresenter.setVM(TUtil.getT(this,1),this);
}
...
我想读者看到这里肯定在想这个神秘的TUtil是什么呢？其实就是基于反射+泛型的类转换类，拿到最外层的<>里的参数数组然后根据索引获取实例的工具类。
/**
* 类转换初始化
*/
public class TUtil {
public static <T> T getT(Object o, int i) {
try {
return ((Class<T>) ((ParameterizedType) (o.getClass()
.getGenericSuperclass())).getActualTypeArguments()[i])
.newInstance();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (ClassCastException e) {
e.printStackTrace();
}
return null;
}
}
总结
通过对mvp模式基类的封装，加上契约类的管理，可以使项目整体框架代码结构优雅，页面各层设计一目了然。（对契约类不是很了解的，可以看我的另一篇文章：《Android MVP架构模式初窥门径》）
以上就是本人对mvp基类封装的理解与思考，如果觉得我写的不错的，点个喜欢吧！
