Flutter Adaptive Ui

Flutter Adaptive UI

You are a Flutter adaptive UI implementation agent. Your job is to make the UI work from narrow mobile windows to expanded desktop/web layouts without guessing from device type.

Principle 0

Adaptive Flutter UI is based on available constraints, not platform labels. Use window or parent constraints for layout decisions, keep touch usable first, and add mouse, keyboard, and platform behavior as explicit branches that can be tested.

Core rule: constraints go down, sizes go up, parent sets position.

Default breakpoints:

• Compact: width < 600
• Medium: 600 <= width < 840
• Expanded: width >= 840

Workflow

1. Identify the user flow, target form factors, supported platforms, and the expensive failure mode: overflow, unreadable wide content, lost state, inaccessible keyboard flow, or wrong platform behavior. 2. Inspect existing widgets before changing layout. Find navigation, dialogs, lists, grids, fixed widths/heights, orientation checks, Platform.* layout checks, and custom input/focus handling. 3. Abstract shared data before branching. For example, create one destination model used by both NavigationBar and NavigationRail. 4. Measure the right space:

• Use MediaQuery.sizeOf(context) for app-level or page-level window decisions.
• Use LayoutBuilder when the branch depends on the parent constraints of a widget subtree.

5. Branch by breakpoints or capabilities, not by device type. Use compact/medium/expanded layouts for space changes; use Capability and Policy objects for what the app can do or should do. 6. Implement the smallest adaptive change that preserves state. Keep scroll position, selected navigation destination, form input, and focus stable across resize/orientation/fold changes. 7. Validate on at least compact and expanded widths. Include medium width when the implementation has a distinct tablet layout.

Resource Routing

Do not read every reference by default. Read only the routed material needed for the current failure mode or implementation path.

Implementation Rules

• Treat Dart snippets in references/ as explanatory fragments unless the reference explicitly says otherwise. Use assets/ for starter code.
• Do not use Platform.isIOS, Platform.isAndroid, device names, or OrientationBuilder for layout decisions. Use available width/constraints instead.
• Do not let large screens stretch text fields, cards, lists, or reading content across the full window without a deliberate max width or multi-column layout.
• Start with a solid touch interaction, then add hover, shortcuts, focus traversal, and keyboard activation as accelerators.
• Use GridView.extent, adaptive flex layouts, or constrained content widths for expanded layouts instead of duplicating whole screens when a local reflow is enough.
• Keep Capability methods about what is possible and Policy methods about what should be shown or allowed. Name methods by the decision, not by the platform.
• Treat bundled assets as starter examples. They are copy-ready only after flutter analyze passes in the target project or a scratch Flutter project.

Validation

After changing a Flutter project:

1. Run flutter analyze. 2. Run relevant widget tests when layout branching, navigation state, focus, or policy/capability behavior changed. 3. Manually or automatically check narrow (<600), medium (600-839 when used), and expanded (>=840) widths. 4. Verify no new overflow stripes, clipped text, lost selected state, lost scroll position, or broken keyboard traversal. 5. If validation cannot run, report the blocker and the risk. Do not present an adaptive UI change as verified without a width check or analysis result.

Fallback

If the target project lacks enough context to choose a final layout, implement the smallest reversible abstraction first: shared destination/data models, local LayoutBuilder branches, and isolated Capability/Policy interfaces. Ask the user only for product decisions that cannot be inferred from the app, such as which content should move, hide, or become primary on each form factor.

Best Practices for Adaptive Design

Design Considerations

Break down your widgets

While designing your app, try to break down large, complex widgets into smaller, simpler ones.

Refactoring widgets can reduce the complexity of adopting an adaptive UI by sharing core pieces of code. There are other benefits as well:

• On the performance side, having lots of small const widgets improves rebuild times over having large, complex widgets.
• Flutter can reuse const widget instances, while a larger complex widget has to be set up for every rebuild.
• From a code health perspective, organizing your UI into smaller bite sized pieces helps keep the complexity of each Widget down. A less-complex Widget is more readable, easier to refactor, and less likely to have surprising behavior.

Design to the strengths of each form factor

Beyond screen size, you should also spend time considering the unique strengths and weaknesses of different form factors. It isn't always ideal for your multiplatform app to offer identical functionality everywhere. Consider whether it makes sense to focus on specific capabilities, or even remove certain features, on some device categories.

For example, mobile devices are portable and have cameras, but they aren't well suited for detailed creative work. With this in mind, you might focus more on capturing content and tagging it with location data for a mobile UI, but focus on organizing or manipulating that content for a tablet or desktop UI.

Another example is leveraging the web's extremely low barrier for sharing. If you're deploying a web app, decide which deep links to support, and design your navigation routes with those in mind.

The key takeaway here is to think about what each platform does best and see if there are unique capabilities you can leverage.

Solve touch first

Building a great touch UI can often be more difficult than a traditional desktop UI due, in part, to the lack of input accelerators like right-click, scroll wheel, or keyboard shortcuts.

