Flutter widgets (I): basic concepts

Photo by Randall Ruiz on Unsplash

Flutter is the brand new mobile SDK by Google designed to implement multi-platform applications. And widgets are its main building block. But… what are they exactly? When should we use them? Let’s find out!

Intro

A Flutter widget is basically a class that knows how to describe its user interface. If you come from the Android world, think of widgets as any Android component that has a layout: an activity, a fragment or even a view.

Flutter apps are just a big collection of widgets. The system uses them to represent not only straightforward visual elements (buttons, textfields…) but also more abstract components, like alignments.

As you might guess, widgets have their own lifecycle. And, as usual, it can brings us some trouble every now and then. But before getting down to it, let’s review the following basic concepts:

• the widget tree
• the widget lifecycle
• the available widget types
• the widget’s state objects
• the widget creation
• the BuildContext object

Widget tree

As said before, every Flutter application is basically a group of widgets composed together. Keep in mind that widgets are used to represent any aspect of the program, such as:

• layout components to organize the contents displayed on screen (Grid, Container, Row, Column…)
• structural views (Text, Image, Icon, Button…)
• style elements (TextStyle, Theme…)
• animation and transformation instances (FadeIn, FadeOut, Matrix…)
• position and spacing objects (Alignment, Padding, Margin…)

All these widgets get arranged inside the widget collection by developing a tree structure: every element (node) can specify its child (or children) so a parent-child relation is established between them.

In fact, the widget tree in Flutter is quite similar to the DOM element in web development, but its management is not as expensive in terms of performance.

Composition

Unlike other frameworks or programming languages, Flutter promotes the usage of composition over inheritance. When creating a new UI element, instead of subtyping an existing one, we have to wrap it inside another.

For instance, suppose we want a screen with a primary action button displaying some text. What will we find if we explore the widget tree…? Probably something like this:

So we have a container that is the root of the subtree and it contains some button. At the same time, the button declares a child for the string literal displayed on it. And the text has a text style object inside to customize its color and font. And… it goes on and on until we hit a leaf node that has no children.

“Flutter uses composition to create the widget tree”

Widget lifecycle

In general, when we talk about the lifecycle of a widget, we are referring to the iterative process of:

1. creating the widget
   
2. updating its visual interface in order to refresh the contents shown

This process is performed many times by the Flutter system, and every time we receive notifications (via callback method invocations) that allow us to hook custom behaviour.

Widget types

In Flutter, widgets can be either stateless or stateful. Although Flutter includes other widget types, these two are the most frequently used by far.

Stateless widgets are “dummy” views which display some static values, like texts or icons, for instance. Once created, their UI will remain the same. Stateless components are managed by the system, which creates and destroys them when required.

On the other hand, stateful widgets are “smart” views that display dynamic contents (values that may change over time). Stateful elements have more control over their lifecycle: they are still managed by the system, but with the ability to request an update of their view too (when displayed content changes).

“The Flutter system manages both stateless and stateful widget lifecycles, but stateful widgets have more control over it”

State objects

Stateful widgets always have a state object that stores the data displayed by the widget. These objects persist after configuration changes, so they are alive even if the associated widget is modified.

If you come from the Android world, a viewmodel would be a proper analogy, but with a slight difference: while Android viewmodels are recommended (but not mandatory), widget states are enforced by the Flutter system.

“State objects are mantained after configuration changes”

Widget creation

Widgets are always created through the execution of the build() method, which returns the new visual component that will be added to the tree:

Widget build(BuildContext cntxt) {
   //XXX: return a red box
   return Container(
      color: Colors.red,
      child: ...
   );
}

As you can see, the only parameter received by this method is a BuildContext instance. Why do we need a context when building a new element…?

BuildContext

Since widgets are scattered all along the widget the tree, the Flutter system needs a way to pinpoint a specific element. For that purpose, it uses instances of BuildContext class. A build context is just that: a reference to the particular position of some widget inside the tree.

Wrapping up

So… if you want to give Flutter a try, keep in mind the following ideas:

• Flutter represents almost any aspect of our application using widgets
• Widget are just classes that can describe some aspect of the user interface. They can display either static or dynamic data
• Flutter uses composition to nest elements inside other elements
• All the widgets put together create a widget tree
• The BuildContext class allow us to locate any element inside the tree

In the next article, we will focus on the widget lifecycle. Until then, check Dartpad and the following code samples to start playing around with it:

• Stateful widgets
• Stateless widgets

Write you next time!