Horizontal StackView Spacing not working at runtime - ios

I'm having problems when using StackViews for laying out my views when device rotation changes.
I get good results in storyboard.
However it isn't working as expected at runtime; after doing rotation on simulator, search control size increments and space is gone! I even tested on a physical device.

I had width constraint for the filter button; that's all I need I think.
Problem is gone now! Fixed by myself by deleting and re-adding controls to the UIStackView, looks like stackviews are not very stable; sometimes it might fail, so must delete and add them again. Have in mind that!
Width constraint for filter button

Related

Layout of iOS app gets disoriented when built on different iphone simulators

enter image description here
I have set the constraints from the safe area for every labels and textfields but the problem is still occurring. The app perfectly sets only on iphone 11 and iphone 12 simulators only.
(Have shared the screenshot)
I have set the constraints from the safe area for every labels and textfields
No, you don't. If you did, you would not have this problem. You have not correctly set the trailing constraints for these views. In fact, it looks like none of your views has correct constraints.
Every view must be completely configured through constraints as to its position and its size. It must, in other words, be bounded top, left, bottom, and right. Labels and text fields and buttons have an automatic height so you don't need to fix their bottoms, but all of your views need top, left, and right constraints.

Auto Layout constraints for container view inside UITableView header broken for different devices

I have an issue that makes no sense to me. I have the following setup:
| UITableView |
|| UITableView header ||
||| UIView |||
So inside my UITableView header I have a container view that has leading, trailing and top constraints to its superview. Everything is set up correctly for my test device size (which is iPhone 8). If I change the test device to iPhone 8 Plus I get a strange offset for my trailing constraint - 39pt to the right edge, which is exactly the difference between iPhone 8 plus width in points and iPhone 8.
When I switch between devices in Xcode and see that the trailing constraint is not correct I just make an adjustment myself (change trailing to 1 and then back to 0) and the problem goes away for the particular device.
Initially I thought it is bug in Xcode but when I tested on a device the problem is still there.
I tried setting up a new view controller and adding the same elements but with no effect.
I am attaching screenshots to make my issue clearer.
Before: Adjusting the desired constraints
After: Switching to a device with different size
Adding this as an answer because it's too much for a comment - even though it's really just a confirmation, not a solution.
OK - looked at your project.
I'd say it's an IB / Storyboard bug, which I've seen in other circumstances. If you change the View As... device, the frame does not update immediately.
However, if you change anything that would cause a layout update - such as temporarily changing the background color of a view or font size of a label - everything should snap into place.
You'll also notice that if you select an element and move it slightly, the Update Frames button / menu item becomes enabled... and that will also correctly update the frames.
Note: When I ran the app, regardless of how the layout looked in Storyboard, the constraints correctly sized the views at run-time.
At first I accepted DonMag's answer (thanks for your time) as this really seemed to be an Xcode Interface Builder bug. As I investigated further when having the scenario I mentioned auto layout constraints are not updating the layout when I need it hence not giving me the right view.bounds.
I tried getting it in viewDidLayoutSubviews() without success as well - it was still giving me a size that suits another device.
What did the trick was calling view.layoutIfNeeded() before working with view's bounds. What it does is to update the view's layout immediately. As a result you can access the desired view's bounds.

Xcode / Swift Scrollview Layout too wide

