Baserecyclerviewadapterhelper: 下拉加载更过不起作用...

Created on 5 Jul 2016  ·  31Comments  ·  Source: CymChad/BaseRecyclerViewAdapterHelper

设置 openLoadMore(true) 并且设置了setOnLoadMoreListener,,但是当下拉的时候onLoadMoreRequested并没有被调用....

Most helpful comment

那就写个8条,只要大于这个8并且到最后一条就会调用上拉的回调。
private boolean isLoadMore() {
return mNextLoadEnable && pageSize != -1 && mRequestLoadMoreListener != null && mData.size() >= pageSize;
}

All 31 comments

如你所见,这样确实没有卵用。这个issue 本来我提交了,但是被author关闭了。
你需要调用两个参数的 openLoadMore(size,true)才可以的。其中size是新增加的数据长度。建议author不要关闭这个issue,或者,更新文档,让大家清楚地知道该用法。

另外,我的另一个问题是,如果每次加载的数据长度是随机的,我该怎么弄呢?如果我并不清楚,新增加的数据的长度,又该如何弄呢?

下拉加载?

size只是一页显示多少个而已,并且只对第一次有用,后续你不用改size

所以长度随机也没问题,而且一般开发(我见过的开发)长度都会统一。

openLoadMore(0,true),这样你也可以,这样一进来就会调用onLoadMoreRequested

等你们试好了和我说,我再来关闭。

有什么问题随时提。

我的想法是,可以把 openLoadMore(0,true),的第一个参数去掉,因为并没有实际的作用啊。另外,服务器返回的数据长度是随机的,这个是我目前的实际需求,并不是忽悠。

如果服务器,每次最多返回20条数据,但是,可能是少于20条的。那么,我该怎么处理呢?可能第一次是返回13条,第二次返回16条这样子的。加载更多和下拉刷新调用的接口是一样的。

那么请问你一页要显示多少?如果你一个屏幕都没显示完,你还上拉吗?

加载更多和下拉刷新调用的接口是一样的。 但是是否有参数可以控制加载数据的数量?

因为我遇见的或者说我认识的都是有一定固定长度,我以前也是后台开发,当然我不能以偏概全,你也不能以偏概全,所以这样有参数是合理的,我可以在openLoadMore(true) 这个重载方法里面将size模式设置为0,这样就满足了双方的需求了,之前这么设计的考虑是因为,考虑到第一肯定是有数据的,然后在设置一个数据长度(也就是第一次数据的长度),滑到这个长度了(也就是最后一个数据了)我再上拉加载然后在调用这个onLoadMoreRequested方法。下一次其实你只要告诉我会有下一页了,我也就会又在最后一条滑到的地方调用onLoadMoreRequested方法。除非你说false了,那我就不继续加载了。

不好意思,似乎我的问题让你不愉快了,抱歉。。。

  • 一页显示的数据,就是一次请求返回的数据量。最多20条,但是可能会少于20条。20条会超过一个屏幕的。至于大于8条,就会超过一个屏幕的。一般返回的数据都会超过一个屏幕。
  • 加载更多的操作,如同下拉刷新,服务器会返回给我一组数据,依然是最多20条。我会根据是下拉刷新还是加载更多,在页面上做数据的累加显示或者重新显示。
  • 服务器返回的数据长度,没有办法控制。因为服务器会根据多个维度的参数,踢出不符合要求的数据。所以,原本是准备返回20条的数据,结果,由于一些剔除,会导致返回的数据长度不足20条。
  • 这个需求确实比较操蛋....

那就写个8条,只要大于这个8并且到最后一条就会调用上拉的回调。
private boolean isLoadMore() {
return mNextLoadEnable && pageSize != -1 && mRequestLoadMoreListener != null && mData.size() >= pageSize;
}

不好意思,文字中的情绪是我现实中出现的问题,再此我表示非常抱歉。

上拉加载更多,失效openLoadMore

?失效?什么操作具体操作 @chenbinzhou

我猜可能是,在加载更多完成之后没有调用adapter.notifyDataChangedAfterLoadMore(data,true);,而是调用 adapter.notifyDataSetChanged();导致的

恩 对了 如果你的data自己维护 你可以使用adapter.notifyDataChangedAfterLoadMore(true);

  • 我还发现一个问题,就是,如果设置adapter.openLoadMore(0, true);,在第一次手动上滑去加载更多的时候,recyclerViewscrollBars不能触碰到屏幕底部,而且,离屏幕底部还有差不多一个Item的高度,然后就直接刷新数据了。“加载更多view”也是一闪而过。你可以看一下我的demo,就知道了。https://github.com/duckAndroid/listdemo/tree/master
  • 在加载更多的时候,显示的有点不正常,突兀的感觉。加载完成之后又正常了。特别是第一次手动上滑到加载更多的时候。

首先谢谢指导,我把我的问题说一下。
openLoadMore(size, true); 初始化打开moresetLoadingView(customLoading); 设置进度view.notifyDataChangedAfterLoadMore(mList, true); 加载更多数据时候openLoadMore(size, true); 有下一页openLoadMore(false) 没下一页onLoadMoreRequested 实现这个方法经过调试发现不执行onLoadMoreRequested,请问我这边是哪里缺少设置吗?

------------------ 原始邮件 ------------------
发件人: "陈宇明";[email protected];
发送时间: 2016年7月5日(星期二) 晚上9:53
收件人: "CymChad/BaseRecyclerViewAdapterHelper"[email protected];
抄送: "黑马"[email protected]; "Mention"[email protected];
主题: Re: [CymChad/BaseRecyclerViewAdapterHelper] 下拉加载更过不起作用... (#131)

恩 对了 如果你的data自己维护 你可以使用adapter.notifyDataChangedAfterLoadMore(true);


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

我也遇到了一个问题,就是第二次加载更多时没有触发onLoadMoreRequested方法,但是loadingView是显示了的,数据是固定的10条。
另外建议setNewData方法中,先设置mData.clear(),再赋值mData = data。

我决定弃坑了。这个加载更多的坑太多了,我相信会有更好的方式来实现recyclerview的加载更多。或者使用更原始的方式,直接监听底部来完成。这个adapter 我感觉最好的地方是 adapter实现起来更加简洁。但是,加载更多,就不要了。建议author砍掉加载更多吧,将一个功能做到极致就好了。大杂烩是没法优雅的。

@duckAndroid 也不算是坑吧,只是有问题,遇到问题解决问题就行了,我至今都没找到一个完美的加载更多方法。

这是什么问题 ,调用不起来加载更多的view

作者有qq吗?加一下qq 972713831

我找到问题所在了,原来每次加载后都要notifyDataChangedAfterLoadMore(true)下一次才会加载。
源码中缺少一些必要的注释。

notifyDataChangedAfterLoadMore(true) 这个我已经找到了。但是他的坑在于,你加载更多的时候的界面的突兀。注意,一定是使用异步数据来测试,同步数据看不出效果

558178792 加Q群吧,这里面都是使用者,我最近比较忙,抱歉。

加群的时候记得带上自己的github账号的昵称

加了 请通过 在群里问问

------------------ 原始邮件 ------------------
发件人: "陈宇明";[email protected];
发送时间: 2016年7月7日(星期四) 晚上6:02
收件人: "CymChad/BaseRecyclerViewAdapterHelper"[email protected];
抄送: "黑马"[email protected]; "Mention"[email protected];
主题: Re: [CymChad/BaseRecyclerViewAdapterHelper] 下拉加载更过不起作用... (#131)

558178792 加Q群吧,这里面都是使用者,我最近比较忙,抱歉。


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Was this page helpful?
0 / 5 - 0 ratings