UI glitches when scrollView.pagingEnabled

[joedj]

Hiya,

Thanks for MSPullToRefreshController!

I've been trying to get MSRefreshDirectionLeft working on a scroll view with pagingEnabled = YES (the UI is similar to the weather widget in the notification centre), and haven't been having much luck.

It doesn't always bounce back to the inset returned by - (CGFloat)pullToRefreshController:(MSPullToRefreshController *)controller refreshingInsetForDirection:(MSRefreshDirection)direction. Works fine if I disable pagingEnabled.

Currently the best workaround I have is disabling paging in canEngageRefreshDirection and re-enabling it again in didEngageRefreshDirection after a short delay (and didDisengageRefreshDirection).

I can attach some sample code if you have any interest in helping out with this.

[bogardon]

oops. i'll take a look. can you attach your code in the mean time?

So I just tried this out myself. What I'm seeing is that it does go back to the inset, except that it is does not do it smoothy. Is this what you see as well?

[joedj]

Thanks.

Sample code here:
http://joedj.net/pulltest.tgz

Video of behaviour here:
http://youtu.be/7Llbfzse2dQ

[bogardon]

I'm definitely getting the same behavior you're getting when I use your viewcontroller. Namely, it doesn't stop at the declared inset, and where it stops seems random.

What's interesting is, if I set your HEIGHT constant to 25, I get the behavior I was talking about. Namely, it always stops at the declared inset, except it skips there.

Without knowing how pagingEnabled works underneath, this will be hard to fix....

[joedj]

No worries, at least I'm not crazy. Don't feel like you have to fix it on my account :) I already released my project using the delay workaround I mentioned in the initial post:

https://github.com/joedj/purchasestats
(specifically https://github.com/joedj/purchasestats/blob/master/PurchaseStatsView.m#L249 )

[workwithnano]

Would there be any harm in using @joedj's fix within the library since it has access to the scrollView?

[joedj]

Note that my workaround isn't perfect. For example, if you pull the view such that canEngageRefreshDirection fires, then release it a little bit until didDisengageRefreshDirection fires, and then pull it back so that canEngageRefreshDirection fires again, the content offset jumps a bit. I don't know why this happens...

Still, it's good enough for me :)

[JohnCoulton]

Hmm, I'm assuming with the note of "wontfix" this isn't on the dev radar? I'm experiencing the same problems described above and the proposed hack-around is causing more problems than it's fixing. I'm going to be working towards my own solution, but for what it's worth, I'd like to add a little +1 to the investigation of this if possible.