Comment on Show HN: iOS Table View that automatically adjusts with keyboard show/hideComments−thought_alarm14yYou should be setting the TableView's `contentInset` and `scrollIndicatorInsets` properties, rather than adjusting the TableView's frame.Convert the keyboard frame to the superview's coordinate system using `-convertRect:fromView:`, e.g. : keyboardFrame = [tableView.superview convertRect:keyboardFrame fromView:tableView.window]; The bottom inset is then simply the difference between the TableView's height and the keyboard's Y coordinate.You would also set those properties and scroll to the selected row in the same animation block.−bobsprynOP14yI believe I started to try that method but ran into issues. Wasn't aware of the scrollIndicatorInsets though, so maybe that was the issue.Would that method have any significant advantages? Less code? Would it avoid all the crazy frame calculations depending on the rotation?−thought_alarm14yYes, `-convertRect:fromView:` replaces your frame calculations based on rotation.−bobsprynOP14yAh yes. I see now that I totally missed the fact that the keyboard rect also needed to be converted. Well that was a painful point to miss!Cool. I'll give that a whirl. Those rotation bits were a biatch. Thanks for the pointers.
Comments
You should be setting the TableView's `contentInset` and `scrollIndicatorInsets` properties, rather than adjusting the TableView's frame.
Convert the keyboard frame to the superview's coordinate system using `-convertRect:fromView:`, e.g. :
The bottom inset is then simply the difference between the TableView's height and the keyboard's Y coordinate.You would also set those properties and scroll to the selected row in the same animation block.
I believe I started to try that method but ran into issues. Wasn't aware of the scrollIndicatorInsets though, so maybe that was the issue.
Would that method have any significant advantages? Less code? Would it avoid all the crazy frame calculations depending on the rotation?
Yes, `-convertRect:fromView:` replaces your frame calculations based on rotation.
Ah yes. I see now that I totally missed the fact that the keyboard rect also needed to be converted. Well that was a painful point to miss!
Cool. I'll give that a whirl. Those rotation bits were a biatch. Thanks for the pointers.