1

This question was asked 9 years ago, but the accepted answer just explained how to prevent full screen soft keyboards.

I would like to detect whether the keyboard will take up the entire screen, because in my app it is important that at least part of the underlying screen is visible (for context).

I know how to detect whether the screen is in landscape orientation or not, but on tablets for example, this does not result in the keyboard covering the whole screen.

Perhaps there is a reasonable way to predict this based on the screen dimensions?

Mark
  • 7,446
  • 5
  • 55
  • 75
  • It would seem like this depends on a lot of variables, well beyond screen dimensions, including Android OS version, device make and model, soft keyboard app/version/configuration, whether there is a hardware keyboard (in-built/USB/Bluetooth), etc. "in my app it is important that at least part of the underlying screen is visible (for context)" -- then it would seem like blocking full screen soft keyboards is what you need. If you do not want to do that, yet you do not want a full screen soft keyboard... what would you do even if you had that information? – CommonsWare Aug 07 '21 at 14:48
  • 1
    It's quite a common scenario. Normally when the user launches the app, the keyboard is shown so they can immediately start using the search box (the primary feature). I just think this would be too confusing to launch the app and be taken straight to a full screen keyboard. Therefore, if I knew it was going to be full screen, I'd just not show it and let the user tap on the searchbox instead. – Mark Aug 07 '21 at 14:51
  • I suppose one option might be to make use of `view.rootWindowInsets.getInsets(WindowInsetsCompat.Type.ime())` the first time it is shown and use that information for subsequent calls to determine whether to show it or not. – Mark Aug 07 '21 at 15:10
  • 1
    With that, you would need some heuristic to determine whether the insets make it unlikely that you would be able to show the relevant context. And, make sure that those "subsequent calls" are in the current process and take configuration changes into account, because the variables can change at runtime (e.g., whether a Bluetooth or USB keyboard is available). – CommonsWare Aug 07 '21 at 15:22

0 Answers0