One way to approach this challenge is to focus initially on a great touch-oriented UI. You can still do most of your testing using the desktop target for its iteration speed. But, remember to switch frequently to a mobile device to verify that everything feels right.

After you have the touch interface polished, you can tweak the visual density for mouse users, and then layer on all the additional inputs. Approach these other inputs as accelerator—alternatives that make a task faster. The important thing to consider is what a user expects when using a particular input device, and work to reflect that in your app.

Implementation Details

Don't lock the orientation of your app.

An adaptive app should look good on windows of different sizes and shapes. While locking an app to portrait mode on phones can help narrow the scope of a minimum viable product, it can increase the effort required to make the app adaptive in the future.

For example, the assumption that phones will only render your app in a full screen portrait mode is not a guarantee. Multi window app support is becoming common, and foldables have many use cases that work best with multiple apps running side by side.

To summarize:

• Locked screens can be an accessibility issue for some users
• Android large format tiers require portrait and landscape support at the lowest level
• Android devices can override a locked screen
• Apple guidelines say aim to support both orientations

Avoid device orientation-based layouts

Avoid using MediaQuery's orientation field or OrientationBuilder near the top of your widget tree to switch between different app layouts. This is similar to the guidance of not checking device types to determine screen size. The device's orientation also doesn't necessarily inform you of how much space your app window has.

Instead, use MediaQuery's sizeOf or LayoutBuilder, then use adaptive breakpoints.

Don't gobble up all of the horizontal space

Apps that use the full width of the window to display boxes or text fields don't play well when these apps run on large screens.

Use LayoutBuilder and GridView to optimize layout for large screens, creating multi-column layouts that effectively use horizontal space.

Avoid checking for hardware types

Avoid writing code that checks whether the device you're running on is a "phone" or a "tablet", or any other type of device when making layout decisions.

What space your app is actually given to render in isn't always tied to the full screen size of the device. Flutter can run on many different platforms, and your app might be running in a resizeable window on ChromeOS, side by side with another app on tablets in a multi-window mode, or even in a picture-in-picture on phones. Therefore, device type and app window size aren't really strongly connected.

Instead, use MediaQuery.sizeOf(context) or LayoutBuilder to get the size your app or widget subtree is currently running in.

Support a variety of input devices

Apps should support basic mice, trackpads, and keyboard shortcuts. The most common user flows should support keyboard navigation to ensure accessibility. In particular, your app should follow accessible best practices for keyboards on large devices.

The Material library provides widgets with excellent default behavior for touch, mouse, and keyboard interaction.

For custom widgets, ensure they properly handle:

• MouseRegion for hover effects
• FocusNode for keyboard navigation
• Semantics properties for screen readers

Restore List state

To maintain the scroll position in a list that doesn't change its layout when the window size or orientation changes, use the [PageStorageKey][] class. PageStorageKey persists the widget state in storage after the widget is destroyed and restores state when recreated.

If the List widget changes its layout when the window size or orientation changes, you might have to do a bit of math to preserve the user's visible position.

Save app state

Apps should retain or restore app state as the device rotates, changes window size, or folds and unfolds. By default, an app should maintain state.

If your app loses state during device configuration, verify that the plugins and native extensions that your app uses support the target form factor, such as a large screen. Some native extensions might lose state when the device changes position.

Use const widgets whenever possible

Creating widgets with const constructor improves performance by allowing Flutter to reuse widget instances instead of recreating them on every rebuild. This is especially important for adaptive layouts where widgets may rebuild frequently due to size changes.

Avoid unnecessary rebuilds

Use const constructors for widgets that don't change. Use ValueKey when widgets need stable identity across rebuilds. Consider using LayoutBuilder to limit rebuilds to only the subtree that needs to respond to size changes.

[PageStorageKey]: https://api.flutter.dev/flutter/widgets/PageStorageKey-class.html

Capabilities and Policies

Design to the strengths of each form factor and platform capability

Consider the unique strengths and weaknesses of different devices. Beyond their screen size and inputs, such as touch, mouse, keyboard, what other unique capabilities can you leverage? Flutter enables your code to run on different devices, but strong design is more than just running code. Think about what each platform does best and see if there are unique capabilities to leverage.

Flutter's recommended pattern for handling different behavior based on these unique capabilities is to create a set of Capability and Policy classes for your app.

Capabilities

A _capability_ defines what the code or device _can_ do. Examples of capabilities include:

• The existence of an API
• OS-enforced restrictions
• Physical hardware requirements (like a camera)

Policies

A _policy_ defines what the code _should_ do.

Examples of policies include:

• App store guidelines
• Design preferences
• Assets or copy that refers to the host device
• Features enabled on the server side

How to structure policy code

Policy and capability implementations may consult platform APIs, server flags, package configuration, or runtime services. Keep those checks behind named methods so widgets branch on intent instead of raw platform labels. If an implementation needs dart:io, isolate it from web builds rather than importing it from shared UI code.

The following guidelines explain best practices when developing the capabilities and policies for your app:

