我想在回收者视图中显示一些复杂对象的名称/基本属性的列表（即它们由其他对象的多个集合组成），然后在用户选择时获取完整的对象。例如，顶层对象是“播放脚本”，每个对象都包含由与播放脚本相关联的“演员”之一说出的许多“口语”。
我正在尝试使用Android Architecture组件执行此操作，并已（使用Florian @ codinginflow.com的教程）成功地使用Room创建了简化的Play_Script类，DAO和存储库。我还在ASP.Net中创建了一些基本的REST Web服务，这些服务可以提供来自MySQL数据库的数据。
让我吃惊的是，我要走的路径性能会很差，并且会占用过多的网络带宽，从而获取大量我不会使用的数据。我正在获取每个播放脚本（包括其语音线等），以便具有播放脚本的“名称”和“描述”属性来填充回收站。
在过去，我只是“选择ID，名称，来自Play_Script的描述”，一旦用户做出选择，我便会使用ID作为获取我需要的所有其他东西的键。我怀疑我在数据实体设计中缺少一些基本知识，但是无法提出任何关键词，这些关键词会让我搜索完成（/完全没有）这种常见任务的示例。
请问这个菜鸟对他的第一个问题有帮助吗？
干杯， Z
更新5月15日： 尽管我没有任何回应，但根据最近几周的阅读（例如re Dependency Injection），我怀疑Android开发中没有针对此类问题的全面方法。看来，人们通常要么检索大量数据，然后使用他们所需的内容，要么构建多个Web Service API来返回稀疏数据，其中包括客户端可以在需要时用来扩展的密钥。因此，例如，您可能同时创建了“ plays_light”和“ plays_detail” Get API。
答案 0 :(得分：0)
我的解决方案与我5月的更新完全相同-即扩展Web API并提供许多类似的调用，这些调用返回不同的信息粒度。它不是特别优雅，我怀疑可能有更好的方法，但是它可以工作。总的来说，我发现用户倾向于在父实体中较少的详细信息，而在涉及单个孩子/孙子时则更多。
我现在确实意识到了为什么某些应用如此之慢的原因：很容易在Web服务设计中偷懒并仅返回数据负载-客户端将仅使用其中的一部分-并通过说服自己来证明这一点单一的API将会普遍适用，因此，无论谁拿起我的代码来理解它，都很容易。
同样，这可能是我的经验不足，但是我发现通过API调用检索的Android方面的关系数据的本地缓存非常笨拙-大量存储外键，然后重新解析json以将数据获取到SQLite表中。我希望Dagger在简化此过程方面比迄今为止证明的有用。实际上，为了维护我的理智，我整理了整个与Dagger相关的代码。不确定我是否完全成功！
更好的答案仍然非常受欢迎。 Z