浅谈android嵌入第三方sdk的二次封装原则

        由于android的开源特性,很多功能(例如网络请求,json解析等)可以在网上找到大把的工具,另外还有很多第三方sdk(例如,推送)已经大行其道。这些第三方框架以其调用方便,性能稳定等特性大受android程序猴子欢迎。虽然这些sdk内部封装的很好,调用也极其方便,所以很多人都不想在此基础上进行二次开发,以方便自己使用。这样造成的问题就是,一旦更换sdk,结果将是灾难性的大面积修改甚至重构。

       猴子不才,看到同事对那些第三方sdk的封装讲大大降低这一风险,于是偷偷总结一下,方便以后查看。现在以联网请求为例来分析这一封装方式的优越性。

       哥们采取的方法是,按照功能分层,最底层只负责将sdk中提供的功能进行封装调用:

public static RequestHandle post(String url, Map<String, Object> map,
                                 Callback callback) {

    StringEntity entity = MapParamsConverter.map2Entity(map);

    HttpRequestCallBack requestCallBack = new HttpRequestCallBack(callback);
    RequestHandle handler = mAsyncHttpClient.post(MyApplication.appContext, url, entity, "application/json", requestCallBack);
    return handler;
} 
       其中 mAsyncHttpClient是第三方的网络请求框架的实际工作层。

       上一层则是封装基本的公共参数,例如deviceid,token等,这部分代码涉及公司机密,也没什么技术性可言,就不粘贴了,这一层封装的用处是,将公共数据抽取,提高代码的重用性,毕竟代码是该被重用而飞被复制。

       再上一层则是,必要参数的封装,例如在登录接口,需要传递用户名,密码什么的。也没什么技术性可言。

      这样经过三层封装,好处就是,当底层的网络请求框架需要被换掉时,只需改动

RequestHandle handler = 你的请求框架的.post(MyApplication.appContext, url, entity, "application/json", requestCallBack);

      完全不需要管哪里调用网络请求,也不需要知道他究竟传给了什么参数,变化都被隔离在最底层的基本方法上。

     


      

      

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页