I have a scenario where I needed to add an animation inside the Navigation Bar, but the simulator doesn't animate. I add a UIView, add a label/text field and create outlets for the constraints and update them with "UIView animateWithDuration:" Instead, the simulator just updates the constraints and displays the view accordingly, but without any animation. I have tried it by modifying both constraints as well as frames (separately).
[self.view layoutIfNeeded];
[UIView animateWithDuration: 3
delay: 0.0
options: UIViewAnimationOptionCurveEaseInOut
animations: ^{
self.constraint.constant += 60;
NSLog(#"inside animation");
[self.view layoutIfNeeded];
}
completion:nil];
This is shown when I increment the width constraint by "60" in viewDidLoad: . And it comes out non-animated.
When I configure the constraints (increment width by "60") through a button click, even a static updation doesn't happen.
The same code works perfectly outside the navigation bar inside the UIView, though.
Appreciate any help...
If your navigation bar contains some animation, then you could try out drawing custom navigation bar. Here's what you've to do :
In your view controller in viewDidLoad() method add the following code
self.navigationController.navigationBarHidden = YES;
After that using a UIView create a custom navigation bar with frame adjusted to be visible and top.
After that add components on the view and start working with animations.
You can achieve that by taking custom UIView and create width NSLayoutConstraint outlet to it and in code you can handle the constant property of this variable by calling UpdateConstraintsIfNeeded or UpdateViewConstraints method before calling animation code
Ok, I've solved this at last. Phew...
What I did was...
Added a view in place of barButtonItem (let's call this "superView") and over it another view (and let's call this "subView") so that I get the following configuration.
Constraints were set between subView and objects on top of it. Now, I created outlets (superView and subView) for superView and subView, made them transparent (optional, of course).
Useful note: Set the superView's width to the default bar button item's width and the subView's to the screen width. Disable "Clip Subviews" on superView but enable on the subView.
Added animations as needed where I had wanted, but layoutIfNeeded on the "superView", not the parent view.
[self.superView layoutIfNeeded];
Good luck.
I am using a UIPageViewController. When the in-call status bar is toggled while in this view, it adjusts fine. If the in-call status bar is open before the UIPageViewController is loaded, the page gets pushed down by 20pt and a black bar is shown in that space.
Here's a screenshot of what this looks like:
Other posts recommend using setting automaticallyAdjustsScrollViewInsets on the page controller to NO. I've already tried that and it does not work. I've also tried self.edgesForExtendedLayout = UIRectEdgeNone;
Setting the origin of the UIPageViewController frame to 0 works, but feels wrong:
CGRect frame = self.pageController.view.frame;
frame.origin.y = 0;
self.pageController.view.frame = frame;
I ended up resolving this by ensuring the right constraints were on my view controller's main view. Here is an example where I am adding a view controller's view as a subview to a root view controller and then using Masonry (https://github.com/SnapKit/Masonry) to establish constraints that will snap all the child view controller's main view's edges to the root view controller (which itself already has autoresizing masks in place from Interface Builder). This resolved my issue of the status bar leaving that black space because it was pushing this view down (rather than re-sizing):
[self.view addSubview:viewController.view];
[viewController.view mas_makeConstraints:^(MASConstraintMaker *make) {
make.edges.equalTo(self.view);
}];
In your case, and I don't have your full code so I don't know for sure but something like:
[self.pageController.view mas_makeConstraints:^(MASConstraintMaker *make) {
make.edges.equalTo(self.pageController.view.superview);
}];
.. ought to do the trick.
I got a view controller hierarchy with the following parent-child relationship:
UINavigationController (contains) MainViewController (contains) UIPageViewController (contains) UITableViewController
In the inner-most UITableViewController, I have automaticallyAdjustScrollViewInset set to YES, however this setting doesn't seem to work. As can be seen in the screenshot below, the table view's contentInset doesn't seem to be adjusted with the navigation bar.
My goal is to have this table view's contentInset to be automatically adjusted with the outer-most navigation bar. If the navigation bar or the status bar is hidden, I want the content inset to adjust accordingly.
How can I do that? Thanks!
The UINavigationController adjust its child view controller's topLayoutGuide automatically.
In your case it is not being propagated down far enough.
If you make sure this topLayoutGuide makes it down to your table view controller then you won't have to set the contentInset manually.
Also, your view controller hierarchy seems overly complex (I don't know the details of your project). This simplified version of what you have will give you what you are after for free.
Apparently the outer-most UINavigationController is still accessible to the inner-most UITableViewController via its navigationController property.
Because the navigation bar's frame is accessible by the inner-most view controller, we can do something like this in its viewDidLayoutSubviews.
- (void)viewDidLayoutSubviews
{
[super viewDidLayoutSubviews];
self.tableView.contentInset = UIEdgeInsetsMake(CGRectGetMaxY(self.navigationController.navigationBar.frame), 0, 0, 0);
self.tableView.scrollIndicatorInsets = self.tableView.contentInset;
}
I have a UIPageViewController with translucent status bar and navigation bar. Its topLayoutGuide is 64 pixels, as expected.
However, the child view controllers of the UIPageViewController report a topLayoutGuide of 0 pixels, even if they're shown under the status bar and navigation bar.
Is this the expected behavior? If so, what's the best way to position a view of a child view controller under the real topLayoutGuide?
(short of using parentViewController.topLayoutGuide, which I'd consider a hack)
While this answer might be correct, I still found myself having to travel the containment tree up to find the right parent view controller and get what you describe as the "real topLayoutGuide". This way I can manually implement automaticallyAdjustsScrollViewInsets.
This is how I'm doing it:
In my table view controller (a subclass of UIViewController actually), I have this:
- (void)viewWillLayoutSubviews {
[super viewWillLayoutSubviews];
_tableView.frame = self.view.bounds;
const UIEdgeInsets insets = (self.automaticallyAdjustsScrollViewInsets) ? UIEdgeInsetsMake(self.ms_navigationBarTopLayoutGuide.length,
0.0,
self.ms_navigationBarBottomLayoutGuide.length,
0.0) : UIEdgeInsetsZero;
_tableView.contentInset = _tableView.scrollIndicatorInsets = insets;
}
Notice the category methods in UIViewController, this is how I implemented them:
#implementation UIViewController (MSLayoutSupport)
- (id<UILayoutSupport>)ms_navigationBarTopLayoutGuide {
if (self.parentViewController &&
![self.parentViewController isKindOfClass:UINavigationController.class]) {
return self.parentViewController.ms_navigationBarTopLayoutGuide;
} else {
return self.topLayoutGuide;
}
}
- (id<UILayoutSupport>)ms_navigationBarBottomLayoutGuide {
if (self.parentViewController &&
![self.parentViewController isKindOfClass:UINavigationController.class]) {
return self.parentViewController.ms_navigationBarBottomLayoutGuide;
} else {
return self.bottomLayoutGuide;
}
}
#end
Hope this helps :)
I might be wrong, but in my opinion the behaviour is correct. The topLayout value can be used by the container view controller to layout its view's subviews.
The reference says:
To use a top layout guide without using constraints, obtain the guide’s position relative to the top bound of the containing view.
In the parent, relative to the containing view, the value will be 64.
In the child, relative to the containing view (the parent), the value will be 0.
In the container View Controller you could use the property this way:
- (void) viewWillLayoutSubviews {
CGRect viewBounds = self.view.bounds;
CGFloat topBarOffset = self.topLayoutGuide.length;
for (UIView *view in [self.view subviews]){
view.frame = CGRectMake(viewBounds.origin.x, viewBounds.origin.y+topBarOffset, viewBounds.size.width, viewBounds.size.height-topBarOffset);
}
}
The Child view controller does not need to know that there are a Navigation and a Status bar : its parent will have already laid out its subviews taking that into account.
If I create a new page based project, embed it in a navigation controller, and add this code to the parent view controllers it seems to be working fine:
you can add a constraint in the storyboard and change it in viewWillLayoutSubviews
something like this:
- (void)viewWillLayoutSubviews
{
[super viewWillLayoutSubviews];
self.topGuideConstraint.constant = [self.parentViewController.topLayoutGuide length];
}
The documentation says to use topLayoutGuide in viewDidLayoutSubviews if you are using a UIViewController subclass, or layoutSubviews if you are using a UIView subclass.
If you use it in those methods you should get an appropriate non-zero value.
Documentation link:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/Reference/Reference.html#//apple_ref/occ/instp/UIViewController/topLayoutGuide
In case if you have UIPageViewController like OP does and you have for example collection view controllers as children. Turns out the fix for content inset is simple and it works on iOS 8:
- (void)viewWillLayoutSubviews {
[super viewWillLayoutSubviews];
UIEdgeInsets insets = self.collectionView.contentInset;
insets.top = self.parentViewController.topLayoutGuide.length;
self.collectionView.contentInset = insets;
self.collectionView.scrollIndicatorInsets = insets;
}
This has been addressed in iOS 8.
How to set topLayoutGuide position for child view controller
Essentially, the container view controller should constrain the child view controller's (top|bottom|left|right)LayoutGuide as it would any other view. (In iOS 7, it was already fully constrained at a required priority, so this didn't work.)
I think the guides are definitely meant to be set for nested child controllers. For example, suppose you have:
A 100x50 screen, with a 20 pixel status bar at the top.
A top-level view controller, covering the whole window. Its topLayoutGuide is 20.
A nested view controller inside the top view covering the bottom 95 pixels, eg. 5 pixels down from the top of the screen. This view should have a topLayoutGuide of 15, since its top 15 pixels are covered by the status bar.
That would make sense: it means that the nested view controller can set constraints to prevent unwanted overlap, just like a top-level one. It doesn't have to care that it's nested, or where on the screen its parent is displaying it, and the parent view controller doesn't need to know how the child wants to interact with the status bar.
That also seems to be what the documentation--or some of the documentation, at least--says:
The top layout guide indicates the distance, in points, between the top of a view controller’s view and the bottom of the bottommost bar that overlays the view
(https://developer.apple.com/library/ios/documentation/UIKit/Reference/UILayoutSupport_Protocol/Reference/Reference.html)
That doesn't say anything about only working for top-level view controllers.
But, I don't know if this is what actually happens. I've definitely seen child view controllers with nonzero topLayoutGuides, but I'm still figuring out the quirks. (In my case the top guide should be zero, since the view isn't at the top of the screen, which is what I'm banging my head against at the moment...)
This is the approach for the known guide length. Create constrains not to guides, but to view's top with fixed constants assuming guide distance will be.
Swifty implementation of #NachoSoto answer:
extension UIViewController {
func navigationBarTopLayoutGuide() -> UILayoutSupport {
if let parentViewController = self.parentViewController {
if !parentViewController.isKindOfClass(UINavigationController) {
return parentViewController.navigationBarTopLayoutGuide()
}
}
return self.topLayoutGuide
}
func navigationBarBottomLayoutGuide() -> UILayoutSupport {
if let parentViewController = self.parentViewController {
if !parentViewController.isKindOfClass(UINavigationController) {
return parentViewController.navigationBarBottomLayoutGuide()
}
}
return self.bottomLayoutGuide
}
}
Not sure if anyone still got problem with this, as I still did a few minutes ago.
My problem is like this (source gif from https://knuspermagier.de/2014-fixing-uipageviewcontrollers-top-layout-guide-problems.html).
For short, my pageViewController has 3 child viewcontrollers. First viewcontroller is fine, but when I slide to the next one, the whole view is incorrectly offset to the top (~20 pixel, I guess), but will return to normal after my finger is off the screen.
I stayed up all night looking for solution for this but still no luck finding one.
Then suddenly I came up with this crazy idea:
[pageViewController setViewControllers:#[listViewControllers[1]] direction:UIPageViewControllerNavigationDirectionForward animated:NO completion:^(BOOL finished) {
}];
[pageViewController setViewControllers:#[listViewControllers[0]] direction:UIPageViewControllerNavigationDirectionForward animated:YES completion:^(BOOL finished) {
}];
My listViewControllers has 3 child viewcontrollers. The one at index 0 has problem, so I firstly set it as root of pageviewcontroller, and right after that set it back to the first view controller (as I expected).
Voila, it worked!
Hope it helps!
This is an unfortunate behavior that appears to have been rectified in iOS 11 with the safe-area API revamp. That said, you will always get the correct value off the root view controller. For example, if you want the upper safe area height pre-iOS 11:
Swift 4
let root = UIApplication.shared.keyWindow!.rootViewController!
let topLayoutGuideLength = root.topLayoutGuide.length
I would like to have a UITableView in a navigation controller occupying the entire screen. I have a smaller custom UIView which needs to slide up from the bottom, squeezing the table view by 100 pixels. The custom view needs to be static, not moving while the user navigates the tableview. Ive been told not to have 2 UIViewControllers (VC) managing views on the same screen.
Currently, my AppDelegate adds a subview to its window from a VC, which then loads the tableview and custom view with
[self addSubview:tablviewcontroller.view];
[self addSubview:customViewController.view];
How should this be implemented?
the way I would structure this is as follows:
have a UIViewController subclass whose view takes up the entire screen. It will have two subviews.
First subview: The view of the UINavigationController that contains your table view controller.
Second subview: the custom UIView.
Have the UINavigationController's frame initially be set to the entire bounds of the main view controller's view and the custom view's frame just below the visible area of the screen.
When you need to slide up the view, use UIView animation to animate changing the frame of the UINavigationController's view by decreasing the height and change the frame of the custom UIView by changing its y coordinate to now be in-frame.
Okay. You want a navigation controller, of which the root view is a table view. Then, possible by an user input, you want this table view to slide up by 100 pixels, and another view takes place at the bottom. While the other view stays there, the user may keep using the table view.
Here is how I would do it:
Create a generic view controller (let's call it NavigationWithAuxiliaryViewController). The root view of this class covers all your application window.
This view has an instance of UINavigationControlleras its property, say navController. It also has an UIView (for the other view) as its property (say, auxView). Position the other view at the bottom. However, this view is hidden by default. Also, the frame of the root view of UINavigationController covers the entire view.
When you decide to squeeze up the table view, modify frame property of UINavigationController. Do something like this (not this ugly though):
if (slideViewOn) {
[UIView beginAnimations:#"slideUp" context:nil];
navController.view.frame = CGRectMake(0, 0, 320, 260);
auxView.hidden = NO;
[UIView commitAnimations];
} else {
[UIView beginAnimations:#"slideDown" context:nil];
navController.view.frame = CGRectMake(0, 0, 320, 480);
auxView.hidden = YES;
[UIView commitAnimations];
}
The easiest way to squeeze up the whole navigation/table stuff is to modify the whole frame for the navigation controller, which is why you need a separate view (out of the navigation controller) for the other view.