Most of my iPhone apps need to accept keyboard input somewhere and that means I need to reposition my UI elements such that the keyboard does not hide the field the user is typing in. The iPhone Application Programming Guide offers one example of Moving Content That Is Located Under The Keyboard but this is not necessarily the best solution.
Resizing a view’s frame
One option is certainly to implement Apple’s example code and resize the view’s frame based on the dimensions of the keyboard every time the keyboard is shown or hidden.
Resizing a view’s frame with a reference view
When working with complex views, especially views that support rotation, I have found it convenient to add an extra empty view to my xib files to serve as a reference. I set this reference view to the dimensions I want my resizable view to match when the keyboard is hidden. I can then resize my view relative to this constant frame and not need to worry about reversing my resize calculations when the keyboard is hidden.
Setting UIScrollView’s inset properties
When working with a scroll view (or table view) I’ve found that the best option is to set the view’s content and scroll inset properties. Since this does not change the scroll view’s frame it eliminates the flicker the view resizing as the keyboard is dismissed (notable if the scroll view’s parent view has a different background color).
Example code
Examples of all three techniques are available as an Xcode project at http://svn.carbonfive.com/public/jonah/ManagingKeyboardExample/
Jonah,
Thanks for this sample. I wonder why it’s necessary to subtract the tabBarHeight from the keyboard height? It works just right, but it seems like it *should* be the right thing to set the bottom offset to the full keyboard height. Is this working around a UIKit bug, or is there another explanation?
Curious,
Jeff
Hi Jeff,
In the example project you have a table view which is positioned above a tab bar. When you present a keyboard it is aligned with the bottom of the screen, covering both the tab bar and part of the table view. In portrait mode that gives you a 216px high keyboard which covers the 49px tab bar and 167px of the table view. Since the table view’s inset is relative to the bottom of the table view if we set it to the full keyboard height and scrolled to the bottom of the table view you would have a 49px gap between the last cell and the top of the keyboard.
If you want to have a more portable implementation then what I should really be doing is calculating the position of the bottom of the table view relative to the bottom of the window and using that height (as long as it is less than the keyboard height) instead of the tab bar’s height. Then the insets would be set correctly for a table view positioned anywhere in the window.