当前位置: 首页 > 编程笔记 >

Android在Kotlin中更好地使用LitePal

长孙翔
2023-03-14
本文向大家介绍Android在Kotlin中更好地使用LitePal,包括了Android在Kotlin中更好地使用LitePal的使用技巧和注意事项,需要的朋友参考一下

Kotlin 是一个用于现代多平台应用的静态编程语言,由 JetBrains 开发。

Kotlin可以编译成Java字节码,也可以编译成JavaScript,方便在没有JVM的设备上运行。

Kotlin已正式成为Android官方支持开发语言。

自从LitePal在2.0.0版本中全面支持了Kotlin之后,我也一直在思考如何让LitePal更好地融入和适配Kotlin语言,而不仅仅停留在简单的支持层面。

Kotlin确实是一门非常出色的语言,里面有许多优秀的特性是在Java中无法实现的。因此,在LitePal全面支持了Kotlin之后,我觉得如果我还视这些优秀特性而不见的话,就有些太暴殄天物了。所以在最新的LitePal 3.0.0版本里面,我准备让LitePal更加充分地利用Kotlin的一些语言特性,从而让我们的开发更加轻松。

本篇文章除了介绍LitePal 3.0.0版本的升级内容之外,还会讲解一些Kotlin方面的高级知识。

升级到3.0.0

首先还是来看如何升级。

为什么这次的版本号跨度如此之大,直接从2.0升到了3.0呢?因为这次LitePal在结构上面有了一个质的变化。

为了更好地兼容Kotlin语言,LitePal现在不再只是一个库了,而是变成了两个库,根据你使用的语言不同,需要引入的库也不同。如果你使用的是Java,那么就在build.gradle中引入如下配置:

dependencies {
  implementation 'org.litepal.android:java:3.0.0'
}

而如果你使用的是Kotlin,那么就在build.gradle中引入如下配置:

dependencies {
  implementation 'org.litepal.android:kotlin:3.0.0'
}

好了,接下来我们就一起看一看LitePal 3.0.0版本到底变更了哪些东西。

泛型的优化

不得不说,其实LitePal的泛型设计一直都不是很友好,尤其在异步查询的时候格外难受,比如我们看下如下代码:

在异步查询的onFinish()回调中,我们直接得到的并不是查询的对象,而是一个泛型T对象,还需要再经过一次强制转型才能得到真正想要查询的对象。

如果你觉得这还不算难受的话,那么再来看看下面这个例子:

可以看到,这次查询返回的是一个List<T>,我们必须要对整个List进行强制转型。不仅要多写一行代码,关键是开发工具还会给出一个很丑的警告。

这样的设计无论如何都算不上友好。

