Android device - serious keyboard regression in 5.3.0

Android
21

Hi Pete,

Thanks for the info. I was unable to reproduce the problem. Would you be able to provide a tiny app that with minimal code reproduces the issue?

22

Hi Lucasz,

Thanks for asking, and sorry for the delay in replying.

I tried to create a reproducible test case, but got bogged-down trying to create a cut-down case.

So, as timescales for the Wotja 5.5.1 release have been tight, I decided to resolve it pragmatically.

Here is what I did.

  1. No longer use the Juce alert approach for Mobile, e.g.:

juce::AlertWindow *w = new juce::AlertWindow(title, message, juce::AlertWindow::NoIcon);
const juce::String cKeyboardComponentName = “keyboardComponent”;

w->addTextEditor(cKeyboardComponentName, defaultValue, “Enter value”, false);
w->addButton(“OK”, 1, juce::KeyPress(juce::KeyPress::returnKey, 0, 0));
w->addButton(“Cancel”, 0, juce::KeyPress(juce::KeyPress::escapeKey, 0, 0));

I’m convinced this was part of the problem - I’d wager that it was related to having the text field appear in the middle of the screen, and how it interacts with this bit of Juce code:

            public void onGlobalLayout()
            {
                Rect r = new Rect();

                view.getWindowVisibleDisplayFrame(r);

                int diff = view.getHeight() - (r.bottom - r.top);

                // Arbitrary threshold, surely keyboard would take more than 20 pix.
                if (diff < 20)
                    handleKeyboardHidden (view.host);
            };

  1. Replaced the above, with:
    2a. Android: a simple custom Component implementing a “full screen” display, that has a single-line text field near the top, an OK / Cancel button pair, and a little bit of UI chrome to make it look nice; when the user touches the text field, the keyboard behaves as expected.
    2b. iOS: use an UIAlertController with embedded UITextField. This is more attractive than any Juce control I could create :slight_smile: and of course works as the user would expect.

  2. Furthermore, I’ve implemented my single-line and multi-line text fields for both Android and iOS, such that they are read-only on mobile; when the user taps these fields, I have them:
    3a. on Android, show a Component similar to that in 2. above, but with a single/multi-line text field as appropriate (which is not read only, so the Juce keyboard code can fire-up)
    3b on iOS, single-line: use the approach as in 2b; multi-line: show a simple UIViewController with an embedded UITextView (and OK/Cancel buttons); which gives me a huge advantage for the user, of giving the user access to the standard iOS text editor pop-up menu elements.

Hoping this feedback helps!

I think it points to a better approach of working with keyboards on Android and iOS (fixes all my keyboard appearance issues on Android, and gives the user access to standard iOS pop-up options for Copy/Paste etc. on iOS). Might be worth considering for the Juce backlog at some point?

Best wishes,

Pete

23

Hi Pete,

Thank you for your detailed feedback and I am sorry to hear that JUCE implementation had caused you the issues you are describing. I am glad you have sorted out your case! Support for native UIs in JUCE is on our radar and is coming (no ETA I could share but stay tuned!).

Lukasz

24

That is very exciting :slight_smile:

It would be fun to speculate if this might be related to Accessibility support. I guess we’ll just have to wait and see!

I’ve also often wondered if you’re going to move at some point to making Components proxies for native UI elements at some point (i.e. mapping directly to UIView and View - taking advantage of compositing through the underlying platform UI pipeline).

Anyhow - great stuff, and good luck!

Pete