1. Introduction

Before introducing the layout of Flutter, we need to understand some of the layout related properties of Flutter.

1.1 Box Constraints

Some people also translate box constraints as box constraints, but I still think boundary constraints are probably more intuitive.

A boundary constraint in a Flutter is that a widget can decide how it occupies layout space based on specified constraints. Flutter borrows a lot of React stuff, including some layout ideas, but it doesn’t isolate the layout itself. Instead, Flutter uses different widgets to create different layouts. By embedding styles into widgets, users can write layouts like building blocks, just like React, but without the styles. The benefit of doing this, I think, is probably for uniform rendering. Adding styles makes the layout much more complex and reduces performance at the rendering level. Therefore, Flutter adds different types of layout widgets in a large direction. In a small direction, very little customization is given, limiting the layout to a limited scope, allowing the entire rendering to be unified while completing the layout, speeding up updates and rendering. However, the disadvantages are also obvious. There is much less flexibility, and different layout methods are separated from the widgets. There are a lot of widgets that people need to understand, which increases the learning cost.

1.2 Types of constraints

In Flutter, widgets are rendered by their underlying RenderBox. The Constraints to render boundaries are given by the parent, and widgets resize within these Constraints. Constraints include minimum and maximum width and height, and dimensions are specific width and height.

In Android, there are three types of layout width and height restrictions: match_parent, wrap_content, and specific size. In Flutter, there are also these three constraints.

  • As large a constraint as possible, such as Center, ListView, etc.
  • Following content size constraints, such as Transform, Opacity, etc.;
  • Specify size constraints, such as Image, Text, etc.

However, Flutter does not handle widgets so absolutly. These constraints are contained in the widgets, unlike Android, which can be specified outside. Therefore, some widgets, such as Containers, have different constraints depending on the parameters. Container is as large as possible by default, but given the size, the specific value is preferred. Different widgets may have different setting conditions, and their children may have different constraints. Flutter restricts each widget to a different set of constraints. The actual layout of Flutter needs to be considered comprehensively.

Classification of 2.

Many widgets are not easy to distinguish by their constraints, and are officially classified by the number of their children.

  • The layout of single child elements, including Container, Padding and other 18 types (currently on May 25, 2018, I think it will be added later, similar below);
  • Layout with multiple children elements, including Row, Column and 11 others;
  • Layout Helper, such as ListView.Builder, is more efficient in this way when there are many elements. Similar to Android RecyclerView, it has an automatic recycling mechanism. This isn’t really a category, and I think we’re going to see more of them.

2.1 the advantages and disadvantages

Container, Padding, Center, Align, Row, Column, Stack, ListView, etc.

Flutter provides nearly 30 different layout widgets, again due to its positioning of widgets (not explained here, see my previous article for more information). Compared to other mobile development platforms, we can see that Flutter has a huge number of layout widgets, which is one reason why Flutter currently has a long learning curve.

First, the advantages, unified rendering, update efficiency is higher. However, for the average developer, this doesn’t matter too much. High performance is a basic capability that a platform should provide, isn’t it something you should provide?

Say next disadvantage, master rise or very trouble, layout rise also quite egg ache. The conventional layout is fine, but when it comes to the complex layout, I think this can be achieved, and that can be achieved, and FINALLY I don’t know which can be achieved.

3. The widget explanation

The custom widgets in Flutter are inherited from the StatefulWidget or StatelessWidget (not the only ones). These two widgets are currently the most common ones. If the state of a control does not change, it is displayed directly when it is created, and does not change the color value, size, or other properties. This type of widget is generally inherited from StatelessWidget, such as Container and ScrollView. If a control needs to dynamically change or respond to some state, such as click state, color value, content area, etc., it is generally inherited from StatefulWidget, such as CheckBox, AppBar, TabBar, etc. The difference between the two types of widgets can be seen simply from their names. Both types of widgets inherit from the Widget class.

3.1 the Widget class

The Widget class is important in Flutter. There are PreferredSizeWidget, ProxyWidget, RenderObjectWidget, StatefulWidget, and StatelessWidget that inherit from the Widget class. Most of the widgets we use on a daily basis inherit from widget classes.

3.2 the State

Before we talk about statefulWidgets, let’s talk about State. State has two functions:

  1. The widget can be read synchronously when it is built;
  2. Changes may occur during the widget’s life cycle.

3.2.1 State Life cycle

The life cycle of State has four states:

  • Created: The state. initState method is called when a State object is created;
  • The initialized: when the State object is created, but not yet ready to build, the State. The didChangeDependencies at this time is called;
  • Ready: When the State object is ready to build and state.dispose is not called;
  • Defunct: state. dispose cannot be constructed after it is called.

The complete life cycle is as follows:

  • Create a State object, will call StatefulWidget. CreateState;
  • Associated with a BuildContext, it is said to be loaded (Mounted);
  • Call initState;
  • Call didChangeDependencies;
  • After the above steps, the State object is fully initialized, calling build;
  • DidUpdateWidget is called if necessary;
  • If you’re in development mode, hot load calls Reassemble;
  • If its subtree contains a State object that needs to be removed, deactivate is called.
  • Call Dispose,State object will not be constructed later;
  • When dispose is called, the State object is unmounted and cannot be remounted.

3.2.2 setState

One of the more important methods in State is setState, where the widget is updated when the State is changed. For example, by clicking on the CheckBox, you can switch between selected and unselected states by modifying the state.

Looking at the setState source code, an exception will be thrown in case of some exceptions:

  • Null is passed in;
  • In the defunct stage;
  • The Created phase is not mounted.
  • Parameter returns a Future object.

3.3 StatefulWidget and StatelessWidget

3.3.1 StatelessWidget

For StatelessWidget, the Build method is called in three cases,

  1. The widget is inserted into the tree for the first time;
  2. The parent node of the widget changes the configuration.
  3. The InheritedWidget that the widget relies on changes.

3.3.2 rainfall distribution on 10-12 StatefulWidget

There are two main categories of StatefulWidgets:

  1. Create resources in initState and dispose them in Dispose, but don’t rely on inheritedWidgets or call setState, which are basically used at the root of an app or page.
  2. Use setState or rely on inheritedWidgets, which are rebuilt many times over the business lifecycle.

4. How to lay it out

Every page design is different and the layout options for the same page are also different. I think it is unrealistic to simply say how to layout Flutter. Please refer to the official layout tutorial of Flutter.