Bounds automatically changes on UIScrollView with content insets

Question

I\'m using a UIScrollView as my paging scroll view, pagesScrollView. Inside that, I put individual UIScrollViews which are used exclusively for zooming. Inside

Answer 1

I have checked you example use below code in viewController.m file

-(void)viewDidLoad
{
    if ([[UIDevice currentDevice] systemVersion].floatValue>=7.0) {
        self.edgesForExtendedLayout = UIRectEdgeNone;
    }
}

It's working fine...

Answer 2

It turns out the issue (described below) only appears once PAGING IS ENABLED on the UIScrollView! Wtf? :)

As you said that, If you enable the scroll paging, the UIScrollView will stop at a paging edge after a dragging or any movement, which is promised by the framework. Bounds.origin.y set by zero means that the first page edge matched the scroll view frame edge, cuz you have 64 contentInsets there. So that's not bug, that is what it is. And since your bar is translucent, remember where is your scroll view's frame edge, it's under the bar. In a word, this is not a bug, I think, but a effect of scroll paging.

Answer 3

Just switch off Adjust Scroll View Insets

Answer 4

It's an iOS bug. I created the following subclass of UIScrollView to get a log of what happens to y over time and who was pushing it:

@implementation CSScrollView

- (void)setContentOffset:(CGPoint)contentOffset
{
    NSLog(@"%0.0f %@", contentOffset.y, [NSThread callStackSymbols]);
    NSLog(@"[%@]", self.layer.animationKeys);
    [super setContentOffset:contentOffset];
}

@end

(and changed the view class in the storyboard)

When you release your finger, a method called UIScrollView _smoothScrollDisplayLink: starts animating the scroll view to its final position. As per the second log, there's no CAAnimation involved, the scroll view uses its own display link to do its own transition. That custom code appears to make the mistake of animating from y = whatever to y = 0, failing to take the content offset into account.

As a proof-of-concept hack I changed the code to:

@implementation CSScrollView

- (void)setContentOffset:(CGPoint)contentOffset
{
    contentOffset.y = -64.0f;
    [super setContentOffset:contentOffset];
}

@end

And, unsurprisingly, the problem went away.

You probably don't want to hard code the -64.0f but I'd conclude:

• it's an iOS bug;
• work around it by rejecting nonsensical values via a subclass of UIScrollView with a suitable custom implementation of - setContentOffset:.

A sensible generic means might be to check the state of self.panGestureRecognizer — that'll allow you to differentiate between scrolls the user is responsible for and other scrolls without relying on any undocumented API or complicated capturing of delegate events. Then if necessary crib the correct contentOffset.y from the current value rather than hardcoding it.

Answer 5

My pagesScrollView has contentInset.top = 64 and bounds.origin.y = -64 (that seems weird to me, but that's what the system is setting automatically for me), and this works just fine. My screen looks great!

It because of iOS 7 sets contentInset.top to 64 on all scrollviews. Just add this line of code into your view controller and all will work as expected:

-(UIRectEdge)edgesForExtendedLayout {
return UIRectEdgeNone;

}

I checked on your example project.