emo 今天往 MavenCentral 上发布了 0.9.0 的版别。
依赖更新
这个版别，首先是依赖库的更新：
-
Compose BOM升级到2023.08.00，即依赖Compose 1.5.0 -
Compose Compiler升级到1.5.2 -
kotlin升级到1.9.0 -
constraintLayout-compose运用1.1.0-alpha10，现在唯有photo库用到。 -
accompanist升级到0.32.0
因为 navigation 的动画体系从 accompanist 中转正，所以 scheme 库也移除了 accompanist 的 navigation-animation 的依赖，转而运用官方 navigation 库，如果运用了自定义的转场动画完成，则需求稍微适配一下，否则对运用者没有影响。
Compose 1.5.0 带来了 mutableIntStateOf、mutableLongStateOf、mutableFloatStateOf、mutableDoubleStateOf 为基础类型服务，emo 也随之更新了所有能够运用的当地。
增加 BOM 支撑
因为 emo 的子库众多了，并且相互之间也存在依赖联系， emo 现在也开始运用 BOM 来方便调用者进行版别办理。当时 BOM 版别为 2023.08.00
开发只需求在 build.gradle.kts 的 dependencies 里增加
implementation(platform("cn.qhplus.emo:bom:2023.08.00"))
就能够去除掉其它 emo 库的版别好了，当然，也有破例。
破例便是我实测 ksp 的依赖并 bom 的办理，所以关于 config 和 scheme 的 ksp 仍是需求加上版别号。。。
代码重构
关于 photo 库进行了小小的重构，之前写了一份耦合严重，混乱不堪的 GesturePhoto 组件，现在重构了一份 GestureContent 组件，之所以改名，其现在不只是服务于图片预览，并且服务于 pdf 查看，并且开发也能够直接运用，只要用它包裹内容，就拥有了图片预览的常见手势缩放移动操作。
val gestureContentState = remember {
GestureContentState(
ratio,
isLongImage,
)
}
GestureContent(
modifier = Modifier.fillMaxSize(),
state = gestureContentState,
onTap = {
...
},
canTransformStart = {
...
},
) { onRatioEnsure ->
// content
}
现在图片预览组件也基于 GestureContent 了，代码可读性更高，也便于自己之后的保护和修改。
其它首要便是一些自己发现，或许群友们运用过程中发现的大大小小的 bugfix 了。
在升级过程中，有一个有意思的发现：
Compose 1.5.0 将更多的 Modifier 使用 Modifier.Node 这一接口进行了重构，这包含了事情处理的 pointerInput，但这里它有一点小小的不同。
咱们知道，pointerInput 提供的 lambda 是在协程中履行的，但是旧版别的完成中，协程是 pointerInput 履行时就发动了，而新版别完成则是初次事情发生时才发动。假定一个界面有 100 个 pointerInput， 那旧版别就会一开始就发动了 100 个协程，而新版别则是触碰了哪个才发动对应的协程，这无疑能够削减协程数量，毕竟不是每个按钮都会被点击。但随之而来也必须留意写法了。
之前我要监听多种手势时，我的写法是下面这样子：
Modifier.pointerInput(Unit){
launch {
detectTapGestures(...)
}
launch {
awaitEachGesture(...)
}
}
我在 pointerInput 里发动多个子协程去监听多个不同的手势处理，但在新版别，因为初次事情发生才会发动协程，而 launch 发动则会形成异步，也便是第一次的事情无法被子协程所捕获，就形成了事情丢掉。
所以咱们要替换写法，咱们能够给 launch 加上 CoroutineStart.UNDISPATCHED 来指明子协程发动完成后才继续履行自身，pointerInput 内部也是用这种方式来确保第一次事情不丢掉的。咱们也能够分红两个 pointerInput ：
Modifier.pointerInput(Unit){
detectTapGestures(...)
}.pointerInput(Unit){
awaitEachGesture(...)
}
现在我倾向于第二种，因为能够事情处理程序可能依赖不同的 key， 分隔是最好的。
最后，官网文档也已经更新！！！
我是古哥E下，前微信读书客户端程序猿 / 自学 5 年中医，保护过上万 Star 开源项目 QMUI Android，现独立保护好用简洁的 Android 组件库 emo。
关注我可得：ChatGPT 开发玩法 | 程序员学习经历 | 组件库新变动 | 中医健康调理 。
emo官网：emo.qhplus.cn
