Show soft keyboard automatically when EditText receives focus

I’ve been unpleasantly surprised at how difficult it is to find info on showing or hiding the Android soft keyboard, so I’m putting a few code snippets out here for posterity.

Problem

I have a DialogFragment with an EditText. When the dialog is shown, I want to immediately focus the EditText and show the keyboard.

Solution 1 (recommended)

Set the dialog Window’s soft input method.

public class EditNameDialog extends DialogFragment {

	private EditText editText;

	public EditNameDialog() {
		// Empty constructor required for DialogFragment
	}

	@Override
	public View onCreateView(LayoutInflater inflater, ViewGroup container,
			Bundle savedInstanceState) {
		View view = inflater.inflate(R.layout.fragment_edit_name, container);
		editText = (EditText) view.findViewById(R.id.txt_yourName);

		// Request focus and show soft keyboard automatically
		editText.requestFocus();
		getDialog().getWindow().setSoftInputMode(LayoutParams.SOFT_INPUT_STATE_VISIBLE);

		return view;
	}
}

As an alternative to editText.requestFocus(), you can use the <requestFocus /> tag in the fragment’s XML layout:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/edit_name"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_gravity="center"
    android:orientation="vertical" >

    <TextView
        android:id="@+id/lbl_yourName"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="What is your name?" />

    <EditText
        android:id="@+id/txt_yourName"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:ems="10" >
		<requestFocus />
    </EditText>

</LinearLayout>

Setting the Window’s soft input method is definitely the easiest way to show the keyboard. However, in some circumstances, you may need to “force” it open or shut by invoking the InputMethodManager directly.

Solution 2

Invoke the InputMethodManager service.

This approach is more complicated because the input method manager ignores keyboard requests unless the EditText and the Window it’s in both have focus. So upon entering an Activity / Dialog, you need to wait until focus has settled down before you request the keyboard. You can do this by calling the InputMethodManager service in an OnFocusChangeListener, but Views can get focus before the Window itself does, so you have to wait for Window focus. There is no way that I can find to add an OnFocusChangeListener on the Window object itself, but listening for View focus and posting a Runnable seems to work:

...
		editText.setOnFocusChangeListener(new OnFocusChangeListener() {
			@Override
			public void onFocusChange(View v, boolean hasFocus) {
				editText.post(new Runnable() {
					@Override
					public void run() {
						InputMethodManager imm = (InputMethodManager) getActivity().getSystemService(Context.INPUT_METHOD_SERVICE);
						imm.showSoftInput(editText, InputMethodManager.SHOW_IMPLICIT);
					}
				});
			}
		});
		editText.requestFocus();
...

This solution is not recommended because it may be buggy, but illustrates using post() to wait for the UI to settle, which may be useful in other circumstances. Note that this solution won’t work with the requestFocus tag in the layout XML because in that case, the EditText receives focus before the OnFocusChangeListener has been registered. Therefore, in the example above, we programmatically request focus after adding the listener.

Bad solutions

You can set the attribute android:windowSoftInputMode=”stateVisible” for your activity in AndroidManifest.xml. However, in the case of a DialogFragment, that will show the keyboard in the Activity’s window, which is behind the Window associated with the Dialog in the DialogFragment.

In order to get around possible Window / View focus bugs, you can use postDelayed() with a number of milliseconds to post a Runnable; however, hard-coded delays are never recommended because they may introduce unpredictable behavior under different conditions / different devices.

Summary

Ordinarily, the soft keyboard default behavior should be sufficient; however, when you programmatically focus on an EditText, you can set the Window’s soft input method to show the keyboard.