App分页探讨

2017-11-16  本文已影响542人  Nagi

作为一名App开发者,数据分页是很常见的需求,但在实现过程中多多少少都会存在一些问题,遇到次数多了,我就想,别人是怎么做的?有没有完美的分页方式?在研究了一些资料后,对分页有了更全面的认识。基于不同的场景,做法各不相同,各有优点和缺点,不存在完美的分页。


分页划分

先从交互设计的角度来看,在实现时首先要确定采取哪种方式,主要是Web分页和流式分页的区别:

Web分页

传统的Web分页

流式分页

典型的流式分页

在实际生产中往往采用折中的方式,比如自动加载几次后让用户手动点击“更多”继续加载,或者在信息流中间增加用于定位的页码;


再从开发的角度来看,可以分为前端分页与后端分页,这个确定主要工作由哪边来做。


前端分页不多谈,因为实现比较直接,一次性拉取所有数据,然后前端控制数据的展现量。这里着重探讨后端分页。上文已经探讨了交互分类的区别,第一种传统的Web式分页,是Web开发中常用的分页方式,实现上是Web分页接口,通过页码进行分页,一般来说,就是根据pageIndex和pageSize来进行分页。第二种流式分页,相对于Web来说,是因为App的交互方式,下拉刷新,向上滚动加载,一般并没有Web上显式的页码,在Web上清晰的页码,在App上往往是不可见的。这种方式为流式分页。流式是UI交互的分类,实现起来可以多种多样,可以采用Web式分页接口来实现。


如果流式分页上采用Web分页接口会有什么问题呢?


那么,如何解决Web分页的这些问题?


以上为研究网络上一些资料后的总结,那么,看起来可行的解决方法就是游标式分页,当分页数据需要增删改时该如何处理?


到目前为止,看起来都不错,暂不考虑多个客户端同一个账号做不同修改的同步。让我们更深一步,增删改会对原有其它数据产生影响时该如何处理?当然,全部重新拉取不少不可用,只是十分粗暴。


再更进一步,增删改会对原有数据的排序产生影响,这种情况出现在数据为多层时,例如数据按某个属性分组,增删改某个数据会对整个分组的排序产生影响,这时该如何处理?貌似到这里开发会有强烈的冲动全部重新拉取,不过如果多做一点,也可以避免。


接口实现的可能形式

上一篇下一篇

猜你喜欢

热点阅读