I'm part of a team working on an app that uses auto-layout for the iPhone 6, but we just found out that we also need to support iPhone 4s and 5. Because the layout was designed for 6's larger screen, we decided to use ScrollViews.
I used this video as a tutorial of sorts:
UIScrollView and Autolayout - Xcode 6
For the most part, it works. I can scroll up and down.
The Problem:
Scrolling vertically works. But now I also have to scroll horizontally, which is not ideal / shouldn't happen.
Even with the simulator set back to iPhone 6, anything with the scrollview gets widened to the point that the user has to scroll sideways.
Any suggestions?
What I Tried:
Some parts of the app does work without a hitch as far as my eye can see, but I've yet to apply a scrollview to those, so it's hard to tell if it's the scrollview's fault or something else at work. I did find this, though:
Non-working (scrollviews used - can scroll down, but width gets blown up):
Working (no scrollviews used - can't scroll down, but UI matches screen width):
I have no idea if that actually makes a difference. I tried to set the size to any/any as well, but that screws up with existing auto-layout constraints.
I also tried doing it programatically, but there's some known issues regarding the system returning the wrong screen size (which screws up everything even worse).
When working with ScrollView & AutoLayout you should put all content in a content view(UIView) and pin it to scroll view. (I am assuming this you did)
Now, If you want to disable horizontal scroll(like in TableView) then you will need to add a equal width constraint between scroll view & content view.

iOS / XCode Auto Layout Woes. Easier Way?

I'm wondering if xCode auto layout / constraints are really as frustrating as I think, or am I just not understanding them. For example, I started with this basic label in the view controller:
Fair enough. A box with text that has equal margins on the left/right and a smaller top margin. Now when I run any size device, that gets skewed/cut off from the device view. So right away for some reason Xcode thinks that despite me putting the entire label in the view controller, it things it should display halfway off the screen. Don't get it but okay, so I went ahead and added auto layout constraits to the right, left and top margins. The result is:
So it centered it, which is nice, but now it just ignores the fact that I made the width larger and it just shrinks it down anyways? For something so simple this seems to be very...unreliable. I then added the "aspect ratio" constraint and it seemed to look fine in all of the devices...finally!
I curiously also simply tried to get rid of all those, and simply add the "aspect ratio" constraint and the "horizontal center in container" constraint. On the main storyboard preview (not the simulator) it looked like this:
Not what I'm looking for, as it's not stretched downward like I want, they shrunk it again. However...when actually running it in the simulator...it looks perfect, the way I want it to in the first picture of the view controller.
Why the preview and simulator differed, I suppose (from reading other questions) it's because there were a few warnings after I added these. One was that the horizontal and vertical positions are one initially and will be different at run time. But when I ran it, it definitely held the initial ones and not the ones they said it would be at run time. It also told me that vertical position was ambiguous...well yeah I only set a center and aspect ratio...pretty obvious and not sure how I'd even solve that error. It solves it when I delete the horizontal center...but now it's not centered which is a step back from what I wanted.
Long story short, how do I deal with this. My previews and simulations aren't accurate with each other even for the simplest auto layout specifics. Apps nowadays are so complicated and on every device they scale and work beautifully, and this seems to not agree with even just one label.
Does anybody have any good articles, advice, or anything that would help me? This auto layout stuff seems to be so picky and that's really all I know so I have to deal with it. And don't even get me started on why the text doesn't scale with the label...why would I want the text on an iphone 4 to be the same on an ipad even when my label is increasing in size with the device?
A lot to go through, but it's just very frustrating and I can't see myself doing much else before I try to understand these basics. Thank you and much appreciated.
I think you have to understand constraints first...without that you always made things frustrating....For understand the constraints you can check this links
http://www.raywenderlich.com/50317/beginning-auto-layout-tutorial-in-ios-7-part-1
http://mathewsanders.com/designing-adaptive-layouts-for-iphone-6-plus/
It takes a bit of experience to get used to it, but once you get it, you get it for good and it's very easy.
Basically the rule of thumb is don't trust exactly what you see in storyboard when it comes to the size of the actual object. Say you have a UIView centered horizontally and vertically in the main view. True it will try to keep the size of that UIView but center it in any size device, but I would never just leave it at that. I would either:
Add width and height constraints
Add a width/height constraint and an aspect ratio constraint
Add a width constraint and top and bottom constraints
Add a height constraint and leading and trailing constraints
Add top, bottom, leading, and trailing constraints
In other words, the exact size of the object should always be determined via the constraints, and not by the UIView itself. This gets away from the finicky behavior and also ensures that it's displayed on any device exactly the way you intend it to.

Why do I get an autolayout error on a constraint that should not be installed for the size class?

I'm using iOS 8. My nib has autolayout and size classes enabled. I've made two layouts in IB, one for Any Width/Any Height, and one for Any Width/Compact Height. I've tested different orientations and device sizes in IB and I don't have constraint problems in IB.
Now when I run the app on my phone. The view lays out correctly in portrait. Then I rotate my phone into landscape and I get a "Unable to simultaneously satisfy constraints." error. When I look at the list of conflicting constraints, I see a constraint that should have been uninstalled for landscape layouts. When rotation completes the landscape layout appears correctly.
It's as if iOS is trying to lay out the view with the new bounds before the old constraints are uninstalled. Is this a known problem with iOS? Is there a step I need to implement to correctly support size classes?
I ran into this same issue. Very frustrating! At first I added code to willTransitionToTraitCollection:withTransitionCoordinator: in order to detect if the newCollection was a size class that didn't need the constraint. If so, then I set the constraint.active = NO.
It did the trick, but I hated the code. I was just like, "Why should I have to do this? The constraint is not installed for the new size class!"
Then I figured out that if I lowered the priority of the offending constraint to 999 in interface builder I no longer got the constraint error in the console when I rotated. :-) And all is right with the world again.
I still think this is an iOS bug, but I don't have time to make a sample project to reproduce it. I think what is unusual about this layout is that I have an image view that moves to an entirely different location when the phone is rotated into landscape.
The width constraint on the image view had different constants for either size class, but this was throwing an exception.
The next thing tried was to use different width constraints. One was installed for compact height, the other was installed for everything else. This was still throwing an exception, even though the breaking constraint should not have been installed.
Finally, the solution I got working was to have two image views, one for regular layouts, and one for compact height. Only one image view was installed at a time. This works without exceptions and looks exactly the same.

Resources