一个简单的做法是这样的:
当我们收到下一页请求时,我们可以简单的用相反的流程从请求中获取我们创建的JSON对象。
如果其他人用base64去解码blob呢
这是肯定的,所以你可以选择先把JSON进行加密。你也可以选择不把DynamoDB请求作为分页基础。
你是否注意到了,在图1和图2的例子中,客户端仅在后续请求中发送cursor?这是设计使然。
我之前提到过,客户端已经告诉我们请求是第一次请求,分页机制只在后续的请求中提供分页信息。对于我来说,这意味着分页机制不应该包含任何其他行为,除了上一次请求的cursor。反过来说,这意味着我们需要在curor中捕获取原始查询条件,以便我们构造数据库查询语句。或者我们在cursor中获取实际数据库请求,这似乎又是一个简单而实用的解决方案。
双向分页中使用cursor
使用双向分页时,你需要能够及时向前(将新的内容添加到时间线中)和向后(获取旧的内容)进行分页。因此简单的字符串cursor已经不能满足需求,我们需要两个cursor,每个方向使用一个例如:
{ "before": "iwnVn1a8N", "after": "M82B111C"}
此外,在向前分页时,即使没有更多的结果,我们仍需要返回cursor,因为以后可以将新结果集添加到源中。因为我们还需要一对布尔标识:
{ "before": "iwnVn1a8N", "hasBefore": true, "after": "M82B111C", "hasAfter": true}
当客户端获取分页信息并接收到 hasAfter标识为 false时,它就知道后续暂时没有更多结果。因此它可以决定不去主动获取下一页的结果,而变为被动定期轮询新结果。
让我们用一个简单的例子来说明一下,想象一下如果你推特的时间线中获取推文,那么API会首先返回最新的推文。
好的,让我们再运行另一个例子,这次我们按时间线向前翻页。
现在前端分页,让我们回到之前提过的分页过程中偶尔需要改变方向的问题。
我们分页的原因是因为将所有的结果集一次性返回是不切实际而且低效的,例如:把凯蒂·佩里的108M的推特粉丝列表在一次请求-响应的过程中返回,那么服务器和app都会瘫掉。
除了限制在一次请求-响应过程中返回数据的多少之外,我们还需要对app将缓存的数据量设置上限前端分页,以提升用户体验防止app崩溃。
这意味着,在某个时间点,随着用户不断滚动浏览旧推文,客户端将需要开始删除已获取的数据,否则可以会将内存耗尽。也就是说,当用记向后举动查看推文时,客户端将需要重新获取已删除的数据,从而反转分页的原始方向。
幸运的是上面所述的方案足够灵活,可以满足你做到这一点。每一页结果都有一个关联的cursor,使你可以从任何方向获取到下一页。因此如果你需要获取被销毁的页面数据,就像你获取最新页面一样简单。
处理间隔
还是拿推特的例子来说。如果关闭推特app后,过段时间再打开推特,你发现推文已经被缓存到了app中;你也就意识到所有的从缓存中进行分页的方法不够灵活。相反,客户端可以使用非分页请求获取最新的推文。向下滚动时客户端按照图中所示的方法用自动获取较旧的页面,并填补间隔,直到它与缓存的数据结合在一起。
推特app的策略随着时间的推移发生了改变,我看到的另一种策略是在时间轴中放一个可视可点击的标记,以标记缺失的推文。这使得用户有了可以选择的空间,来自己决定是否翻阅旧的推文来填补间隔。
这就是我分享的实现单向和双向分页的简单有效的方法,希望它对你有用!
限时特惠:本站每日持续更新海量设计资源,一年会员只需29.9元,全站资源免费下载
站长微信:ziyuanshu688