Android MVP升级路(二)时尚版

前言

第一篇文章的结尾对时尚版MVP结构做了一个简单的预告,下面继续从时尚版MVP说起。

时尚版MVP架构-Model层的优化

在从乞丐版MVP架构优化成平民版MVP架构的过程中,几乎每个单元都做了很大优化并封装到了base层,但是唯独Model层没什么变化。所以,时尚版MVP架构的优化主要就是对Model层的优化。

单独封装,集中管理

Model层相比其他单元来说比较特殊,因为它们更像一个整体,只是单纯的帮上层拿数据而已。再就是MVP的理念是让业务逻辑互相独立,这就导致每个的网络请求也被独立成了单个Model,这种方式在实际开发中就会出现一些问题:

  • 无法对所有Model统一管理。
  • 每个Model对外提供的获取数据方法不一样,上层请求数据没有规范。
  • 代码冗余高,网络数据请求除URL和参数外其他大概都一样的。
  • 对已存在的Model管理困难,不能直观的统计已存在的Model。

所以我们更希望Model层是一个庞大且独立单一模块,请求方式规范化,管理Model更加直观。

时尚版MVP架构Model层结构

如上图所示,时尚版MVP架构的Model层中,Presenter 请求数据不再直接调用具体的Model对象,统一以 DataModel 类作为数据请求层的入口,以常量类 Token 区别具体请求。 DataModel会根据Token的不同拉取底层对应的具体Model。

优化之后的Model层是一个庞大而且独立的模块,对外提供统一的请求数据方法与请求规则,这样做的好处有很多:

  • 数据请求单独编写,无需配合上层界面测试。
  • 统一管理,修改方便。
  • 利用Token类可以直观的统计出已存在的请求接口。

代码实现

根据上节结构图中的描述在考虑到实际情况,我们需要设计以下几个类:

  • DataModel: 数据层顶级入口,项目中所有数据都由该类流入和流出,负责分发所有的请求数据。
  • Token:数据请求标识类,定义了项目中所有的数据请求。
  • BaseModel:所有Model的顶级父类,负责对外提供数据请求标准,对内为所有Model提供请求的底层支持。

最后实现后理想的请求数据方法是:

BaseModel

BaseModel中定义了对外的请求数据规则,包括设置参数的方法和设置Callback的方法,还可以定义一些通用的数据请求方法,比如说网络请求的Get和Post方法。

public abstract class BaseModel<T>  {

    //数据请求参数
    protected String[] mParams;

    /**
     * 设置数据请求参数
     * @param args 参数数组
     */
    public  BaseModel params(String... args){
        mParams = args;
        return this;
    }

    // 添加Callback并执行数据请求
    // 具体的数据请求由子类实现
    public abstract void execute(Callback<T> callback);

    // 执行Get网络请求,此类看需求由自己选择写与不写
    protected void requestGetAPI(String url,Callback<T> callback){
        //这里写具体的网络请求
    }

    // 执行Post网络请求,此类看需求由自己选择写与不写
    protected void requestPostAPI(String url, Map params,Callback<T> callback){
        //这里写具体的网络请求
    }

}

写好了BaseModel后再看实现具体Model的方法:

public class UserDataModel extends BaseModel<String> {

    @Override
    public void execute(final Callback<String> callback) {

        // 模拟网络请求耗时操作
        new Handler().postDelayed(new Runnable() {
            @Override
            public void run() {
                // mParams 是从父类得到的请求参数
                switch (mParams[0]){
                    case "normal":
                        callback.onSuccess("根据参数"+mParams[0]+"的请求网络数据成功");
                        break;

                    case "failure":
                        callback.onFailure("请求失败:参数有误");
                        break;

                    case "error":
                        callback.onError();
                        break;
                }
                callback.onComplete();
            }
        },2000);
    }
}

从上面代码段可以看出,实现具体的Model请求时必须要重写BaseModel的抽象方法execute

DataModel

由于DataModel负责数据请求的分发,所以最初打算作成一个简单工厂模式的样子,通过switch(token)语句判断要调用的Model。

但如果这样设计的话,在实际开发中我们每次添加一个数据请求接口,不光需要新建对应的Model和Token,还需要在DataModel类的switch(token)语句中新增加对应的判断,贼麻烦~

思来想去,我觉得利用反射机制会是一个比较理想的办法,请求数据时以具体Model的包名+类型作为Token,利用反射机制直接找到对应的Model。

public class DataModel {

