在上篇文章中我们主要讲到Jetpack中Paging库的分页原理，乍一看这个库解决了很多在实际开发中遇到的棘手问题，比如配合Retrofit以及Room解决网络请求数据持久化问题等。
然后看似强大的框架在使用的时候并不是那么简单，同样会遇到很多意想不到的问题，那么今天我们就通过这篇文章揭露一下Paging库在开发中需要注意的细节。
数据查询
使用Paging的时候就难免会用数据库，Paging的数据源是通过数据访问对象DAO提供的，那么在写查询语句的时候千万要注意一点，那就是不要忘记加排序，如果不加的话在编译的时候就会报异常，所以我们应该在SQL语句中指定一个整型字段升序还是降序。
而这个排序字段就是DAO中方法返回类型DataSource.Factory中的Key，它能唯一地表示数据项在表中的位置。当然了这个字段可以是主键ID，但是通常做法是在实体中增加一个整型字段，比如indexInReponse。
网络请求参数
上篇文章中我们介绍过，Paging中加载更多会调用BoundaryCallback的onItemAtEndLoaded方法。这个方法中的参数是列表上显示的最后一个实体对象，而不是我们通常网络请求接口中的参数page和size，这让很多安卓开发者不知所措。
那么如何根据实体对象算出对应的page和size呢？其实很简单，我们可以用上面的indexInResponse计算出当前所在的页数，然后将页数据加1便得到了需要给接口传入的参数。
数据更新
很多开发者在使用Paging的时候都遇到递归问题，基本上是BoundaryCallback的onZeroItemsLoaded方法和onItemAtEndLoaded方法被无限循环调用了。
其实根源就在数据更新的时候更新到数据库的数据与数据源中数据不匹配，我们以onZeroItemsLoaded为例，比如初始状态列表显示为空，并且数据源我们指定的是姓名为“张三”的所有数据，但是从网络上请求的数据以后把姓名为“李四”的数据库插入到表中，这时候Paging又会执行一次查询操作，结果发现数据源中找不到姓名为“张三”的数据，所以会再次执行方法onZeroItemsLoaded，以此便形成了不良递归。
所以杜绝这个问题最根本的方法就是一定要保证更新的数据与数据源中的一致，onItemAtEndLoaded循环调用的情况类似，这里就不再赘述了。
好了，那么今天关于分页库Paging在开发过程中的接入注意事项就讲完了，希望大家看了上面几点以后遇到问题了可以少走一些弯路。
举报/反馈
1711
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
