Fixed
Status Update
No update yet.
Comments
an...@google.com
ap...@google.com
Diego, currently computeCurrentWindowMetrics requires a @UiContext and will crash if the provided context cannot be unwrapped to an Activity or InputMethodService.
For views that are created without a UiContext, such as in a robolectric test, or when inflated using the applicationContext (for example to be added to window manager directly with WM#addView), should computeCurrentWindowMetrics implement some fallback behavior (such as size of the ViewRootImpl, or default display size)? If not then consumers of this API will need to define their own fallbacks which will lead to inconsistency
Description
Sometimes we want to use mutableState() only to be able to safely set values during composition/measure and then have ability to read this value without causing extra remeasure/recomposition. Currently we have to just use regular vars which is not thread-safe and the value will be updated even if the composition is aborted.
We discussed it and though the api could be