Can I use setFrame and autolayout on the same view?
I want to add padding to all of my buttons, so I subclassed UIButton, and among other changes, I wanted to add a fixed padding by using setFrame method. Everything was working, except for setFrame. I checked around, and I found out that if I uncheck "using AutoLayout" on that view, then I can use setFrame, and it works. Is there a way around this? I really want to use autolayout, because it helps in making the app look nice on both iphone 5 and earlier devices. But I also would like to use setFrame in my subclass, to make my life a litle easier.
Summing up, my question is: Can I use autolayout and also adjust the frame of a UIView programmatically?
Yes, this can be done.
If you set a view's translatesAutoresizingMaskIntoConstraints = YES
, then calls to setFrame:
are automatically translated at runtime into layout constraints based on the view's current autoresizingMask
. This lets you mix frame-based layout with constraint-based layout.
For instance you could use Auto Layout to define the layout of all of the subviews of a view, but still call setFrame:
to set the size and position of the view itself. From your perspective, you're doing layout with a mix of Auto Layout and direct frame manipulation. But the system is actually using constraints to handle everything.
However, there is one big caveat about using translatesAutoresizingMaskIntoConstraints
.
When you do this, you still need to make sure that these automatic constraints can be satisfied with the rest of your constraints.
So, for instance, suppose there are already constraints that determine the size and position of your view, and then you also set translatesAutoresizingMaskIntoConstraints = YES
and called setFrame:
. The call to setFrame:
will generate new constraints on the view, which will probably conflict with the already existing constraints.
(In fact, this error happens often. If you ever see a log message complaining about conflicting constraints, and one of those constraints is a NSAutoresizingMaskLayoutConstraint
, then what you're seeing is a conflict with an automatic constraint. This is an easy mistake, because translatesAutoresizingMaskIntoConstraints = YES
is the default value, so if you're configuring constraints in code you need to remember to turn it off if you don't want these automatic constraints.)
In contrast, suppose again that there are already existing constraints that determine the size and position of your view, but then you set translatesAutoresizingMaskIntoConstraints = NO
before you call setFrame:
. In this case, your setFrame:
calls would not produce new constraints, so there would be no conflict between separate constraints. However, in this case, there is still a "conflict" between the constraints and the frame value you set. At the next time Auto Layout is invoked, it would see the already existing constraints on the view, calculate the frame value which they require, and set the frame to the required value itself, clobbering the value you set manually.
For more details, check out the section "Adopting Auto Layout" in Apple's Cocoa Auto Layout Guide.
What turned out to be the easiest thing for me was to remove the view I wanted to move/resize from its superview, set its frame
, and then add it back. For example, take a custom UILabel
in a UITableViewCell
subclass:
[cell.myLabel removeFromSuperview];
cell.myLabel.frame = someFrameIGenerated;
[cell.contentView addSubview:cell.myLabel];
Something that worked for me was simply adding an IBOutlet
for my constraints to the view controller, then changing the constant
property on the outlet.
For example, to change the x origin of a view, set an outlet from that view's leading constraint to your controller. In other words, create an outlet @IBOutlet var labelXOrigin: NSLayoutConstraint!
. Then, when you want to adjust the x position, simply do something like
self.labelXOrigin.constant = 20.0 // Or whatever origin you want to set.