优先方法实现网络可预测性
|
roductsRepository 提供了一个合理的同商品数据进行交互的接口，此应用中，所有内容都存储在本地 Room 数据库中，它为 @Dao 提供了针对不同排序具有不同功能的两个接口。 repository 是 Android 架构组件中的一个可选部分，如果您在应用中已经集成了它或者其他的相似功能的模块，那么它应该更偏向于使用挂起函数。因为 repository 并没有生命周期，它仅仅是一个对象，所以它不能处理资源的清理工作，所以默认情况下，repository 中启动的所有协程都有可能出现泄漏。 使用挂起函数除了避免泄漏之外，在不同的上下文中也可以重复使用 repository，任何知道如何创建协程的都可以调用 loadSortedProducts，例如 WorkManager 所调度管理的后台任务就可以直接调用它。 repository 应该使用挂起函数来保证主线程安全。 注意: 当用户离开界面后，有些在后台中处理数据保存的操作可能还要继续工作，这种情况下脱离了应用生命周期来运行是没有意义的，所以大部分情况下 viewModelScope 都是一个好的选择。
再来看看 ProductsDao，示例代码如下： 如果您之前没有用过 LiveData，您可以看看这篇由 @CeruleanOtter 写的文章，它介绍了 LiveData 是如何为 UI 保存数据的 —— ViewModels: A Simple Example。
这是在 Android 上使用协程的通用模式。由于 Android framework 不会主动调用挂起函数，所以您需要配合使用协程来响应 UI 事件。最简单的方法就是来一个事件就启动一个新的协程，最适合处理这种情况的地方就是 ViewModel 了。 在 ViewModel 中启动协程是很通用的模式。
ViewModel 实际上使用了 ProductsRepository 来获取数据，示例代码如下： 使用协程解决实际编码问题 前两篇文章主要是介绍了如何使用协程来简化代码，在 Android 上保证主线程安全，避免任务泄漏。以此为背景，我们认为使用协程是在处理后台任务和简化 Android 回调代码的绝佳方案。 目前为止，我们主要集中在介绍协程是什么，以及如何管理它们，本文我们将介绍如何使用协程来完成一些实际任务。协程同函数一样，是在编程语言特性中的一个常用特性，您可以使用它来实现任何可以通过函数和对象能实现的功能。但是，在实际编程中，始终存在两种类型的任务非常适合使用协程来解决：
协程对于处理这些任务是一个绝佳的解决方案。在这篇文章中，我们将会深入介绍一次性请求，并探索如何在 Android 中使用协程实现它们。 一次性请求 一次性请求会调用一次就请求一次，获取到结果后就结束执行。这个模式同调用常规函数很像 —— 调用一次，执行，然后返回。正因为同函数调用相似，所以相对于流式请求它更容易理解。 一次性请求会调用一次就请求一次，获取到结果后就结束执行。 举例来说，您可以把它类比为浏览器加载页面。当您点击了这篇文章的链接后，浏览器向服务器发送了网络请求，然后进行页面加载。一旦页面数据传输到浏览器后，浏览器就有了所有需要的数据，然后停止同后端服务的对话。如果服务器后来又修改了这篇文章的内容，新的更改是不会显示在浏览器中的，除非您主动刷新了浏览器页面。 尽管这样的方式缺少了流式请求那样的实时推送特性，但是它还是非常有用的。在 Android 的应用中您可以用这种方式解决很多问题，比如对数据的查询、存储或更新，它还很适用于处理列表排序问题。 问题：展示一个有序列表 我们通过一个展示有序列表的例子来探索一下如何构建一次性请求。为了让例子更具体一些，我们来构建一个用于商店员工使用的库存应用，使用它能够根据上次进货的时间来查找相应商品，并能够以升序和降序的方式排列。因为这个仓库中存储的商品很多，所以对它们进行排序要花费将近 1 秒钟，因此我们需要使用协程来避免阻塞主线程。 在应用中，所有的数据都会存储到 Room 数据库中。由于不涉及到网络请求，因此我们不需要进行网络请求，从而专注于一次性请求这样的编程模式。由于无需进行网络请求，这个例子会很简单，尽管如此它仍然展示了该使用怎样的模式来实现一次性请求。
为了使用协程来实现此需求，您需要在协程中引入 ViewModel、Repository 和 Dao。让我们逐个进行介绍，看看如何把它们同协程整合在一起。 （编辑：威海站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
