掘友等级
获得徽章 0
刚刚为 MVI-Dispatcher-KTX 解决一棘手问题,在确保 “多观察者消费且各只消费一次” 前提下,消除页面初始化和息屏亮屏等场景 “Flow 错过收集”,感兴趣可自行查阅
继 KeyValueX,提供一种简明易用 KeyValue-Dispatcher 实现。迭代心路历程已追加至《KeyValueX》篇,感兴趣可自行查阅
juejin.cn
如您已是 UnPeek-LiveData 资深玩家,今天这框架请不要错过 ——
刚于 Github 发行 “唯一可信源” 成熟态 MVI-Dispatcher,通过它可一举消除 “mutable 样板代码 + LiveData 连发事件覆盖 + LiveData.setValue 误用滥用” 高频痛点。
欢迎 star 、test 、feedback 三连~
github.com
有后端配合,领域层 数据层 贼清爽,各只需一方法即可处理全应用网络请求。
彻底做到纯函数原子式 I/O(也即我们早前于《一通百通声明式 UI 扫盲干货》篇提到之“仅一入口 + 仅一出口”)
尝试用 Java + MVI 重构远古项目,单向数据流 + 原子集分发真很爽,只是 Java switch 逻辑易 “串流”;无密封类乃至须自定义内部类 + 静态 FLAG,如此亦增加一致性隐患。
故 Java 下 MVI 使用见仁见智,单向数据流思想偏爱罢。
事件 Event 倾向于 "发送" 语境。事件通常来自 UI 层,例如通过 Button click 发起某事件。
而 mutable 系框架倾向于 "接收事件、处理业务逻辑" 后的末流消息分发。
为此,基于 "单一职责原则",最终我们将 UnPeekLiveData 更名为 Result,示意其纯粹 "消息分发" 用途,
通过语义,让团队成员在 Activity/Fragment 中使用 result.setValue 时感觉别扭,促使其自动仅在 "唯一可信源" 内部业务逻辑末端使用。
具体可 pull 最新源码查阅。
github.com
感谢小伙伴们实事求是的交流,经过长达 2 年的互动和演化,本示例项目的架构流程已基本确立,此处分享一份架构流程图,感兴趣可自行保存和查阅。
github.com
看到 issue 区有小伙伴从头开始追溯 UnPeekLiveData 的演化历程,此处贴一份最新源码的简化版,该简版仅保留最核心的 “event 防倒灌”,剔除了 内存清理、允许空值、允许 “state 倒灌” 等设计,感兴趣可自行对照查阅。
github.com
分享一个 Android Studio 4.2.1 的坑,
最近在尝试 maven-central 上传,对着开源案例一步一步匹配脚本,却被 “tasks 消失不见”的奇怪问题困扰许久,
最后我猜测也许就算是 stable 版本(4.2.1),也会有问题”,于是另外安装了 canary 最新版(2021.1.1 canary1),才看到标题栏出现了提示说,“tasks 在同步时生成”已关闭。。
Android Studio 4.2.1 stable 在没有任何提示的情况下,以“用户体验优化”的名义默认关闭了 “task 生成” 的选项。
下一页