After many experiments, I found the best answer to my question. The short answer is a change frame when you get a UIKeyboardDidHideNotification
.
A custom inputView is embedded in another view managed by a system called UIPeripheralHostView
. Therefore, changing a custom inputView at the wrong time does not immediately reflect or show an ugly layout at best.
When the device rotates, the system briefly hides the keyboard, and then animates the rotation of the keyboard from the old orientation to the new orientation. I think an animation block is inserted somewhere between the two notifications UIKeyboardDidHideNotification
and UIKeyboardWillShowNotification
. These notifications are associated with the UIKeyboardWillChangeFrameNotification
. βRamβ in this notification actually means a UIPeripheralHostView
frame.
Thus, changing the scope of my input view when I receive UIKeyboardDidHideNotification
gives the system the ability to adjust the frame of the UIPeripheralHostView
before starting the animation, which will lead to a smooth transition from the short keyboard to the high keyboard during orientation changes.
This works in iOS 5. But Apple may change the practice in the future.
source share