Fix small-loading time bug. #32

Open
wants to merge 1 commit into
from

Projects

None yet

3 participants

@henryeverett

Added animation delegate to re-check if data is finished loading. This fixes a bug which causes the loading view to display indefinately if the data is loaded before the pull-down animation is complete.

There may well be a better way of doing this, but it demonstrates the problem. Demo files updated too.

@henryeverett henryeverett Added animation delegate to re-check if data is finished loading. Thi…
…s fixes a bug which causes the loading view to display indefinately if the data is loaded before the pull-down animation is complete.
4933a28
@DimaVartanian

I implemented a fix that doesn't require any code changes outside the component

https://gist.github.com/3661149

just perform the animation by calling performSelector with a delay of 0.0.

@ying22
ying22 commented Sep 9, 2012

Actually the problem is incorrect ordering when setting state in egoRefreshScrollViewDidEndDragging.
You need to first set state to loading and start animation...then trigger the refresh.
So all you need to do is flip the ordering:

https://gist.github.com/3682890 (see this instead: https://gist.github.com/3695472)

@DimaVartanian

@ying22 : I tried your fix and it does not fix the problem for me.

You can test a fix for this problem in the sample project by removing the delay off of [self doneLoadingTableViewData] in the egoRefreshTableHeaderDidTriggerRefresh function in the demo view controller. Changing this will cause the animation to continue indefinitely.

It is fixed in my fork: https://github.com/dim1014/EGOTableViewPullRefresh

@ying22
ying22 commented Sep 10, 2012

I tested it by changing egoRefreshTableHeaderDidTriggerRefresh to:

[self reloadTableViewDataSource];
[self doneLoadingTableViewData];
//[self performSelector:@selector(doneLoadingTableViewData) withObject:nil afterDelay:0.0];

What version simulator are you using?

@DimaVartanian

Yep I see it now. Your solution solves the problem. However, it causes the arrow and view to jump very abruptly. Adding that tiny delay on it will cause it to still animate very briefly and dismiss the usual way in all cases. I like your solution because it is less hacky, but will stick to mine to maintain a smoother animation.

@ying22
ying22 commented Sep 11, 2012

I see, then there are two ways to do this depending on what version of iOS you want to run on..with or without block support.

https://gist.github.com/3695472

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment