I have a container view inside main main view of UIViewController which is in storyboard. The containerView have multiple subviews which further have textfields and labels inside them.
All of this hierarchy is in autoresizing model.
Now what is wrong here is that whenever I close Xcode and come back to those views, the subview frames automatically get disturbs and normally go in negative like if it is on 0 from y axis it will now be -2 or -3.
It is happening in multiple controllers and mostly on the storyboards which have more than 7-8 controllers. Auto layout resolves this issue but due to a lot of views it would be a time taking task.
Any suggestions to resolve this problem without converting to auto layout?
Edit:
I have reduced the number of controllers in storyboards as well but it didn't effected and the issue is still appearing
After trial and error, if the stretchable properties of autoresizing are removed and the stretch is handled in subviews then this issue do not happen. I have tried this hack and it was not changing the frame on quoting and reopening the Xcode.
Related
I've recently switched up to Xcode 7 Beta 5 and I've been trying to solve the UITableView issue that I know lots have experienced. One solution I found was to disable size classes, however, once I did that I wanted to roll back my solution to a commit I just performed before that.
After I discarded all the changes I was presented with my view controllers and none of their subviews visible in them. In the hierarchy to the left they are listed but are 'greyed out'. Can anyone help with solving this?
Screenshot for reference:
It's worthwhile noting that when the app runs all of the ui elements are still present as expected - just in storyboard they are not displaying.
Try checking it in different layout such as any width compact height.
Grey out generally means that your view are active on a particular layout.
You can see the changes when you tap in the bottom wAny hAny and select different sizes...
In one of the WWDC videos, Apple said that the layout is done from top down, ie from superview to subview (after constraints are calculated from bottom up). Display is also done from top down.
My questions are:
1. At what point in the viewcontroller is a view's frame (origin and size) determined? I tried to log the size of a view (defined using auto layout), but it was always 0 0 0 0, which is odd, because the view is already generated in the simulator;
For an autoresized view, when is view.frame available?
Same question, except this time it is UIImageView.frame. I tried to log to console, even though the size is fit into the constraints, the logged UIImageView frame is 0 0 width_of_original_image height_of_original_image. But for other views like labels, the frame is printed correctly on the console.
It seems like that there is a mysterious auto layout engine that performs transform, and nobody knows what is going on inside the engine, but to check what is thrown onto the simulator display to figure out how the view was rendered by this engine???
It's not mysterious. It's quite simple! Think of constraints as instructions written down on pieces of paper - the views. Every once in a while, it's layout time! The runtime collects the pieces of paper from the views in order and obeys them - and so you end up with laid out frames.
So if you check sizes of things before layout time, you get the wrong answer because it hasn't happened yet.
And when is layout time? It's whenever the runtime sends views layoutSubviews - in fact, the runtime obeys constraints and performs layout during layoutSubviews. And your view controller can hear about this before or after, with viewWillLayoutSubviews and viewDidLayoutSubviews.
I think the part that confuses beginners the most is what happens when a view controller comes into existence. viewDidLoad means it has a view, but that is all; neither the view nor its subviews are in the interface yet, so obviously there can be no layout. Considerably later, we get viewWillAppear:, the view goes into the interface, and now we get layout. So if you check sizes in, say, viewDidAppear:, they will be right.
We're currently having a problem that only seems to affect iOS7 devices.
Within our .xib file we have two views within a container view (i.e.: not at the top level of the view hierarchy) that need to be circular on display. The views have constraints applied to their position and horizontal spacing within the container, and an aspect ratio condition requiring they are square. The views should expand in width/height on larger screen sizes, respecting the constraints described.
In our VC, we have the following in viewDidLayoutSubviews to force these views to appear circular:
- (void)viewDidLayoutSubviews {
self.progressContentContainerView.layer.cornerRadius = self.progressContentContainerView.frame.size.width/2;
}
This seems to work fine on iOS8, however on iOS7 there is a period after the view has been displayed where the constraints have not yet been applied and the size of the view/views is incorrect (see attached screenshots). This resolves itself and correctly renders a circle after half a second. This only appears to happen when the views that we intend to be circular are NOT at the top level of the VC's view hierarchy which seems to imply that viewDidLayoutSubviews is called before the subviews of subviews have also been laid out.
My guess is that we could potentially fix this issue by subclassing UIView for the nested container, adding references to the circular view within this subclass and overriding viewDidLayoutSubviews here to make the cornerRadius adjustment. This seems like a bit of a workaround though and I'm interested to see if there are other options.
Is there a cleaner/more idiomatic solution to this problem?
I know this is an old question but have you tried calling either:
[self.progressContentContainerView setNeedsUpdateConstraints];
or:
[self.progressContentContainerView layoutIfNeeded];
I designed about 40 view controllers using a 5.5 inch storyboard layout. After all of that I tested it on the iPhone 4S...big mistake. everything is jumbled together being for a larger screen size. I was able to fix one view controller up using Size Classes. I am wondering if there is any way I can adjust all 40 at the same time, or at least avoid doing this for every single one. It is really frustrating finding this out now. Thanks!
This is a relatively complicated issue you are attempting to solve, but I have two potential solutions. Both suggestions are based on moving your current interface into containing UIScrollView instances
If you are using storyboards, then for each of your view controller scenes, put a UIScrollView as a descendent of the view controller's view. From there, provided your subviews are contained within other views (like a container view for a set of buttons), you can move those into your scroll view. You will have to setup constraints to define the size of the scroll view's content, but this will allow the size of the device to have a smaller impact on the interface as you will get scrolling as needed.
If you are using nib files (.xib) then it is essentially the same thing, but easier. In this case, move a UIScrollView onto the canvas, but not as a subview of the default view. Once that is out there, move the original view to be a subview of the scroll view and set constraints to be 0 from the subview to the scroll view. Finally, right click drag from the File's Owner icon to the scroll view and set that as the view outlet.
Hopefully one of these will help you.
Simple enough, I wish to hold two UIContainerViews in a single UIViewController.
Using storyboard, I can add them both in, but then any adjustment made to each container size, results in the containers disappearing with only the segue left visible.
Is this a storyboard bug, or does it represent a restriction on holding two containers in the same view?
If the embed segues are still there, the containers are still there. My guess is the frames got updated and didn't have enough constraints to determine their size, so they went to zero. This happens to me frequently when I am in the process of creating their constraints. I would adjust their size through their constraints and I'll bet that fixes your issue.