I have seen and used both of the methods to hide the on screen keyboard while coding Android:



InputMethodManager imm = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE);
imm.hideSoftInputFromWindow(myEditText.getWindowToken(), 0);

I have read through the documentation for both and I am still unclear as to how each is different, the same, which is a better method or practice to use, and which one should be used in which situations.

Here is an excerpt from the .setSoftInputMode documentation:

Specify an explicit soft input mode to use for the window, as per WindowManager.LayoutParams.softInputMode. Providing anything besides "unspecified" here will override the input mode the window would normally retrieve from its theme.

And here is an excerpt from the InputMethodManager documentation that seems to say nearly the same thing:

You can also control the preferred soft input state (open, closed, etc) for your window using the same windowSoftInputMode attribute.

More finer-grained control is available through the APIs here to directly interact with the IMF and its IME -- either showing or hiding the input area, letting the user pick an input method, etc.

So what is the difference in these two options to hide the Android soft keyboard, and does one have a benefit over the other? Is one more efficient? What are specific uses for each?

  • 3
    I've purged all the comments. There's an active Meta discussion on this question, if you would like to discuss its topicallity please do it there, not here. Thanks. – yannis May 10 '13 at 21:50

I think is very clear in InputMethodManager documentation when it says:

  • The input method manager as expressed by this class is the central point of the system that manages interaction between all other parts. It is expressed as the client-side API here which exists in each application context and communicates with a global system service that manages the interaction across all processes.
  • An input method (IME) implements a particular interaction model allowing the user to generate text. The system binds to the current input method that is use, causing it to be created and run, and tells it when to hide and show its UI. Only one IME is running at a time.

What I mean is that the InputMethodManager is "bigger" and has a lot of more responsability than setSoftInputMode. The first one is a

Central system API to the overall input method framework (IMF) architecture, which arbitrates interaction between applications and the current input method.

and in the other hand, the second is just a setter method.

| improve this answer | |

setSoftInputMode instructs the framework as to whether the soft input window should be shown or hidden when your activity is focused. The framework implements this behavior by calling on the methods of InputMethodManager. As alluded to in the documentation you quoted, you can exercise finer-grained control by disabling the automatic behavior (SOFT_INPUT_STATE_UNCHANGED) and then implementing the precise behavior you want with InputMethodManager.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.