Flutter life cycle methods and UI widget communication

I started my career as a UX/UI- Intern at Divami Design Labs almost a year ago. Since then, I have worked with different UI development technologies such as HTML, CSS, React, Angular, etc. We, as designers, always strive for pixel-perfect UI development with zero issues. The technology used to build UI keeps changing based on the client’s preference and technology trend. 

Recently, I was assigned to a Flutter project and got an opportunity to explore the various features and concepts in it.  Flutter is natively compiled applications for web, desktop, and mobile. Most importantly, it is a single code-based. i.e we can adjust UI and business logic globally through editing the code which works for both iOS and Android. There is a new feature in Flutter known as Hot Reload which saves time in rendering the application. It does so without affecting the current state of the application. 

In this blog, I would like to share my learning in widget development in Flutter. Let’s begin…

All the UI components which we see on the screen are known as ‘Widgets’. Widgets are broadly divided into two types based on the ability of the widget to reload it at the run time.

• Stateless Widget
• Stateful Widget

Stateless Widget:

Stateless widgets cannot change their state during the runtime of the app, which means the widgets cannot be redrawn while the app is in action. Stateless widgets are immutable. In a stateless widget, the “build” method can be called only ONCE while the app is in action, which is responsible for drawing the widgets onto the device screen.

The boilerplate code for ‘Stateless Widget’ is ‘stless’.

Code:

The above code is an example of ‘Stateless Widget’ where ‘MyApp’ is a ‘StatelessWidget’ and it is overriding the build method. The build method is returning a ‘MaterialApp’ widget and this method will be called only once i.e. whenever the ‘MyApp’ will be initialized, then build will be called and the widgets will be drawn on the screen.

But if there is a change in any of the variables associated with the Widgets, then the build method will not be called and nothing will be updated on the screen because it is StatelessWidget.

Example:

Stateful Widget:

Stateful Widget can change their state multiple times and can be redrawn on to the screen any number of times while the app is in action. Stateful Widgets are mutable. Stateful Widgets are used when part of the UI changes dynamically.

The boilerplate code for ‘Stateful Widget’ is ‘stful’.

Code:

The name of the widget is again “MyApp”, but now it overrides the “createState” method, instead of the “build” method, which returns the instance of the class “_MyAppState”.

The class “_MyAppState” extends from State<> which takes “MyApp” as a template input. Now, this “_MyAppState” overrides the “build” method and returns a widget. This is where you can define the UI of the app, which is Stateful. As it is a Stateful widget you can call the build method any number of times by pressing a button which will increase the counter value by one, which will redraw the widgets on the screen.

Example:

Life Cycle:

The life cycle is based on the state and how it changes. A stateful widget has a state so we can explain the life cycle of flutter based on it. Stage of the life cycle:

• createState
• initState
• didChangeDependencies
• build
• didUpdateWidget
• setState
• deactivate
• dispose

We will have more states for creation than destruction because of the construction and reconstruction of widgets and their states.

createState:

When we create a stateful widget flutter framework will instruct to create a method createState() in override. This method will return an instance of a state associated with it.

In this life cycle example, I used ‘MyHomepage’ as my stateful class name. All widgets have bool mounted and turn into true when the ‘buildContext’ is assigned and is currently on a tree. It’ll keep that value until dispose gets called.

initState()

This is the first method called after the widget is created. It is called only once. It is used to initialize the data that can change on the widget.

didChangeDependencies:

This method is called immediately after initState() on the first time the widget is built.

build:

This method is the most important one. It is called after ‘didChangeDependencies()’. The entire tree of widgets to be rendered relays on this method. This will be called every single time the Ui needs to be rendered.

didUpdateWidget:

If the parent widget changes configuration and has to rebuild the widget. When the parent Widget made a change and needs to redraw the UI to get the oldWidget parameter and so that compare it with the current widget to do some extra logic right there. It works every time when we reload (hot reload) the app.

setState:

This is a method that is used to change the state when it is called. This is called inside a method. This method tells the Flutter framework that something has changed in its state, which causes it to rerun the build method so that the display can reflect the updated values. If we want to change without calling setState(), then the build method would not be called again, and so nothing would appear to happen.

deactivate:

This is called when the state is removed from the tree, but it might be reinserted into another part of the tree before the current frame change is finished.

dispose:

This one is very important and is called when this object and its State is removed from the tree permanently and will never build again which is the equivalent opposite of initState(). This is the one you need to unsubscribe streams, dispose of animations, etc

We have seen the life cycle states of the widget. Now we can see the passing of data from stateful/stateless widget to another.

Passing data from one widget to another

In cases in which we want to send and receive data from widget we make use of ‘Constructors’. For receiving data stateful and stateless widgets have different methods.

Stateless Widget:

For example, we will create an app that is built on a stateless widget, and on button click, we will see some text on the console. Now we will create a custom button that can be used commonly in any class.

Here the constructor is as shown below. As ‘onButtonPressed’ is a call back function we initialize as ‘VoidCallBack’

Now its time to use custom ButtonAction

When we use debugShowCheckedModeBanner: false, then we won’t see debug banner in the app screen. By default, its value is true.

The whole code looks like:

Output: When the button is clicked, we can see a Message in the console.

In the android studio console.

Stateful Widget:

Now we will create the above example by using a Stateful widget.

Output: Will be the same as the above example. 

The key difference in a stateless and stateful widget is how we pass the data. In Stateless widget we use data as,

While in the stateful widget,

The parent and child widgets might not be of the same widget types. For example, the parent widget is stateless and the child widget is stateful and vice versa.

Well, I hope this blog can help you in understanding the Flutter life cycle methods. If you are interested to view our profile, you can see them here