最近项目里面用到了模块化开发,按照对应功能点划分模块开发,每一个功能都是一个module,由于接手的代码相对有点杂乱,维护以及迭代非常难过,所以跟公司申请时间重构,但是公司为了眼前利益赶项目,并没有搭理我,没办法,只能利用自己空余时间一个一个功能点慢慢重构了,这也就当是自己的一个收获了吧。首先,我是拿常见的第三方登陆和分享试手的,好了,进入正题。
首先,我用的mob的sharesdk(mob现在被游族网络收购了,这个是为数不多的还在维护更新的sdk),现在官网推荐我们的集成方式是用AndroidStudio自带的gradle去自动编译。步骤很简单,就两个步骤,第一步在新建工程的app目录下面的bulid.gradle中添加需要集成的平台信息:
效果图并在头部加上 apply plugin:'com.mob.sdk';否则编译不过。
然后,在整个工程的外部bulid.gradle中添加如下信息:
效果图MobSDK的版本号不要轻易修改(除非你知道最新的版本具体的版本号)。
至此,我们就可以写功能代码了,这一块我就忽略了,一个简单的登陆分享demo就做完了。但是正如我上文所说的,我现在是模块化开发,我需要把登陆分享的功能做成一个library,我最终的目标是想把登陆分享的功能封装成github上面的一个远程依赖库,可能有人会问,封装成依赖库,那要是项目里面功能需求变了,整个依赖不都要修改吗?是的,确实是这样的,依赖库的代码是不可编辑的,我想到的解决办法是对应改需求的话,我就对应新建一个项目专属的分支呗,每个分支维护不同工程的不同版本,虽然好像听起来有点扯,但是目前这是我想到的最好的办法,总比每个工程重新接入mob要好得多。
如果想把代码变成一个远程的依赖,首先要把核心的代码全部封装起来,对外部来说只提供调用的方法,最多的话就是方便处理业务逻辑把登陆分享的回调传递到外层,当然,这里不能直接用sdk的回调了,需要自己写一个接口回调,因为外部的类是没有办法引用sdk相关代码的,因为sdk相关的代码全部被封装起来了,如果,外部可以继续使用sdk的代码,那我们封装的意义何在呢?
好了,下面就把刚刚创建的登陆分享的demo(下面简称demo),变成另一个工程的library,新建一个工程导入一个module,具体步骤忽略,这个时候就有一个问题了,因为demo的编译方式是靠外层的bulid.gradle,demo作为library被导入一个新的工程的时候,外层的bulid.gradle是没法导入,这个时候编译报错,找不到对应的sdk,这个问题怎么解决呢,当时这个问题我搞了两天,幸好我没放弃,我首先想到的办法是直接下载对应的jar包,放到library的libs文件夹下面,mob官网打开的时候,竟然不能下载jar包,直接弹出弹窗给出了自动编译的方式,这种方式我只好放弃了,因为官网不支持了,官网强烈推荐自动编译的方式。即使我可以从之前的工程里面把对应的jar包掏出来,但是sdk实时更新的好处就没有了,这相当于是走了回头路了,这是不可取的。后来我想到demo的编译方式,直接在新工程的外层bulid.gradle添加demo同样的classpath,确实编译成功了,并且library里面的sharesdk相关的类和方法都可以引用了,正当我开心的插上测试机运行的时候,问题出来了,这个时候报错,build失败,找不到对应的sdk版本。如果找不到对应的sdk,那么为什么library里面引用类和方法没有报错呢?既然可以使用代码,为什么整个工程运行报错呢?第一次遇到这个问题,我把我身边的资源全都问了一遍,但是都没有解决这个问题,我后来想这个肯定跟mob的外层的bulid.gradle编译有关,因为如果不是这种方式,对应的不会有这种问题,所以我只能向mob技术支持请求帮助,其实很多时候你会发现,问题或者报错本身倒是没什么,如果遇到过,可能就是一句代码的事,真正难的是描述这个问题,怎么把这个问题描述清楚,就比如我遇到的这个问题,我花了半个小时才让他明白了我的意思。在和他描述的同时,我去搜索了mob上面的报错集合,突然一条回复让我一惊,在新建工程的内部bulid.gradle里面也需要在头部添加 apply plugin:'com.mob.sdk';我还在编译的时候,技术支持给我发来了同样的解决办法,哈哈,几分钟之后编译成功,可以正常运行了。到这里离我想要的目标实现了一半,登陆分享的功能已经被封装成了一个library了,接下来我想把对应的代码生成一个远程依赖,具体操作忽略(https://jitpack.io)。在项目里面里面引入github项目生成的一个链接,编译成功,结下来就是写代码测试了,运行测试,发现所有的登陆分享全部报错(前提包名正确并且签名打包的),对应的报错信息是appKey 缺失,就是被封装的代码(包括平台相关信息都是放在bulid.gradle中)里面的信息拿不到,但是如果不是远程依赖的话,直接library引入是可以正常调起三方使用的。后来我大概查了一下资料,生成远程依赖的代码的bulid.gradle里面的信息是完全封闭的,这也和代码封装的理念相通,所有引用这个依赖的工程无法访问里面的appKey等第三方信息,至此,发现生成远程依赖库的想法彻底被推翻,但是通过这个功能点整理,最起码把整个流程梳理了一下,因为这里的mob登陆分享比较特殊,如果是常规功能封装成远程依赖的话还是可以的。
好了,至此,本文就结束了,希望可以给遇到同样问题的朋友一点思路!
附录 github地址:https://github.com/lifeng19930608/ShareAndLogin
网友评论