三菱PLC,台达PLC,欧姆龙PLC,PLC锁定和解锁,Jetpack 实战项目 PokemonGo(神奇宝贝)基于 MVVM 架构和 Repository 设计模式,PokemonGo 项目中用到的技术,都是之前写过的一系列文章里面涉及到的知识点:Paging3(network + db),Dagger-Hilt,App Startup,DataBinding,Room,Motionlayout,Kotlin Flow,Coil,JProgressView 等等。
项目 PokemonGo 已经上传到 GitHub: https://github.com/hi-dhl/PokemonGo,欢迎前去查看,动态效果图如下所示,如果动图无法查看,请点击这里查看 动态效果图 | 静态图
Jetpack 实战项目 PokemonGo 涉及的技术:
Gradle Versions Plugin:检查依赖库是否存在最新版本
Kotlin + Coroutines + Flow:flow 是对 Kotlin 协程的扩展,让我们可以像运行同步代码一样运行异步代码
JetPack
Paging3(network + db):用到了 Paging3 中的 MediatorResult 用来实现 network + db
Dagger-Hilt (2.28-alpha):依赖注入框架
App Startup:设置组件初始化顺序
DataBinding:以声明方式将可观察数据绑定到界面上
Room:在 SQLite 上提供了一个抽象层,流畅地访问 SQLite 数据库
LiveData:在底层数据库更改时通知视图
ViewModel:以注重生命周期的方式管理界面相关的数据
Andriod KTX:编写更简洁、惯用的 Kotlin 代码
项目架构
MVVM 架构
Repository 设计模式
Data Mapper 数据映射
Retrofit2 & OkHttp3:用于请求网路数据
Coil:基于 Kotlin 开发的首个图片加载库
material-components-android:模块化和可定制的材料设计 UI 组件
Motionlayout :MotionLayout 是一种布局类型,可帮助您管理应用中的动画
Timber: 日志打印
JProgressView :一个小巧灵活可定制的进度条,支持图形:圆形、圆角矩形、矩形等等
以上技术栈对应之前写的技术文章:
Jetpack 最新成员 AndroidX App Startup 实践以及原理分析
Jetpack 成员 Paging3 实践以及源码分析(一)
Jetpack 新成员 Paging3 网络实践及原理分析(二)
Jetpack 新成员 Hilt 实践(一)启程过坑记
Jetpack 新成员 Hilt 实践之 App Startup(二)进阶篇
Jetpack 新成员 Hilt 与 Dagger 大不同(三)落地篇
全方面分析 Hilt 和 Koin 性能
[译][2.4K Star] 放弃 Dagger 拥抱 Koin
项目中封装 Kotlin + Android Databinding
为数不多的人知道的 Kotlin 技巧以及 原理解析(一)
为数不多的人知道的 Kotlin 技巧以及 原理解析(二)
如果之前对这些技术没有接触过,或者只是听说,对阅读本文没有什么影响,本文会对这些技术结合着项目 PokemonGo 来分析,为了文章的简洁性,本文不会细究技术细节,因为每个技术都需要花好几篇文章才能分析清楚,我会在后续的文章去详细分析。
如何检查依赖库最新版本
在之前的文章 再见吧 buildSrc, 拥抱 Composing builds 提升 Android 编译速度 分析过,到目前为止大概管理 Gradle 依赖提供了 4 种不同方法:
手动管理 :在每个 module 中定义插件依赖库,每次升级依赖库时都需要手动更改(不建议使用)
使用 ext 的方式管理插件依赖库 :这是 Google 推荐管理依赖的方法 Android官方文档
Kotlin + buildSrc:自动补全和单击跳转,依赖更新时 将重新 构建整个项目
Composing builds:自动补全和单击跳转,依赖更新时 不会重新 构建整个项目
新版的 AndroidStudio 只支持 ext 的方式 和 手动方式管理 检查依赖库是否存在最新版本,不支持 buildSrc、gradle-wrapper 版本的检查。
满足不了 PokemonGo 项目的需求,在 PokemonGo 项目中采用 buildSrc 方式去管理所有依赖库,因为 PokemonGo 项目采用单模块结构,而且支持 自动补全 和 单击跳转 很方便,所这里用到了 Gradle Versions Plugin