title: Keyboard "WillShow" and "WillHide" vs. Rotation
body: <p>I've got a view controller listening for both UIKeyboardWillShowNotification and UIKeyboardWillHideNotification. The handlers for these notifications adjust various parts of the view, which is standard procedure.</p>
  
  <p>The following code is used to convert the keyboard rect from screen coordinates:</p>
  
  <pre><code>CGRect keyboardBounds = [self.view convertRect:[keyboardBoundsValue CGRectValue] fromView:nil];
  </code></pre>
  
  <p>Again, standard procedure. Unfortunately, there is a critical situation where this conversion fails. Look at what happens when an iPhone is rotated from portrait to landscape while the keyboard is deployed:</p>
  
  <p>1) iOS automatically fires <em>UIKeyboardWillHideNotification</em>; self.interfaceOrientation is reported as <em>portrait</em>; keyboardBounds.height is <em>216.0</em>. <strong>This makes sense</strong>. Why? Because the notification handler is given the chance to "clean up" before the view switches to landscape mode.</p>
  
  <p>2) iOS automatically fires <em>UIKeyboardWillShowNotification</em>; self.interfaceOrientation is reported as <em>portrait</em>; keyboardBounds.height is <em>480.0</em>. <strong>This does NOT make sense</strong>. Why not? Because the notification handler is going to do its work thinking that the height of the keyboard is 480.0!</p>
  
  <p>Did Apple drop the ball on this one, or am I doing something wrong?</p>
  
  <p>Please note that listening instead for UIKeyboard<b>Did</b>ShowNotification is not a valid solution, because it significantly degrades the user experience. Why? Because animating my changes to the view after the keyboard deployment animation occurs is... well, pretty terrible-looking.</p>
  
  <p>Has anyone managed to get autorotation working perfectly while the keyboard is deployed? It seems like an explosion of chaos that Apple has completely overlooked. >:|</p>