Noticing some issues with some characters

[hughstephens]

I've been using this for quite a while (and it's awesome, thank you so so much) but I've noticed that some characters won't be typed?

For example, it leaves the &AKA- rather than typing a U+00A0 (no-break space).

Is this something you've noticed? Is there some kind of key map that I can use to make sure all of our users' inputs are compliant? It's quite difficult to identify exactly which characters don't work as it would involve testing every single letter!

Cheers & thanks again for the plugin, a lifesaver.

[sumio]

@hughstephens, thank you for your reporting and using it!

Any Unicode characters (including "\u00A0") should be accepted in my Utf7Ime and leaving of &AKA- may be a bug...

Although I tried to reproduce your report, I couldn't reproduce it in Android 4.4.2/4.3/4.2.2 emulators.
My test code is as follows and both are passed in my environment.

UiObject editText = ...;
String input = "Hello\u00A0World";
editText.setText(Utf7ImeHelper.e(input));
assertEquals(input, editText.getText();

UiObject editText = ...;
String input = "\u00A0";
editText.setText(Utf7ImeHelper.e(input));
assertEquals(input, editText.getText();

Can you show your failing test code and your environment (Android OS version, emulator or device?, etc.)?
I'd like to try to reproduce it based on your information.

Thanks in advance!

[hughstephens]

Hi @sumio, it seems to have happened sporadically on a few devices. We run 4.4.3 on Moto G's 24x7x365 at a really high volume, so it's something that seemed to occur on some rather than others.

Could it be related to the cache? I noticed on a couple of them when I did an uninstall/reinstall of the keyboard apk that the cache had grown to about 1.1GB specifically for the kb...which is pretty damn weird as I'm not sure why it's really cacheing much at at all (?).

As a non-Android dev (web) I'm not sure what other info I can provide other than what I've observed but if there is anything I can help you with let me know and I can check it out and get back to you...

[hughstephens]

(high volume there meaning of text/typing – probably around 50-60,000 words a day, ranging from standard English through to Arabic etc)

[sumio]

(Rewrited due to my misunderstanding)

Hi @hughstephens, thank you for additional information.

As you've guessed, it may be a cache-related problem because Utf7Ime buffers non-ASCII characters until ASCII character appears. If your inputting long text contains only non-ASCII character, about 50,000 words will be stored in a single StringBuilder (which is on-memory!).

If my guessing is right, spliting it into some short texts may avoid your trouble. For example, write:

UiObject editText = ...;
String[] inputArray = {"<unicode text(1) here>", "<unicode text(2) here>", "<unicode text(3) here>"};

StringBuilder inputBuffer = new StringBuilder();
for  (String input : inputArray) {
    inputBuffer.append(Utf7ImeHelper.e(input));
}
editText.setText(inputBuffer.toString()); 

instead:

UiObject editText = ...;
String input = "<unicode text(1) here><unicode text(2) here><unicode text(3) here>";
editText.setText(Utf7ImeHelper.e(input)); 

I'll try reproduce it by inputing long text on Android emulator and find a solution.
Please give me a few days.
Thanks again for your report!

[hughstephens]

Hi @sumio it's actually on either a Nexus 7 tablet or a Moto G phone – so they should have enough memory. I'm not sure what kind of capacity you have – but I'm actually quite happy to engage you as a consultant to review what we're doing and make some improvements – it's mostly just something I would prefer to work out the exact issues and resolve than fuss about anything else. If you're interested, maybe drop me a line at hugh @ dialogueconsulting dot com dot au. Cheers!

[hughstephens]

I should also note that we never have more than 1000 characters run through at a time – although these might be 1000 complex characters (e.g. traditional chinese chars)