SVPullToRefresh
SVPullToRefresh copied to clipboard
Pull to Refresh activates Infinite Scrolling
My set up is very simple:
__weak MyClass *weakSelf = self;
[self.tableView addPullToRefreshWithActionHandler:^{
[weakSelf refreshPollData];
}];
[self.tableView addInfiniteScrollingWithActionHandler:^{
[weakSelf loadMorePollData];
}];
Infinite Scrolling gets called even though only Pull to Refresh should be called. Could this be because I don't have many rows in my table?
Hmm yeah that could be. I thought this was fixed a while ago, I'll try to give it another look soon.
Yes, I encountered the same problem when number of cell in a tableview, say 1, is small.
Issue #96
The fix: showsInfiniteScrolling
should initially be set to NO if the scroll view's content height is lesser than its frame. If anyone wants to jump ahead and make a pull request for this, would be much appreciated.
all if we set showsInfinitsScrolling to NO but if we want drag to load more data how handle to visible the infinite view?
my solution: 1、when view did appear: add pull and infinities action handler and trigger refresh action. 2、after pull refresh callback , invite: [self.tableView showsInfiniteScrolling]; 3、change the showsInfiniteScrolling method as follow: // return !self.infiniteScrollingView.hidden; return self.showsInfiniteScrolling = self.contentSize.height < self.frame.size.height ? NO : YES;
+1. @anhuijhy brings up a good point. Sometimes the initial list may be small. e.g. "Get all the results since yesterday" has no guaranteed length -- but we'd still want the infinite scroll enabled if we wanted each "up swipe" to load the previous day's results.
Any way to differentiate between the two swipe types (up vs. down) if the view is shorter than the frame?
Check if the scrollView.contentOffset.y greater than 0 before changing state work for me. In UIScrollView+SVInfiniteScrolling.m:
- (void)scrollViewDidScroll:(CGPoint)contentOffset { if(self.scrollView.contentOffset.y > 0 && self.state != SVInfiniteScrollingStateLoading && self.enabled) { ... }
PR #245 has @siliconprime-duc 's fix in case this project is still alive :bow:
I think #260 fixes this.