Android官方架构组件Paging-Ex_列表状态的响应式管理

如许的需求随处可见，比如 侧滑删除、为评论点赞 等等：
本文将阐述：怎样管理Paging分页列表的 状态，为何如许计划，以及计划的过程。
列表的状态问题

和市面上其它热门的分页库相比，Paging最大的亮点在于其 将列表分页加载的逻辑作为回调函数封装入 DataSource 中，开发者在设置完成后，无需通过代码手动控制分页的加载，列表会 自动加载 下一页数据并展示。
这种便利意味着开发者不必要自己持有 数据源 ，大多数时候这使得开发流程更加便利，但总有偶然，比如如许一个界面：

这种需求屡见不鲜，其本质是，列表本身展示服务端返回的列表数据之外，还必要 本地控制额外的状态。
什么叫 额外的状态 ? 我们先用简单的一张图展示没有额外状态的情况，这时，列表的全部UI元素都从服务端获取：

现在我们将上文Gif中的点赞效果也通过一张图表现：

读者可能还未认识到两种业务场景之间的差别性：对于列表的初始化来讲，全部UI元素都被服务端返回的数据渲染，每条评论是否已经被点赞，服务端都通过Comment进行了形貌。
必要注意的是，在某一刻，用户发现某个评论非常风趣，因此他选择对该评论进行了点赞的操作。
在业务代码中，我们必要向服务端POST一个点赞的请求，服务端返回了一个200的乐成码，但问题来了，接下来我们 怎样让列表中的那条评论状态发生变化（即点赞的icon由灰色变成绿色高亮，已告知用户点赞乐成）？
这就引发了文章最开始的谁人问题，当列表的状态发生了变更，怎样管理并更新列表？
方案1：再次刷新请求接口

最简单的方案是再次请求API，每当列表状态发生了变更，重新拉取评论列表，服务端返回的最新数据中，该评论天然已经被点赞了（即列表精确进行了更新）。
读者应该清楚，该方案实际并不可行，原因有二：

• 成本太高
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。