Avoid using platform labels to make layout decisions or assumptions about what a device can do.

Instead, describe what you want to branch on in a method.

Example: Your app has a link to buy something in a website, but a policy decision controls whether that entry point is shown.

class PurchasePolicy {
  const PurchasePolicy({required this.externalPurchaseAllowed});

  final bool externalPurchaseAllowed;

  bool shouldShowExternalPurchase() {
    return externalPurchaseAllowed;
  }
}

Widget buildPurchaseEntryPoint({
  required PurchasePolicy policy,
  required VoidCallback openPurchasePage,
}) {
  if (!policy.shouldShowExternalPurchase()) {
    return const SizedBox.shrink();
  }

  return TextButton(
    onPressed: openPurchasePage,
    child: const Text('Buy in browser'),
  );
}

What did you get by adding an additional layer of indirection? The code makes it more clear why the branched path exists, and the widget now depends on a named policy decision instead of platform mechanics.

With this code in a class, any widget test can pass a PurchasePolicy and verify the behavior independently of where the device runs. It also means that later, if you decide that buying in a browser isn't the right flow for a target, you can change the policy implementation and the tests for purchase UI won't need to change.

Capabilities in Detail

Sometimes you want your code to do something but the API doesn't exist, or maybe you depend on a plugin feature that isn't yet implemented on all of the platforms you support. This is a limitation of what the device _can_ do.

Those situations are similar to the policy decisions described above, but these are referred to as _capabilities_. Why separate policy classes from capabilities when the structure of the classes is similar? The Flutter team has found with productionized apps that making a logical distinction between what apps _can_ do and what they _should_ do helps larger products respond to changes in what platforms can do or require in addition to your own preferences after the initial code is written.

For example, consider the case where one platform adds a new permission that requires users to interact with a system dialog before your code calls a sensitive API. Your team does the work for platform 1 and creates a capability named requirePermissionDialogFlow. Then, if and when platform 2 adds a similar requirement but only for new API versions, then the implementation of requirePermissionDialogFlow can now check the API level and return true for platform 2. You've leveraged the work you already did.

Policies in Detail

We encourage starting with a Policy class initially even if it seems like you won't make many policy based decisions. As the complexity of the class grows or the number of inputs expands, you might decide to break up the policy class by feature or some other criteria.

For policy implementation, you can use compile time, run time, or Remote Procedure Call (RPC) backed implementations.

Compile-time policy checks are good for platforms where the preference is unlikely to change and where accidentally changing the value might have large consequences. For example, if a platform requires that you not link to the Play store, or requires that you use a specific payment provider given the content of your app.

Runtime checks can be good for determining if there is a touch screen the user can use. Android has a feature you can check and your web implementation could check for max touch points.

RPC-backed policy changes are good for incremental feature rollout or for decisions that might change later.

Summary

Use a Capability class to define what the code can do. You might check against the existence of an API, OS-enforced restrictions, and physical hardware requirements (like a camera). A capability usually involves compile or runtime checks.

Use a Policy class (or classes depending on complexity) to define what the code should do to comply with App store guidelines, design preferences, and assets or copy that need to refer to the host. Policies can be a mix of compile, runtime, or RPC checks.

Test the branching code by mocking capabilities and policies so that widget tests don't need to change when capabilities or policies change.

Name the methods in your capabilities and policies classes based on what they are trying to branch, rather than on device type.

Adaptive Design Workflow

Three-Step Approach

Google engineers recommend following 3-step approach to make your app adaptive.

Step 1: Abstract

First, identify the widgets that you plan to make dynamic. Analyze the constructors for those widgets and abstract out the data that you can share.

Common widgets that require adaptability are:

• Dialogs, both fullscreen and modal
• Navigation UI, both rail and bottom bar
• Custom layout, such as "is the UI area taller or wider?"

For example, in a Dialog widget, you can share the info that contains the _content_ of the dialog.

Or, perhaps you want to switch between a NavigationBar when the app window is small, and a NavigationRail when the app window is large. These widgets would likely share a list of navigable destinations. In this case, you might create a Destination widget to hold this info, and specify the Destination as having both an icon and a text label.

Step 2: Measure

You have two ways to determine the size of your display area: MediaQuery and LayoutBuilder.

MediaQuery

In the past, you might have used MediaQuery.of to determine the size of the device's screen. However, devices today feature screens with a wide variety of sizes and shapes, and this test can be misleading.

For example, maybe your app currently occupies a small window on a large screen. If you use the MediaQuery.of method and conclude the screen to be small (when, in fact, the app displays in a tiny window on a large screen), and you've portrait locked your app, it causes the app's window to lock to the center of the screen, surrounded with black. This is hardly an ideal UI on a large screen.

Use MediaQuery.sizeOf instead of MediaQuery.of for performance reasons. MediaQuery contains a lot of data, but if you're only interested in the size property, it's more efficient to use the sizeOf method. Both methods return the size of the app window in logical pixels.

Requesting the size of the app window from inside the build method, as in MediaQuery.sizeOf(context), causes the given BuildContext to rebuild any time the size property changes.

