The ultimate solution for Android soft keyboard to block the input box

preface

After a long time of development, we will inevitably encounter various pits.

On the way to Android development, the pit of "soft keyboard blocking the input box" can be described as a huge pit for a long time - come on, let's take our time.

Beginner level chapter

The most basic situation is as shown in the figure: there is an EditText at the bottom of the page. If no processing is done, the EditText may be blocked when the soft keyboard pops up.

In fact, the handling of this situation is very simple. You only need to set the value adjustpan or adjustresize of Android: windowsoftinputmode in the androidmanifest file, such as:

Generally speaking, they can solve problems. Of course, the effects of adjustpan and adjustresize are slightly different.

Adjustpan is to move the whole interface upward to expose the input box without changing the layout of the interface;

Adjustresize recalculates the size of the interface after the pop-up of the soft keyboard, which is equivalent to using fewer interface areas to display content, and the input box is generally included.

↑ ↑ ↑ OK, this is just an introduction. Basically all Android engineers on earth can handle it.

Don't worry, look down~

Try WebView? Here comes the pit

In the introduction above, the soft keyboard is triggered and popped up by the native EditText. When H5 and hybrid have almost become the standard configuration of app, we often encounter the situation that the soft keyboard is triggered and popped by the web page elements in WebView.

Situation description

At this point, the situation becomes complicated:

First, when the page is in non full screen mode, setting adjustpan to the activity will fail.

Secondly, when the page is in full screen mode, both adjustpan and adjustresize will fail.

-- explain that the full screen mode here means that the page is full screen, including application or activity using fullscreen theme, using status color coloring, immersive status bar, immersive mode, etc. - in short, this problem will occur as long as the app itself takes over the control of the status bar.

The following table can briefly list the specific situations.

Why is it a pit? " issue 5497”

The situation in the above table is not what Google expects. The ideal situation is that they all work normally - so this is actually a bug of the Android system itself.

Why did the article say at the beginning that it was a pit?

Because this bug is from Android 1 The X era (2009) was reported, and up to today's Android 7 0 (2016) has not been repaired yet... / ㄒo ㄒ / it can be said that this is not only a pit, but also an officially dug pit~

"Issue 5497", details portal ☞ issue 5497 - Android - WebView adjustresize windowsoftinputmode breaks when activity is fullscreen - Android open source project - issue tracker - Google project hosting

Of course, no matter who dug the pit, it is ultimately up to the developer to solve it.

After encountering a pit, there are two ways to get there: hiding or filling.

Pit hiding posture

As shown above, the condition of pit is that the activity with WebView uses full screen mode or adjustpan mode.

Then the posture of hiding in the pit is very simple --

If there is a WebView in the activity, do not use full screen mode, and set its windowsoftinputmode value to adjustresize

Well, isn't it simple?

But sometimes, we need to have both full screen mode and WebView. At this time, we can't hide the pit. We need a new pit filling posture. Fortunately, the wisdom of developers is infinite. After all these years, some people have found some solutions.

AndroidBug5497Workaround

Personally, I think the best solution is this: androidbug5497workaround, which only needs a magical androidbug5497workaround class.

You can see from the name that it is specially used to deal with the "5497" problem, and the steps are super simple:

Copy the androidbug5497workaround class to the project

In the oncreate method of the activity that needs to fill the pit, add a sentence androidbug5497workaround Assistadctivity (this) is sufficient.

After testing, it is basically available on all Android versions, and the effect is basically equivalent to the setting of adjustresize.

Look at a comparison chart:

From left to right, a full screen activity page using WebView from our factory app is: the style without soft keyboard, the effect of soft keyboard blocking the input box, and the final effect after using Android bug5497workaround.

What is its principle?

This cool androidbug5497workaround class is actually not very complex. There are only dozens of lines of code. Post it here first:

The code basically does the following things:

1. Find the root view of the activity

Take a look at the code of the entry:

In the first line, Android R.id. The view referred to in content is the root view of the area that developers can control on all Android activity interfaces.

If the activity is in full screen mode, Android R.id. Content is the content that occupies all screen areas.

If the activity is in normal non full screen mode, Android R.id. Content is to fill all areas except the status bar.

In other cases, for example, the activity is a pop-up window, or the split screen style after 7.0, Android R.id. Content is also the range of pop-up window or half of the screen where the split screen is located - these cases are rare, so we won't consider them for the time being.

The setcontentview (view) / setcontent (int layeres) we often use is actually to put our specified view or layeres on Android R.id. Content becomes its child view.

So, then, the second line, content The mchildofcontent obtained by getchildat (0) is actually used to obtain the view we put in with setcontentview.

2. Set a listener to listen for changes in the view tree

View. Getviewtreeobserver () can get a viewtreeobserver object -- this object is an observer, which is specially used to listen to some changes in the current view tree. The addongloballayoutlistener registered here will notify the callback when the global layout of the current view tree changes or the visual state of the view changes.

- "soft keyboard pop-up" is a source that will trigger this event. (the pop-up of soft keyboard will change globallayout)

In other words, the event of "soft keyboard pop-up" can be monitored now.

3. After the interface changes, obtain the "available height"

When the soft keyboard pops up, the next thing is to get the available height of the changed interface (the height that can be used by developers to display content).

Look directly at the code:

View. Getwindowvisibledisplayframe (rect rect), rect that this line of code can get -- that is, the remaining rectangular area of the interface after removing the title bar and the part blocked by the soft keyboard -- as shown in the figure, the area in the red box.

Schematic diagram of rect area

It can also be seen that:

rect. The top value is actually the height of the title bar. (in fact, this is often used as a way to get the title block height)

Screen height - rect Bottom is the height of the soft keyboard. (the method of obtaining the height of the soft keyboard also appears) at this time, there are:

In full screen mode, available height = rect bottom

Non full screen mode, available height = rect bottom - rect. top

4. The last step is to reset the height

The available height we calculated is the interface height that can be seen in the visual effect at present. However, the actual height of the current interface is one more distance from the soft keyboard than the available height.

Therefore, the last step is to set the interface height to the available height - it's done.

A "height difference > (usableheight sans keyboard / 4)" judgment is added to the above code to remove unnecessary interference. There are many reasons that can trigger the ongloballayout event, not only the pop-up change of the soft keyboard, but also the hidden display change of each sub view. They have a limited impact on the height of the interface. After adding this judgment, the height will be reset only when the height of the interface changes by more than 1 / 4 of the screen height, which can basically ensure that the code only responds to the pop-up of the soft keyboard.

summary

To sum up, that's it:

Normal activity (without WebView), directly use adjustpan or adjustresize

If with WebView:

a) If not in full screen mode, you can use adjustresize

b) If it is in full screen mode, androidbug5497workaround is used for processing.

The above is the ultimate solution for the Android soft keyboard to block the input box introduced by Xiaobian. I hope it will help you. If you have any questions, please leave me a message, and Xiaobian will reply to you in time. Thank you very much for your support for the programming tips website!