When I push to a UIViewControllerB and then pop back to UIViewControllerA entire view of UIViewControllerA is about 20 px higher then it should be and in a moment (I guess after viewDidAppear) it moves to its normal position. I do not manipulate constrains or UINavigationBar settings in any way while this. I do have all elements of UIViewControllerA top space to top layout guide. What might cause this? I've worked with storyboard a few and have never faced something like this.
Try adding view.layoutIfNeeded() in your viewDidLoad or viewDidAppear.
The most recent XCode adds some new behaviors. Try setting the constraints of UIViewControllerA to have the top one be flush with the bottom of the UINavigationBar.
This was somehow caused by removing subview, I've added to cover screen while loading data: after removing this subview, constrains where changed (this only happened on this UIViewController, other UIViewControllers with this subview are fine). I've fixed it by doing this:
self.stopLoading() //removes subview
self.view.layoutIfNeeded()
Related
in iOS 13 it happens that the view of UIViewcontroller that is presented as model starts from the tip of the arrow. Because of it top banners in all of my popover gets cut. Can I prevent this from happening ? I want that my UIView does not start from arrow but once arrow is finished.
To fix this issue, I opened up my view controller's XIB, selected the top-most view, and then checked "Use Safe Area Layout Guides" under the File Inspector. Then I added Auto Layout constraints (of length 0) around that view's sole subview (a UITableView).
(I also needed to update the view controller's background colour. This changed the arrow colour back to what it was in iOS 12 and before.)
Background: https://forums.developer.apple.com/thread/122703
I wonder if your contentView contains UIScrollView. If yes, please add alwaysBounceVertical = YES to your scrollView. It works in my case.
I don't know why they changed this behavior, it can be a pita to deal with it if you are not using xibs. I couldn't find anything in the docs about it.
Use the safe areas to adjust the position of your view. You can both try to extend the size of that red area, or skip the arrow completely. In this particular case you can use safeAreaInsets.top if the arrow is going to be on the top always.
I have a View inside a ScrollView inside my main View
The problem is that my scrollView have a bad default contentOffset.
His value is (0, -64) in portrait
The Apple doc says
The default value is CGPointZero.
I put this code on my controller to temporary handle it :
dispatch_async(dispatch_get_main_queue(), {
self.scrollView.setContentOffset(CGPointZero, animated:false)
})
Why my contentOffset have not the good default value ?
It's probably an issue with the view insets.
On your XIB/Storyboard for your view controller, make sure to uncheck the Adjust Scroll View Insets
or in your code add self.automaticallyAdjustsScrollViewInsets = false
Swift 4.2+
scrollView.contentInsetAdjustmentBehavior = .never
I found the explanation on this website:
http://www.codelord.net/2013/10/18/adapting-scroll-views-to-ios-7/
Handling navigation bar on top of our scroll view
The iOS 7 view of course comes with the new look where scroll views go under the navigation bar for a nice effect. One can change the scroll view’s contentInset manually to cover for the portion of it that is being overlapped at the top, but doing so manually is tedious and not fun. I was very thrilled to discover handling it should come at no cost if my ViewController has automaticallyAdjustsScrollViewInsets set to YES.
This didn’t work for me out of the box since it turns out for the magic to happen the scroll view has to be the first subview of your ViewController’s UIView. I had to reorder my subviews and then the magic started rolling.
As below image shows, in the storyboard, I put a UIScrollView (say called A) under navigation bar and another UIScrollView (say called B) inside A. B is at the top of A.
However, in the simulator, there is big margin between B and the up bound of A (I didn't use any autolayout or write any code). Can anyone tell me the reason? Thanks.
add the below line in your - (void)viewDidLoad method
self.automaticallyAdjustsScrollViewInsets = NO;
hope it will fix your issue.
Even though you're not using Auto-layout, you have Auto-layout checked on in your Storyboard. Because you do, UIScrollViews and any Subclasses of it (UITableView, UICollectionView, etc.) all automatically adjust for the UINavigationBar height when in a UINavigationController. This is implicit and there's no way to turn it off. The only solution is to "offset the offset" or to move the UIScrollView away from the UINavigationBar.
The big margin size is navigation bar height, try add a top autolayout for your scrollView.
I've seen similar questions about custom transitions(iOS7 Custom ViewController transition and Top Layout Guide and Navigation controller top layout guide not honored with custom transition), but I have problem even with regular push. I'm using latest Xcode available now (Version 5.1.1 (5B1008)).
Here is my storyboard:
Problem occurs in 3rd VC
Here is 3rd VC settings:
My 3rd controller's layout is follows:
UIView
UIScrollView
InnerUIView
Other views
I've tried two different ways to create a layout:
Ignore top layout guide (it has y = 64 because of nav bar)
I pinned scrollview's top to container (ignoring topLayoutGuide), manually set height of inner view and pinned its top to scrollView. It gave me the following result:
Looks fine, but why do I need top layout guide then?
Use topLayout guide
ScrollView's top is pinned to topLayoutGuide.
As you can see, top button moved down and view looks strange.
What is the right way of creating such layouts?
I had the same problem and spent hours pulling my hair out.
My container view inside scrollview had weird top offset despite the fact that it had top constraint set.
The workaround I've found - you have to uncheck Adjust Scroll View Insets in your controller layout options
that way content view (in my case) stays pinned to scrollview's top.
Unfortunately I couldn't find any reasonable explanation of this behaviour.
In my case, Xcode 7 and 8, I had to uncheck the 'Adjust Scroll View Insets' for the Views in my Navigation View Controller. And yes, it wasted too much time before I figured this out.
EDIT: Apple has found out that we have found a solution, so they managed to break this again in XCode 9 and 10, to keep us developers pulling our hair. Haven't found a solution yet.
I have a UIScrollView filled with subviews, all is well when creating it and initially filling it.
But when I add a new subview that is positionned outside of the visible screen portion, or when I just resize an existing subview that is also outside of the visible screen portion, there is a subsequent 0.3s-long scroll animation (I can see it happening from my delegate) that seems to match the newly added/resized element.
Attempts:
pagingEnabled is always NO.
Setting scrollEnabled to NO during subview manipulations doesn't help.
Doing a setContentOffset:animated:NO after subview manipulations doesn't prevent the animation.
One single giant subview with all my subviews in it doesn't help.
My current workaround is to initially set the frame to fit inside the visible screen portion, or doing resizing work inside another superview, but it feels dirty, and won't handle all situations...
Is there a way to prevent this automatic scrolling animation when programmatically manipulating subviews?
Xcode 4.3, iOS SDK for 5.1.
I too discovered this problem and found this solution http://www.iphonedevsdk.com/forum/iphone-sdk-development/94288-disabling-uiscrollview-autoscroll.html
It involves subclassing the UIScrollView and entering no code in the following method.
- (void)scrollRectToVisible:(CGRect)rect animated:(BOOL)animated {
}
Like the guy says on the link I've found it works and no problems so far. Hope it works for you.
I had this problem because I set the content size of the scroll view prior to adding the subview.
As soon as I change the code so that the content size of the scroll view was set after adding the subview the problem went away.