有什么好的模式可以解决新旧API负载之间的差距(在iOS时间线TableView中)？

Question

这个问题可能不适合本网站更喜欢的具体答案,并且可能会远远超出用户体验领域,但我还没有找到更好的空间来提出这样的问题,并且对它有合理的认识. .最终它是一个很好的iOS编程模式来处理这种情况.

在构建iOS应用程序时,我经常需要创建一个类似Twitter或类似Facebook的订阅源界面,或者我必须显示一个(可能)不断更新项目的大量列表.NSFetchedResultsController自然非常适合这种事情,但我遇到了解决先前加载(通常是持久化)的旧(陈旧)数据与API中的新数据之间的差距的问题.我想让用户即时访问以前加载的数据,同时加载新数据,然后通过其间的任何数据处理分页.

我为这种事情做了很好的模式.我见过的一些更好的实现已经在T​​witter上用于iPhone和Tweetbot.这是一篇关于无限加载的uxdesign.com文章的例子:

这个问题可以遍布整个地方.像Twitter或Facebook这样的时间线是显而易见的,但它也可以在显示用户的朋友/连接或其他大型数据列表时出现.以前您可能已经获得了很多结果(在我的情况下,通常是核心数据),您可以立即显示.同时,您希望提供最新数据.在很多情况下,您需要对这些数据进行分页,而不仅仅是一次性完成.

那么这里的正确方法是什么？我已经能够解决时间线方案的最佳方法,这可能是更常见的情况.

基本上我的方法是立即显示旧数据,然后从时间线请求最新的数据,并始终将最高(最新)的ID传递给API.这可能会产生新旧之间的差距,具体取决于分页量,因此一旦滚动到新页面中的最后一个单元格(或理想情况下,新旧之间的某个加载指示符),您就会请求下一个批量数据,要么请求下一页,要么传递低和高ID(来自加载行周围的项目).

这种方法在技术上很麻烦,特别是如果你想使用NSFetchedResultsController,因为你现在必须为你的加载栏的位置保留一个索引,并将任何索引路径映射进出NSFRC以包裹你的加载细胞.

如果您没有接受高ID和低ID的API,而只是使用页面,那么它也意味着大量的网络数据,因为您最终只是通过现有的持久数据进行分页.那么有更好的模式吗？我知道同步数据是一个深刻的,永无止境的领域,但我希望听到其他人有不同的模式.