Android soft keyboard control method and some problems encountered in development.

Android provides the windowSoftInputMode property to control the interaction between the input method soft keyboard window and the Activity main window, which is divided into the window size adjustment series and the input method soft keyboard display control series.

Window resizing series:

This series of parameters is used to control the adjustment strategy of the Activity main window when the soft keyboard pops up. If the main window is not adjusted, the current input control may be blocked by the soft keyboard.

adjustPan:

The main window of the Activity is not resized to make room for the input method, but the content of the window automatically shakes up and down to ensure that the currently focused control is not blocked by the keyboard, and the user can see what he or she is typing. Compared with the adjustResize mode, it is not very satisfactory because the user must close the input method to interact with the control blocked by the input method.

adjustResize:

The activity's main window will be resized to make room for the input method.

adjustUnspecified:

The current mode does not explicitly specify whether the Activity uses adjustPan or adjustResize. The system automatically selects a mode. If the current Activity's Window has a control that can scroll its own content, such as ScrollView, then adjustResize is selected because it believes that scrolling can make the content in the Window visible even in a small area. This is the default mode for Activity.

adjustNoting:

There is no change in the Activity's Window.

In both modes, the relationship between screen – main window – main window content – ​​soft keyboard is as follows:

The specific effects are as follows:

Without scrolling content, adjustPan:

Without scrolling content, adjustResize:

There is no scrolling content, adjustUnspecified == adjustPan

There is scrolling content (ScrollView), adjustPan

There is scrolling content (ScrollView), adjustResize

There is scrolling content (ScrollView), adjustUnspecified == adjustResize

Input method soft keyboard display control series:

This series of parameters is used to control the display or hiding strategy of the soft keyboard when a thing containing a Window (Activity, Dialog, etc.) is displayed at the forefront of the screen.

stateUnspecified:

The system selects the corresponding mode according to the current specific situation.

stateUnchanged:

The soft keyboard maintains its last state (the state of the soft keyboard when the last Activity or Dialog was at the forefront of the screen) and does not change, regardless of whether the last state was displayed or hidden.

stateHidden:

When the user actively enters the current interface, the soft keyboard is hidden. Leaving the previous interface and returning to the current interface does not count as "active entry". When entering passively, the previous state is maintained.

stateAlwaysHidden:

As long as the user enters this interface, the soft keyboard is hidden, regardless of whether it is active entry (newly launching the interface) or passive entry (leaving the previous interface and returning to the current interface).

stateVisible:

When the user actively enters the current interface, the soft keyboard is displayed. Leaving the previous interface and returning to the current interface does not count as "active entry". When entering passively, the previous state is maintained.

stateAlwaysVisible:

As long as the user enters this interface, the soft keyboard will be displayed, regardless of whether it is active entry (newly launching this interface) or passive entry (leaving the previous interface and returning to the current interface).

A Bug on Some Huawei Phones

I encountered a bug today. On some Huawei phones, except for the first click on the input box, the adjustPan parameter will take effect (the soft keyboard can pop up the input box normally). From the second time onwards, no matter how you click, the adjustPan parameter will be invalid.

The layout model is roughly as follows:

 <RelativeLayout
 xmlns:android= "http://schemas.android.com/apk/res/android"  
 xmlns:tools= "http://schemas.android.com/tools"  
 android:id= "@+id/activity_main"  
 android:layout_width= "match_parent"  
 android:layout_height= "match_parent"  
 tools:context= "cn.hjf.inputtest.MainActivity" > 
  
 <ScrollView
 android:layout_width= "match_parent"  
 android:layout_height= "match_parent" > 
  
 <LinearLayout
 android:layout_width= "match_parent"  
 android:layout_height= "match_parent"  
 android:orientation= "vertical" > 
  
 < View  
 android:layout_width= "match_parent"  
 android:layout_height= "400dp"  
 android:background= "#2b532b" /> 
  
 <EditText
 android:layout_width= "90dp"  
 android:layout_height= "wrap_content"  
 android:layout_gravity= "center_vertical"  
 android:background= "@null"  
 android:gravity= "center"  
 android:inputType= "numberDecimal"  
 android:maxLength= "8"  
 android:minWidth= "60dp"  
 android:padding= "5dp"  
 android:text= "0.00" />

The effect is this:

After a long time of troubleshooting (very hard), I finally found the critical point that triggers the bug, which is the following two sentences:

 android:gravity= "center"  
 android:inputType= "numberDecimal"  

After a long period of verification, we came to a conclusion: On some Huawei models, in this layout model, if the inputType parameter is set in EditText (not none), then when the gravity value is certain, this problem will occur. The general situation is as follows:

Red means invalid, green means valid (can work normally). When these two parameters are not specified, it can work, because the combination of the default values ​​of these two attributes can work, as shown in the blue block in the figure above. (Note: It does not completely match all situations. If there are similar situations, you can match as needed and view the results)

The default values ​​of these two properties can be found in the source code:

attrs.xml

themes.xml

 <item name = "editTextStyle" >@style/Widget.EditText</item>

attrs.xml

 <! -- The type of data being placed in a text field, used to help an  
 input method decide how to let the user enter text. The constants
 here correspond to those defined by  
 {@link android.text.InputType}. Generally you can select  
 a single value, though some can be combined together as  
 Setting this attribute to anything besides indicated.
 <var>none</var> also implies that the text is editable. -->  
 <attr name = "inputType" >
 <! -- There is no content type. The text is not editable. -->  
 <flag name = "none" value= "0x00000000" />

 /**
 * Special content type for   when   no explicit type has been specified.
 * This should be interpreted to mean that the target input connection  
 * is   not rich, it can not process and show things like candidate text nor
 * retrieve the current text, so the input method will need to run in a
 * limited "generate key events" mode, if it supports it. Note that some  
 * input methods may not support it, for example a voice-based input
 * method will likely not be able to generate key events even if this
 * flag is   set .
 */
 public   static final int TYPE_NULL = 0x00000000;

A demand

I encountered a requirement, the general model is: there is an interface with an input box and two buttons, which control the addition and subtraction of numbers in the input box respectively, as shown in the following figure:

[[195692]]

Every time the number in the input box changes, whether it is manually entered or controlled by a button, a refresh will be triggered, and a dialog box will pop up during the refresh.

Then the requirement is that when manually inputting, when the refresh is triggered, the input method is displayed, but after the dialog box is displayed and then disappears, the input method is hidden. When it is controlled by a button, there is no problem, because the input method is hidden during the whole process. So the requirement is that after the dialog box is displayed and then disappears, the input method can maintain the state when the refresh is triggered.

Solution: When setting the current Activity to stateUnchanged, the desired effect is not achieved, because the window where the dialog is located does not have this property set, so the dialog window also needs to be set to stateUnchanged, the method is:

 getWindow().setSoftInputMode()

And then it works.