Overview to implement a How to make the Widget Lifecycle in the flutter.
In this blog, we are going to learn about the Widget Lifecycle in the flutter. We will cover the implementation of the Widget Lifecycle in the flutter in this blog.
You may become more familiar with Flutter app development from Mobikul.
So let’s get started.
There are two types of widgets.
1.) Stateless 2.) Stateful
1.) Stateless :
A Stateless Widget cannot have states change over time. There are no data changes inside the stateless widget.
The build function only runs once inside the Widget when it is created.
So, If we want to change something on the screen, it can not reflect over the screen because it is completely stateless. It means it cannot rebuild itself when anything gets changed.
It destroys the widget completely and then creates a new instance of some different data.
2.) Stateful :
Stateful Widget changes over time. E.g., If we have some kind of counter then it will be changed over time.
The changes are done inside the setState() when we change the data inside this method, which will trigger the build function.
Stateful Widgets LifeCycle:
1.) createState():
When we build a new Stateful Widget, it immediately calls createState() right away and this override method must exist.
|
1 2 3 4 |
class MyDemoPage extends StatefulWidget { @override _MyDemoPageState createState() => new _MyDemoPageState(); } |
2.) initState():
Once the State object has been created, the first method call is initState()
It is called only once when the widget is created. It Subscribes to streams or any object that could change our widget data.
|
1 2 3 4 5 6 7 8 |
@override initState() { super.initState(); // Add listeners to this class cartItemStream.listen((data) { _updateWidget(data); }); } |
3.) didChangeDependencies():
This method calls immediately after the initState() the first time the widget is built.
|
1 2 3 4 |
@override void didChangeDependencies() { super.didChangeDependencies() } |
4.) build():
This method is to build the widget tree.
Also, it is triggered every time when we use setState() to change the data.
|
1 2 3 4 |
@override Widget build(BuildContext context, MyButtonState state) { return Container(color:Colors.red); } |
5.) didUpdateWidget(Widget oldWidget):
If the parent widget changes and has to rebuild this widget (because it needs to give it different data), but it is being rebuilt with the same runtime Type, then this method is called.
This is because Flutter is re-using the state, which is long-lived. In this case, you may want to initialize some data again, as you would in initState().
|
1 2 3 4 |
@override void didUpdateWidget(MyHomePage oldWidget) { super.didUpdateWidget(oldWidget) } |
6.) setState():
The setState() is called often from the flutter framework itself and from the developer.
It is used to notify the framework that “data has changed”
|
1 2 3 |
void updateProfile(String email) { setState(() => this.email = email); } |
7.) deactivate():
The ‘deactivate()’ is used when the State is removed from the tree.
But before the current frame change can be re-inserted into another part of the tree
|
1 2 3 4 |
@override void deactivate() { super.deactivate(); } |
8.) dispose():
The ‘dispose()’ is used when the state/widget is removed permanently.
|
1 2 3 4 5 |
@override dispose() { animationController.dispose(); // you need this super.dispose(); } |