封装网络框架时,如何优雅的传参?

前言

我相信大家对于网络框架的使用选择已经是驾轻就熟了。OKhttp,Retrofit,Volley,NoHttp等等网上一系列优秀的框架,这里不讨论网络框架的选择,另外对于网络框架进行二次封装也基本上是信手拈来的事,所以这里也不加讨论。本文只介绍如何优雅的传参。


对于网络框架传参,我想大部分人都会有三种做法:

  1. 直接通过方法将所有参数一起传入
  2. 通过set方法将参数逐个传入model中
  3. 新建Request实体类,将参数传入实体类中,然后将实体类传入到网络请求框架中。

那么我们先介绍这几种的优缺点:

「1. 直接通过方法将所有参数一起传入」
    /**
     * 登录
     * @param account 账号
     * @param password 密码
     */
    public void login(String account,String password){
        //执行网络请求的操作
    }
    new LoginApi().login("账号","密码");

如上述代码所示,直接将参数传入。
优点:设计简单。
缺点:1.方法直接传入参数,每次更改参数类型或者数量时,自己封装的网络框架的方法都需要修改。(特别对于组件化开发及其不方便)2.如果参数数量很多,十个或者几十个参数时,那么此方法将会非常长,代码也就变得很难看。

「2. 通过set方法将参数逐个传入model中」
public class LoginApi extends ApiModel<String,LoginBean> {
    /**
     * 登录账号
     */
    private String mMobile;
    /**
     * 登录密码
     */
    private String mPassword;
    @Override
    protected void request() {
        //进行网络请求
    }

    @Override
    protected boolean isNeedEncrypt() {
        return true;
    }

    /**
     * 设置手机号
     * @param mobile 手机号
     * @return LoginApi
     */
    public LoginApi setMobile(String mobile){
        mMobile = mobile;
        return this;
    }

    /**
     * 设置密码
     * @param password 密码
     * @return LoginApi
     */
    public LoginApi setPassword(String password){
        mPassword = password;
        return this;
    }

}
new LoginApi().setMobile("账号").setPassword("密码").request();

优点:采用链式设计结构代码优雅美观
缺点:1.方法通过set传入,每次后台更改参数类型或者参数数量,都需要需改自己封装的网络框架(特别对于组件化开发及其不方便)。

「3. 新建Request实体类,将参数传入实体类中,然后将实体类传入到网络请求框架中。」
    /**
     * 登录请求
     * @param request 请求
     */
    public void login(LoginRequest request){
        //进行网络请求
    }
LoginRequest request = new LoginRequest();
request.setAccount("账号");
request.setPassword("密码");
new LoginApi().login(request);

优点:易于修改参数类型,参数个数,设计比较优雅。
缺点:每次在调用封装的网络框架接口时,都需要事先封装一个实体类,然后将实体类传入,而且每个接口都需要设计一个对应的实体类,操作复杂。

以上三种方法都有各自的优缺点,那么是否存在着一种方式可以包含上述所有的优点,而没有上面的缺点呢?答案自然是肯定的。


其实上述的几种方式都是考虑的如何将参数传入,所以思维就固定住了。我们不妨反过来思考,封装的网络框架该如何获取对应的参数?
看到这,我想不少人会疑惑,怎么获取?那么请往下看。

public class LoginPresenter extends BasePresenter<ILoginContract.ILoginView> implements ILoginContract.ILoginPresenter {
    @HttpConfig(httpApi = LoginApi.class)
    private String mobile;
    @HttpConfig(httpApi = LoginApi.class)
    private String passwd;
    @Inject
    public LoginPresenter() {

    }

    @Override
    public void login(String account, String pwd) {
        this.mobile = account;
        this.passwd = pwd;
        new LoginApi(this).setCallback(mLoginCB).needRequest().showProgress().request();
    }

    private NetworkCallBack<LoginBean> mLoginCB = new NetworkCallBack<LoginBean>() {
        @Override
        public void OnSuccess(boolean b, ResponseBean responseBean, LoginBean loginBean) {
             //登录成功回调
        }

        @Override
        public void OnFail(boolean b, String s, boolean b1) {
            //登录失败回调
        }
    };
}

