大家早上好,看到这个标题,相信很多喜欢LitePal朋友应该是一把鼻涕一把泪。两年多了,今天终于又升级了
是的,我看了一下时间,LitePal的上个版本还是2018年10月份发布的,之后就再也没有更新过。因为我接下来将主要的时间都放在了giffun这个项目上,忙完giffun紧接着又开始编写《第三行代码》,以至于完全没有时间和精力去维护LitePal。
期间有不少朋友咨询过我,是不是放弃维护LitePal了?莫名感到有点心酸,我欠这个项目的有点多了。
那么时隔两年之后的更新,LitePal又发生了什么变化呢?我们一起来看一看吧。
/ Close Issues /
这两年时间里,我不光没有时间更新LitePal的功能,甚至连GitHub上的issues都无暇顾及,以至于积累了大量的issues。那么在开发新功能之前,首先要做的,肯定是解决这些issues。
我将所有的issues都浏览一遍之后,发现大体可以归为以下几类:
1. 用法的咨询。对于这类issue我基本都进行了回复,只是回复的有点太晚了,可能没能帮上你们的忙,这里非常抱歉。
2. 功能上的建议。这些年来许多朋友都在LitePal的功能性方面提供了不少建议,也让LitePal变得更加强大。不过关于功能建议方面的事情我待会还会再谈,这里暂时先跳过。
3. 系统类型的Bug。有些朋友使用LitePal时遇到了崩溃,就认为是LitePal的bug,但有的时候并非如此。比如CursorWindows这个bug被提了好几次,但其实这是系统底层的限制,CursorWindow缓存数据达到最大限制就会抛出异常。即使你不使用LitePal,用原生的SQLiteDatabase也会出现这个异常,所以这种问题我确实无法修复,大家只能在使用层面尽量减少这种一次性加载大量数据的场景。
4. LitePal的Bug。对于提出这类问题的朋友我非常感谢,这次确实又发现了几个LitePal内部的bug。比如特定情况下升级数据库会丢失数据、Date类型字段无法保存1970年以前的数据、findFirst()方法在某些时候查询速度会非常慢等等。这次在开发新版本之前,我将这些提出的bug全部都进行了修复,保证这是一个更加稳定的版本。
那么现在LitePal的GitHub中还剩下多少issue呢?给大家看一下:
没错,就只剩下一个了。并且这是一个新功能的建议,我确实计划在之后的版本中考虑加入这个功能,所以暂时将它保留了下来。
好了,现在issues都解决掉了,接下来终于可以对LitePal进行升级了。
/ 合二为一 /
在之前的LitePal 3.0.0版本当中,我为了让它支持一些Kotlin中不错的语法特性,将原来的一个库变成了两个库,如下图所示:
是的,使用哪种编程语言就引入哪个库,我本来认为这是一件很好的事情,然而没过多久我就后悔了,这是一个非常错误的决定。
将库分成了Java和Kotlin两个版本之后,它们又会共同引入Core库来作为依赖,Core库是主业务逻辑实现的地方。那么当需要添加什么新功能的时候,我需要在Core库中进行具体的功能实现,然后在Java库中添加一个对外接口,在Kotlin库中添加一个对外接口,还要为Kotlin的专属语法再添加一个对外接口。本来只需要在一个地方维护的代码现在变成了要在四个地方维护,所有API的数量也变成了四倍,导致代码维护成本急剧增加。
这个问题是我必须要解决的ÿ