美文网首页Android开发Android技术知识Android开发
Android MVP升级路(三)随心所欲的旗舰版

Android MVP升级路(三)随心所欲的旗舰版

作者: 吴七禁 | 来源:发表于2018-07-25 12:48 被阅读615次

Android MVP升级路系列文章目录:

01 序

  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带给我们的架构思想以及深处的精髓留在心中,将来无论遇到什么框架,对逻辑美的执念会帮助我们走的更远。

相关文章

网友评论

  • 学定饿:感谢
    谁能参悟兮世事如棋:你是不知火舞的弟弟?
  • 咚咚蹡蹡:9.0反射就用不了了:cold_sweat:
    德鲁大叔凯里欧文:可以用啊,官方只是针对源码内部的一些方法,添加hide方法不让你反射sdk内部的方法,我们自己写的可以用反射的
    吴七禁:@咚咚蹡蹡 考虑考虑MVVM吧
  • 谁把我的昵称都占用了:clazz instanceof BaseModel cannot cast Class to BaseModel 这个不能拿转化?
    吴七禁:感谢你的提醒,这个是我的疏忽大意给写错了,clazz已经是Class类型的了,就不能使用instanceof方法判断了,这个判断的主要目的是我们希望传入的class对象是基于BaseModel类的,而我们实例hua对象时加了try...cacth的,所以有没有这个判断不会影响结果,直接把这个判断去掉就行来了,如果坚持要判断的化Class类中有提供可以满足功能的方法。
  • 德鲁大叔凯里欧文:mvvm楼主不妨也写文章分享下吧
    德鲁大叔凯里欧文:@吴七禁 :kissing_heart: 好哒,看了你的文章我现在对mvp应用可是得心应手,感谢哈
    吴七禁:@德鲁大叔凯里欧文 正在写,我写东西比较慢...
    德鲁大叔凯里欧文:先关注一哈,坐等LL更新mvvm的文章
  • Holly_dd20:终于等到
  • zbiext:能和Retrofit、RxJava配合这个Demo吗?
    zbiext:@吴七禁 我的意思是你能,写个吗?😂
    吴七禁:@zbiext 当然可以啊
  • 梦境丶缠绕:作者啥时候写MVVM呢?很期待~
    吴七禁:@梦境丶缠绕 正在写
  • 梦境丶缠绕:虽然,最终版相对于上个版本的内容不多,但还是谢谢作者的讲解,一步一步的封装下来进步了不少
    吴七禁:@梦境丶缠绕 笔芯
  • 92dc7705a802:等待已久,谢谢博主的分享
  • _love_me:如果activity 有多个子Presenter ,getPresenter 这个方法怎么写
    吴七禁:@_love_me 在baseactivity 里并没有设计getPresenter 方法啊
    _love_me:@吴七禁 对啊 在一个activity 我new 多个Presenter 在baseactivity 的getPresenter 这个方法怎么获取这多个Presenter
    吴七禁:presenter都是new出来的,你的意思是说如何获取presenter吗?
  • 骑小猪看流星:用反射真心有点用过了,
    d878c4c94786:类的加载都是反射,咋滴,你要自己整个虚拟机
    100岁的Android工程师:的确,反射本身就不推荐用,用多了性能就低,严重影响面向对象的这种思想。而且有些库中就已经用了反射。如果用了retrofit,里面的动态代理也是反射。那么一个app就太多反射了
    吴七禁:@骑小猪看流星 杠精本人?
  • Active_Loser:等待已久
    吴七禁:谢谢
  • f0a189b84b74:博主 博主 我想问下又没有 源码可以参考的呢
    吴七禁:源码都在文章里了:cry:
  • 沐小晨曦:前排!
    吴七禁:安排

本文标题:Android MVP升级路(三)随心所欲的旗舰版

本文链接:https://www.haomeiwen.com/subject/rabkpxtx.html