What is a 'UIView-Encapsulated-Layout-Width' constraint?

Question

I keep getting 'Unable to simultaneously satisfy constraints' exceptions (Xcode 5, iOS 7, both device and simulator), where one of the constraints in the list is something like this:

"<NSLayoutConstraint:0x165b23d0 'UIView-Encapsulated-Layout-Width'
H:[StoryPlayerCell:0x165affc0(0)]>"

I did not set this constraint myself. It's also not an NSAutoresizingMaskLayoutConstraint. But where does it come from? And how can I get rid of it?

I have no idea. And I can't find anything about 'UIView-Encapsulated-Layout-Width' in the Apple's documentation. Even the Google search returns nothing at all.

Any suggestions?

PS: I'm using this cell in a UICollectionView with a custom subclass of UICollectionViewFlowLayout. Maybe the 'Encapsulated-Layout' part has something to do with this?

Answer 1

A quick and nice fix, is to assign 999 priority value to the custom constraints with high priority. The encapsulated & auto-generated constraints should dominate with higher priority than your constraints.

https://stackoverflow.com/a/25795758/590010

Answer 2

i played with the sample, i think these codes is causing the Autolayout exception.

CGFloat height = MAX(0, -y + maxY); line 79 in CSStickyHeaderFlowLayout.m.

if you use a static value for the height like 200, the exception won't happen anymore. i can't understand what exactly is UIView-Encapsulated-Layout, but seems like dynamically changing the UICollectionViewLayoutAttributes frame may cause that problem. in the sample project, it's the height, in PO's problem, i guess it's the width. Maybe i can dig a little bit more into it, if you think that would be helpful

Answer 3

I found this with iOS 10 builds where I was using UITableViewCell subclasses as normal views not as table rows. The cell was constraining its contentView to zero width.

The workaround I used was to just add the contentView to the view hierarchy instead of the tableview cell. I also made sure to retain the tableView cell (as it was no longer being retained by the view hierarchy itself).

Answer 4

My situation

For me, I knew (logically) that my programmatic constraints should have worked. I was updating them after rotation of the device.

My quick-and-easy solution without changing constraints was to make sure that this was all done on the main thread. Why? I'm not too sure, but I assume that the rotation update must be in an asynchronous thread.

How I fixed it

From:

topTitleLeadingAnchorLandscape.isActive = true

To:

DispatchQueue.main.async {
    self.topTitleLeadingAnchorLandscape.isActive = true
}

---

Hope this saves someone lots of time in the future! 😀

Answer 5

I can shed some light on the answer to the question. In my OS X app, I found such a mysterious constraint on the cell view of an NSTableView, (that is, an object which I had previously returned in the NSTableViewDelegate method -tableView:viewForTableColumn:row). I had also sent a setWidth:0.0 message to this same table column. Changing the parameter in that setWidth: from 0.0 to something else was reflected in the constant value of the mysterious constraint.

Conclusion: Constraints which log themselves with 'UIView-Encapsulated-Layout-Width' or 'NSView-Encapsulated-Layout-Width' are caused by setting the width of a table column, or something similar.