If you want your widget to be fullscreen, even when the app window is small, use MediaQuery.sizeOf so you can choose the UI based on the size of the app window itself.

LayoutBuilder

LayoutBuilder accomplishes a similar goal as MediaQuery.sizeOf, with some distinctions.

Rather than providing the size of the app's window, LayoutBuilder provides the layout constraints from the parent Widget. This means that you get sizing information based on the specific spot in the widget tree where you added the LayoutBuilder. Also, LayoutBuilder returns a BoxConstraints object instead of a Size object, so you are given the valid width and height ranges (minimum and maximum) for the content, rather than just a fixed size.

For example, imagine a custom widget, where you want the sizing to be based on the space specifically given to that widget, and not the app window in general. In this scenario, use LayoutBuilder.

Step 3: Branch

At this point, you must decide what sizing breakpoints to use when choosing what version of the UI to display. For example, the Material layout guidelines suggest using a bottom nav bar for windows less than 600 logical pixels wide, and a nav rail for those that are 600 pixels wide or greater.

Important: Your choice shouldn't depend on the _type_ of device, but on the device's available window size.

Example breakpoints commonly used:

• Compact (Mobile): width < 600
• Medium (Tablet): 600 <= width < 840
• Expanded (Desktop): width >= 840

Layout Basics in Flutter

Core Concepts

In Flutter, almost everything is a widget—even layout models are widgets. The images, icons, and text that you see in a Flutter app are all widgets. But things you don't see are also widgets, such as the rows, columns, and grids that arrange, constrain, and align the visible widgets. You create a layout by composing widgets to build more complex widgets.

Lay out a Single Widget

Select a layout widget

Choose from a variety of layout widgets based on how you want to align or constrain a visible widget, as these characteristics are typically passed on to the contained widget. For example, you could use the [Center][] layout widget to center a visible widget horizontally and vertically.

Create a visible widget

Choose a visible widget for your app to contain visible elements, such as text, images, or icons.

Add the visible widget to the layout widget

All layout widgets have either of the following:

• A child property if they take a single child—for example, Center or Container
• A children property if they take a list of widgets—for example, Row, Column, ListView, or Stack.

Add the layout widget to the page

A Flutter app is itself a widget, and most widgets have a build() method. Instantiating and returning a widget in the app's build() method displays the widget.

Lay Out Multiple Widgets Vertically and Horizontally

One of the most common layout patterns is to arrange widgets vertically or horizontally. You can use a Row widget to arrange widgets horizontally, and a Column widget to arrange widgets vertically.

To create a row or column in Flutter, add a list of children widgets to a [Row][] or [Column][] widget. In turn, each child can itself be a row or column, and so on.

Aligning widgets

You control how a row or column aligns its children using the mainAxisAlignment and crossAxisAlignment properties. For a row, the main axis runs horizontally and the cross axis runs vertically. For a column, the main axis runs vertically and the cross axis runs horizontally.

The [MainAxisAlignment][] and [CrossAxisAlignment][] enums offer a variety of constants for controlling alignment.

Sizing widgets

When a layout is too large to fit a device, a yellow and black striped pattern appears along the affected edge. Widgets can be sized to fit within a row or column by using the [Expanded][] widget.

Packing widgets

By default, a row or column occupies as much space along its main axis as possible, but if you want to pack the children closely together, set its mainAxisSize to MainAxisSize.min.

Nesting rows and columns

The layout framework allows you to nest rows and columns inside of rows and columns as deeply as you need. To minimize the visual confusion that can result from heavily nested layout code, implement pieces of the UI in variables and functions.

[Center]: https://api.flutter.dev/flutter/widgets/Center-class.html [Column]: https://api.flutter.dev/flutter/widgets/Column-class.html [CrossAxisAlignment]: https://api.flutter.dev/flutter/rendering/CrossAxisAlignment.html [Expanded]: https://api.flutter.dev/flutter/widgets/Expanded-class.html [MainAxisAlignment]: https://api.flutter.dev/flutter/rendering/MainAxisAlignment.html [Row]: https://api.flutter.dev/flutter/widgets/Row-class.html

Common Layout Widgets

Container

Adds padding, margins, borders, background color, or other decorations to a widget.

Summary:

• Add padding, margins, borders
• Change background color or image
• Contains a single child widget, but that child can be a Row, Column, or even the root of a widget tree

GridView

Lays widgets out as a two-dimensional list. GridView provides two pre-fabricated lists, or you can build your own custom grid. When a GridView detects that its contents are too long to fit the render box, it automatically scrolls.

Summary:

• Lays widgets out in a grid
• Detects when the column content exceeds the render box and automatically provides scrolling
• Build your own custom grid, or use one of the provided grids:
• GridView.count allows you to specify the number of columns
• GridView.extent allows you to specify the maximum pixel width of a tile

Example using GridView.extent:

Widget _buildGrid() => GridView.extent(
  maxCrossAxisExtent: 150,
  padding: const EdgeInsets.all(4),
  mainAxisSpacing: 4,
  crossAxisSpacing: 4,
  children: _buildGridTileList(30),
);

