Status Update
No update yet.
Comments
al...@google.com
ro...@google.com
I'd recommend to remove the dependency on window altogether, see
va...@google.com
Ah, interesting.
So if we remove the dependency on Window altogether because we can shift the implementation away from using the Window, then we'd want all code paths for creating a WindowInsetsControllerCompat to take just a View.
Effectively, everything should just go through ViewCompat.getWindowInsetsController.
The internal implementation then would be able to make the same workarounds (setting setSystemUiVisibility, etc.) using the View reference instead of the Window reference.
The most awkward case is still the WindowInsetsControllerCompat.toWindowInsetsControllerCompat method, which we would want to take the View (and therefore makes it equivalent to the ViewCompat.getWindowInsetsController)
Does that sound right?
ca...@google.com
That sounds good to me. I think it always good if developers know where to look for to get a Compat instance even though it takes one more parameters. And I think it's fine to delegate the call of WindowInsetsControllerCompat.toWindowInsetsControllerCompat to ViewCompat.getWindowInsetsController
I'll reassign this bug to you since you've done a lot of work on it already, but feel free to reassign it back if needed.
ap...@google.com
Branch: androidx-main
commit 0d8eb4081585d1be1997cb097f5fd54b41ddf8bb
Author: Alex Vanyo <vanyo@google.com>
Date: Tue Nov 23 01:06:28 2021
Convert WindowInsetsControllerCompat behavior to depend on a View to align behavior
Relnote: Converted WindowInsetsControllerCompat to depend on a View instead of a Window or the platform WindowInsetsController. This improves behavior with Dialogs, showing the IME, and ensures the non-deprecated creation methods workaround
Bug: 207401542,210121779
Test: Updated and new tests
Change-Id: I292640cb4acc39e47a4d2ce0502293d42468ed67
M core/core/api/restricted_current.txt
M core/core/src/androidTest/java/androidx/core/view/WindowInsetsAnimationCompatActivityTest.kt
M core/core/src/main/java/androidx/core/view/ViewCompat.java
M core/core/api/public_plus_experimental_current.txt
M samples/Support4Demos/src/main/java/com/example/android/supportv4/view/WindowInsetsControllerPlayground.kt
M core/core/src/main/java/androidx/core/view/WindowCompat.java
M core/core/src/androidTest/java/androidx/core/view/WindowInsetsControllerCompatActivityTest.kt
M core/core/api/current.txt
M core/core/src/main/java/androidx/core/view/WindowInsetsControllerCompat.java
M core/core/src/androidTest/java/androidx/core/view/WindowInsetsCompatActivityTest.kt
M core/core/src/androidTest/java/androidx/core/view/ViewCompatTest.java
Description
This is effectively a follow-up to
The fix to that bug (https://android-review.googlesource.com/1783607 )
windowparameterImpl30.However, this was not the primary constructor, which means that only instances of
WindowInsetsControllerCompatconstructed with aWindowwill be able to workaroundIn particular, the code-path that uses
WindowInsetsControllerCompat.toWindowInsetsControllerCompat(insetsController: InsetsController)bypasses the window constructor, meaning that the bug will still occur on API 30 with any method of retrieving theWindowInsetsControllerCompatwith that code-path.Those methods include:
ViewCompat.getWindowInsetsController(view: View)WindowCompat.getInsetsController(window: Window, view: View)WindowInsetsControllerCompat.toWindowInsetsControllerCompat(insetsController: InsetsController)The current workaround is to avoid all of the above methods, and instead directly use the proper constructor:
WindowInsetsControllerCompat(window: Window, view: View).As a proposed fix, the constructor of
WindowInsetsControllerCompatthat doesn't take aWindowshould be deprecated for API 30, since theWindowis required to workaround