Conversation
…Changed, after layout Fixes: #10054
User Test ResultsTest specification and instructions
Test Artifacts |
| @Override | ||
| public void onConfigurationChanged(Configuration newConfig) { | ||
| super.onConfigurationChanged(newConfig); |
There was a problem hiding this comment.
What set me on this path: we're calling methods that should be automatically called by the Android OS with parameters we're managing in order to maintain WebView and host page layout. That... feels odd. It does seem to be the correct time to adjust Android View layout data, at least.
The question this left me with, though: the API for Configuration suggests that it returns the "available" width and height. The thing is... the Configuration passed in as a parameter would have been computed before we set new layout parameters in place. So... is it actually right to expect the values to be current within this method? Or, do we need to wait for layout adjustments to take place first? If we're adjusting height, that could certainly be volatile... and made worse if we're also simultaneously flipping our width and height values due to orientation change.
|
I am going to install this now |
mcdurdin
left a comment
There was a problem hiding this comment.
Code changes look okay.
I know this is a bug fix, and we are trying to keep changes minimal. It seems like part of the problem here is the existing spaghetti is making it very difficult to reason about the orientation state.
One simple refactor I think we should try and apply is to reduce the number of loadJavascript calls:
- Each call is costly
- If we have a
setDimensionsfunction which is passed an object, then we can set as many of the dimensions as are passed in, in the specific order that they should be set, and without having to bubble that ordering detail all the up into the Java code. - It helps us see where we are only setting width or height or vice-versa.
| loadJavascript(KMString.format("setBannerHeight(%d)", bannerHeight)); | ||
| loadJavascript(KMString.format("setOskWidth(%d)", newConfig.screenWidthDp)); | ||
| loadJavascript(KMString.format("setOskWidth(%d)", width)); | ||
| // Must be last - it's the one that triggers a Web-engine layout refresh. | ||
| loadJavascript(KMString.format("setOskHeight(%d)", oskHeight)); |
There was a problem hiding this comment.
This smells like it should be a single function call, setDimensions({bannerHeight:%d,oskWidth:%d,oskHeight:%d}).
This may also be relevant:
keyman/android/KMEA/app/src/main/java/com/keyman/engine/KMKeyboard.java
Lines 426 to 436 in 91e91bf
Calls to these functions (on master branch):
- Only 1 call to
setBannerHeight, right here. - 4 calls to
setOskHeight - 2 calls to
setOskWidth
Test Results
I have followed the acceptance steps. I tried to change the view from portrait to landscape and landscape to portrait. OSK always displays the correct width and height after the device's orientation. It works correctly after repeating steps more than 10 times. It works correctly. Thank you.
|
|
Changes in this pull request will be available for download in Keyman version 18.0.53-alpha |
|
So far the test build has worked perfectly for me. I'll move to 18.0.53-alpha on my phone today. |
Fixes: #10054
This aims to fix the size and orientation issues we've been seeing for our touch-keyboards on Android.
Note that this PR adds to the adjustments made by ##11604. That does appear to properly ensure the correct "outer size" of the keyboard - that of the hosting WebView. The remaining issues appear to lie within the keyboard host-page inside of the WebView.
In order to properly handle this, ensuring proper layout for our WebView-internal keyboard, we split management of WebView's layout operations from the JS calls used to set the WebView-internal layout, the latter of which are based on the final size of the hosting WebView. To do so, we relocate the latter set of calls to
onSizeChanged, overriding a superclass method that ought be triggered afteronConfigurationChangedand its layout-update.User Testing
TEST_KEYBOARD_REPEATED_RESTORE
TEST_GENERAL_USE: Test the system keyboard in general use, tossing in a few orientation changes from time to time. Verify that the keyboard always displays correctly for the current orientation.