UIRefreshControl disappears

[Ufosek]

I use TLYShyNav in my UITableView. I also added a UIRefreshControl to it.
let refreshControl = UIRefreshControl()
refreshControl.tintColor = UIColor.blackColor()
refreshControl.addTarget(self, action: "didRefreshed", forControlEvents: UIControlEvents.ValueChanged)
scrollView.addSubview(refreshControl)

And the problem is when I set self.shyNavBarManager.scrollView = self.tableView refresh control disappears when refreshing. When just dragging everything is ok but when beginRefreshing is called refresh is disappeared. Its similar to #28, but I test it on real device and I don't see any flickering.
What may be the issue?

Here are logs from didRefreshed
with shyNavBarManager (why is it hidden?!)
Optional(<UIRefreshControl: 0x126623970; frame = (0 -66; 375 60); hidden = YES; autoresize = W; tag = 665; layer = <CALayer: 0x17422a800>>)
without
refresh = Optional(<UIRefreshControl: 0x14c6277b0; frame = (0 -74.5; 375 60); autoresize = W; tag = 665; layer = <CALayer: 0x174230620>>)

[Mazyod]

Thanks, I don't have an idea why it flickers. UIRefreshControl has been flaky since its inception. Anyway, why worry about it if its on simulator only?

[Ufosek]

It does not flicker, and I test it on real device as I said. It just disappears just before didRefreshed is called.

[chrisvxd]

+1, I also have this issue. The library is causing the UIRefreshControl to disappear once the refresh has been initiated, and the ScrollView bounces back over the Refresh Control.

[Mazyod]

@Ufosek my bad, I should've read the issue better. Ok, I get the issue, and will hopefully work on a fix soon!

[dewinni]

+1, I also have this issue. The library is causing the UIRefreshControl to disappear once the refresh has been initiated, and the ScrollView bounces back over the Refresh Control.

[BenchR267]

We have the same problem. What I found out: the control gets moved up for 60pts, which is the exact height of the refresh control itself.

[maxkattner]

Hey @Mazyod, do you have any idea when you will get to work on this issue? Together with @BenchR267 I took a look at it for one day, but we were struggling finding any hint what leads to this 60pts jump. So sadly we don't have further information for you. :/

[Mazyod]

Thanks guys, I am looking at spending some time fixing issues over the next couple weeks.

[rmato]

+1 I have the same issue :(

[Mazyod]

This issue is proving to be quite troublesome .. As soon as I find a way to avoid breaking the refresh control, the UITableView headers break .. They might need to be handled manually by the user of the component by disabling the shy behavior when the refresh control is active.. I'll post back with more on this.

[Mazyod]

For those looking for a quick way to work around this issue, here is a hack:

// Add this in TLYShyScrollViewController.m, instead of the original tly_setInsets call 
if (intelligently || fabs(delta + 60.f) > FLT_EPSILON)
{
    [self.scrollView tly_setInsets:insets preserveOffset:intelligently];
}

Of course, this magical 60.f is the height of the refresh control. This tells the component not to update the bounds if the change happens to be 60.f.

Caveats

1. If you have tableView headers, they will not work properly when you scroll while refreshing.
2. Might break if the extension view height is 60.f, not sure.

Still looking for a better way...

[DanielRakh]

Can you be more specific about where to implement this hack? I'm working in Swift and using ShyNavBarManager.

[Mazyod]

@DanielRakh it's written specifically above, in TLYShyScrollViewController.m, instead of the original tly_setInsets call

[DanielRakh]

@Mazyod sorry I must be missing something. What is this TLYShyScrollViewController.m you're referencing? In Swift, I'm just using the .framework.

[BenchR267]

@DanielRakh It would be the best to include the framework via Cocoapods. Just fork the original repository, make the changes @Mazyod was saying and link to your fork in the Podfile.
Thanks @Mazyod I'll take a look at it today!

[Mazyod]

@DanielRakh My bad, I didn't realized you were going the Framework approach. @BenchR267 has the right approach, thanks!

[BenchR267]

@Mazyod it's working fine for us, thanks! We will switch to the original repository when the bug is fixed :)

[DanielRakh]

@BenchR267 @Mazyod got it. Thanks guys!

[Mazyod]

@BenchR267 Thanks for reporting back 👍

[hlung]

Looking forward to seeing this fixed! Any progress? :)

[ikousik]

Got the same issue!! Any update?

[BenchR267]

There is no official bug fix, just this work around. You can use our fork until the bug is fixed in the original version if you want: https://github.com/lovoo/TLYShyNavBar

[ikousik]

Cool !! Why don't you pull request?

[BenchR267]

As you can see in the code changes, this is just a quick fix that might break in some cases. (A value is set to a magic number of 60.0). @Mazyod any news on a fix that is not just a hack? :)

[szweier]

The fix I used is still hacky but moved a little earlier than the method suggested above.

In TLYShyScrollViewController.m I changed

if (self.scrollView.contentSize.height < FLT_EPSILON
         && ([self.scrollView isKindOfClass:[UITableView class]]
             || [self.scrollView isKindOfClass:[UICollectionView class]])
         )
    {
        return 0.f;
    }

to

if ((self.scrollView.contentSize.height < FLT_EPSILON
         && ([self.scrollView isKindOfClass:[UITableView class]]
             || [self.scrollView isKindOfClass:[UICollectionView class]])
         ) || (self.scrollView.contentOffset.y <= -64))
    {
        return 0.f;
    }

64 seemed to be the offset of the scrollview when pull to refresh was visible.

[szweier]

For those following along I think I've found a fix and made a PR #122 , please give it a try, it'd be good to see if the fix works in other scenarios.

[ikousik]

can you please look into ISSUE 120. I am not able to find any fix for this.

[roosmaa]

Setting hasCustomRefreshControl = true (introduced with #134) fixed this issue for me when using UIRefreshControl.