    public static BaseModel request(String token){

        // 声明一个空的BaseModel
        BaseModel model = null;

        try {
            //利用反射机制获得对应Model对象的引用
            model = (BaseModel)Class.forName(token).newInstance();
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        return model;
    }

}

Token

由于上节中DataModel使用反射机制获取对应Model的引用,所以Token中存的就应该是对应Model的包名+类名:

public class Token {
    // 包名
    private static final String PACKAGE_NAME = "com.jesse.mvp.data.model.";
    // 具体Model
    public static final String API_USER_DATA = PACKAGE_NAME + "UserDataModel"; 
}

使用方式

完成了Model层之后再去Presenter调用数据时的样子就舒服多了:

 DataModel
    // 设置请求标识token
    .request(Token.API_USER_DATA)
    // 添加请求参数,没有则不添加
    .params(userId)
    // 注册监听回调
    .execute(new Callback<String>() {

           @Override
           public void onSuccess(String data) {
               //调用view接口显示数据
               mView.showData(data);
           }

           @Override
           public void onFailure(String msg) {
               //调用view接口提示失败信息
               mView.showFailureMessage(msg);
           }

           @Override
           public void onError() {
               //调用view接口提示请求异常
               mView.showErrorMessage();
           }

           @Override
           public void onComplete() {
               // 隐藏正在加载进度条
               mView.hideLoading();
           }
 });

添加model步骤

  1. 新建一个Model并继承BaseModel,完成具体的数据请求。
  2. 在Token中添加对用的Model包名+类名。注意写好注释,方便以后查阅。

总结

经过优化的Model层很好的统一化了请求方法规范,利用BaseModel不仅有效的减少了数据请求的冗余代码,最关键的还是得到了将所有Model的集中控制权,例如我们想给所有的请求都加上coockies,直接在BaseModel层做处理即可。

时尚版MVP虽然只对Model层进行了优化,实际开发中已经能发挥很大的作用。

下面一章旗舰版将三层同时优化。

原文发布于微信公众号 - 我就是马云飞(coding_ma)

原文发表时间:2017-11-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程思想之路

WiFiAp探究实录--功能实现与源码分析

Android虐我千百遍,我待Android如初恋。 ——————编辑于2017-08-02——————— wifi热点说的是wifiAp相...

1.7K90
来自专栏orientlu

FreeRTOS 软定时器实现

考虑平台硬件定时器个数限制的, FreeRTOS 通过一个 Daemon 任务(启动调度器时自动创建)管理软定时器, 满足用户定时需求. Daemon 任务会在...

20120
来自专栏蓝天

Linux系统面面观 PROC文件系统详细介绍

什么是proc文件系统? proc文件系统是一个伪文件系统,它只存在内存当中,而不占用外存空间。它以文件系统的方式为访问系统内核数据的操作提供接口。用户和应用...

12720
来自专栏潇涧技术专栏

Art of Android Development Reading Notes 13

《Android开发艺术探索》读书笔记 (13) 第13章 综合技术、第14章 JNI和NDK编程、第15章 Android性能优化

10120
来自专栏编程札记

深入golang之---goroutine并发控制与通信

本文章通过goroutine同步与通信的一个典型场景-通知子goroutine退出运行,来深入讲解下golang的控制并发。

1.3K70
来自专栏JetpropelledSnake

HCNP学习笔记之子网掩码的计算和划分详细

TCP/IP网间网技术产生于大型主流机环境中,它能发展到今天的规模是当初的设计者们始料未及的。网间网规模的迅速扩展对IP地址模式的威胁并不是它不能保证主机地址的...

9810
来自专栏Google Dart

Flutter 构建完整应用手册-持久化

如果我们有一小部分我们想要保存的键值,我们可以使用shared_preferences插件。

21820
来自专栏everhad

App开发:模拟服务器数据接口 - MockApi

为了方便app开发过程中,不受服务器接口的限制,便于客户端功能的快速测试,可以在客户端实现一个模拟服务器数据接口的MockApi模块。本篇文章就尝试为使用gra...

58080
来自专栏影子

开始食用grpc(之一)

转载请注明出处:https://www.cnblogs.com/funnyzpc/p/9501353.html

31920
来自专栏北京马哥教育

MongoDB多纬度监控方法详解

一、mongostat工具方法 mongostat是mongdb自带的状态检测工具,在命令行下使用。它会间隔固定时间获取mongodb的当前运行状态,并输出。如...

48150

扫码关注云+社区

领取腾讯云代金券