6 ms·

Generally agree with the article, but of course I have my disagreements. Specifically: > I consider Auto Layout one of the top 5, maybe top 3 technologies to e

Generally agree with the article, but of course I have my disagreements. Specifically: > I consider Auto Layout one of the top 5, maybe top 3 technologies to ever come out of Apple. It’s beautiful, easy to work with and there’s nothing I can’t do with it. It's not beautiful, nor easy to work with, nor does it work for every scenario. I am going to say something heretical: I have given up on auto layout and I find "manual" layout much easier. But that's because I rely on "one cool trick"[1]: Do not lay out views using an x-y cursor. Instead, slice up the bounds of the view being layed out using `CGRect.divide()`... So simple. If you're using manual layout but not using `CGRect.divide()`, I urge you to give it a shot it will change your life. Of course maybe everyone does it that way and I'm the only person who thinks it's a life-changer. :) [1] Side note: I learned this trick from a technical interview at EA games years ago... The best interviews are those where you leave knowing more than when you went in, even if you don't get the job.

cageface 9y ago
Dealing with auto layout is probably my least favorite aspect of iOS dev, but I wouldn't recommend doing layout by hand. There are just too many variables to consider to write really robust manual layouts. That said I'm really disappointed with UIStackView. When it was first announced it seemed like a great solution to a lot of common layout problems but in practice I've found it tends to cause as many problems as it solves and now I mostly just use it when I need a clean way to hide & reveal various UI elements dynamically. I'd take some variant of flexbox over all this any day.
- nielsbot 9y ago
  I do think auto-layout could be fixed with better a) design tools and b) visualization, test and debug tools.
- oculusthrift 9y ago
  i just use pure nslayoutconstraints and don’t have to deal with uibuilder. i find it pretty easy. especially if you code yourself some helper functions for it
- krzat 9y ago
  What problems did you have with UIStackView?
  - cageface 9y ago
    Adding or hiding elements often causes layout conflicts, because UIStackView adds a new constraint at 1000 priority. You have to work around this by bumping one of the other constraints down to 999. Also recent versions of interface builder tend to complete fail at rendering nested stack views, even though the layouts work fine when you actually run the app.
xor1 9y ago
Never heard of using CGRect.divide(), thanks!
asveikau 9y ago
Maybe someone with more experience in the platform can confirm or deny this. There are a bunch of things that have been standard issue in certain frameworks for decades. Then Apple "invents" the same topic and the Apple-focused people who have not looked elsewhere start to drool over it and call it very innovative and new. I think Auto Layout smells like one of these. UI toolkits in other niches have had dynamically sized layout engines for a long time. But some platforms, like Win32, or Mac, or NeXT, were more into absolute positioning for longer. Now Apple is picking up other ideas, and it's oh my god so amazing (assuming you've been in the Apple world the whole time).
- ridiculous_fish 9y ago
  I was one of the maintainers (but not inventors) of Apple's autolayout. It's not at all true that "Mac or NeXT" (?) views were absolutely positioned: they used dynamic positioning via autoresizing, which started with a reference layout and then declaratively described how to modify it. This already is well beyond simple absolute layouts and is sufficient for many cases. Autolayout takes this a step further by adding constraints and priorities for breaking them. This allows you to declaratively and naturally express tricky layouts like aspect ratios or preferred minimum sizes ("I'll have to truncate at...") which are typically special-cased in other layout engines. Tooling around this stuff is challenging, but the architecture is leagues beyond the simple dynamic layout engines in other UI toolkits. iOS can't fully realize it (no resizable windows) but on the Mac it shines.
  - asveikau 9y ago
    I guess I must have imagined a decade or more of seeing absolute positioning in objc code. I will re-state it. What would cause people to say that Auto Layout is one of the top achievements Apple has ever produced? Unfamiliarity with how other people have approached the problem is high on my list.
- rimliu 9y ago
  As usual Apple does not claim it invented the concept. They refer to http://constraints.cs.washington.edu/cassowary/ http://constraints.cs.washington.edu/cassowary/ in their WWDC 2011 session 103.
