Ensure the IME is created before the HUD is shown. about tecla-framework HOT 15 CLOSED

@jorgeSilva @ericwan78

Creating transparent overlay and edit boxes is a patch to start LatinIME. I was hoping that we could avoid this completely. The root of the issue is that we need an instance of LatinIME in order to simulate back key and home key.

I found that UiDevice class, which is included in the uiautomator.jar library provided by android. It allows us to simulate home,back,search etc keys.
http://developer.android.com/tools/help/uiautomator/UiDevice.html
It will also provide users flexibility to use a different IME while using TeclaHUD.

I will give this thing a try.

from tecla-framework.

@sagarchandarana123 remember that we also need to implement scanning on the IME. So even if we can emulate keys some other way, we would still need to create our own IME from scratch, which seems unnecessary.

Note that the Latin or any other IME can be made to extend our framework IMEService. This should also enable us to grab an instance of it. However, as @ericwan78 pointed out, the instance will have to be an ancestor and this may get quite awkward. I think I like @ericwan78's suggestion to turn the Latin IME into a library and turn the framework into the main app. I will open an experimental issue for that.

from tecla-framework.

Any progress on this?
On 4 Apr 2013 08:32, "Sagar Chandarana" [email protected] wrote:

@jorgeSilva https://github.com/jorgesilva @ericwan78https://github.com/ericwan78

Creating transparent overlay and edit boxes is a patch to start LatinIME.
I was hoping that we could avoid this completely. The root of the issue is
that we need an instance of LatinIME in order to simulate back key and home
key.

I found that UiDevice class, which is included in the uiautomator.jar
library provided by android. It allows us to simulate home,back,search etc
keys.
http://developer.android.com/tools/help/uiautomator/UiDevice.html
It will also provide users flexibility to use a different IME while using
TeclaHUD.

I will give this thing a try.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/76#issuecomment-15894384
.

from tecla-framework.

@jorgeSilva I will look into #77 and your branch to see if it's possible and feasible to turn IME into library. Meanwhile, I will use the patch suggested by you so that the issue is atleast resolved.

from tecla-framework.

Apparently we have an Android built-in class InputMethodManager which might be allowing us to do exactly what we want. It allows a force-show of current input method and much more. http://developer.android.com/reference/android/view/inputmethod/InputMethodManager.html

from tecla-framework.

@sagarchandarana123 I tried using the manager a while ago and couldn't get it to behave properly. Maybe you will have better luck with Jelly Bean

from tecla-framework.

Is this issue still valid? Does the architectural changes done in #108 resolve this, too?

from tecla-framework.

Yes, this issue is still valid. The changes in #108 should make this a bit easier to solve since the always running TeclaApp class can keep instances of the IME and the A11yService, thus allowing us to keep track of what is running and what is not.

You can also make use of the isIMERunning and related methods in the new Persistence class

from tecla-framework.

The IME is created as soon as it is set to be the default IME. It doesn't wait for an editable text box.
Checked using a logcat message.
My branch:
https://github.com/sagarchandarana123/tecla-framework/commit/8b43eb76ec1587ec22867cec2a5b846d00af1736

from tecla-framework.

Now we have to ensure that teclaIME (Android AOSP currently) is set too be the default IME, i.e. show a warning the same way it did show in old TeclaAccess.

from tecla-framework.

@sagarchandarana123 how many times did you test? is it consistent? this was definitely not the case in earlier versions of Android. Also, having the IME be created does not mean it is ready to receive calls. The keyboard may need to be shown before making calls to the IME to avoid null pointer exceptions... not sure about any of this though.

from tecla-framework.

Added logs for IME's startInputView and finishInputView, too.
Code: https://github.com/sagarchandarana123/tecla-framework/commit/29b21f846d1f97434aef97b778c7bceaed6a98be

I tested again, with two different approaches:

1. First approach:
   Log cat here (important lines are highlighted):
   https://docs.google.com/document/d/1--XRVLz_U7HXwcWu-6QtGGlJzBJoS1bUlzdMq76vKKE/edit?usp=sharing
   -> Tecla Accessibility Service enabled, but the keyboard is not set to be default at first. I.E ime is inactive.

• The back key on HUD doesn't work.

-> Then activated the IME as default, 'IME created' message is logged just after that, without any user activity. but 'InputView started' message is not logged.

• The back key works.

-> Then went to a text input box, (Using the 'Home' and 'Back' keys of HUD itself) and 'InputView started' message is logged.

2. Second approach:
   Log cat here:
   https://docs.google.com/document/d/1cCFJN1XJXW0GpgS9bQBL4ycY2fFtlM-skRve6QRcKEY/edit?usp=sharing
   -> Tecla-AS and Keyboard both inactive at first.
   -> Then activated the IME as default, 'IME created' message is logged just after it, without any user activity. but 'InputView started' message is not logged.

• It means the keyboard is created by Android it self w/o any interference by Tecla-AS.

from tecla-framework.

@jorgeSilva I know this wasn't happening in older Androids. I am searching if Google has officially announced or other developers are experiencing this change.

from tecla-framework.

Compiling and testing another open source keyboard, it seems universal that the IME is created as soon it's set to be the default one. Logcat posted above suggests that only creation is enough to make IME 'callable' and back-home keys work fine. This issue now depends on #127 and can be closed.

from tecla-framework.

Agreed

from tecla-framework.