UIView-Encapsulated-Layout-Width / Height Constrained to Zero

Question

There are a number of stack overflow questions about auto-layout of UITableView cells and section headers / footers that concern the UIView-Encapsulated-Layout-Width constraints that the UITableView uses to make its components be the correct size:

• what is NSLayoutConstraint "UIView-Encapsulated-Layout-Height" and how should I go about forcing it to recalculate cleanly
• iOS 8.3 'UIView-Encapsulated-Layout-Width' in Custom Keyboard
• Auto-layout: What creates constraints named UIView-Encapsulated-Layout-Width & Height?
• What is a 'UIView-Encapsulated-Layout-Width' constraint?

The purpose of these constraints seems pretty clear – they allow the UITableView and also UICollectionView to interface with constraint layout and pass in its specification about how large cells (and other components) should be.

Most issues seem to be that people have a set of required constraints that are incompatible with these encapsulation constraints also requiring a size of 0. The most workable answers seem to be to lower the priority of user defined constraints to 999 so that the framework's can overrule them.

However – what I'm interested in understanding is why is UITableView requiring a width of 0 for one of its views? Is this a bug? Or is it a results of incorrect use? Or does it make perfect sense?

Height constraints of 0 sometimes make sense, if cells are being expanded from nothing. Lowering priorities is a good way to handle this. But why would the cells be getting a width of 0?

Answer 1

UIView doesn't have the intrinsic size hence width and height constraints needed. UIView-Encapsulated-Layout-Width and UIView-Encapsulated-Layout-Height are created by UICollectionView / UITableView initially. And later on sets the constraint constant based to the sizeForItem or heightForRowAtIndexPath delegate method. To ensure that UICollectionViewCell / UITableViewCell created in cellForItem / cellForRow method will be having the exact size.