Comments 7
Но только так убивается вся суть iOS7+ дизайна: весь прикол был в том, что это не вся скроллвью смещается наверх. Скроллвью оставалась такой же фулскриновой, и ей лишь добавлялся нижний contentInset. Таким образом при скролле контента он мог заезжать под клавиатуру и быть чуть виден сквозь неё.
Более того, это поведение зашито в UITableViewController и работает из коробки. Если поместить UITextField в ячейку таблички, то даже строчки кода писать не придется – все взлетит, как есть.
Могу ошибаться, но это же поведение зашито и в UIScrollView. UITextView содержит в себе UIScrollView, а значит, что и в нем это поведение должно быть из коробки. Но если его вдруг нет, то лучше вешать contentInset на keyboardLayoutGuide, а не позицию компонента на экране.
Профиты "зашитого" поведения:
Не придется тратить время на написание того, что уже работает.
Не придется писать тесты своих велосипедов.
При последующих изменениях в ядре системы можно быть уверенным, что Apple о нас подумает и добавить поддержку старого кода и поведения.
К сожалению, поведение зашито только в UITableViewController и UICollectionViewController.
Значит, им там и место :)
А больше нигде и не нужно. И все попытки натянуть сову на глобус – неправильны в самой постановке реализации.
Либо пользуемся имеющимися контроллерами, либо создаем свой универсальный... Но мне сложно придумать такой универсальный контроллер, в котором мне бы пришлось добавлять поддержку работы с клавиатурой. Имеющихся двух вполне достаточно для решения проблемы, описанной в статье. Да и любой другой проблемы с клавиатурой.
Keyboard Layout Guide