List<Widget> _buildGridTileList(int count) =>
    List.generate(count, (i) => Image.asset('images/pic$i.jpg'));

ListView

[ListView][], a column-like widget, automatically provides scrolling when its content is too long for its render box.

Summary:

• A specialized [Column][] for organizing a list of boxes
• Can be laid out horizontally or vertically
• Detects when its content won't fit and provides scrolling
• Less configurable than Column, but easier to use and supports scrolling

Example:

Widget _buildList() {
  return ListView(
    children: [
      _tile('CineArts at the Empire', '85 W Portal Ave', Icons.theaters),
      _tile('The Castro Theater', '429 Castro St', Icons.theaters),
      _tile('Alamo Drafthouse Cinema', '2550 Mission St', Icons.theaters),
      const Divider(),
      _tile('K\'s Kitchen', '757 Monterey Blvd', Icons.restaurant),
      _tile('Emmy\'s Restaurant', '1923 Ocean Ave', Icons.restaurant),
      _tile('Chaiya Thai Restaurant', '272 Claremont Blvd', Icons.restaurant),
      _tile('La Ciccia', '291 30th St', Icons.restaurant),
    ],
  );
}

ListTile _tile(String title, String subtitle, IconData icon) {
  return ListTile(
    title: Text(
      title,
      style: const TextStyle(fontWeight: FontWeight.w500, fontSize: 20),
    ),
    subtitle: Text(subtitle),
    leading: Icon(icon, color: Colors.blue[500]),
  );
}

Stack

Use [Stack][] to arrange widgets on top of a base widget—often an image. The widgets can completely or partially overlap the base widget.

Summary:

• Use for widgets that overlap another widget
• The first widget in the list of children is the base widget; subsequent children are overlaid on top of that base widget
• A Stack's content can't scroll
• You can choose to clip children that exceed the render box

Example:

Widget _buildStack() {
  return Stack(
    alignment: const Alignment(0.6, 0.6),
    children: [
      const CircleAvatar(
        backgroundImage: AssetImage('images/pic.jpg'),
        radius: 100,
      ),
      Container(
        decoration: const BoxDecoration(color: Colors.black45),
        child: const Text(
          'Mia B',
          style: TextStyle(
            fontSize: 20,
            fontWeight: FontWeight.bold,
            color: Colors.white,
          ),
        ),
      ),
    ],
  );
}

Card

A [Card][], from the [Material library][], contains related nuggets of information and can be composed of almost any widget, but is often used with [ListTile][]. Card has a single child, but its child can be a column, row, list, grid, or other widget that supports multiple children. By default, a Card shrinks its size to 0 by 0 pixels. You can use [SizedBox][] to constrain the size of a card.

Summary:

• Implements a Material card
• Used for presenting related nuggets of information
• Accepts a single child, but that child can be a Row, Column, or other widget that holds a list of children
• Displayed with rounded corners and a drop shadow
• A Card's content can't scroll
• From the Material library

Example:

Widget _buildCard() {
  return SizedBox(
    height: 210,
    child: Card(
      child: Column(
        children: [
          ListTile(
            title: const Text(
              '1625 Main Street',
              style: TextStyle(fontWeight: FontWeight.w500),
            ),
            subtitle: const Text('My City, CA 99984'),
            leading: Icon(Icons.restaurant_menu, color: Colors.blue[500]),
          ),
          const Divider(),
          ListTile(
            title: const Text(
              '(408) 555-1212',
              style: TextStyle(fontWeight: FontWeight.w500),
            ),
            leading: Icon(Icons.contact_phone, color: Colors.blue[500]),
          ),
          ListTile(
            title: const Text('costa@example.com'),
            leading: Icon(Icons.contact_mail, color: Colors.blue[500]),
          ),
        ],
      ),
    ),
  );
}

ListTile

Use [ListTile][], a specialized row widget from the [Material library][], for an easy way to create a row containing up to 3 lines of text and optional leading and trailing icons. ListTile is most commonly used in [Card][] or [ListView][], but can be used elsewhere.

Summary:

• A specialized row that contains up to 3 lines of text and optional icons
• Less configurable than Row, but easier to use
• From the Material library

[Card]: https://api.flutter.dev/flutter/material/Card-class.html [Column]: https://api.flutter.dev/flutter/widgets/Column-class.html [ListTile]: https://api.flutter.dev/flutter/material/ListTile-class.html [ListView]: https://api.flutter.dev/flutter/widgets/ListView-class.html [Material library]: https://api.flutter.dev/flutter/material/material-library.html [Stack]: https://api.flutter.dev/flutter/widgets/Stack-class.html [SizedBox]: https://api.flutter.dev/flutter/widgets/SizedBox-class.html

Layout Constraints in Flutter

Core Rule

Constraints go down. Sizes go up. Parent sets position.

Flutter layout can't be understood without knowing this rule.

In more detail:

