Develop Reference

Prevent Keyboard from hiding the submit button of alert Dialog

I have a custom Spinner class and which uses an alert Dialog to display its contents and it has "Submit" and "Cancel" buttons. The alert dialog has one edit text and others are just read-only labels. On click of edit text the virtual keyboard appears and it moves the layout moves bit up but the buttons remain hidden. I want the buttons to be visible also.
Things I have tried so far:-
Manifest :-
android:windowSoftInputMode="stateVisible|adjustResize"
android:windowSoftInputMode="adjustPan"
In Activity Class:-
this.getWindow().setSoftInputMode(
WindowManager.LayoutParams.SOFT_INPUT_ADJUST_PAN);
It is just moving screen enough not to hide the edit text where as my button are still remain invisible.

You can't. The height of the keyboard is decided by the keyboard- it can't be made smaller. The rules for the keyboard are that if it the cursor would be covered, unless all movement is shut off it will scroll everything the minimum such that the cursor is on screen. There is no way to tell the OS to scroll it more than that. There is resize, but I'm not sure that will work for an alert dialog- I think those still go full screen. The keyboard API just isn't made for your usecase.

Start Activity from Soft Keyboard WITHOUT hiding the soft keyboard

I know this should not be a big challenge but it really drives me insane.
I am developing a simple soft keyboard input method and basically I have added a button to my softkeyboard, by pressing which, a dialog should pop up to prompt user to do some choices.
By far everything is ok about creating and opening the dialog. Since normally a dialog is created and displayed from outside an activity, so a flick solution could be to create a transparent activity which embedded the dialog in it. By doing so, I could easily start a dialog when user click the button on my softkeyboard.
But one tricky problem is: every time user click the button and the dialog (actually a dialog in a transparent activity) displays, it will always make my softkeyboard hide. I just need to start the dialog without any changes to the status of my softkeyboard -- I want my softkeyboard keeps showing when the dialog starts.
Here is a snapshot of Google Keyboard, it has the similar button which display a dialog and the dialog did not hide the keyboard, this is exactly what I want. So please anyone suggest me how to achieve this. Thanks so much.

THey aren't launching an Activity. They're launching a dialog. Which is tricky from an input method because its a service (you have to specify the dialog's window token to make it show) but doable.

How to view custom softkeyboard while tap on EditText in android?

I want to show softkeyboard after tapping on EditText in my custom Softkeyboard.
I have made one custom keyboard in which I've added one key.
This key will navigate you to a Conversion View which contains an EditText.
So after tapping on that EditText I want to open my own custom softkeyboard.
Please reply me as soon as possible.

You have two options: create a soft keyboard using the InputMethodService--that is, create a true soft keyboard that will be listed under the keyboard listing in the device's settings that the user can turn on and use at any time. That can be a lot of work.
You're other option is to mock the soft keyboard by creating a custom view, of which you handle input and toggle the visibility of explicitly in your app; blocking the native soft keyboard from showing (which you can do per activity via your manifest or in code).

Android: Show dialog in front of soft keyboard

I have an EditText and an ImageButton beside it. When I click the EditText the soft keyboard shows up. Fine. When I click the ImageButton a custom dialog shows up and the soft keyboard gets automatically hidden. I want the keyboard to stay open though. How can I achieve this?

Found the solution. I used the common Dialog class to display my dialog. Using AlertDialog instead did the trick.

AlertDialoug focusing on EditText when dismissed.. causing Keyboard to appear.. what to do?

I am using an AlertDialog to pop up and ask the user for some information, when the user clicks on a button.
The dialog is working fine, and I get the user info it dismisses itself.
However when the app returns focus to my primary view.. it is setting the focus to an EditText widget which causes the keyboard to appear for that View.
I don't want the Keyboard to appear unless the user explicitely puts focus on that field, so how do I change/override the default behavior, so that it doesn't autofocus on this field after the AlertDialog is dismissed.
It doesn't behave this way when the view initially inflates, the field is focused (highlighted), but the keyboard is not visible, only after the user taps on the field does the keyboard come up when the app launches. This behavior after dialog dismiss is completely different.. any ideas?
(No the EditText is not anywhere near the buttons of the alert dialog, so its not as though a second tap or something is happening accidentally or the click is being passed up the stack.)

Try doing this after the dialog is dismissed:
getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_HIDDEN);

You can ask the InputMethodManager to resign the keyboard when you dismiss the dialog:
EditText mValue; //The input view in your Dialog
//Close the keyboard
InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
imm.hideSoftInputFromWindow(mValue.getWindowToken(), 0);
Hope that Helps!

The issue was as stated in comments above, I was not dismissing the keyboard from the ALERTDIALOG, I was working on the false assumption that when the dialog was dismissed that the keyboard would be as well. This assumption was wrong.
The keyboard for the alert dialog was not dismissed, the view returned to the parent view and because the edit text in the parent view got focus the keyboard updated itself to appear properly for this view.
The attempts to dismiss keyboard in the dialog dismiss listener did not remove the keyboard because they were trying to dismiss the keyboard for fields in the parent window and at the time of their execution it was still tied to the field in the alertview.
Add the dismisskeyboard calls to the onclick events that dismissed the dialout for the edittext fields in the alertDialog resolve the problem.