ExtractEditText, InputMethodService, InputConnection, etc.

[bnovc]

I want to do a few, probably unusual, things to TextView, but the
extracted text view keeps getting in the way.

Here are a couple things I'm curious how I'm "supposed" to do:

- I am creating a PopupWindow in TextView. When I create the view to
go inside of it, I pass the Context and it creates fine and works well
out of extracted mode. In extracted mode, when I create my view, it
doesn't get assigned a window token. This causes it to crash when I
display my PopupWindow. I think this is a bug. Is it? I'm working
around it right now by doing this awful hack:

public IBinder getWindowToken() {
return mTextView.getWindowToken();
}

inside of my view, where mTextView is obviously a pointer to the
TextView it was created in.

- I want to cause the back button to close my PopupWindow. Since
InputMethodService is asynchronous wrt to TextView (I believe), I
think I have to put a call in onKeyDown in InputMethodService to send
a query to InputConnection to TextView which sends back whether the
PopupWindow is already visible. Is this some better way to do this or
am I, hopefully, misunderstanding the relationship between these
things?

- When I create my PopupWindow in the extracted view, it creates one
for the normal TextView and one for the ExtractEditText. Obviously I
only want the visible one, but ExtractEditText decided to overwrite
isFocused() with a hacky always true. To fix this right now I'm doing
another awful hack:

InputMethodManager imm = InputMethodManager.peekInstance();
if (!imm.isFullscreenMode() || this instanceof
ExtractEditText) {
// pop up the window
}

I would really prefer not to have a reference to a child class in
TextView. I'm also not clear why some methods in TextView appear to
get called twice whereas others do not. If I put my logic to pop up my
window in ArrowKeyMovementMethod's onTouch, then it will only be
called for the appropriate View.

- Semi-unrelated to these other questions, but I also want to do
something like InputMethodService where it shrinks the visible area
and displays the keyboard. Is there a way for me to do this from
TextView? It seems like it is using onComputeInsets() to achieve this,
but I haven't followed it down all the way, yet.

Thanks for any input!

[Dianne Hackborn]

Are you writing an input method or an app?

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[bnovc]

I'm not writing either. I'm modifying TextView.java (and if necessary
to communicate, I suppose IC/IMS).

Thanks for any suggestions, Dianne.

> hack...@android.com

[bnovc]

I guess I should have specified that I am using a custom input method
for an on-screen keyboard, but the changes that I am working on have
all been in TextView.java so far.

Are there any diagrams available for the interactions between all of
the Input classes / which process they're run in / etc.?

Thanks

[Dianne Hackborn]

I don't know if there is a diagram in the docs, but there are three processes involved:

- The application.
- The input method manager service (in the system process).
- The input method.

The application takes with the manager through the InputMethodManager class, and you will find a callback aidl interface that the input method manager service uses to send information back to the app.

The input method manager service talks with the input method through the various interfaces in InputMethodService.  The input method talks back with the manager through the InputMethodManager class.

The input method talks with the application through InputConnection.  Internally the application talks back with the input method through IInputMethodSession, though this is hidden behind InputMethodManager in the public API.

The input method manager service arbitrates all of this, setting up the connections between the apps and IME.  For example, for each application that wants to use an input method, it asks the IME to create a new IInputMethodSession for that app, and hands the resulting instance to the app.  It tells the IME which IInputMethodSession is currently active, so only the in-focus app can interact with the IME.

hac...@android.com

[bnovc]

So, if I want to send something from a TextView to an ExtractEditText,
it goes:

TextView -> InputMethodManager -> IInputMethodSession ->
IInputMethodSessionWrapper -> InputMethodSession -> .aidl ->
InputMethodService -> ExtractEditText

is that right?

I copied the flow of updateCursor() from onDraw() for my own use and
that seems to work. I am sending out from my TextView that I want to
handle the back button, so it gest back to InputMethodService which
can ignore the button on press. I guess this is the most direct way?
If so, that answers my 2nd question from my original post.

If I want to send something from ExtractEditText -> TextView, how
would that go?

On my first and third question from my original post, is the
WindowToken business a bug and is there a better way for me to
determine in my TextView when the ExtractEditText is available, so I
don't create duplicate PopupWindows?

Thanks