The Windowsoftinputmode property in Android is detailed

How to implement the soft keyboard does not automatically eject, using the method is to set the Android:windowsoftinputmode property. So what exactly does this attribute do, and what does he do? Today, this article explores the role of the Android:windowsoftinputmode attribute.

First of all, from the name of this property, we can intuitively see its role, this property is to set the window soft keyboard interactive mode.

The Android:windowsoftinputmode attribute has a total of 9 values, namely:

Stateunspecified,stateunchanged,statehidden,statealwayshidden,statevisible,statealwaysvisible, Adjustunspecified,adjustresize,adjustpan.

When we set properties, we can choose one of these 9 values, or we can use the state...| Adjust "in the form of settings. So how do these values affect the interaction between the soft keyboard and the window? Below, we will test each of these 9 values, in the end how to affect the display of the soft keyboard.

1.stateUnspecified

When we do not set the Android:windowsoftinputmode property, the software defaults to this interaction, the system will take the corresponding soft keyboard display mode according to the interface, for example, when there is only text and buttons on the interface, The soft keyboard does not eject automatically because there is no need to enter it. Then, when the interface appears on the focus of the input box, the soft keyboard will not automatically pop it? That's not necessarily true! For example, in the following interface layout, the soft keyboard does not pop up automatically.

That is, by default, in this interface case, the system is not sure whether the user needs a soft keyboard, and therefore does not automatically eject. But why is that not necessarily? This is because, if we are outside of this layout, wrap the previous

ScrollView, the soft keyboard will automatically bounce out!

Below, in this layout file, the soft keyboard will automatically pop up

Copy CodeThe code is as follows:
<linearlayout xmlns:android= "Http://schemas.android.com/apk/res/android"
Xmlns:tools= "Http://schemas.android.com/tools"
Android:layout_width= "Match_parent"
android:layout_height= "Match_parent"
android:orientation= "Vertical" >

<scrollview
Android:layout_width= "Match_parent"
android:layout_height= "Match_parent" >

<linearlayout
Android:layout_width= "Match_parent"
android:layout_height= "Wrap_content"
android:orientation= "Vertical" >

<button
Android:layout_width= "Match_parent"
android:layout_height= "Wrap_content"
android:onclick= "Toother"
android:text= "Jump"/>

<edittext
Android:layout_width= "Match_parent"
android:layout_height= "Wrap_content"/>
</LinearLayout>
</ScrollView>

</linearlayout>

This is indeed a very strange way of judging. Therefore, we can conclude that when the property is set to Stateunspecified, the system does not eject the soft keyboard by default, but when the interface of the input box with the focus has a scrolling requirement, it will automatically eject the soft keyboard. As for why you should emphasize the input box to get the focus, this is because, if the input box is not the focus, the soft keyboard will not automatically pop up, so that the interface does not automatically eject the soft keyboard one of the solutions, is in the XML file, set a non-input box control to get focus, thereby preventing the keyboard pop-up.

2.stateUnchanged

The meaning of the Chinese means that the state does not change, how should we understand this sentence? In fact, it is very well understood, that is, the current interface of the soft keyboard state, depending on the previous interface of the soft keyboard state. For example, if the current interface keyboard is hidden, then the interface after the jump, the soft keyboard is also hidden, if the current interface is displayed, then the interface after the jump, soft keyboard is also the display state.

3.stateHidden

As the name implies, if we set this property, then the keyboard state must be hidden, regardless of the previous interface what state, regardless of the current interface has no input requirements, anyway is not displayed. Therefore, we can set this property to control the soft keyboard does not automatically eject.

4.stateAlwaysHidden

This property can also make the soft keyboard hidden, but I do not know and Statehidden properties of the difference, I would like to go to StackOverflow on the question, but, great Wall, ah hehe ... Wish the early victory of the party president

5.stateVisible

Set to this property, you can summon the soft keyboard, even if there is no input box on the interface can be forced to summon out.

6.stateAlwaysVisible

This property can also summon the keyboard, but it is slightly different from the statevisible attribute. For example, when we set the Statevisible property, if the current interface keyboard is displayed, when we click the button to jump to the next interface, the soft keyboard will be hidden because the input box loses focus, when we return to the current interface, the keyboard this time is hidden. But if we set the statealwaysvisible, we jump to the next interface, the soft keyboard is still hidden, but when we come back again, the soft keyboard will be displayed. Therefore, this always explains the difference, regardless of the situation to reach the current interface (normal jump or the previous interface is returned by the user), the soft keyboard is displayed state.

Speaking of which, I think of the above Statehidden and Statealwayshidden, I guess the difference is the same, that is, Statealwayshidden is hidden anyway, but if you jump to the next interface, the soft keyboard is called out , then when the next interface is returned by the user, the keyboard should not be hidden, but I have not found a way to jump to the next interface, but also let the current interface soft keyboard does not disappear, so temporarily can not be verified.

7.adjustUnspecified

Starting with this property, instead of setting the display and hiding mode of the soft keyboard, you set the display relationship between the soft keyboard and the software's display. This option is also the default setting mode when you are not setting this value with us. In this case, the system chooses different modes depending on the interface. If there are controls in the interface that can be scrolled, such as Scrowview, the system will reduce the size of the interface that can be scrolled, ensuring that even if the soft keyboard is displayed, all the content can be seen. If there are no scrolling controls in the layout, then the soft keyboard may cover some of the content, and we can see the difference from the figure below.

Without scrolling controls, the layout underneath the soft keyboard is obscured, and if you want to modify it, you can only hide the soft keyboard and select. Also, focus on the layout above, when we select the lower input box, the above title bar and layout is on the top of the soft keyboard. Remember this feature because there is a property behind it that has a different effect.

There are sliding controls in the layout, and the system will automatically reduce the size of the entire interface, so we can display all the input boxes in the small area above the soft keyboard.

This is the difference between the two display modes.

8.adjustResize

This property indicates that the activity's main window is always resized to ensure that the soft keyboard displays space.

Let's look at the display effect first.

Note that the above title bar and button, set to the Adjustresize property, for the layout without sliding control, although still cannot select all the input boxes, but the display of the window has changed, the default properties, the entire layout is top up, But with the Adjustresize property set, the location of the layout has not changed, which is the biggest difference.

For layouts with sliding controls, the display is the same as the default.

9.adjustPan

If set to this property, then the activity's screen size does not adjust to ensure the space of the soft keyboard, but takes another strategy, the system will be moved through the layout to ensure that the user to enter the input box must be in the user's unemployment range, so that users can see their input content. For layouts without scrolling controls, this is actually the default setting, and if we choose a lower position, the above title bar and some controls will be topped up. But for layouts with scrolling controls, it's not quite the same, so let's look at the following.

First of all, this is when the soft keyboard does not pop up, there is a scrolling control of the display range, the bottom of the display is 9.

When we click on the 5 input box, we will find the following phenomenon.

The top can only be displayed to the button, the title bar is no longer visible.

And the bottom can only slide to 8, the content below is not able to slide.

Therefore, we can understand the function of this attribute.

Through the above experiments, we can conclude that if we do not set the "Adjust ..." property, for layouts that do not have scrolling controls, the Adjustpan method is used, and for layouts with scrolling controls, the Adjustresize method is used.

With this knowledge, we can set up different ways to do what we want. Also, we have a clear understanding of how to make the interface load without displaying the soft keyboard.

Source: http://www.jb51.net/article/56043.htm

From for notes (Wiz)

The Windowsoftinputmode property in Android is detailed