Continuing from the previous version, I upgraded to Swift 3 and Xcode 8 (beta 4). Most of the glitches are gone, but every now and then one shows up. So I’m not entirely sold on the whole thing yet. I’m still having doubts if it wouldn’t be simpler to just have the user enter text in a separate popup of some kind, and only display read-only views in the actual table. The problem with that is that it is a lot less intuitive and user-friendly. OTOH, it would work… I get a feeling Apple really doesn’t want us to do editing in text views in table cells. I don’t think any of Apple’s own apps do that.
Tag: constraints
Now with editing and rotation
I went on and extended the autoresizing table cells to handle interface rotation and table editing as well. In both these cases, the width of the table cell content view changes, so the height of the text view needs to be recalculated. To achieve that, you need to wait to measure the new width of the text view until everything has settled down, but this turns out to be surprisingly difficult. The only functions I found that were called late enough in the view update cycle to give me the new definite text view width were didRotateFromInterfaceOrientation in the controller for rotations, and didTransitionToState in the table view cell for editing state changes.
Autoresizing table cells
Extending the autoresizing of UITextView to table cells, this is how that looks.