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.
Related
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.
I am starting a new project which should be working on every iOS device size possible.
The project is rather simple. The main view will be a scroll view and it will hold a '+' button (where it says 'button' in the image) in the top right corner. (It does not really matter, I'm just trying to give the general idea of what I'm trying to understand and implement.)
A small example:
What is the right approach for this kind of problem?
Should I create a different storyboard for each device?
Should I start creating an adjustable scroll view that will hold the needed buttons with some constraints (if at all possible)?
I have read this tutorial:
auto layout
which explains the auto layout nicely, but does not mention the issue I'm trying to figure out.
Any thoughts?
Use AutoLayout and position your views relative to one another (so no x pixels spacing between views). Make only one storyboard for all devices, when a different view should be loaded on another device (like a completely different layout), select the appropriate size class and adapt the views and constraints.
Then it will be recalculated on every device.
The storyboard has a preview section where you can choose a device to simulate the view on.
I've updated my old pre-AutoLayout view to use AutoLayout. All warnings and errors are gone. I can successfully switch the simulated size to any iPhone and it will work.
However, once I run on actual hardware, the UIImageView that I've set as a background image seems to be hiding all the content (either that or the other content is being pushed off). I've verified that the UIImageView is closest to the root, so it should have the lowest z-index position. When I delete the UIImageView, all the content appears as expected.
If this helps: I've pinned the leading, trailing, top and bottom values of the UIImageView to the superview sides and the respective navbar/toolbar edges.
I've since confirmed it's merely covering the other content by setting a transparency value. So for whatever reason, it's getting pulled to the front. If anyone has intimate knowledge of AutoLayout and has some sane reason as to why that's happening, I'd love to hear it, otherwise, I'll chalk it up to just quirkiness.
I believe the underlying XML of the view had issues.
Solution Summary:
Removed setTranslatesAutoresizingMaskIntoConstraints:NO code.
Re-dragged background image to original position in hierarchy.
Details:
After digging around with the commands that Rob showed me, I was able to confirm that there were a lot of ambiguous layout errors at runtime only. I couldn't see anything inherently wrong with the constraints in Interface Builder, but after redoing the constraints several times and still having no luck, I removed the following from my view controller code:
setTranslatesAutoresizingMaskIntoConstraints:NO
That immediately removed the ambiguity errors.
Why did I put that in there? I have no real good reason other than having read some blogs suggesting to do so. Lesson learned, don't blindly do things.
However, this actually still did not fix the original problem. I reran the program and the background image was still jumping to the front of all sibling subviews even though there were no longer any ambiguity errors.
I was able to send it manually to the back by executing
sendSubviewToBack: against lldb.
and the view looked as intended. With no ambiguity errors remaining I decided to just drag the background uiimageview to a new position in the view hierarchy, then I executed the code. Then I stopped and dragged the uiimageview back to its original position, and executed again. And voila, it was in the proper position. I can only imagine the underlying XML had problems.
I have issue with autolayout.
I have three different views (could be n views as well). When I pin first one to top of super view and connect one next to the other everything seems fine. But if I want to change height of first one the other two does not follow (they stay on the same position). What I find weird about this is that if I connect only two views this works perfectly.
To have better understanding what I am trying to achieve I made simple, example solution with three views:
http://i.stack.imgur.com/cMwiB.png
So, when I set height of green view to 0 ( can be any other number as well ) and only red view is connected, this works fine, red will move as it should. Blue one is not connected and it remains where it is:
Here is screenshot when I connect blue to red:
What I tried to do:
connect blue one to green as well ( not working)
connect blue only to green ( not working )
"boxing": have boxes with views at the time ( ugly, hard to manage, not working in all cases)
What I would like to know:
what makes this happen? Can I change this kind of behavior?
What is the best practice to have flexible length for height (Besides UITableView)
Thanks in advance.
Ok, I think you're falling into the same trap I did, when I investigated autolayout some time ago. It's tricky to explain, but I'll do my best. When you work with autolayouts, you need to forget completely about setting a view's frame at all. And that, my friend, includes changing size and positioning. When you use autolayout, you define some constraints, some "rules", that the view tries to respect when rendering the screen, so the more specific the rules are, the less random will be the behavior of the view. I mean, if you just define the spacing between views, you're implying that the height of the views doesn't matter, so it's possible that some views grow or shrink when the re-layout is called (that is, if you don't specify a constraint for size. You probably want to always specify the size of some views in every layout...)
By the way, you're allowed to violate the constraints by manually changing the frame of an element AFTER a re-layout is called, but when the re-layout method is called again, the constraints will be forced so the size and positioning of the views will change. Quick tip: an easy way to force the re-layout method is to change orientation (command+left / command+right in the simulator).
So after saying that, I have to say that the layout you provided is completely working as intended, at least to me. When you change orientations the constraints you specified are ALWAYS being respected. If you want, you can try to apply some frame-setting in the viewDidAppear method, because this one is called AFTER the autolayout (and thus, you're able to violate the constraints temporally). After doing this, your view will be broken but once you change orientation the constraints should be respected again. Make sure it's that way.
From here I can only wish you luck ;) Oh, and refer to the documentation, it was a life saver to me when I looked at this half a year ago. https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Introduction/Introduction.html It might seem a classic, but it's a pretty nice doc.
EDIT: one last thing. I have the impression that constraints are not designed to be dynamic. You define them once, and they're there always. Their main purpose is to ensure that subviews are rendered as intended in every screen resolution without fail, so if I were to make an application with moving views, I would leave them outside of the autolayout, or avoid using it at all. Just a personal impression though :)
I find myself often having to reposition subviews of a view after hiding or showing one of them. The way I'm doing this is by programmatically changing a view frame's origin and/or size, or its center. But is there an easier way I'm missing? Is there a way to do it with Autosizing masks?
I don't think there's any automatic way of doing this. You could probably get clever about how you do it programmatically (e.g. if you used a set of sequential tag identifiers, you could loop through and calculate the height of the previously visible tag to calculate the origin of the next subview; or if there are a group of subviews that are always going to move together, you could put them in a container UIView and thus move a whole bunch of them by just moving their container view; etc. ... it depends upon how they're laid out and which fields might be hidden).
This won't help you for now, but check out WWDC 2012 session 202 for a discussion of a relevant improvement in iOS 6.