• A widget gets its constraints from its parent. A constraint is just a set of 4 doubles: a minimum and maximum width, and a minimum and maximum height.
• Then the widget goes through its own list of children. One by one, the widget tells its children what their constraints are, and then asks each child what size it wants to be.
• Then, widget positions its children (horizontally in the x axis, and vertically in the y axis), one by one.
• And, finally, widget tells its parent about its own size (within the original constraints, of course).

Limitations

Flutter's layout engine is designed to be a one-pass process:

• A widget can decide its own size only within the constraints given to it by its parent. This means a widget usually can't have any size it wants.
• A widget can't know and doesn't decide its own position in the screen, since it's the widget's parent who decides the position of the widget.
• Since the parent's size and position also depends on its own parent, it's impossible to precisely define the size and position of any widget without taking into consideration the tree as a whole.
• If a child wants a different size from its parent and parent doesn't have enough information to align it, then the child's size might be ignored. Be specific when defining alignment.

Widget Types

Generally, there are three kinds of boxes, in terms of how they handle their constraints:

• Those that try to be as big as possible (e.g., [Center][], [ListView][])
• Those that try to be same size as their children (e.g., [Transform][], [Opacity][])
• Those that try to be a particular size (e.g., [Image][], [Text][])

Some widgets vary from type to type based on their constructor arguments (e.g., [Container][] varies based on width/height parameters).

Examples

Example 1: Container fills screen

Container(color: Colors.red)

The screen is parent of Container, and it forces Container to be exactly same size as screen. So Container fills screen and paints it red.

Example 2: Container with fixed size in screen

Container(width: 100, height: 100, color: Colors.red)

The red Container wants to be 100×100, but it can't, because the screen forces it to be exactly the same size as the screen. So Container fills the screen.

Example 3: Centered Container

Center(child: Container(width: 100, height: 100, color: Colors.red))

The screen forces the Center to be exactly the same size as the screen, so Center fills the screen. The Center tells the Container that it can be any size it wants, but not bigger than the screen. Now the Container can indeed be 100×100.

Example 4: Aligned Container

Align(
  alignment: Alignment.bottomRight,
  child: Container(width: 100, height: 100, color: Colors.red),
)

Align also tells the Container that it can be any size it wants, but if there is empty space it won't center the Container. Instead, it aligns the container to the bottom-right of the available space.

Example 5: Infinite Container

Center(
  child: Container(
    width: double.infinity,
    height: double.infinity,
    color: Colors.red,
  ),
)

The screen forces the Center to be exactly the same size as the screen, so Center fills the screen. The Center tells the Container that it can be any size it wants, but not bigger than the screen. The Container wants to be of infinite size, but since it can't be bigger than the screen, it just fills the screen.

Example 6: Empty Container

Center(child: Container(color: Colors.red))

The screen forces the Center to be exactly the same size as the screen, so Center fills the screen. The Center tells the Container that it can be any size it wants, but not bigger than the screen. Since the Container has no child and no fixed size, it decides it wants to be as big as possible, so it fills the whole screen.

Example 7: Nested Containers

Center(
  child: Container(
    color: Colors.red,
    child: Container(color: Colors.green, width: 30, height: 30),
  ),
)

The screen forces the Center to be exactly the same size as the screen, so Center fills the screen. The Center tells the red Container that it can be any size it wants, but not bigger than the screen. Since the red Container has no size but has a child, it decides it wants to be the same size as its child. The red Container tells its child that it can be any size it wants, but not bigger than the screen. The child is a green Container that wants to be 30×30. The red Container sizes itself to the size of its child, so it is also 30×30. The red color isn't visible because the green Container entirely covers all of the red Container.

Example 8: Container with padding

Center(
  child: Container(
    padding: const EdgeInsets.all(20),
    color: Colors.red,
    child: Container(color: Colors.green, width: 30, height: 30),
  ),
)

The red Container sizes itself to its children's size, but it takes its own padding into consideration. So it is also 30×30 plus padding. The red color is visible because of the padding, and the green Container has the same size as in the previous example.

Example 9: ConstrainedBox without Center

ConstrainedBox(
  constraints: const BoxConstraints(
    minWidth: 70,
    minHeight: 70,
    maxWidth: 150,
    maxHeight: 150,
  ),
  child: Container(color: Colors.red, width: 10, height: 10),
)

You might guess that the Container has to be between 70 and 150 pixels, but you would be wrong. The ConstrainedBox only imposes additional constraints from those it receives from its parent. Here, the screen forces the ConstrainedBox to be exactly the same size as the screen, so it tells its child Container to also assume the size of the screen, thus ignoring its 'constraints' parameter.

Example 10: ConstrainedBox with Center

Center(
  child: ConstrainedBox(
    constraints: const BoxConstraints(
      minWidth: 70,
      minHeight: 70,
      maxWidth: 150,
      maxHeight: 150,
    ),
    child: Container(color: Colors.red, width: 10, height: 10),
  ),
)

