iOS: post the code that closes the input panel

When the user is tranferring input focus between line edits
(or similar controls), the edit that lost focus will close
the input panel, just to see that the input that gained
focus will open it again. This will cause the input panel
to "jump", and can also trigger other input panel related
code/signals unnecessary.

Change-Id: Iac0a103e8d2f0f7cdcc04b8ec5b10e07587d1ad6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>

src/plugins/platforms/ios/qiosinputcontext.h

@@ -66,6 +66,7 @@ public:
 private:
     QIOSKeyboardListener *m_keyboardListener;
     UIView *m_focusView;
+    bool m_hasPendingHideRequest;
 };
 
 QT_END_NAMESPACE

src/plugins/platforms/ios/qiosinputcontext.mm

@@ -99,6 +99,7 @@ QIOSInputContext::QIOSInputContext()
     : QPlatformInputContext()
     , m_keyboardListener([[QIOSKeyboardListener alloc] initWithQIOSInputContext:this])
     , m_focusView(0)
+    , m_hasPendingHideRequest(false)
 {
 }
 
@@ -120,12 +121,20 @@ void QIOSInputContext::showInputPanel()
     // responder. Rather than searching for it from the top, we let the active QIOSWindow tell us which view to use.
     // Note that Qt will forward keyevents to whichever QObject that needs it, regardless of which UIView the input
     // actually came from. So in this respect, we're undermining iOS' responder chain.
+    m_hasPendingHideRequest = false;
     [m_focusView becomeFirstResponder];
 }
 
 void QIOSInputContext::hideInputPanel()
 {
+    // Delay hiding the keyboard for cases where the user is transferring focus between
+    // 'line edits'. In that case the 'line edit' that lost focus will close the input
+    // panel, just to see that the new 'line edit' will open it again:
+    m_hasPendingHideRequest = true;
+    dispatch_async(dispatch_get_main_queue(), ^{
+        if (m_hasPendingHideRequest)
             [m_focusView resignFirstResponder];
+    });
 }
 
 bool QIOSInputContext::isInputPanelVisible() const