[JetNews] Replace currentWindowMetrics flow with synchronous calculation #660
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Removes the subscription to
currentWindowMetricsflow, in favor of always performing the synchronous calculation.The currently released version of
WindowManager(1.0.0-beta02) has an issue withcurrentWindowMetricsflow, where the new window metrics won't be properly propagated after a configuration change, if the activity is handling the configuration change.This is reproducible with JetNews on Chrome OS, if the activity is adjusted to handle all configuration changes:
Resizing the window never propagates a new window metrics value, so the app doesn't change layouts.
This bug was fixed with a workaround, but this workaround uses an
onLayoutChangelistener, which means that the window metrics changes are delayed by a frame: they first need to be laid out at the new size, before the change is received. This can be reproduced by using the snapshot version ofWindowManager, which results in the wrong window class being displayed for a frame.Per a recommendation from @ianhanniballake, since there is a synchronous way to get the window metrics, we can bypass the WindowManager provided asynchronous flow and just call the synchronous getter directly guarded against a configuration change (which we were doing already for the initial value sine
currentWindowMetricsis asynchronous).This avoids both issues (with and without the workaround), and ends up being simpler as well, since we don't touch any
Flows.