Now, Center allows ConstrainedBox to be any size up to the screen size. The ConstrainedBox imposes additional constraints from its 'constraints' parameter onto its child. The Container must be between 70 and 150 pixels. It wants to have 10 pixels, so it will end up having 70 (the minimum).

Example 11: ConstrainedBox with large Container

Center(
  child: ConstrainedBox(
    constraints: const BoxConstraints(
      minWidth: 70,
      minHeight: 70,
      maxWidth: 150,
      maxHeight: 150,
    ),
    child: Container(color: Colors.red, width: 1000, height: 1000),
  ),
)

Center allows ConstrainedBox to be any size up to the screen size. The ConstrainedBox imposes additional constraints from its 'constraints' parameter onto its child. The Container must be between 70 and 150 pixels. It wants to have 1000 pixels, so it ends up having 150 (the maximum).

Example 12: ConstrainedBox with correct size

Center(
  child: ConstrainedBox(
    constraints: const BoxConstraints(
      minWidth: 70,
      minHeight: 70,
      maxWidth: 150,
      maxHeight: 150,
    ),
    child: Container(color: Colors.red, width: 100, height: 100),
  ),
)

Center allows ConstrainedBox to be any size up to the screen size. ConstrainedBox imposes additional constraints from its 'constraints' parameter onto its child. The Container must be between 70 and 150 pixels. It wants to have 100 pixels, and that's the size it has, since that's between 70 and 150.

Example 13: UnconstrainedBox

UnconstrainedBox(
  child: Container(color: Colors.red, width: 20, height: 50),
)

The screen forces the UnconstrainedBox to be exactly the same size as the screen. However, the UnconstrainedBox lets its child Container be any size it wants.

Example 14: UnconstrainedBox with overflow

UnconstrainedBox(
  child: Container(color: Colors.red, width: 4000, height: 50),
)

The screen forces the UnconstrainedBox to be exactly the same size as the screen, and UnconstrainedBox lets its child Container be any size it wants. Unfortunately, in this case Container has 4000 pixels of width and is too big to fit in the UnconstrainedBox, so the UnconstrainedBox displays the much dreaded "overflow warning".

Example 15: OverflowBox

OverflowBox(
  minWidth: 0,
  minHeight: 0,
  maxWidth: double.infinity,
  maxHeight: double.infinity,
  child: Container(color: Colors.red, width: 4000, height: 50),
)

The screen forces the OverflowBox to be exactly the same size as the screen, and OverflowBox lets its child Container be any size it wants. OverflowBox is similar to UnconstrainedBox, and difference is that it won't display any warnings if child doesn't fit space. In this case Container is 4000 pixels wide, and is too big to fit in the OverflowBox, but the OverflowBox simply shows as much as it can, with no warnings given.

Example 16: UnconstrainedBox with infinite Container

UnconstrainedBox(
  child: Container(color: Colors.red, width: double.infinity, height: 100),
)

This won't render anything, and you'll see an error in the console. The UnconstrainedBox lets its child be any size it wants, however its child is a Container with infinite size. Flutter can't render infinite sizes, so it throws an error with following message: "BoxConstraints forces an infinite width."

Example 17: LimitedBox

UnconstrainedBox(
  child: LimitedBox(
    maxWidth: 100,
    child: Container(
      color: Colors.red,
      width: double.infinity,
      height: 100,
    ),
  ),
)

Here you won't get an error anymore, because when the LimitedBox is given an infinite size by the UnconstrainedBox, it passes a maximum width of 100 down to its child. If you swap the UnconstrainedBox for a Center widget, the LimitedBox won't apply its limit anymore (since its limit is only applied when it gets infinite constraints), and the width of the Container is allowed to grow past 100.

Example 18: FittedBox

FittedBox(child: Text('Some Example Text.'))

The screen forces the FittedBox to be exactly the same size as the screen. The Text has some natural width (also called its intrinsic width) that depends on the amount of text, its font size, and so on. The FittedBox lets the Text be any size it wants, but after the Text tells its size to the FittedBox, the FittedBox scales the Text until it fills all of the available width.

Example 19: FittedBox in Center

Center(child: FittedBox(child: Text('Some Example Text.')))

The Center lets the FittedBox be any size it wants, up to the screen size. The FittedBox then sizes itself to the Text, and lets the Text be any size it wants. Since both FittedBox and Text have the same size, no scaling happens.

Example 20: FittedBox with large text

Center(
  child: FittedBox(
    child: Text(
      'This is some very very very large text that is too big to fit a regular screen in a single line.',
    ),
  ),
)

FittedBox tries to size itself to the Text, but it can't be bigger than the screen. It then assumes the screen size, and resizes Text so that it fits the screen, too.

Example 21: Large text without FittedBox

Center(
  child: Text(
    'This is some very very very large text that is too big to fit a regular screen in a single line.',
  ),
)

If you remove the FittedBox, the Text gets its maximum width from the screen, and breaks the line so that it fits the screen.

Example 22: FittedBox with unbounded Container

FittedBox(
  child: Container(
    height: 20,
    width: double.infinity,
  ),
)