上面是业务层代码,调用model层的网络接口时,并没有传入参数。这是为何?
关键就在于将参数作为presenter的成员变量,并给参数设置注解。那么该如何自定义注解才能化腐朽为神奇呢?请看以下代码

        if(mIsRequest){
            JsonObject jsonObject = new JsonObject();
            Field[] fields = mObj.getClass().getDeclaredFields();//获取该对象所有成员变量
            int pageIndex = -1;
            int pageSize = -1;
            for (Field field : fields) {
                HttpConfig config = field.getAnnotation(HttpConfig.class);//获取该成员变量的HttpConfig注解
                if(config == null){
                    continue;
                }
                Class[] clazz = config.httpApi();//获取该注解的class数组
                try {
                    for (Class cls : clazz) {//循环class数组
                        if (cls.getName().equals(getClass().getName())) {
                            //当class的名字与当前api类名字相同时,意味着将参数传入到当前api类中
                            String param = field.getName();//成员变量的名字即网络请求参数名
                            if (param.equals("pageSize")) {
                                pageIndex = (int) field.get(mObj);
                                break;
                            }
                            if (param.equals("pageIndex")) {
                                pageSize = (int) field.get(mObj);
                                break;
                            }
                            field.setAccessible(true);
                            if(field.get(mObj) != null){//成员变量不为null时,将变量添加到jsonObject中
                                switch (field.getType().getName()) {
                                    case "java.lang.Boolean":
                                        jsonObject.addProperty(param, (Boolean) field.get(mObj));
                                        break;
                                    case "java.lang.Character":
                                        jsonObject.addProperty(param, (Character) field.get(mObj));
                                        break;
                                    case "java.lang.Integer":
                                    case "java.lang.Double":
                                    case "java.lang.Float":
                                    case "java.lang.Long":
                                    case "java.lang.Byte":
                                    case "java.lang.Short":
                                        jsonObject.addProperty(param, (Number) field.get(mObj));
                                        break;
                                    case "java.lang.String":
                                    default:
                                        jsonObject.addProperty(param, (String) field.get(mObj));
                                        break;
                                }
                            }
                            break;
                        } else if (cls.getName().equals("java.lang.Object")) {
                            break;
                        }
                    }
                } catch (IllegalAccessException e) {
                    LogUtil.e("e = " + e);
                }
            }

在new出loginApi的model时将presenter传入,然后在model中将presenter的成员变量全部获取到,然后选取注解为loginAPI的成员变量,设置成一个json对象。
这样不管后台怎么更改参数类型或者是参数数量,只要修改p层的成员变量就可以了,而且不需要再传入参数,设计优雅,使用简单。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,744评论 6 502
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,505评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,105评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,242评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,269评论 6 389
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,215评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,096评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,939评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,354评论 1 311
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,573评论 2 333
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,745评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,448评论 5 344
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,048评论 3 327
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,683评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,838评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,776评论 2 369
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,652评论 2 354

推荐阅读更多精彩内容

  • Swift1> Swift和OC的区别1.1> Swift没有地址/指针的概念1.2> 泛型1.3> 类型严谨 对...
    cosWriter阅读 11,097评论 1 32
  • Android 教你一步步搭建MVP+Retrofit+RxJava网络请求框架 转载请注明出处http://ww...
    milomallo阅读 1,348评论 2 25
  • 面相,其实,它让哦何群雄马上想起,丞相,两个字,丞相最有名的就是李斯,萧何,曹操,诸葛亮,还有两个字,宰相,宰相最...
    小雄1976阅读 263评论 0 0
  • 小孩的一大特色就是经常因为一点小事就不分场合地哇哇大哭。一哭吧,有的家长就心疼,不心疼的家长也心烦,特别是如果在公...
    纳新老师阅读 435评论 1 4
  • 上节课对一次期末考试进行了讲评,其中一道填空题错误较多,针对该题我变换数字进行了反复讲解,最后又在黑板上出了一道题...
    平安幸福1阅读 307评论 0 0