I have an app with with a UITabController and each tab is a UINavigationController. The root of one of my UINavigationControllers is a UIViewController.
Inside that view controller's view, I want to layout some subviews, but I'm confused as to where & how to lay them out in a way that will be resolution independent (i.e. not hardcode values such as 320px, 480px, 44px, etc.).
When the view is fully loaded and presented on a vertical iPhone, it's height will be 367px = 480 - 20 (status bar) - 44 (nav bar) - 49 (tab bar).
Inside the view controller, I currently create all my subviews within the viewDidLoad method. However, it appears that within this method, the view's current height is 460px (self.view.bounds.size.height). So when setting up my subviews, I cannot properly calculate the sizes of anything.
Within the viewWillAppear: method, the view does know it's proper size, but that would mean setting & calculating the subview's frames every time the view will appear (e.g. tab changes or popping from child view controllers on the navigation stack.
Is the only way to do this properly to layout in viewWillAppear:?
I have tried using the autoresizing properties (parent's autoresizesSubviews & autoresizingMask) but they don't seem to work at all!? Do these only take effect once the view is all setup and then it is resized (manually / orientation change?).
I'd be grateful if someone could let me know why the autoresizing isn't working, and how best to lay things out by not hardcoding any sizes.
You can do your layout logic inside the viewWillLayoutSubviews of the UIViewController.
-(void)viewWillLayoutSubviews{
[super viewWillLayoutSubviews];
// Your layout logic here
}
DOC: Called just before the view controller's view's layoutSubviews method is invoked. Subclasses can implement as necessary. The default is a nop.
autoresizesSubviews should be set on your parent view, while autoresizingMask should be set on the child views - this is the mistake I made so you could, too.
In loadView you should size your subviews to fit whatever size of parent view is at the moment, and then later on when parent view is resized from 460 to 367 pixels your sub-views will be resized as well, according to your mask settings above.
If that fails, there is nothing wrong in setting the view size within viewWillAppear - the performance impact of doing it every time is negligible.
If nothing else works, there is always layoutSubviews: - there you could do manual layout if you have to, it's invoked when system believes layout may have to change. there is also setNeedsLayout: that I sometimes invoke from viewWillRotate:/viewDidRotate: etc. But really this shouldn't be needed and autoresize should be good enough.
EDIT: Yes, to implement custom layout logic in layoutSubviews as I mention above one would need to subclass UIView.
Swift 5:
override func viewWillLayoutSubviews() {
super.viewWillLayoutSubviews()
// Your Code
}
Related
When a UIStackView recalculates its fill proportionally distribution of UI elements upon a change in Stack view size, I'd like to make adjustments to those elements right before they appear. It seems as though there must be a method called between the ViewWillAppear and ViewDidAppear.
Any Idea what happens between these two when the stack recalculates?
viewWillAppear and viewDidAppear have to do with the view controller life cycle and coming on and off screen, but not with layout. You want either UIViewcontroller's viewDidLayoutSubviews or UIView's layoutSubviews method. When these methods are called, auto layout is done with he view controller's subviews or with the UIView's frame, respectively. You can tweak the frames and update things like sublayers that are not affected by auto layout at this point.
I am using Auto Layout in my iPhone app and have a UIScrollView. I need to change the content size of my scroll view at several points while my apps running (so setting the content size in viewWillAppear is useless as I have seen this suggested in other places).
When I change it, my subviews jump about, presumably because it breaks the auto layout constraints.
So how can I approach changing my scrollview content size with auto layout enabled?
Thanks.
I was having this same issue, and I know this can't be the final solution, but for now, rather than calling this in viewWillLayoutSubviews, by putting the code inside viewDidLayoutSubviews it allowed me to set the contentSize AFTER the viewController did it's default business :)
Hope that helps.
Test your code in viewWillLayoutSubviews. Apple say:
When a view’s bounds change, the view adjusts the position of its
subviews. Your view controller can override this method to make
changes before the view lays out its subviews. The default
implementation of this method does nothing.
UIViewController Class Reference
I have a configuration UITableView that can launch a colour picker via a UINavigationController approach:
[self.navigationController pushViewController:colorPickerViewController animated:YES];
[colorPickerViewController release];
The effect of this means the ColourPicker will have a navigation bar at the top ( and back button)
The structure of the ColourPickerViewControll and it view ColourPickerView is as follows:
- ColourPickerViewController - in it's XIB file at the top level view it has:
- ColorPickerView : UIView (i.e. custom UI view) - in it's methods it has:
- (id)initWithCoder:(NSCoder*)coder {
if ((self = [super initWithCoder:coder])) {
CGFloat currVertBounds = self.bounds.size.height;
The issue here is the the value of currVertBounds is coming to 480, so it's not taking account of the navigation bar
QUESTION: How do I get the true displayed height of the ColorPickerView instance?
Is it something to do with trying to get the layout calculated in the custom UIView, and perhaps the custom view isn't rendered within the overall controll/navigationController at that stage?
You're reading bounds too early. None of the layout/subviewing magic that happens in UIKit will take place during [super initWithCoder:]. You should be reading bounds and laying out your view either:
In viewDidLoad/viewWillAppear, and set up the autosizing parameters for all manually created UI elements so they can get moved around with respect to different interface orientations. In these functions I wouldn't rely on bounds being exactly correct but I would say it's at least the right height:width ratio. It could possibly be in the wrong orientation, though.
In viewDidAppear, if you wish to manually position elements. By the time you hit viewDidAppear all of the resizing and such has taken place, and the only thing left to worry about is future rotations, which you should adjust your view for in willAnimateRotationToInterfaceOrientation:duration:.
Docs on willAnimateRotationToInterfaceOrientation:duration: state:
By the time this method is called, the interfaceOrientation property is already set to the new orientation. Thus, you can perform any additional layout required by your views in this method.
iOS 5.0 docs add the clause:
...set to the new orientation , and the bounds of the view have been changed. Thus...
I think this is still the case for prior iOS versions.
Views for iPhone will by definition have a height of 480 pixel when created in Interface Builder, so that's what you're seeing when you're initializing the view. Once the view has been properly initialized and added to the view stack, it will be resized to match the actual space available.
You're simply asking the view of its height before it has been adjusted.
Try reading the height in viewDidLoad, then it should be correct.
Yes, this is right because the instance of UINavigationController is declared in your (delegate.h) & that navigationBar is added to window not on your self.view
When you check the bounds of your current view, it should definitely return 320 * 480.
It should not include height of navigation bar in you view, as it not on that view. Its on window.
I'm trying to switch from two-stage rotation to one-stage rotation (to avoid the console warning, and because Apple recommend doing so because one-stage is faster).
However I can't figure out how to get the new size of my view (taking into account the navigation bar, status bar, etc) early enough to perform the update of my UI during the animation (rather than simply snapping the items to their new positions at the end as many applications seem to do, which results in a big "jerk" right at the end of the animation).
The sizes I get in the willAnimateRotationToInterfaceOrientation:duration: method are (perhaps obviously) the old sizes.
I can see I should be able calculate it by hand, working out the current bar heights, then inferring the new view frame size by deducted those from the rotated screen dimensions? (which isn't that difficult to do, though is perhaps fragile as it assumes the navigation bar, status bar, etc will be the same height in both orientations, and you'd have to manually take account of the toolbar being different heights in portrait vs landscape - I just want to make sure I've not missed a more straightforward or common way.)
Any feedback on approaches other people have taken would be great!
Thanks
Joseph
I've had the most success using my view's layoutSubviews method for autorotations. When layoutSubviews gets called during an orientation change, the view's bounds are already set to what they will be at the conclusion of the rotation. You can also at this time query the status bar, navigation bar, and toolbar for their sizes and get the correct post-rotation values (although the status bar width and height may be swapped--I just take the smaller value as the height, works great). Using that information you can lay out subviews and they will then be animated as part of the rotation.
It can be annoying to create a UIView subclass for every situation where you want to do this, so I created a special subclass of UIView called DelegatingView, which looks like this:
#protocol DelegatingViewDelegate
- (void)layoutSubviewsForView:(UIView*)view;
#end
#interface DelegatingView : UIView {
id<DelegatingViewDelegate> _delegate;
}
#property (nonatomic,assign) id<DelegatingViewDelegate> delegate;
#end
#implementation DelegatingView
#synthesize delegate = _delegate;
- (void)layoutSubviews {
[super layoutSubviews];
[_delegate layoutSubviewsForView:self];
}
#end
I use this as my base view, add subviews to it, and set my UIViewController as the delegate. Then I can layout subviews from my view controller, having access to the current orientation and so on.
Which OS version are you targeting? Under OS 4.0 (which is what I did a quick test in), [view bounds] within willAnimateRotationToInterfaceOrientation:duration: returns the new, post-rotation bounds.
If you are not seeing that, I’d suggest double-checking that your view has the appropriate auto resize mask set.
If you have complex layout requirements in the view of your view controller, it is worth it to create a subclass of UIView and perform your layout code in -layoutSubviews (the correct place to do view layout). As Hilton Campbell pointed out, if you use this method for layout, you can check frame sizes and subview relationships and set their new positions appropriately.
If your view controller's view has a simple set of subviews, then you should probably just set their autoresizingMask properties appropriately, and let them animate themselves automagically.
I tried two methods to adjust view's size.
1.) notify child views to adjust their size after -(void)viewWillAppear;
The drawback is that it will be executed each time when viewWillAppear.
ex:
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];
[self notifyChildViewWillAppear:animated];
}
at child view
- (void)notifyChildViewWillAppear:(BOOL)animated
{
// at this time, the size of superview's bounds
//equals the content view's size
// (no navigationBar's height and toolbar's height.
self.frame = [self superview].bounds;
}
2.) Calculate the necessary size by hand.
I calculate as viewDidLoad.
The sizes of navigationBar and toolBar can be derived by following code.
self.navagationController.navigationBar.view.frame.size.height;
self.tabBarController.tabBar.frame.size.height;
I have just started learning objective-C and the iphone sdk and I have a question that I hope someone can help shed some light on.
What is the difference in the following:
self.view = someView;
and
[self.view addSubView: someView];
Say for example, in a simple app, where we have only one controller and one container view (has a few image subviews).
What is the difference between the two statements? The reason that I'm asking is because I was tinkering around in some sample code and I noticed the view was being initialized with images as subviews like so:
if (self = [super initWithFrame:CGRectZero])
{
//adds some images as subviews here
}
As I understand it the initWithFrame: CGRectZero, creates a frame with size at [0,0,0,0] (essentially invisible).
When I directly set the view with
self.view = someView;
I notice the view actually displays the image. But when I add the view to as a subview of controller's 'default' view, it doesn't. So basically my question is, whats going on behind the scenes? Why is the first method "resizing" the frame and the second one not doing the same thing.
What you see on the screen of your iPhone is almost always a hierarchy of views.
When you look at, say, your inbox in Mail, you're seeing a bunch of views. There's a big containing view.[1] Within that, there's a navigation bar view, a table view, and a toolbar view. Within the navigation bar view, there's a button view on each side and a label view in the middle. Inside the table view, there are a bunch of table cell views, and each of those cells has several label views. The toolbar has five button views. I could go further and talk about the views inside those buttons and so on, but I'm sure you get the idea.
The view above any given view is its superview; the views below it are its subviews. So a table cell view has a table view as its superview and a bunch of label views as its subviews. The top view, the one that has all the other views inside it, is called the root view.
Each view has its own drawing surface. The rectangle formed by that drawing surface is called the frame. The frame of a view is relative to the frame of its containing view. So if one of our table cell's label subviews has its frame at (0,0), that means it will be in the table cell's top left corner, even if the cell is halfway down the screen.
When you're writing a view controller, self.view is that root view I mentioned earlier; all the other views are subviews of that one (or subviews of its subviews, etc.). One of the features of a view controller is that it automatically resizes its self.view to fit the screen. (The available area will be smaller in the middle of a phone call: the status bar is twice as high then, so there's less space for your app. It will also be smaller if your view controller is being managed by a navigation controller or tab bar controller, but that's a different story.) But just because you resize its root view doesn't mean that the root view's subviews will automatically resize. To do that, you need to set their autoresizing mask (a property which tells the view how it should react when its superview changes size):
someView.autoresizingMask = UIViewAutoresizingFlexibleWidth
| UIViewAutoresizingFlexibleHeight;
(There's a graphical way to set up the autoresizing mask in Interface Builder—click the ruler icon in the inspector window and look at the "Autosizing" section.)
Even that's not enough, though, if someView isn't the right size to start with. To do that, adjust its frame before you add it as a subview of self.view:
someView.frame = CGRectMake(
0, // all the way to the left
0, // all the way at the top
self.view.frame.size.width, // same width as the root view
self.view.frame.size.height, // same height too
);
So why would you ever use subviews if you have to do all this twiddling that the root view does for you? Simple: you can only have one root view, but one view is almost never enough for what you need to do. If you really need only one view, of course, you can just set it as the root view and go on your merry way, but chances are, things are more complicated than that.
[1] I'm simplifying a bit here, but that's fine for right now.
When you add a view as a subview, you need to make sure that you're actually adding to an existing view.
self.view = view sets the controller's view. Without this (either in code or done with a XIB) you'll never see anything as the controller has no view to show.
[self.view addSubView: someView] assumes that self.view is already set. If it doesn't, you're adding someview as a subview of nil, and it will never get seen.
Basically, think of self.view as the big container, and all the subviews are just pieces inside of it. If you don't need any subviews, setting self.view to a UIImageView or UIWebView is fine. If you do need subviews, you'll need a big, empty container view in which to put them.
In your case, I'm betting self.view is never set, and you're adding your image views to nil.
Setting the view controller "view" property only changes the view it is managing.
Adding a view as a subview of another view, actually adds the subview underneath the other view.
They are very different things, as one adjusts a view controller and the other alters a view hierarchy.
As a guess, the reason you didn't see anything the first way was the frame for the subview you were adding was CGRectZero (0 in size).