Just been having a quick play with this exercise, and the solution seems to be reasonably trivial:
adjust constraints to greater than or equal too to allow for growth
set the rowHeight to UITableViewAutomaticDimension
enable Dynamic Types - automatically adjust font for the labels in the nib
This all works, but it makes me wonder why we bother explicitly defining row height and label sizes? I’m guessing that there is a significant performance hit in using dynamic types and having to calculate the row height all the time.
Can anyone with more experience confirm or generally elucidate? Is there a better way to do this?
The original reason for setting row heights and label sizes was because that was the only way to do table view row sizes originally. In fact, if I recall corrctly (and I might be misremembering this so don’t hold me to this) I believe originally table rows had to be of uniform height under iOS. Then, you could specify the row height for each row via table view delegares and so you could change the height of each row. But then had to specify the height of each subview within the table cell so that each one can resize according to the row size.
Automatic row heights became possible only once Auto Layout was introduced and the ability to dynamically size rows has been slowly improving. If you use Auto Layout, setting up dynamic sizing is probably the best option to go with these days. But sometimes getting it all to work together (Auto Layout, dynamic sizing, dynamic type etc.) can be a bit painful. So, we still use explicit row heights because that’s what we were used to and because the other option can get a bit more complicated at times.
Given that Xcode 9 now also provides easier ways to set dynamic row heights via Interface Builder, I think that in the next few years dynamic row heights might become the norm. Personally, I think it’s just a matter of adjusting to change
