iOS: Sometimes Keyboard pushes up the whole qml page

Question

I am developing a cross-platform QML QtQuick application. One window is typical chat with header, message area and TextEdit input below. On the iOS (both in simulator and a real device) I faced the problem with the virtual keyboard that "moves" the text edit as well as the whole window upward and does not allow to see the header.

Here is screenshot with the application window: https://drive.google.com/file/d/0B6ZI4g3F2MLOSXB2RjBDbGNEWEk

Same issue has been registered in Qt bug tracker already. But there is no solution. Moreover, similar problem has been reported on the forum, with no answer.

Any ideas on solution or workaround?

Answer 1

I've implemented a work around in the past but it is indeed problematic.

Keyboard avoidance is a pain and Qt's one-size-fits approach to scroll the entire screen is not ideal (especially when it's buggy and a pain to disable), causing navigation bars to move off the screen, etc.

Basically, my work around was to:

• add a MouseArea as a child of the TextField, this stops the focus being set and the default scrolling behaviour to kick in
• in the onClick handler for that MouseArea, move the field so that it is not under the area where the keyboard will appear. This can be done using states for example and behaviour animations
• when the animation stops, explicitly set the focus to the text field which will cause the keyboard to come up (but the screen won't scroll since you've moved the focus element out of the way)

Getting the things to animate nicely can be a pain. Also, you can to some extent hard code the size of the keyboard but need to resort to ObjC to get the actual keyboard height (and expose it to QML via some property).

Flip side, i.e. keyboard dismissal, can also be a pain. Need to handle text field loosing focus, user tapping on white space, user tapping the dismiss key (on iPads), etc. Checkout Qt.inputmethod

In Qt's defence, keyboard avoidance is hard to do, requiring knowledge of the app layout for best results. Which is why UIKit actually doesn't handle it at all (except in cases where it can know what to scroll and by how much, such as tables).