Android keyboard panel conflict layout flashing solution

I have written a core idea before: Switching between the panel and the keyboard in WeChat

This time, the practice is mainly based on the core idea. The principle of practice is to use the CustomRootLayout layout change to know whether the real layout change is caused by the keyboard, and then process it in the next PanelLayout's onMersure.

• The new algorithm no longer modifies View#LayoutParams dynamically, but is a simpler and clearer approach
• ***The code automatically and dynamically adapts the panel height to the keyboard height on the original basis, which greatly optimizes the experience.

We can see that the switch from the keyboard to WeChat is seamless and flicker-free. This basic experience is in line with expectations.

But in reality, simple keyboard and panel switching will cause flickering, which is a problem. Today we will analyze and solve this problem in practice.

Final effect comparison:

I. Preparation

The following is based on android:windowSoftInputMode with adjustResize.

As shown in the figure, for the convenience of analysis, we divide it into 3 Views:

• CustomRootView: Remove statusBar and ActionBar(ToolBar…balabala)
• FootRootView: The entire bottom (the entire View including the input box and the bottom panel)
• PanelView: PanelView

The entire processing process actually needs to be divided into two parts:

Switch from PanelView to Keybord

Phenomenon: Because PanelView#setVisibility(View.GONE) is called directly when the Keybord is displayed, the entire FooterRootView will appear to the bottom and then be lifted up by the keyboard.

It should be in line with expectations: It should be lifted up directly by the keyboard, without having to lift it up from the bottom.

Switching from Keybord to PanelView

Phenomenon: When hiding the Keybord, directly call PanelView#setVisibility(View.VISIBLE), which will cause the entire FootRootView to be pushed to the top of the keyboard first, and then go down to the bottom with the animation of the keyboard.

As expected: it switches directly to the bottom as the keyboard is retracted, with the flash being lifted up by the keyboard.

II. Processing

principle

When the layout is about to change due to the Keybord, the PanelView is adapted. (Note that all judgments must be made before Super.onMeasure)

method:

By changing the height of CustomRootView, we can ensure that the layout will change due to the keyboard before Super.onMeasure, and then inform PanelView to give it a valid height before Super.onMeasure.

Note:

1) In adjustResize mode, the height of CustomRootView will decrease when the keyboard is popped up, and increase when the keyboard is retracted, and vice versa. Therefore, this mechanism can be used to know when the real PanelView is about to change.

2) Since the size of clipRect has been determined by the time onLayout arrives, and we want to avoid calling onMeasure multiple times, we need to call it before Super.onMeasure

3) When the keyboard is retracted, multiple measures will be triggered. If you do not judge whether the layout will change due to the actual keyboard retraction, and directly give View#VISIBLE, there will still be flickering.

4) Switching from Keybord to PanelView causes layout conflicts only when the Keybord is being displayed.

5) The layout conflict caused by switching from PanelView to Keybord has been handled internally in PanelView and CustomRootView.

III. GitHub:

JKeyboardPanelSwitch

© 2012 – 2016, Jacksgong(blog.dreamtobe.cn). Licensed under the Creative Commons Attribution-NonCommercial 3.0 license (This license lets others remix, tweak, and build upon a work non-commercially, and although their new works must also acknowledge the original author and be non-commercial, they don't have to license their derivative works on the same terms). http://creativecommons.org/licenses/by-nc/3.0/