tzahola 9y ago
There’s one thing you cannot do with manual layout, and that is composability. If you write a custom container, but want the contents of the container to provide sizing information upwards, you can do that pretty easily with AutoLayout. Constraints propagate information automatically in both directions. You can simulate something similar with sizeToFit/sizeThatFits, but you’ll find out pretty soon that your components are not as generic as you thought they were. E.g. how to trigger a grandparent relayout from a deeply nested child view, when it no longer fits its current size? Autolayout does that automatically.
- nielsbot 9y ago
  I use the intrinsicSize property to send requested size info upwards (subview->superview). using that you can resize your views correctly during the layout.
rimliu 9y ago
I guess autolayout and CSS are the pointers of UI development. For some it clicks, for others it does not. I've enjoyed making layouts in CSS even before flexbox and grid, and I have no problems doing it using autolayout. But there are problems if you are not using AL. Having layout guides and anchors makes it much easier compared to pre iOS9 days. Just don't do it in IB—it may look easier this way, but it is a pain to debug. I find myself leaning more and more on UI creating in code only, so much more flexible and gives more control. Manipulating frames may seem to give more control, but I think it takes even more away, introduces unneeded complexity (missing out on layout guides, size classes, intrinsic size, easy control for compressibility/content hugging, etc.). I wonder how many devs who used frames for layout are regretting this decision while fixing their apps for iPhone X.
golergka 9y ago
I have little experience with iOS auto-layout (and iOS development in general), but auto-layout engines on every OS or framework are always hard to get into exactly because automatic layout of interface is a hard problem - and solving it properly requires quite a high level of abstraction. Which always seem too hard to digest to developers that are just getting into the framework are only trying to position elements at fixed points on the screen, without giving any serious thought to automatic layout. As a result, most of the projects that I inherited as a maintainer almost never used advanced auto-layout features and every change in the interface required re-positioning all other elements by hand. So, auto-layout ends up right there with static typing and unit tests: technologies that are of little use to the original developers who are only trying to "get shit done" up and running, but are so important for maintainers that end up with this mess later.
vbezhenar 9y ago
How your layout responds to changed text (localization). I've found that fixed layout generally works (I remember Delphi which was a breeze to design UI) but when your labels become long, everything is out of place.
gwking 9y ago
The divide trick is interesting; I've used it here and there over the years but never came to rely on it. Looks like the pattern became much more concise with Swift's tuple unpacking. For what it's worth, I settled on "two uncool tricks": the venerable autoresize mask, which I have aliased to be shorter words, and extension properties for top, left, right, bottom, and center. These are just convenience accessors over a view (or layer's) frame, but there is one crucial design choice: when right or bottom mutates, it moves the origin (as opposed to resizing - this way left/right/top/bottom all have similar meaning). Together these properties lets me write code that states intent more directly and succinctly, e.g. for a content view and a bottom bar, `bar.bottom = view.height; content.height = bar.top;`. It's still imperative code, and order matters, but it reads decently well. Conditional insertions can be just that, etc. Lastly, it helps immensely to factor out constants into named properties, e.g. `let y_margin = 4; let text_pad = 2`, especially for maintenance. It is essentially the x-y cursor approach without a cursor - just use the relative properties of the layout built thus far to position the next item. As for autoresize, the dumb trick worth mentioning is to initialize autoresized root views with a weird size, e.g. 99x99. Then if something is not configured right you will see the telltale square. I have given auto layout several serious tries, most recently in 2014 or so. I tried both Interface Builder (which I deeply dislike due to nonsense XML git conflicts) and code. I found that with a few extension properties I could write auto layout code by hand effectively, but what ruined it for me was that ApKit throws layout exceptions. In general I appreciate Apple's approach to exception handling but to have my view crash before I could even see the layout was very unproductive. In contrast, when I make an autoresize mistake I can usually see what the problem is and correct it, rather than guessing at which combination of constraints caused an exception. I would be curious to hear from folks if the auto layout situation has improved, and if there are tools that have helped with debugging (I used to rely on Reveal a lot).
nodamage 9y ago
The one place where I've found autolayout makes things much easier is dealing with variable height table cells. Manually measuring the heights of cells is a lot more work compared to using self-sizing cells and having autolayout do it for you. Especially if you want to support Dynamic Type which means that every table cell containing text potentially has a variable height. On the other hand, there are situations where if your views are highly dynamic then the complexity of autolayout starts to negate its benefits. Any time you need to save references to a bunch of constraints so you can adjust their constants or toggle them on/off later. Or if you have one set of constraints to start but need to replace them with other constraints at runtime as your data changes. Or if you have a lot of subviews to layout and you need to start coordinating content hugging/compression resistance/layout priorities between them. (This is the worst cause it starts to feel like you are adjusting arbitrary magic numbers to make your layout behave the way you want.) At some point you cross a threshold where your autolayout code gets absurdly complicated and you might as well have done it all manually. Ultimately I've found it best to treat autolayout like any other tool in the box: use it when it makes things easier, but don't hesitate to rip it out and do things manually when the situation arises.
- hyberbole_1234 9y ago
  I recommend using Cartography for this
