Android MVP升级路（三）为所欲为的旗舰版

01 序

1. 第1、二章中有些类的命名存在笔误，目前发现的已纠正。

2. 若是你有把前两篇文章认真的看完，那么你已经基本掌握了MVP架构核心思想，能够在实际开发项目中使用它了。

3. 有很多问我要源码demo的朋友，demo确实有，前面文章之因此没留下源码是由于我更但愿你可以亲手写出来一套属于本身的东西，在这过程当中你能够反复斟酌各层之间的逻辑，包结构以及如何设计父类的通用方法。建议还没手写过的朋友停下来去写一套本身的MVP。

4. 鉴于前面文章已经算是MVP的入门，本文主要聊一些实际使用中架构项目时的思考。

02 Token的有效性

在第二章中咱们利用了相似策略模式的方法对Model层实现了统一管理，利用Token标识不一样的model，但是这样会存在一些隐患。

例如当咱们给一个已经登记在Token中的Model类改了名字，必须同时去Token中更新手动一下对应的字符串。抛开增长维护成本不说，一旦有一个类咱们忘记手动更新，那么它就不能用了。

显然，意识到这个问题后此方法必须马上优化。

放弃Token，直接对类反射

上一章说道，token其实就是描述某个model类“包名+类名”的字符串，有了它咱们就能够获得这个类对应的class对象，从而实例化出对象： model = (BaseModel)Class.forName(token).newInstance(); // 使用token实例化对象

既然token有限制，咱们就直接跳过token解析这一步，直接传递class对象：

public class DataModel {
        public static BaseModel request(Class clazz) {
            // 声明一个空的BaseModel
            BaseModel model = null;
            // 判断class对象是否是BaseModel的实例
            if (clazz instanceof BaseModel) {
                try {
                    //利用反射机制得到对应Model对象的引用
                    model = (BaseModel) clazz.newInstance();
                } catch (ClassNotFoundException e) {
                    e.printStackTrace();
                } catch (InstantiationException e) {
                    e.printStackTrace();
                } catch (IllegalAccessException e) {
                    e.printStackTrace();
                }
            }
            return model;
        }
    }
复制代码

请求数据时直接传递model的class对象便可：

DataModel
                // 设置Model
                .request(UserDataModel.class)
                // 添加请求参数，没有则不添加
                .params(userId)
                // 注册监听回调
                .execute(new UserCallback());
复制代码

到此咱们已经解决了token方法中更新类名须要手动同步的问题，可是还并不完美。假如一个项目中有10处位置调用了同一个model，当这个model类名有变化时这10处均发生了改变，虽然IDE会自动帮咱们修改其余地方，可是终究仍是发生了多余的变化。

理想状态下，咱们但愿不管model被多少处调用，它自身的改变并不会影响其余地方，那要怎么作呢？方法有不少，好比采用Token<Key,Value>方法映射等等，你们一块儿想一想呀欢迎留言~

03 通用的callback

在数据请求中咱们须要在callback的各个回调中分别取处理对应的请求结果，可是你只要写多了就会发现，除了请求成功的回调方法，其余的像请求失败，请求出错这些方法咱们作的事几乎是同样的。

那既然这样，咱们是否是能够构建一个通用的BaseCallback去处理请求的异常状况呢？

04 连接view

在第一章咱们封装了base层后，虽然大大的减小冗余代码，可是在每一个activity咱们都要去手动操做presenter与view的连接与断开操做，这显然不是很美好的。

优化的办法也很简单，咱们都知道每一个activity都继承于BaseActivity，每一个presenter都继承于BasePresenter，因此，咱们只须要在BaseActivity中实现BasePresenter连接view的操做便可。

在BaseActivity中：

public abstract class BaseActivity extends Activity implements BaseView {

    /**
     * 获取Presenter实例，子类实现
     */
    public abstract BasePresenter getPresenter();

    /**
     * 初始化Presenter的实例，子类实现
     */
    public abstract void initPresenter();

    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        initPresenter();
        if (getPresenter() != null){
            getPresenter().attachView();
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (getPresenter() != null){
            getPresenter().detachView();
        }
    }

    // 下面代码省略...
}
复制代码

在具体的Activity中使用：

public class MainActivity extends BaseActivity implements MvpView  {

    // 继承于BasePresenter
    MvpPresenter presenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    }

    @Override
    protected BasePresenter getPresenter() {
        return presenter;
    }

    @Override
    protected void initPresenter() {
        presenter = new MvpPresenter();
    }

    // 下面代码省略...
}
复制代码

在上面的例子中，我为了更直观的展现效果设计了两个抽象方法，分别是初始化和获取presenter，固然其实彻底能够只有一个获取presenter方法就行，看本身喜爱便可。

05 思想

能读到这里的朋友相信都是真爱没错了，不知道朋友你有没有发现不管是前两章讲的那么详细可是没给源码，仍是这章的点到为止，我都是在强调思想要远比代码重要。

其实MVP自己的代码，格式什么的并是不那么重要，重要的它的核心思想，以一种什么样的方式工做的。当你彻底理解了它的思想，你就能够按照本身的喜爱随意优化架构。

06 无奈的没落

回想起大学那会刚接触MVP时真的被惊艳到了，不一样类别的逻辑代码被划分的层次分明，但是随着时间的慢慢推移，MVP的缺陷也愈来愈明显，那就是代码太过冗余，尽管咱们尝试使用各类奇淫巧技来消除样板代码，可仍是不太优雅。

随着近几年MVVM的横空出世，以及Android官方推出的全新架构组件都在标志着MVP已经渐渐远离主流的项目搭建。

说到这里让我不由的想起世界杯解说中的一句话：

人生有多少个十年，能够陪伴一我的的全部高峰与低谷，但是当我站立在人潮中，看千百双手挥舞，却再也看不到你的影踪。

虽然咱们须要更高效更完美的架构，可是更应该把MVP带给咱们的架构思想以及深处的精髓留在心中，未来不管遇到什么框架，对逻辑美的执念会帮助咱们走的更远。