IOS7.0 Xcode5 AutoLayout Memorandum

 

Xcode5 xib:

List 1:

(This can be set when two views are selected)

Alignment on the left,

Right alignment,

Top alignment,

Bottom alignment,

X axis center alignment,

Y axis center alignment,

Text baseline alignment,

 

(This can be set when a single view is selected)

Align the X axis and center of the parent view,

The Y axis center alignment of the parent view,

 

(Select box)

No operation is performed after the constraint is added,

After adding constraints, place the view involved in the constraints again,

After adding constraints, place all the views in the container again.

 

Click OK. After selecting the above project, click Add constraint.

The cross above is "constraint with the nearest neighbor". Fill in the number and click the dotted line to turn it into a solid line to add this constraint.

Here, the "Neighbor" refers to a parent view containing a child view as a box with a pile of wood. The building blocks are used as "neighbors" compared with the border of the box and other building blocks"

 

(Defined wide/high data constraints)

Width specified,

Height specified,

 

(Defines the width and height constraints between multiple views)

Same Width,

Same height,

 

(List, alignment constraints between multiple views, equivalent to the content of the previous menu)

 

(List, frame update method, equivalent to the previous menu)

(Click OK. After setting constraints, click Add)

 

(The operation object in the upper half menu is the currently selected view, and the operation object in the lower half is the view in the selected view)

Refresh the frame (use all the constraints currently set ),

Refresh the constraint (update the constant value of the constraint based on the current constraint and frame ),

Add missing constraints (automatically add constraints that the system thinks you should add but forget to add. Conflicts often occur during testing)

Reset to the constraints recommended by the system (clear the constraints that the system deems repetitive/conflicting, and problems often occur during testing)

Clear all constraints (delete all constraints bound to an object)

 

(Which views are refreshed when constraints are added)

Same view and parent view

Sub-view

Problem: Constraints and constraints conflict, whether it is xib or xib, xib and code, code and code. constraint conflicts are usually reported only under specific circumstances. For example, if the landscape screen is normal but the landscape screen is conflicted, or if the xib is dragged up incorrectly, the conflict may occur. the system automatically resolves the constraint conflicts, usually relying on the permission level. However, due to the general usage, it is impossible to determine the permission level of a constraint, therefore, it is difficult to set the right level to cope with conflicts. conflicts of constraints may be handled differently when the system automatically resolves the same situation, resulting in some problems that cannot be reproduced every time. constraints conflict. An error log will appear during debugging. You can find and resolve the conflict based on the log. constraints conflict. No crash is found on ios6 and occasional crash occurs on ios7. the trade-off between xib and code: autolayout is no longer a "Don't use" issue, but a "how to use" issue. The underlying framework seems to have completely deleted autoresizemask, instead, autoresizemask is automatically converted to auto layout. In this case, the original autoresizemask can be used, but the system still uses them as autolayout, the constraint automatically converted during use will also encounter conflicts, and the problems caused by conflicts are even more strange and difficult to handle.

What I often encounter is that, for example, the autolayout used between a control and its parent view is specified by code. I can determine the constraint format, however, to facilitate the use of xib to process its internal view, the drag and drop constraint on xib will cause a constraint conflict in some specific situations due to its complexity and I have not yet clarified it, when the system automatically handles conflicts, the lower-level constraint will be abandoned. However, the system cannot determine the level of permission that each constraint should be in, there are often occasional problems (for example, there is no problem between the constraint in the vertical screen, after the horizontal screen is over, it is found that a label in a control accidentally did not delete the specified width of the constraint, this causes the constraint conflict between the deformed control and the label in the control, and then triggers a series of chain reactions)

Of course, the use of xib to define viewcontroller also requires access to constraint, and each of them must be managed and specified (by default, constraint often causes conflicts)