A Simplistic Review of the Lifecycle of Flutter Widgets

This is a concept that I couldn’t wrap my head around for a while, so I searched and tried to explain it in the simplest way I could, and I guess you’re probably trying to do the same If so, you’re at the right place. Let's get into it.

Stateless and Stateful widget

Stateless widget

These types of widgets don’t change state after they have been created. They are immutable and they are mostly used for the UI to show information. It doesn’t update its state, so once they have been created, they can’t be changed. In this type of widget, the build context is called only once.

The way I understood stateless widgets was that I thought of them as building blocks, and we all know building blocks. Once a building block has been stacked on top of another, it can’t be changed unless it is destroyed and stacked again, but this time differently.

When the portion of the user interface we are describing is independent of any other widgets, stateless widgets can be helpful. The widget types text, icons, icon buttons, and raised buttons are examples of stateless widgets.

Stateful widget

Well, these widgets are different from the stateless widgets. They are dynamic in the way that they can change their state repeatedly and that they can be redrawn again at any time.

Stateful widgets can be combined, and the state of the widget can be tracked using a state object. The state object keeps track of variables such as the configuration of the widgets and the properties of the widget; these variables in the widget can be changed using a setstate, which then updates the app.

The state object lives longer, so it has more lifecycle methods. Just as humans pass through different stages of life and die, so do stateful widgets, but one of the difference is we could tap into those stages in the widget if we wanted different things to happen at various times. This is like going into a certain stage in your life and making a few changes.

Widget lifecycle methods

The methods are listed to show what happens to a widget from the time it is created to the time it is discarded.

• initState
• Build
• didChangeDependencies
• didUpdateWidget
• setState
• deactivate
• Dispose

initState

This is the first method that is called when we create a stateful widget and it is inserted into the widget tree. This method can be used to control HTTP queries, subscribe to streams, or any other object that we know will change the widget's data.

The syntax looks like this;

@override
 void initState() {
//TODO: implement initState
   super.initState();
 }

From the documentation, the super.initState should be at the beginning of the call.

Build

This is the second point in the lifecycle and this method is called after the init state, It describes the area of the user interface that the widget is meant to represent, and it can be called in different situations, like calling initState. calling didUpdateWidget. receiving a call to setState or when the dependency of the state object changes, it can also used for calling deactivate and then reinserting the state object into the tree at another location.

The syntax looks like this;

@override
 Widget build(BuildContext context) {
   return Scaffold();
 }

didChangeDependencies

This comes after the initState in the lifecycle, and it will be triggered if a widget's dependent object changes.

The build method is always called after this method and the framework would call this method to inform it of the change, and it can be called multiple times.

The syntax like this;

@override
 void didChangeDependencies() {
//TODO: implement didChangeDependencies
   super.didChangeDependencies();
 }

The documentation doesn’t state whether the call should come after or before the super.didChangeDependencies

didUpdateWidget

The didUpdateWidget is called if the parent widget needs to rebuild the widget because it changed its configuration. An example is when a variable is passed down the constructor and then the variable is updated. The framework provides the old widget as a comparison point between it and the new widget.The build() method will then be called by Flutter and If you need to compare the new widget to the previous one, use this method.

Any additional calls to setState after using this method are unnecessary because Flutter always calls build().

The syntax looks like this;

@override
void didUpdateWidget(ProductSquare oldWidget) {
//TODO: implement didUpdateWidget
   super.didUpdateWidget(oldWidget);
}

The documentation states that the super.didUpdateWidget should also be at the beginning of the call

deactivate

This method is called when the widget is removed from the widget tree, but it can be reinserted before the current frame’s changes are finished, when the state is moved from one point in a tree to another.

This should not be mistaken for the dispose method, as the deactivate method can remove a widget and insert it later in the widget tree, but the dispose method removes it entirely.

The syntax looks like this;

@override
 void deactivate() {
//TODO: implement deactivate
   super.deactivate();
 }

According to the documentation, the super.deactivate comes after the call

Dispose

Dispose method is called when the state object has been removed entirely from the tree. It is like the opposite of initState; you can cancel all animations, streams, etc. with this method.

This function is called when an object is permanently removed from a tree. You should set all of your dispose logic here. This function is called by the framework when this state object won't ever be rebuilt. The State object is regarded as unmounted and the mounted attribute is false when the framework calls dispose.

The syntax looks like this;

@override
 void dispose() {
//TODO: implement dispose
   super.dispose();
 }

This is the same as the deactivate where the super.dispose comes last.

NOTABLE MENTIONS

constructor

During the creation of a stateful widget, Flutter executes the constructor function and then calls the createState() method. When we examine the stateful widget, the constructor function is executed first. But the lifecycle of the stateful widget's State object begins with the call to the createState() method.

create

The Framework instantly calls createState when told to build a StatefulWidget () and State objects are created with this method. All the mutable state for this widget is contained in this object. A StatefulWidget must use this method, although this step is not designated as an actual stage in the lifecycle, it is crucial to understand what is occurring behind the scenes.

The syntax looks like this;

class MyHomePage extends StatefulWidget {
 @override
 _MyHomePageState createState() => _MyHomePageState();
}

The difference between stateless and stateful

The stateless widget only updates when it is initialized while the stateless widget changes dynamically, RaisedButtons, Text, icons and can be implemented in the stateless widget, checkboxes, radio buttons, and sliders can be implemented in the stateful widget.

Stateless widget does not have a setState(). It will be rendered once and will not update itself but stateful widget has an internal setState() and can re-render if the input data changes, stateless widget is a Static widget while stateful widgets are dynamic, the stateless widget can’t update during runtime, that isn’t the case for the stateless widget as it can update during runtime based on user action

CONCLUSION

This topic has been one of the frequently asked questions by recruiters during job interviews and In this article, we have looked at the different lifecycles in a flutter widget and explained them. You can also try to use these methods in building your applications and In your flutter project, I hope this article gives you enough information about the widget lifecycle.

We are going to look into flutter widgets more in our future articles and try to explain them in digestible chunks for you to understand.
If there’s any thing I missed or you feel should be added to this article please do well to leave a comment below. Thanks for reading.😊