I saw the headline , didn't even read the article and came here to say this and saw your comment.
I've been struggling with auto-layout for about six months now. I finally get it but there's a certain impedance mismatch between how you want your elements to be laid out and what constraints are required to achieve the same result. Humans beings aren't wired to intuitively think like a constraint solver.
I'm not an experienced developer but my thinking on this issue is that the platform should provide some functionality to achieve the most common boiler-plate layouts and anything more complex should be written in code.
Usually constraints are simple and so are the layouts. But to achieve more complex layouts you need constraints which are at cross purposes to each other but have different priorities. It's not intuitive to work through this stuff.
The answer there is great but tell me , you could have aspect fitted the view to it's parent in just four lines of code instead of going through this confusing series of constraints.
I was making a tic tac toe game and I decided to try and draw the boxes and lines using auto layout. The constraints were making me tear my hair out and finally I wrote 5 lines of custom layout code and it took me only ten minutes and this was after futzing about with the constraints for half an hour and it did what I wanted to on an iPhone , iPad and for any height or width.
I personally believe in a simplified version of FlexBox for common cases (yes I think it needs to be even simpler) and custom code for anything more complex.
Bringing in all the baggage of a constraint solver to do your layout is like trying to use an Abrams Tank to kill a mouse.
Perhaps the right approach would be to still use constraints to describe the layout, but to infer those constraints from examples provided interactively by the designer. The workflow would be:
10 designer creates an initial mock-up
20 designer re-sizes the window / uses another device
30 designer alters the style on that new format, re-sizing boxes, changing font sizes, etc.
40 constraint solver finds a minimal set of constraints consistent with the designer wishes
The examples are meta-constraints. The fitness function is the parsimoniousness of layout constraints, under the constraint that they reproduce the examples.
Yes. Even though I understand the math and the concepts for iOS's constraint based layout, I have found it amazingly difficult to use in practice. In IB, if you set one thing wrong suddenly many of your view's just disappear ... "undo" (or just starting over from scratch) is frequently employed. Debugging is a nightmare ... some cases I never figured out:
I've been struggling with auto-layout for about six months now. I finally get it but there's a certain impedance mismatch between how you want your elements to be laid out and what constraints are required to achieve the same result. Humans beings aren't wired to intuitively think like a constraint solver.
I'm not an experienced developer but my thinking on this issue is that the platform should provide some functionality to achieve the most common boiler-plate layouts and anything more complex should be written in code.
Usually constraints are simple and so are the layouts. But to achieve more complex layouts you need constraints which are at cross purposes to each other but have different priorities. It's not intuitive to work through this stuff.
Here's an example :
http://stackoverflow.com/questions/25766747/emulating-aspect...
The answer there is great but tell me , you could have aspect fitted the view to it's parent in just four lines of code instead of going through this confusing series of constraints.
I was making a tic tac toe game and I decided to try and draw the boxes and lines using auto layout. The constraints were making me tear my hair out and finally I wrote 5 lines of custom layout code and it took me only ten minutes and this was after futzing about with the constraints for half an hour and it did what I wanted to on an iPhone , iPad and for any height or width.
I personally believe in a simplified version of FlexBox for common cases (yes I think it needs to be even simpler) and custom code for anything more complex.
Bringing in all the baggage of a constraint solver to do your layout is like trying to use an Abrams Tank to kill a mouse.