autolayout is terrible

Question

eblu OP

Created Sep ’15

Replies 7

Boosts 0

Views 2.7k

Participants 6

I have a very simple split view window. everything is laid out, but auot layout is screwing everything up.

wish i knew why auto layout jacknifes my Ui.

the splitview is the top level view in the window. it is horizontal, and there is a text field in the rightmost view in the splitview.

the splitview is tied to the window top, bottom, trailing and leading.

at that point, everything works as expected. when compiled, the split controls work just fine.

the problem, is when I try to add constraints to the text box. I put top, leading and trailing constraints on. all to superview. IB actually reversed the first item and the second item in the top constraint, thought I caught the issue. But alas, nope. When I run the app, the splitview became a piece of crap. The split control allows you to drag it, but when you let go, it snaps to some point that it won't let go. It will not under any circumstances behave like a splitview any more.

There is no justification, there is no reason, there is no logical argument for this kind of behavior. But now I need to dig through the documentation and try to understand the short comings of the autolayout engine. Ideas welcome.

Boost

Answer 1

KMT OP

Sep ’15

AL is a bear to get right. That's all there is to it.

See:

Adaptive User Interfaces
Taking Control of Auto Layout in Xcode [ Apple video ~ Xcode 5 ]
https://developer.apple.com/library/ios/recipes/xcode_help-IB_auto_layout/_index.html

0

Answer 2

eblu OP

Sep ’15

I hold that it is sloppy design, rushed implementation, and bad decision making. It's not a bear to get, it's just done wrong.

0

Answer 3

KMT OP

Sep ’15

That's what I said - thanks for confirming.

0

Answer 4

Ken Thomases OP

Sep ’15

Probably the issue is that the holding priority configured on the split view for that subview is lower than the content-hugging and/or compression-resistance priorities of the text field. So, that means that the split view's tendency to size that subview according to the user manipulations of the divider is subordinate to that subview's own tendency to maintain its own intrinsic size.

Increase the holding priority or decrease the text field's content-hugging and compression-resistance priorities.

0

Answer 5

RLKingSoftware OP

Sep ’15

Autolayout is indeed a nightmare BUT, if you keep things simple, use non autolayout for things that don't need

it and AL for only those things that do, it works well. In my experience, the fewer elliments AL has to work on

the better. This is why I use normal spring/strut pairings on things where AL might cause issues.

0

Answer 6

Moya-Dev OP

May ’17

I completely agree. I'm losing hours trying to decently align a few controls .... in Android Studio the same task takes 10 minutes. The autolayout system is ill-conceived and horrible to use. Sorry, but that's how things stand for now. Re-think it, because it is simply awful.

0

Answer 7

JamesKelly OP

Dec ’20

It would be hard to imaging a layout API that is less intuitive and less forgiving than AutoLayout even if those were your specific design goals. It does not reward getting your hands dirty and learning as you go, even though IB presents an approachable interface to many elements of AutoLayout. Debugging a broken layout in particular requires real expertise. Most just tear everything apart and start again.
I really think SwiftUI was in part brought into being by Apple engineers who realised that some huge percentage of iOS developers aren't using their beloved layout system as they intended (for some reason) so they'd do it for them and wrap it up in a declarative API; we tell them what we want and they build it.

0