deleted 9y ago
[deleted]

cageface 9y ago

Dealing with auto layout is probably my least favorite aspect of iOS dev, but I wouldn't recommend doing layout by hand. There are just too many variables to consider to write really robust manual layouts. That said I'm really disappointed with UIStackView. When it was first announced it seemed like a great solution to a lot of common layout problems but in practice I've found it tends to cause as many problems as it solves and now I mostly just use it when I need a clean way to hide & reveal various UI elements dynamically. I'd take some variant of flexbox over all this any day.

nielsbot 9y ago
I do think auto-layout could be fixed with better a) design tools and b) visualization, test and debug tools.
oculusthrift 9y ago
i just use pure nslayoutconstraints and don’t have to deal with uibuilder. i find it pretty easy. especially if you code yourself some helper functions for it
krzat 9y ago
What problems did you have with UIStackView?
- cageface 9y ago
  Adding or hiding elements often causes layout conflicts, because UIStackView adds a new constraint at 1000 priority. You have to work around this by bumping one of the other constraints down to 999. Also recent versions of interface builder tend to complete fail at rendering nested stack views, even though the layouts work fine when you actually run the app.

xor1 9y ago

Never heard of using CGRect.divide(), thanks!

asveikau 9y ago

Maybe someone with more experience in the platform can confirm or deny this. There are a bunch of things that have been standard issue in certain frameworks for decades. Then Apple "invents" the same topic and the Apple-focused people who have not looked elsewhere start to drool over it and call it very innovative and new. I think Auto Layout smells like one of these. UI toolkits in other niches have had dynamically sized layout engines for a long time. But some platforms, like Win32, or Mac, or NeXT, were more into absolute positioning for longer. Now Apple is picking up other ideas, and it's oh my god so amazing (assuming you've been in the Apple world the whole time).

ridiculous_fish 9y ago
I was one of the maintainers (but not inventors) of Apple's autolayout. It's not at all true that "Mac or NeXT" (?) views were absolutely positioned: they used dynamic positioning via autoresizing, which started with a reference layout and then declaratively described how to modify it. This already is well beyond simple absolute layouts and is sufficient for many cases. Autolayout takes this a step further by adding constraints and priorities for breaking them. This allows you to declaratively and naturally express tricky layouts like aspect ratios or preferred minimum sizes ("I'll have to truncate at...") which are typically special-cased in other layout engines. Tooling around this stuff is challenging, but the architecture is leagues beyond the simple dynamic layout engines in other UI toolkits. iOS can't fully realize it (no resizable windows) but on the Mac it shines.
- asveikau 9y ago
  I guess I must have imagined a decade or more of seeing absolute positioning in objc code. I will re-state it. What would cause people to say that Auto Layout is one of the top achievements Apple has ever produced? Unfamiliarity with how other people have approached the problem is high on my list.
rimliu 9y ago
As usual Apple does not claim it invented the concept. They refer to http://constraints.cs.washington.edu/cassowary/ http://constraints.cs.washington.edu/cassowary/ in their WWDC 2011 session 103.

tzahola 9y ago

There’s one thing you cannot do with manual layout, and that is composability. If you write a custom container, but want the contents of the container to provide sizing information upwards, you can do that pretty easily with AutoLayout. Constraints propagate information automatically in both directions. You can simulate something similar with sizeToFit/sizeThatFits, but you’ll find out pretty soon that your components are not as generic as you thought they were. E.g. how to trigger a grandparent relayout from a deeply nested child view, when it no longer fits its current size? Autolayout does that automatically.

nielsbot 9y ago
I use the intrinsicSize property to send requested size info upwards (subview->superview). using that you can resize your views correctly during the layout.

rimliu 9y ago

