I am preparing my main apps to be compatible with iOS 8 and upcoming new devices of possibly varying physical sizes. First order of business: remove any hard-coded 320 values in various places.
In Units convert (note: the upcoming version 3.0 will be called Unitica) I have a very complex cell in the favorites screen.
When you swipe over that cell, you get the option to remove that particular favorited pair; doing that triggers cell removal and adjustment of the position of cells below. And it throws this lovely exception doing that:
1 2 3 4 5 6 7 8 9 10 11 12 13
But – not always: it throws this exception only when there are enough cells that at least one is fully below the bottom edge of the screen. Meaning - the exception is thrown on the cell that will go up and thus appear on the screen.
autoresizesSubviews=YES on the
Look at the last line in the exception report:
At this moment, width of the cell is 0, and since I have many subviews inter-dependent on each other, some of them become impossible to satisfy. My guess: it’s the constraint that unit symbol and name labels are equal to 50% of the cell width minus 40 (the padding on both sides) and that width then becomes
-40pt, which is not allowed, hence the exception.
Thus, unchecking that checkbox in the .xib and all is fine.
Caveat: it’s worth noting that setting
autoresizesSubviews=NO will disable size auto-adjustment of the cell subviews when the cell bounds change. For example, if you have a layout where one can pan around and change container sizes, then cell content will be oblivious to that.
In that case it’s worth revisiting your constraints and see is it possible to remove the dependence on the bounds size.