FittedBox can only scale a widget that is BOUNDED (has non-infinite width and height). Otherwise, it won't render anything, and you'll see an error in the console.

Example 23: Row with text

Row(
  children: [
    Container(
      color: Colors.red,
      child: const Text('Hello!', style: TextStyle(fontSize: 30)),
    ),
    Container(
      color: Colors.green,
      child: const Text('Goodbye!', style: TextStyle(fontSize: 30)),
    ),
  ],
)

The screen forces the Row to be exactly the same size as the screen. Just like an UnconstrainedBox, the Row won't impose any constraints onto its children, and instead lets them be any size they want. The Row then puts them side-by-side, and any extra space remains empty.

Example 24: Row with overflow

Row(
  children: [
    Container(
      color: Colors.red,
      child: const Text(
        'This is a very long text that won\'t fit the line.',
        style: TextStyle(fontSize: 30),
      ),
    ),
    Container(
      color: Colors.green,
      child: const Text('Goodbye!', style: TextStyle(fontSize: 30)),
    ),
  ],
)

Since the Row won't impose any constraints onto its children, it's quite possible that children might be too big to fit the available width of Row. In this case, just like an UnconstrainedBox, the Row displays the "overflow warning".

Example 25: Row with Expanded

Row(
  children: [
    Expanded(
      child: Center(
        child: Container(
          color: Colors.red,
          child: const Text(
            'This is a very long text that won\'t fit the line.',
            style: TextStyle(fontSize: 30),
          ),
        ),
      ),
    ),
    Container(
      color: Colors.green,
      child: const Text('Goodbye!', style: TextStyle(fontSize: 30)),
    ),
  ],
)

When a Row's child is wrapped in an Expanded widget, the Row won't let this child define its own width anymore. Instead, it defines the Expanded width according to the other children, and only then the Expanded widget forces the original child to have the Expanded's width. In other words, once you use Expanded, the original child's width becomes irrelevant, and is ignored.

Example 26: Row with two Expanded

Row(
  children: [
    Expanded(
      child: Container(
        color: Colors.red,
        child: const Text(
          'This is a very long text that won\'t fit the line.',
          style: TextStyle(fontSize: 30),
        ),
      ),
    ),
    Expanded(
      child: Container(
        color: Colors.green,
        child: const Text('Goodbye!', style: TextStyle(fontSize: 30)),
      ),
    ),
  ],
)

If all of Row's children are wrapped in Expanded widgets, each Expanded has a size proportional to its flex parameter, and only then each Expanded widget forces its child to have the Expanded's width. In other words, Expanded ignores the preferred width of its children.

Example 27: Row with Flexible

Row(
  children: [
    Flexible(
      child: Container(
        color: Colors.red,
        child: const Text(
          'This is a very long text that won\'t fit the line.',
          style: TextStyle(fontSize: 30),
        ),
      ),
    ),
    Flexible(
      child: Container(
        color: Colors.green,
        child: const Text('Goodbye!', style: TextStyle(fontSize: 30)),
      ),
    ),
  ],
)

The only difference if you use Flexible instead of Expanded, is that Flexible lets its child be SMALLER than the Flexible width, while Expanded forces its child to have the same width of the Expanded. But both Expanded and Flexible ignore their children's width when sizing themselves.

Example 28: Scaffold with Column

Scaffold(
  body: Container(
    color: Colors.blue,
    child: const Column(
      children: [Text('Hello!'), Text('Goodbye!')],
    ),
  ),
)

The screen forces the Scaffold to be exactly the same size as the screen, so Scaffold fills the screen. The Scaffold tells the Container that it can be any size it wants, but not bigger than the screen. When a widget tells its child that it can be smaller than a certain size, we say the widget supplies "loose" constraints to its child.

Example 29: Scaffold with expanded Column

Scaffold(
  body: SizedBox.expand(
    child: Container(
      color: Colors.blue,
      child: const Column(
        children: [Text('Hello!'), Text('Goodbye!')],
      ),
    ),
  ),
)

If you want the Scaffold's child to be exactly the same size as the Scaffold itself, you can wrap its child with SizedBox.expand. When a widget tells its child that it must be of a certain size, we say the widget supplies "tight" constraints to its child.

[Center]: https://api.flutter.dev/flutter/widgets/Center-class.html [Container]: https://api.flutter.dev/flutter/widgets/Container-class.html [FittedBox]: https://api.flutter.dev/flutter/widgets/FittedBox-class.html [Image]: https://api.flutter.dev/flutter/widgets/Image-class.html [ListTile]: https://api.flutter.dev/flutter/material/ListTile-class.html [ListView]: https://api.flutter.dev/flutter/widgets/ListView-class.html [Opacity]: https://api.flutter.dev/flutter/widgets/Opacity-class.html [Row]: https://api.flutter.dev/flutter/widgets/Row-class.html [Text]: https://api.flutter.dev/flutter/widgets/Text-class.html [Transform]: https://api.flutter.dev/flutter/widgets/Transform-class.html