removed check in shouldbeoff

[alexknop]

Problem:
On my Contacts app, I can type at the top

and when I select a contact, onFinishInputView() is called but not onFinishInput(), so the keyboard is still active,

but if I go back, the boolean isActive was already set to false, so number presses no longer activate the keyboard due to the check in shouldBeOff().

Solution:
Since it seems you want onFinishTyping() to be called in both onFinishInput() and onFinishInputView() in order to cover all bases, such as an app calling either one or both, I removed the check from shouldBeOff() so for scenarios where an app runs just onFinishInputView() and the user tries to type something, it works. shouldBeOff() is still looking at other factors.
With Fix:

Though in my phone's instance this could also be fixed by only calling onFinishTyping() in onFinishInput() and not onFinishInputView() so that isActive stays true. I wonder if this ever came up in your app testing and what apps I could try to work with these weird scenarios where it's necessary to call onFinishTyping() in onFinishInputView(). I have a few phones myself and haven't found a scenario where it's not calling onFinishInput() where it makes sense to.

P.S. We are also calling showWindow in forceShowWindowIfHidden() which may already take care of some of the logic that was once there, such as calling onRestart(), onEvaluateInputViewShown(), etc. Honestly, does implementing that on number presses now remove the need for isActive?

[sspanak]

First, let me answer your question, why does isActive exist. If you don't care, just skip this paragraph. 🙂 So, If you go back in git history to the original version by Clam-, before v6.0, you would see there used to be a variable called mEditing. It had three values: NON_EDIT, EDITING and EDITING_NOSHOW. When I took over, I quickly realised I need one more state for the dialer apps. But with time I started to feel this is a bad idea and I slowly started migrating to the InputModes, and managed to "compress" mEditing into a simple on/off flag, that is now isActive.

The ultimate goal is to remove the state variable completely and just use some InputMode. I think, with the current code, it should be fairly easy to do so and when isActive is now being set to false, instead set mInputMode to ModePassthrough. Unfortunately, there were (and there are) many other issues to take care of, so I haven't had time to check if this would break anything, but I think the time is coming soon.

But never mind the above, it has nothing to do with your problem.

The InputMethodService is always on, even if you don't see it, even it there is no focused text/number field and even if there is no opened app at the moment. This is why you can use the DPAD to select and start an application, or you can start typing numbers on the launcher screen and call someone. This is all normal.

I believe the problem in your case is onStart() or onRestart() are not called, hence TT9 is not getting switched to foreground mode. You should know that applications are not consistent in calling onStartInput() and onStartInputView() either. Please, check these two functions in KeyPadHandler and try to debug them. One of them or both must be called for TT9 to activate.

[alexknop]

onFinishInputView() is what is called when I open a specific contact. When I navigate back, nothing is called (such as onStart or onStartInputView) so that is why when I press a button nothing happens. It recognizes the keypress but isActive is set to false so when it runs the shouldBeOff function it checks for isActive.
So what has happened is the view was finished (makes sense to hide it on the specific contact's page), but not the input itself.
When I press numbers on the specific contact's page, the app doesn't detect the keydown or keyup events. They must be disabled by the author or something.