iOS/MacOS Tricks to Debug/Detecting Ambiguous Auto Layouts Issues
This notes is written by Sheldon. You can find me with #iOSBySheldon in Github, Youtube, Facebook, etc.
This time I will bring you some tricks directly from Apple’s document regarding the ways to debug / detecting ambiguous warning (
“There are a few methods you can call to help identify ambiguous layouts. All of these methods should be used only for debugging. Set a breakpoint somewhere where you can access the view hierarchy, and then call one of the following methods from the console:
hasAmbiguousLayout. Available for both iOS and OS X. Call this method on a misplaced view. It returns
YESif the view’s frame is ambiguous. Otherwise, it returns
exerciseAmbiguityInLayout. Available for both iOS and OS X. Call this method on a view with ambiguous layout. This will toggle the system between the possible valid solutions.
constraintsAffectingLayoutForAxis:. Available for iOS. Call this method on a view. It returns an array of all the constraints affecting that view along the specified axis.
constraintsAffectingLayoutForOrientation:. Available for OS X. Call this method on a view. It returns an array of all the constraints affecting that view along the specified orientation.
_autolayoutTrace. Available as a private method in iOS. Call this method on a view. It returns a string with diagnostic information about the entire view hierarchy containing that view. Ambiguous views are labeled, and so are views that have
You may need to use Objective-C syntax when running these commands in the console. For example, after the breakpoint halts execution, type call
[self.myView exerciseAmbiguityInLayout] into the console window to call the exerciseAmbiguityInLayout method on the myView object. Similarly, type po
[self.myView autolayoutTrace] to print out diagnostic information about the view hierarchy containing myView.