I guess autolayout and CSS are the pointers of UI development. For some it clicks, for others it does not. I've enjoyed making layouts in CSS even before flexbox and grid, and I have no problems doing it using autolayout. But there are problems if you are not using AL. Having layout guides and anchors makes it much easier compared to pre iOS9 days. Just don't do it in IB—it may look easier this way, but it is a pain to debug. I find myself leaning more and more on UI creating in code only, so much more flexible and gives more control. Manipulating frames may seem to give more control, but I think it takes even more away, introduces unneeded complexity (missing out on layout guides, size classes, intrinsic size, easy control for compressibility/content hugging, etc.). I wonder how many devs who used frames for layout are regretting this decision while fixing their apps for iPhone X.

golergka 9y ago

I have little experience with iOS auto-layout (and iOS development in general), but auto-layout engines on every OS or framework are always hard to get into exactly because automatic layout of interface is a hard problem - and solving it properly requires quite a high level of abstraction. Which always seem too hard to digest to developers that are just getting into the framework are only trying to position elements at fixed points on the screen, without giving any serious thought to automatic layout. As a result, most of the projects that I inherited as a maintainer almost never used advanced auto-layout features and every change in the interface required re-positioning all other elements by hand. So, auto-layout ends up right there with static typing and unit tests: technologies that are of little use to the original developers who are only trying to "get shit done" up and running, but are so important for maintainers that end up with this mess later.

vbezhenar 9y ago

How your layout responds to changed text (localization). I've found that fixed layout generally works (I remember Delphi which was a breeze to design UI) but when your labels become long, everything is out of place.

gwking 9y ago

The divide trick is interesting; I've used it here and there over the years but never came to rely on it. Looks like the pattern became much more concise with Swift's tuple unpacking. For what it's worth, I settled on "two uncool tricks": the venerable autoresize mask, which I have aliased to be shorter words, and extension properties for top, left, right, bottom, and center. These are just convenience accessors over a view (or layer's) frame, but there is one crucial design choice: when right or bottom mutates, it moves the origin (as opposed to resizing - this way left/right/top/bottom all have similar meaning). Together these properties lets me write code that states intent more directly and succinctly, e.g. for a content view and a bottom bar, `bar.bottom = view.height; content.height = bar.top;`. It's still imperative code, and order matters, but it reads decently well. Conditional insertions can be just that, etc. Lastly, it helps immensely to factor out constants into named properties, e.g. `let y_margin = 4; let text_pad = 2`, especially for maintenance. It is essentially the x-y cursor approach without a cursor - just use the relative properties of the layout built thus far to position the next item. As for autoresize, the dumb trick worth mentioning is to initialize autoresized root views with a weird size, e.g. 99x99. Then if something is not configured right you will see the telltale square. I have given auto layout several serious tries, most recently in 2014 or so. I tried both Interface Builder (which I deeply dislike due to nonsense XML git conflicts) and code. I found that with a few extension properties I could write auto layout code by hand effectively, but what ruined it for me was that ApKit throws layout exceptions. In general I appreciate Apple's approach to exception handling but to have my view crash before I could even see the layout was very unproductive. In contrast, when I make an autoresize mistake I can usually see what the problem is and correct it, rather than guessing at which combination of constraints caused an exception. I would be curious to hear from folks if the auto layout situation has improved, and if there are tools that have helped with debugging (I used to rely on Reveal a lot).

nodamage 9y ago

The one place where I've found autolayout makes things much easier is dealing with variable height table cells. Manually measuring the heights of cells is a lot more work compared to using self-sizing cells and having autolayout do it for you. Especially if you want to support Dynamic Type which means that every table cell containing text potentially has a variable height. On the other hand, there are situations where if your views are highly dynamic then the complexity of autolayout starts to negate its benefits. Any time you need to save references to a bunch of constraints so you can adjust their constants or toggle them on/off later. Or if you have one set of constraints to start but need to replace them with other constraints at runtime as your data changes. Or if you have a lot of subviews to layout and you need to start coordinating content hugging/compression resistance/layout priorities between them. (This is the worst cause it starts to feel like you are adjusting arbitrary magic numbers to make your layout behave the way you want.) At some point you cross a threshold where your autolayout code gets absurdly complicated and you might as well have done it all manually. Ultimately I've found it best to treat autolayout like any other tool in the box: use it when it makes things easier, but don't hesitate to rip it out and do things manually when the situation arises.

hyberbole_1234 9y ago
I recommend using Cartography for this

deleted 9y ago

[deleted]