在创建应用程序时部分应用模式（Android MVVM 架构组件）是错误的吗？

Question

我有一个大型应用程序，它具有：

• 一些需要显示通过蓝牙接收的实时数据的片段（使用前台服务保持与健康设备的连接）。
• 一些显示存储数据的片段 - 可能需要访问 Repo（因此，使用 MVVM 架构组件模式很好，而且，甚至推荐）。

我的问题很简单：

对于整个应用程序，不使用流：View-ViewModel-Repo-DB/Cloud 访问是否正确（从架构的角度/应用程序设计）？ - 仅将 Android 的模式应用于确实显示存储数据的那些片段/活动。

我在问这个，只要显示实时数据（不是存储在持久性存储中，而是由服务广播）不会在 MVVM 模式上折叠：（什么的回购？我没有 2-3-4-5管理它们的数据源；什么的 ViewModel？）我可以有几个 LiveData 对象——在一个单例类中——由服务更新/或者服务可以发送“实时”广播（所以活动只是绑定到服务或观察来自 Singleton 类的一些 LiveData 对象），没关系）。

这个问题背后的想法是，前台服务是数据源而不是持久数据。 如果将安卓的 MVVM 设计应用于整个应用程序，会出现一个额外的问题：

• 在这个图中“放置”了前台服务的什么位置？ 它是一个应用程序组件，因此它应该与 Activity/Fragment 处于同一级别。 另一方面，它是数据的来源。 （因此，它应该放在 Repository 下）。

此外，我有一些用户界面和服务使用的 SharedPref，例如：

1. ALERT_HEART_RATE - 当收到的值 >= ALERT_HEART_RATE 时，服务会提醒用户； - 活动显示此值/提供更改此值的可能性。

谢谢。

Answer 1

数据源是否持久并不重要……与动态数据的唯一区别是，双向数据绑定没有意义，因为数据源是只读的。