-
Notifications
You must be signed in to change notification settings - Fork 30.1k
Description
MediaQuery mixes platform-specific concepts (that are shared among all views) with view-specific concepts. This makes MediaQuery cumbersome to use in a multi view environment: The View widget needs to inject the view-specific data into the widget tree, without overriding the platform-specific data from the surrounding context. This can be done with the existing MediaQuery concept, but it would require copying the platform-specific data from the context and makes rebuilds less targeted when the data changes.
Since we are removing single view assumptions elsewhere in the framework as well, it would be cleaner to split MediaQuery into ViewQuery (which contains the view-specific data) and PlatformQuery (which contains the rest). The data from the PlatformQuery would be injected near the root of the tree and is accessible from all views. The data from the ViewQuery would be injected by the View widget and its only available within that View.
If we implement the InheritanceBoundary (#115381), the PlatformQuery would not be an inheritance boundary, while ViewQuery would be one.
Data moving to ViewQuery:
- devicePixelRatio
- displayFeatures
- orientation
- padding
- size
- systemGestureInsets
- viewInsets
- viewPadding
Data moving to PlatformQuery:
- accessibleNavigation
- alwaysUse24HourFormat
- boldText
- disableAnimations
- gestureSettings
- highContrast
- invertColors
- navigationMode
- platformBrightness
- textScaleFactor
Migration: We would deprecate MediaQuery and redirect people to PlatformQuery and ViewQuery. During the deprecation policy, MediaQuery would be reimplemented by composing PlatformQuery and ViewQuery internally.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status