iOS: stop listening for keyboard visibility after QIOSMenu::dismiss()

We used to stop listening for keyboard visibility when quipickerview
was deallocated. The problem with that approach is that we don't
have a guarantee for when dealloc gets called. So what can happen
is that we get a call from Qt to dismiss the menu. That causes us
to close the keyboard, which will trigger the notification, which
will call dismiss recursively. This will hit our assert checking
if we have a valid picker view.

This patch will unsubscribe to the notification explicitly upon a
call to dismiss, to avoid recursive dismiss calls.

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

src/plugins/platforms/ios/qiosmenu.mm

@@ -201,7 +201,6 @@ static NSString *const kSelectorPrefix = @"_qtMenuItem_";
 
 - (void)closeMenu
 {
-    [self listenForKeyboardWillHideNotification:NO];
     if (!m_visibleMenuItems.isEmpty())
         QIOSMenu::currentMenu()->handleItemSelected(m_visibleMenuItems.at(m_selectedRow));
     else
@@ -210,7 +209,6 @@ static NSString *const kSelectorPrefix = @"_qtMenuItem_";
 
 - (void)cancelMenu
 {
-    [self listenForKeyboardWillHideNotification:NO];
     QIOSMenu::currentMenu()->dismiss();
 }
 
@@ -466,12 +464,14 @@ void QIOSMenu::toggleShowUsingUIPickerView(bool show)
     } else {
         Q_ASSERT(focusObjectWithPickerView);
         focusObjectWithPickerView->removeEventFilter(this);
-        qApp->inputMethod()->update(Qt::ImEnabled | Qt::ImPlatformData);
         focusObjectWithPickerView = 0;
 
         Q_ASSERT(m_pickerView);
+        [m_pickerView listenForKeyboardWillHideNotification:NO];
         [m_pickerView release];
         m_pickerView = 0;
+
+        qApp->inputMethod()->update(Qt::ImEnabled | Qt::ImPlatformData);
     }
 }