当Room没有LiveData时返回LiveData，而是从REST API获取

Question

我正在寻找处理下面的用例W.R.T.的建议。LiveData处理：ViewModel为LiveData调用存储库（例如产品目录）。存储库首先从LocalDataSource（Room）进行检查，但如果数据不可用，则调用RemoteDataSource（REST API）。

问题：

2）由于RemoteDataSource返回的数据不是LiveData类型，应该做些什么才能使存储库最终将LiveData返回给ViewModel？

存储库是否应该首先将数据（来自RemoteDataSource）插入Room，然后查询Room，以便返回LiveData？这看起来相当昂贵的操作，因为在这个过程中有两次查询空间。请指教。谢了！

Answer 1

首先，感谢@adityakamble49回答了我的问题，他功不可没！您可以使用Repository维护抽象，方法是将LiveData作为返回值，并使用NetworkBoundResource，您可以决定是需要从NetworkBoundResource，还是可以使用html" target="_blank">缓存的数据（DB/DataHolder）。NetworkBoundResource是一种在抽象类中实现通用功能（使用泛型）并在扩展类中提供显式行为的干净方法。

分享我对NetworkBoundResource类与android-priority-jobqueue类的观点，这样可以帮助我们决定在复杂的场景中使用哪一个。

NetworkBoundResource--当应用程序需要从本地数据库或网络获取数据时使用，但当获取失败时（例如没有网络）也会向用户显示错误。在屏幕上拉到折射是一个很好的用例，用户希望看到更新的数据，或者在获取失败时看到错误吐司/对话框。

android-priority-jobqueue-在许多情况下，需要保留一个动作直到它成功完成（而不是显示错误和忘记）。在这样的场景中，JobQueue非常有助于在后台队列中维护挂起的作业（对于关联的触发器），并在以后网络可用时处理这些作业。例如。用户在脱机模式下创建的便笺被添加到JobQueue中，当设备联机时，该便笺将在稍后进行同步。这种情况不能用NetworkBoundResource解决。

NetworkBoundResource候选操作不应该使用JobQueue（反之亦然）来处理，因为它可能会用太多的操作淹没JobQueue，而且其中许多操作可能是重复的，例如，在同一个屏幕上进行多次拉刷新操作，导致多个作业，这是错误的。欢迎他人观点！！！