The way I set constraints is: 1) Add them 2) Position the views by typing numbers in manually rather than dragging 3) Xcode->Editor->Resolve Auto Layout Issues->Update Frames (either Selected Views or All Views) 4) If the view blows up: undo, then find the uncooperative constraint and fix its numbers and repeat #3 5) After performing #3 for the eleventeenth time: Xcode->Preferences...->Key Bindings, enter “frame” and add keyboard shortcuts for Resolve Auto Layout Issues 6) Never, ever use Update Constraints, Add Missing Constraints, or Reset to Suggested Constraints (as these corrupt the hard won constraints that have been entered so far)
7) This is not a step, but from a code perspective, only use: [UIView setNeedsLayout]; [UIView layoutIfNeeded]; Avoid using: [UIView setNeedsUpdateConstraints]; [UIView updateConstraintsIfNeeded]; [UIView updateConstraints]; The only time you EVER need to call updateConstraints or updateConstraintsIfNeeded is if you are manually setting constraints, perhaps with an IBOutlet NSLayoutConstraint or by adding/removing constraints in code. Think of it as, your constraints are your canonical source of truth (like a database) and you are generating the view positions from that. Avoid trying to update constraints based on view positions. 8) To Apple: The menus in #5 need to be removed completely. I would recommend replacing them with suggestions on hover or some kind of agent that assists us with cleaning up constraints in a diff-style view like the kind used in version control, letting us preview and add/remove/update various constraints until the layout is right. ### rant ### I think where auto layout went wrong is that its constraints were already being generated by autoresizing masks, so making them mutually exclusive was shortsided. There is something to be said for working at the conceptual level that gives us the most leverage. We should have been able to choose at the view level whether to use layout/autoresizing instead of at the file level (which would have corresponded with how the API works). Not only that, we should have been able to apply the transformations to swap between them with the click of a mouse (if they are mathematically equivalent). It’s much easier to explain to a designer that clicking the red arrows keeps views proportional, rather than trying to explain the intricacies of a system of linear equations. Methodologies shouldn’t be adopted for political reasons, and especially when those reasons break conventions that are working well in the field. Conceptually auto layout is pretty good, its major failings are mostly with: 1) overzealous limitations in the API 2) poor documentation (lack of serious examples) 3) obtuse GUI in Interface Builder The API overreached when it prevented setting a constraint’s multiplier. This was done for performance reasons (which is almost always a bad idea, since computers are getting ever faster). So that locked us into the mentality that we’re designing at the pixel level rather than fluidly based on ratios with other elements. It also prevents interpolations and animations, for example if we want to make a widget as simple as a bar graph, we have to remove a constraint, change it’s multiplier between 0 and 1, then reinsert it. Or, we have to add additional views/constraints to try to emulate multipliers with constants. It’s difficult conceptually to understand why adding a constraint in VFL can generate a large array of constraints, and how those constraints can conflict with existing constraints and cause the layout to blow up. I have sometimes spent hours solving these paradoxes. This friction is quaint and I feel disappointed whenever I’m forced to drop conceptual correctness and add in a lot of cruft to get a view to come together. The documentation is poor because I have yet to find good examples of visual format language on Apple’s sites (the kind that are readily available for say, css). I’m sure someone will find links to reply with, but that’s not what I’m getting at. My gut feeling is that when auto layout first came out, a lot of people even at Apple maybe didn’t understand it completely, or every edge case where it breaks down, so the documentation was written as a spec instead of as real-world examples. If I was rewriting the docs, I’d be tempted to throw them all away and present them top-down, with a list of most of the common use cases and examples of how to accomplish them. But, what they really need is a better bottom-up mathematical explanation of how the method parameters correspond to the equations. For example, it’s still a mystery to me if a view’s left edge can be proportionately set against another view’s vertical center. If there is no mathematical reason for that to be limited, then the API should allow every permutation. If there is a reason, then Apple should explain in more detail why the API doesn’t correspond to the math. Like with multipliers, I sense that there may be more limitations that aren’t well documented. Don’t get me started on Interface Builder. It’s so broken that I hoped to save myself some grief and provide the workflow above rather than beating a dead horse. It’s started inflicting some pretty aggregious offenses for me lately, like saving views positioned on the half pixel. There is also a long standing bug that causes IB files to change just by opening them. I find that the XML gets filled with superfluous misplaced=“YES” that cause me a lot of unnecessary grief if I’m working with a team and someone commits the IB file without verifying its integrity first. And what I just said presents a big problem because a layout shouldn’t have bad integrity in the first place. This is like a code smell, indicating that something is wrong with the conceptual approach that IB is taking with auto layout. I don’t know the solution but there are a lot of smart people at Apple who can figure it out better than I can. I think part of the solution is to work in an autoresizing style and only add the occasional advanced constraint where warranted. The final solution may be to decouple Interface Builder from Xcode, perhaps as an open source project, so that it can evolve. Zack Morris > On Aug 27, 2015, at 8:38 AM, Dave <[email protected]> wrote: > > Hi, > > Has anyone successfully managed to make auto-layout do anything other than > the most simplest case work? This is a Mac project using XCode 6.4 and I’m > having all kind of trouble. > > For instance, I click on a control and add a constraint to Top, Bottom, Left, > Right of a view and fix the Width and Height, them click add constraints. If > I later click on this view again and select Add contestants, rather than > showing me what is set, shows that no constraints have been added. If I add > them again, rather than replacing the old constraints it adds them all again, > so I end up with two lots of constraints! Is this expected? > > I’m been trying to get get my head around this for a 1.5 days now and I’m in > the verge of getting rid of Auto-Layout altogether and going back to the old > way of doing things which has the added advantage of actually working. I’m > totally shocked that after all the hype on how great it is, it actually sucks > big time when you try to do something non-trivial. As usual I’m sure that > actual Auto-Layout implementation its just the XCode side of things that > sucks as usual. > > If anyone knows of a good tutorial I’d be happy to hear about it or maybe > Auto-Layout is just FooBar’ed in XCode 6.4? > > Cheers > Dave > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Xcode-users mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/xcode-users/zmorris%40gmail.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
