我想在回收者视图中显示一些复杂对象（即它们由其他对象的多个集合组成）的名称/基本属性列表，然后获取用户选择的完整对象。例如，顶级对象是“播放脚本”，每个对象都包含与播放脚本相关联的“演员”之一所说的许多“台词”。
我正在尝试使用 Android 架构组件来执行此操作，并且（使用 Florian @ codinginflow.com 的教程）成功地使用 Room 创建了一个简化的 Play_Script 类、DAO 和存储库。我还在 ASP.Net 中创建了一些基本的 REST Web 服务，它们可以提供来自 MySQL 数据库的数据。
令我震惊的是，我要走的路径会表现不佳，并且会使用过多的网络带宽来获取大量我不会使用的数据。我正在获取每个播放脚本（包括其口语等），以便我拥有播放脚本“名称”和“描述”属性来填充回收器。
在过去，我只是“从 Play_Script 中选择 ID、名称、描述”，一旦用户做出选择，我就会使用 ID 作为获取我需要的所有其他内容的关键。我怀疑我在数据实体的设计中遗漏了一些基本的东西，但无法想出任何关键字来让我搜索这种常见任务做得很好的例子（/根本）。
请你能帮助这个SO noob 解决他的第一个问题吗？
干杯，Z
5 月 15 日更新：虽然我没有得到回应，但从我最近几周阅读的内容（例如依赖注入）来看，我怀疑在 Android 开发中没有针对此类事情的全面方法。看起来人们通常要么检索大量数据，然后使用他们需要的数据，要么构建多个 Web 服务 API 来返回稀疏数据，其中包含客户端可在需要时用于扩展的密钥。因此，例如，您可以同时制作“plays_light”和“plays_detail”Get API。
我的解决方案与我 5 月份的更新完全一样——即扩展 Web API 并提供许多类似的调用，这些调用返回不同粒度的信息。它不是特别优雅，我怀疑可能有更好的方法，但它有效。总的来说，我发现用户在父实体中需要较少的细节，而当我们接触到个别的孩子/孙子时，则需要更多的细节。
我现在确实意识到为什么有些应用程序如此缓慢：在 Web 服务设计中很容易偷懒，只返回大量数据——客户端只会使用其中的一个片段——并通过说服自己使用单个 API 来证明这一点将是普遍适用的，因此对于任何拿起我的代码的人来说更容易理解。
同样，这可能是我的经验不足，但我发现通过 API 调用检索的 Android 端关系数据的本地缓存非常笨拙 - 大量存储外键，然后重新解析 json 以将数据放入 SQLite 表中。我希望 Dagger 在简化这个方面比目前的情况更有用。我实际上解开了一大堆与 Dagger 相关的代码，只是为了保持我的理智。不确定我是否完全成功！
更好的答案仍然非常受欢迎。Z
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句