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?

Solution 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

Solution 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

Solution 3

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! 😀

Solution 4

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).

View more solutions

Comments

[andreamazz]

That's right. Using 200 breaks the parallax effect though. Using 1 instead of 0 seems to solve the problem. Thanks for your help.

[Rog]

This is not an answer to the question :-(

[Goodsquirrel]

Actually this would only be a quick but not a nice fix, because the auto–generated constraint wants the cell width to be 0, which is not what I want.

[Alexey]

By the way, if custom constraints have lower priority now, why would not Auto Layout set label width to be 0, according to its higher-priority system constraint?

[andrew k]

@Goodsquirrel Did you make any progress with this?