Dismissing Modal View Controller causing layout problems - ipad

I have a UIScrollVIew in a Navigation controller, I present a Modal View controller from the Navigation controller, which works fine. When I dismiss the modal view controller (from the parent), all the content in my UIScroll view gets moved around and paging is broken. The contents of the scroll view are added programmatically, but the scrollView was created in IB.

Sounds like it has to do with autoresizing behavior as well as the autoresizing masks. In IB, turn off "Autoresize Subviews" in relation to the ScrollView.
Also check its autoresizing mask: does it make sense? Play with its mask and trouble shoot from there. When you create views programmatically, the default autoresize mask may have unexpected behavior.

Related

Adding subview to UITabBar that goes behind other UITabBar subviews

I am trying to add subview to UITabBar which should be behind other UITabBar Subviews.
I added the subview like this in my subclass of UITabBarController:
self.tabBar.addSubview(CustomTabBarController.xView!)
and then I send it to back as below:
self.tabBar.sendSubview(toBack: CustomTabBarController.xView!)
Problem is it doesn't go back and always appear infront. Also, even when this is the case, I am able to tap on tabbaritems. Is something wrong with UITabBar properties? or else, What am I doing wrong?
A view that a subview of view A can't be behind view A. Think of a subview as being on the page of it's parent view.
It's also likely that a tab bar does not allow you to add subviews to it. Apple's UI controls are usually built to fully manage their view hierarchies, and the results of trying to insert subviews or otherwise mess with the view hierarchy are often undefined.
If you want a view to be behind another view the two views need to have the same parent view. You need to tell the tab bar's superview to add your new view behind the tab bar:
self.tabBar.superview. insertSubview(CustomTabBarController.xView!,
belowSubview: self.tabBar)
Also note that your use of force-unwrapping is ill-advised

Why is a UIToolBar's height not being taken into account by bottomLayoutGuide and automaticallyAdjustsScrollViewInsets in iOS7 (with autolayout)

I haven't been to find anything about this, and it may be that there is no easy solution.
I have a scroll view (in this instance a UITableView) which is the first subview of my UIViewController's view (which is not itself a scroll view). This view controller is in a UINavigationController, and I have also added a UIToolBar as second subview of the view controller's view. Both the table view and the toolbar are positioned and sized in the view controller's view using autolayout (with the table view filling the view, and the toolbar being pinned to the bottomLayoutGuide of the view controller).
As I understood it, navigation bars and toolbars (which are pinned to the bottom of views) should influence the topLayoutGuide and bottomLayoutGuide of the view controller, and by this influence the contentInset of contained scroll views.
The navigation bar is being taken into account (by the topLayoutGuide and automaticallyAdjustsScrollViewInsets) so that my table view content scrolls underneath it, but is visible below it, but my UIToolBar is not - either by bottomLayoutGuide or automaticallyAdjustsScrollViewInsets. This behaviour is the same even if I position my toolbar with a frame (not using constraints).
Am I right in thinking that a UIToolBar pinned to the bottom of the view controller's view should be taken into account by the layout guides? If so, does anyone have any ideas as to why it is not?
If not, is there anywhere (amy method) where I can manually add the tollbar frame to the bottomLayoutGuide so that it is automatically propagated by automaticallyAdjustsScrollViewInsets? And if not, in what method is it best to manually set the table view's content insets?
If you added one yourself it would just be a subview and would not affect the layout guides. Use the built in UIToolbar by setting the UINavigationBar .toobarHidden = false property. Then set the UIViewController.toolbarItems = ...
This toolbar will be your bottom layout guide

Parent UITableViewController not rendering when child rotates

The app I am building is having some issues when navigating in landscape mode.
This is how the table looks in portrait
but if I go to one of the child navigation items rotate and then navigate back in landscape it looks like this
I have tried everything I can think of and cannot fix it, I am using auto layout and storyboards
I'm guessing the table view isn't the main view of the view controller (i.e., self.view). Perhaps you dragged a table view from the object library onto the canvas for your view controller's storyboard scene. When you do that, the default implicit constraints created by Xcode will produce the situation you described upon rotation. You need to create your own explicit constraints in the storyboard that pin the four sides of the table view to its superview.

UIPageViewController not respecting the top layout guide in iOS 7

I am using a page view controller to flip through a series of view controller, each of which is instantiated from a storyboard. I basically used the standard page based application code as a basis and built what I needed on top of it. The view controllers I'm flipping through are UITableViewController subclasses or custom view controller's that contain custom scroll views or what not.
The page view controller is embedded in a navigation controller, but none of the view controllers are respecting the top layout guide, even though the constraints are set to the layout guides in the storyboard in the case of my custom view controllers and I thought that the table view controller would manage this automatically. I mean the view's contents start from (0.0, 0.0) instead of where the user can see it. The only thing that works is actually setting the frames of the view controller's views to begin just under the status bar + the navigation bar, but I want the scroll view's to scroll under the transparent navigation bar.
What am I doing wrong or not doing?
It sounds like you don't want your content view controller's to underlap the navigation and status bars. If that's the case, try setting parent view controller's edgesForExtendedLayout property to UIRectEdgeNone.
// implementation of page view controller's parent view controller
- (void)viewDidLoad
{
[super viewDidLoad];
self.pageViewController = ...
...
self.edgesForExtendedLayout = UIRectEdgeNone; // iOS 7 only
}
For me, setting automaticallyAdjustsScrollViewInsets = NO; on the UIPageViewController fixed the issue. You can change that in the Interface Builder, under Attribute Inspector, uncheck "Adjust Scroll View Insets".
On storyboards:
Uncheck values in parentviewcontollers "Extend Edges" section

UIScrollView inexplicably moving out of position

I have a UIScrollView added and positioned via Interface Builder, as part of a view controller on a navigation controller stack. When I push a new view controller onto the stack, then pop that new view controller, the UIScrollView in the original view has drifted upwards by exactly 52 pixels.
This ONLY happens on the device, and not the Simulator.
Any ideas what might be causing this? I can fix it retroactively with calls to re-position in the viewWillAppear/viewWillAppear, but for some reason on a very few occasions even this doesn't work, so I'd really like to fix the root cause. Thanks!
Note in response to comments: I'm hiding the navigation bar in the pushed view controller, but not the original view controller. Also note that there are several other UIView elements on the original view controller, but it's only the UIScrollView which is moving out of position.
Update: not hiding the navbar in the pushed view controller has no impact on the UIScrollView problem - but thanks for the suggestion, commenters.
Fix: if the navigation bar is being hidden on a view controller, and you don't want any subviews (which you added via Interface Builder) automatically re-positioning in unexpected ways, make sure the struts on the subviews are set to be fixed.

Resources