Flow class

A widget that sizes and positions children efficiently, according to the logic in a FlowDelegate.

Flow layouts are optimized for repositioning children using transformation matrices.

The flow container is sized independently from the children by the FlowDelegate.getSize function of the delegate. The children are then sized independently given the constraints from the FlowDelegate.getConstraintsForChild function.

Rather than positioning the children during layout, the children are positioned using transformation matrices during the paint phase using the matrices from the FlowDelegate.paintChildren function. The children can be repositioned efficiently by only repainting the flow, which happens without the children being laid out again (contrast this with a Stack, which does the sizing and positioning together during layout).

The most efficient way to trigger a repaint of the flow is to supply an animation to the constructor of the FlowDelegate. The flow will listen to this animation and repaint whenever the animation ticks, avoiding both the build and layout phases of the pipeline.

Hit testing and hidden Flow widgets

The Flow widget recomputes its children's positions (as used by hit testing) during the paint phase rather than during the layout phase.

Widgets like Opacity avoid painting their children when those children would be invisible due to their opacity being zero.

Unfortunately, this means that hiding a Flow widget using an Opacity widget will cause bugs when the user attempts to interact with the hidden region, for example, by tapping it or clicking it.

Such bugs will manifest either as out-of-date geometry (taps going to different widgets than might be expected by the currently-specified FlowDelegates), or exceptions (e.g. if the last time the Flow was painted, a different set of children was specified).

To avoid this, when hiding a Flow widget with an Opacity widget (or AnimatedOpacity or similar), it is wise to also disable hit testing on the widget by using IgnorePointer. This is generally good advice anyway as hit-testing invisible widgets is often confusing for the user.

See also:

• Wrap, which provides the layout model that some other frameworks call "flow", and is otherwise unrelated to Flow.
• Stack, which arranges children relative to the edges of the container.
• CustomSingleChildLayout, which uses a delegate to control the layout of a single child.
• CustomMultiChildLayout, which uses a delegate to position multiple children.
• The catalog of layout widgets.