这里非常感谢 xiazunyang 这位朋友在GitHub上提出的这个Issue(https://github.com/LitePalFramework/LitePal/issues/396),并且给出了建议的优化方案,LitePal 3.0.0版本在泛型方面的优化很大程度上是基于他的建议。

那么我们现在来看看,到了LitePal 3.0.0版本,同样的功能可以怎么写:

可以看到,这里在FindCallback接口上声明了泛型类型为Song,那么在onFinish()方法回调中的参数就可以直接指定为Song类型了,从而避免了一次强制类型转换。

那么同样地,在查询多条数据的时候就可以这样写:

LitePal.where("duration > ?", "100").findAsync(Song.class).listen(new FindMultiCallback<Song>() {
  @Override
  public void onFinish(List<Song> list) {
  }
});

这次就清爽多了吧,在onFinish()回调方法中,我们直接拿到的就是一个List<Song>集合,而不会再出现那个丑丑的警告了。

而如果这段代码使用Kotlin来编写的话,将会更加的精简:

LitePal.where("duration > ?", "100").findAsync(Song::class.java).listen { list ->}

得益于Kotlin出色的lambda机制,我们的代码可以得到进一步精简。在上述代码中,行尾的list参数就是查询出来的List<Song>集合了。

那么关于泛型优化的讲解就到这里,下面我们来看另一个主题,监听数据库的创建和升级。

监听数据库的创建和升级

没错,LitePal 3.0.0版本新增了监听数据库的创建和升级功能。

加入这个功能是因为 JakeHao 这位朋友在GitHub上提了一个Issue(https://github.com/LitePalFramework/LitePal/issues/414),在他说明了应用场景之后,我认为监听数据库创建和升级这个功能还是非常有意义的。

要实现这个功能肯定要添加新的接口了,而我对于添加新接口保持着一种比较谨慎的态度,因为要考虑到接口的易用性和对整体框架的影响。

LitePal的每一个接口我都要尽量将它设计得简单好用,因此大家应该也可以猜到了,监听数据库创建和升级这个功能会非常容易,只需要简单几行代码就可以了实现了:

需要注意的是,registerDatabaseListener()方法一定要确保在任何其他数据库操作之前调用,然后当数据库创建的时候,onCreate()方法就会得到回调,当数据库升级的时候onUpgrade()方法就会得到回调,并且告诉通过参数告诉你之前的老版本号,以及升级之后的新版本号。

Kotlin版的代码也是类似的,但是由于这个接口有两个回调方法,因此用不了Kotlin的单抽象方法(SAM)这种语法糖,只能使用实现接口的匿名对象这种写法:

这样我们就将监听数据库创建和升级这部分内容也快速介绍完了,接下来即将进入到本篇文章的重头戏内容。

一次不可思议的升级

从上述文章中我们都可以看出,Kotlin版的代码普遍都是比Java代码要更简约的,Google给出的官方统计是,使用Kotlin开发可以减少大约25%以上的代码。

但是处处讲究简约的Kotlin,却在有一处用法上让我着实很难受。比如使用Java查询song表中id为1的这条记录是这样写的:

Song song = LitePal.find(Song.class, 1);

而同样的功能在Kotlin中却需要这样写:

val song = LitePal.find(Song::class.java, 1)

由于LitePal必须知道要查询哪个表当中的数据,因此一定要传递一个Class参数给LitePal才行。在Java中我们只需要传入Song.class即可,但是在Kotlin中的写法却变成了Song::class.java,反而比Java代码更长了,有没有觉得很难受?

当然,很多人写着写着也就习惯了,这并不是什么大问题。但是随着我深入学习Kotlin之后,我发现Kotlin提供了一个相当强大的机制可以优化这个问题,这个机制叫作泛型实化。接下来我会对泛型实化的概念和用法做个详细的讲解。

要理解泛型实化,首先你需要知道泛型擦除的概念。

不管是Java还是Kotlin,只要是基于JVM的语言,泛型基本都是通过类型擦除来实现的。也就是说泛型对于类型的约束只在编译时期存在,运行时期是无法直接对泛型的类型进行检查的。例如,我们创建一个List<String>集合,虽然在编译时期只能向集合中添加字符串类型的元素,但是在运行时期JVM却并不能知道它本来只打算包含哪种类型的元素,只能识别出来它是个List。

Java的泛型擦除机制,使得我们不可能使用if (a instanceof T),或者是T.class这样的语法。

而Kotlin也是基于JVM的语言,因此Kotlin的泛型在运行时也是会被擦除的。但是Kotlin中提供了一个内联函数的概念,内联函数中的代码会在编译的时候自动被替换到调用它的地方,这就使得原有方法调用时的形参声明和实参传递,在编译之后直接变成了同一个方法内的变量调用。这样的话也就不存在什么泛型擦除的问题了,因为Kotlin在编译之后会直接使用实参替代内联方法中泛型部分的代码。

简单点来说,就是Kotlin是允许将内联方法中的泛型进行实化的。

那么具体该怎么写才能将泛型实化呢?首先,该方法必须是内联方法才行,也就是要用inline关键字来修饰该方法。其次,在声明泛型的地方还必须加上reified关键字来表示该泛型要进行实化。示例代码如下所示:

inline fun <reified T> instanceOf(value: Any) {}

上述方法中的泛型T就是一个被实化的泛型,因为它满足了内联函数和reified关键字这两个前提条件。那么借助泛型实化,我们到底可以实现什么样的效果呢?从方法名上就可以看出来了,这里我们借助泛型来实现一个instanceOf的效果,代码如下所示:

inline fun <reified T> instanceOf(value: Any) = value is T

虽然只有一行代码,但是这里实现了一个Java中完全不可能实现的功能 —— 判断参数的类型是不是属于泛型的类型。这就是泛型实化不可思议的地方。

那么我们如何使用这个方法呢?在Kotlin中可以这么写:

val result1 = instanceOf<String>("hello")
val result2 = instanceOf<String>(123)
// result1为true,result2为false

可以看到,第一行代码指定的泛型是String,参数是字符串"hello",因此最后的结果是true。而第二行代码指定泛型是String,参数却是数字123,因此最后的结果是false。

除了可以做类型判断之外,我们还可以直接获取到泛型的Class类型。看一下下面的代码:

inline fun <reified T> genericClass() = T::class.java

这段代码就更加不可思议了,genericClass()方法直接返回了当前指定泛型的class类型。T.class这样的语法在Java中是不可能的,而在Kotlin中借助泛型实化功能就可以使用T::class.java这样的语法了。

然后我们就可以这样调用:

val result1 = genericClass<String>()
val result2 = genericClass<Int>()
// result1为java.lang.String,result2为java.lang.Integer

可以看到,我们如果指定了泛型String,那么最终就可以得到java.lang.String的Class,如果指定了泛型Int,最终就可以得到java.lang.Integer的Class。

关于Kotlin泛型实化这部分的讲解就到这里,现在我们重新回到LitePal上面。讲了这么多泛型实化方面的内容,那么LitePal到底如何才能利用这个特性进行优化呢?

回顾一下,刚才我们查询song表中id为1的这条记录是这样写的:

val song = LitePal.find(Song::class.java, 1)

这里需要传入Song::class.java是因为要告知LitePal去查询song这张表中的数据。而通过刚才泛型实化部分的讲解,我们知道Kotlin中是可以使用T::class.java这样的语法的,因此我在LitePal 3.0.0中扩展了这部分特性,允许通过指定泛型来声明查询哪张表中的内容。于是代码就可以优化成这个样子了:

val song = LitePal.find<Song>(1)

怎么样,有没有觉得代码瞬间清爽了很多?看起来比Java版的查询还要更加简约。

另外得益于Kotlin出色的类型推导机制,我们还可以将代码改为如下写法:

val song: Song? = LitePal.find(1)

这两种写法效果是一模一样的,因为如果我在song变量的后面声明了Song?类型,那么find()方法就可以自动推导出泛型类型,从而不需要再手动进行<Song>的泛型指定了。

除了find()方法之外,我还对LitePal中几乎全部的公有API都进行了优化,只要是原来需要传递Class参数的接口,我都增加了一个通过指定泛型来替代Class参数的扩展方法。注意,这里我使用的是扩展方法,而不是修改了原有方法,这样的话两种写法你都可以使用,全凭自己的喜好,如果是直接修改原有方法,那么项目升级之后就可能会造成大面积报错了,这是谁都不想看到的。

那么这里我再向大家演示另外几种CRUD操作优化之后的用法吧,比如我想使用where条件查询的时候就可以这样写:

val list = LitePal.where("duration > ?", "100").find<Song>()

这里在最后的find()方法中指定了泛型<Song>,得到的结果会是一个List<Song>集合。

想要删除song表中id为1的这条数据可以这么写:

LitePal.delete<Song>(1)

想要统计song表中的记录数量可以这么写:

val count = LitePal.count<Song>()

其他一些方法的优化也都是类似的,相信大家完全可以举一反三,就不再一一演示了。

这样我们就将LitePal新版本中的主要功能都介绍完了。当然,除了这些新功能之外,我还修复了一些已知的bug,提升了整体框架的稳定性,如果这些正是你所需要的话,那就赶快升级吧。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对小牛知识库的支持。如果你想了解更多相关内容请查看下面相关链接

 类似资料:
  • 如何在中的每个项中使用? 我得xml: null

  • 给定一个在Eclipse中从archetype maven-archetype-quickstart创建的Maven项目(将junit升级到5.5.2,具有JPMS支持),如何将其模块化为JPMS项目,并且在Eclipse中仍然表现良好? 当我尝试这样做时,我首先在文件夹中创建了module文件夹,并将包结构移到其中。项目结构如下所示: jpms(项目文件夹)->src/main/java/org

  • 我有一个AS3/gradle plugin 3项目,我们最近在其中引入了一个本地简单的注释处理器。适用于gradles annotationProcessor Dependency指令。 我开始添加Kotlin代码,并将所有annotationProcessor指令移动到kapt指令。Glide和logan square对Kotlin使用注释处理器没有问题,但我们当地的AP项目无法由kapt执行:

  • 在这种情况下我们必须使用val而不是var?我知道val是当我们知道值不会改变的时候。但我的印象是var对所有情况都是好的。是真的吗?换句话说:只用var有问题吗?

  • 如果你还记得,现在项目已经准备好去使用Kotlin Android Extensions。当我们创建这个项目,我们就已经在build.gradle中增加了这个依赖: buldscript{ repositories { jcenter() } dependencies { classpath "org.jetbrains.kotlin:kot

  • 我正在开发一个使用Zomato Api获取附近餐馆的应用程序。我有一个片段,它向用户显示了所单击餐厅的详细信息。我的目标是在地图上显示餐厅的位置,但我很难做到这一点,因为我会出错。它只在活动中起作用吗?我是否必须将层次结构更改为FragmentActivity? 我得到的错误是: