Window class

The most basic interface to the host operating system's user interface.

It exposes the size of the display, the core scheduler API, the input event callback, the graphics drawing API, and other such core services.

There is a single Window instance in the system, which you can obtain from WidgetsBinding.instance.window.

There is also a window singleton object in dart:ui if WidgetsBinding is unavailable. But we strongly advise to avoid statically referencing it. See the document of window for more details of why it should be avoided.

Insets and Padding

In this diagram, the black areas represent system UI that the app cannot draw over. The red area represents view padding that the application may not be able to detect gestures in and may not want to draw in. The grey area represents the system keyboard, which can cover over the bottom view padding when visible.

The Window.viewInsets are the physical pixels which the operating system reserves for system UI, such as the keyboard, which would fully obscure any content drawn in that area.

The Window.viewPadding are the physical pixels on each side of the display that may be partially obscured by system UI or by physical intrusions into the display, such as an overscan region on a television or a "notch" on a phone. Unlike the insets, these areas may have portions that show the user application painted pixels without being obscured, such as a notch at the top of a phone that covers only a subset of the area. Insets, on the other hand, either partially or fully obscure the window, such as an opaque keyboard or a partially transluscent statusbar, which cover an area without gaps.

The Window.padding property is computed from both Window.viewInsets and Window.viewPadding. It will allow a view inset to consume view padding where appropriate, such as when a phone's keyboard is covering the bottom view padding and so "absorbs" it.

Clients that want to position elements relative to the view padding regardless of the view insets should use the Window.viewPadding property, e.g. if you wish to draw a widget at the center of the screen with respect to the iPhone "safe area" regardless of whether the keyboard is showing.

Window.padding is useful for clients that want to know how much padding should be accounted for without concern for the current inset(s) state, e.g. determining whether a gesture should be considered for scrolling purposes. This value varies based on the current state of the insets. For example, a visible keyboard will consume all gestures in the bottom part of the Window.viewPadding anyway, so there is no need to account for that in the Window.padding, which is always safe to use for such calculations.