java - 如何在 Android MVVM 虚拟机中模拟父子关系？

Question

我正在开发一个 Android 钢琴“测验”应用程序 - 用户点击钢琴键，然后单击黄色的“检查”按钮提交答案进行评估，并查看在钢琴上绘制的正确答案。主QuizActivity有这样的布局:

屏幕的上部包含几个控件(文本、提交按钮等)。
屏幕下方被自定义PianoView占用组件，处理钢琴键盘的绘制。
根据 MVVM 原则，PianoView应该有自己的PianoViewModel ，将其状态(即当前按下的键、突出显示的键等)存储在 KeysStateRepository 中.
内附QuizActivity还应该有一个 QuizActivityViewModel ，处理各种控制(提交答案，跳过问题......)。QuizActivityViewModel需要能够从 PianoView 中查询选定的键(或者更确切地说是从它的 KeysStateRepository )，将它们提交到域层进行评估，然后将结果发送回 PianoView用于可视化。
换句话说，QuizActivity的 ViewModel应该拥有/是 PianoView 的 parent 的 ViewModel以促进交流和数据共享。
如何建模这种父子关系以在 ViewModel 之间进行通信？
AFAIK ViewModel不能依赖另一个 ViewModel (我将作为 ViewModelStoreOwner 传递什么来在另一个 ViewModel 中获得 Viewmodel ？)。我认为用 不可能实现 Dagger 刀柄 至少。
想到了解决此问题的三种解决方案，但都无法使用:
1 - 在 View 之间共享数据的官方方式
Android 开发文档 recommend使用 共享 ViewModel促进两个 fragment/ View 之间的数据共享。但是，这不适合我的用例。 PianoView (或其 ViewModel)应该是其状态的唯一所有者，具有 Repository范围限于其 ViewModel .否则，PianoView组件将不可重用。例如考虑另一个 Activity ，我想在这里有两个独立的PianoView实例可见:

从测验 Activity 中重用共享 View 模型显然是错误的，因为它包含不相关的方法和逻辑(即提交测验答案)并且不适合双键盘场景。
2 - 应用程序范围的存储库
在 Reddit 上解决了类似的问题建议使用存储库的共享实例的解决方案。但是，使用 @Singleton KeyStateRepository将再次阻止两个独立的键盘显示不同的数据。
3(EDIT) - 由事件总线复制的 2 个重复存储库
理论上我可以创建 2 个独立的 ViewModel s 和 2 KeyStateRepository实例。 ViewModels将订阅事件总线。每次一个ViewModel在其存储库上调用一个可变操作，它还会触发一个事件，并且该操作将通过另一个 ViewModel 复制。订阅了相同的事件总线。
然而，这感觉像是一个脆弱而复杂的黑客。我想要一个简单的 MVVM 兼容解决方案。我不敢相信两个 UI 组件的简单父子关系在 MVVM 中是无法实现的。

Answer 1

我想你从 Pavlo 那里得到了一个不错的答案，我会用其他词来澄清他的意思。

KeyStateRepository是钢琴键状态的存储。没有什么能阻止您同时支持 N 架钢琴，这将解决屏幕上有 NNN 钢琴，每个钢琴按下不同键的情况。

PianoView 应该包含在一个 Fragment 中，它应该是你的“单元”。为什么？因为您希望 ViewModel 处理来自 View 的状态和事件。还有一个 Fragment是为这方面提供的 Android 工件。把它想象成你需要的一件烦人的行李。 Android 开发人员过去将这些东西称为“政策委托(delegate)”，因为您将某些事情委托(delegate)给这些( fragment/Activity )，如果没有“框架”(即 Android 框架)，您就无法做到。

考虑到这一点，您有一个 Activity其 viewModel/State 是独立处理的。这个 viewModel 处理什么状态/事件？不在 PianoFragment/View(s) 中的东西。例如。如果您想处理后退导航或顶部的“记录”按钮，则这是 Activity 的域。 “PianoView/Fragment”内部发生的事情不是这个 Activity 的问题。

现在，包含实际 PianoView 的 Fragment 可以设计为包含“多个”或仅包含一个。如果你选择不止一个，那么 PianoContainerFragment 将设计一个 ViewModel 来处理多个 PianoView(所以每个 View 都有一个“名称/键”)并且 KeyStateRepo 将能够处理“CRUD”操作您扔的任何钢琴 View 。 ViewModel 将位于两者之间，为不同的“订阅” View 调度事件。

如果你选择“一个 fragment 包含一个钢琴 View ”，那么它是一个类似的架构，但现在在一个“Activity ”中处理多个“fragment ”现在是 Activity (及其 View 模型)的责任。但请记住，PianoViews(通过共享或不共享的 Fragment)与可在钢琴 View 之间共享的 ViewModel 对话，该 ViewModel 与公共(public) KeyState Repo 对话。 Activity 协调 View 和其他 Android 事物(导航等)，但 View 独立运行，甚至彼此独立运行。

你真的不需要一个共享的 viewModel 我认为，事实上，我不会在真正需要之前这样做，你分开的东西越多，“违反”其中一种花哨模式的机会就越少......但是如果你选择使用 PianoViewModel 作为所有 View 之间的共享，这是完全可以接受的，您将不得不包含 Piano“名称”以区分谁的事件是为谁服务的。

换句话说(使用 ONE PianoViewModel 显示 ASCII 简单性)，

// One QuizActivityViewModel, Multiple Fragments:

Activity -> PianoFragment (PianoView)| 
                                     | <-> PianoViewModel <-> KeyRepo
            PianoFragment (PianoView)|                       /
            -> QuizActivityViewModel <----------------------/

这里 QuizActivity 创建了 N 个 fragment (可能在列表中？)。这些 fragment 在内部初始化它们的 PianoView 并连接到 PianoViewModel(可以像上图一样共享)，或者每个 fragment 都可以有自己的。他们都与同一个 Repo 交谈。存储库是您关于每个“钢琴”内容的“唯一真实来源”。按下了什么键，以及您能想到的任何其他内容(包括名称/键以使其独一无二)。
当 QuizActivity 需要评估这些状态时，它会(通过它自己的 viewModel)询问 NN 钢琴的状态。
或者

// 1 Act. 1 Frag. N Views.
Activity -> PianoFragment (PianoView)| 
                          (PianoView)| <-> PianoViewModel <-> KeyRepo
         -> QuizActivityViewModel  <---------------------------/

有了这些，QuizActivity(也开始创建钢琴)也知道将/显示的钢琴键。它可以与与同一个 KeysRepo 对话的 viewModel 对话(你只有其中之一，这很好)。所以它仍然可以处理“导航”按钮，它可以询问(通过它的 QuizActVM )键的当前状态是什么(对于所有涉及的钢琴)。在 PianoView 中触发钢琴键事件时，PianoViewModel 将接收该事件(触摸了什么键，在什么钢琴上)； KeyStateRepo 将记录这一点，并可能更新 flow {}随着来自钢琴的事件......
Flow 将用 sealed class 表示它将包含足够的信息用于 QuizActivity + VM(可能执行实时验证)和 PianoViewModel 以更新状态并将新状态推送到 PianoFragment(它将更新其 View 的状态) .
这对于任何一种方法都是通用的。我希望这可以澄清顺序。
你能理解这个吗？