StatefulWidget Lifecycle - Flutter by Example
StatefulWidget Lifecycle - Flutter by Example
Flutter by Example
StatefulWidget lifecycle
on Friday, 24th of July, 2020
When a Flutter builds a StatefulWidget, it creates a State object. This object is where all the mutable state for that widget is
held.
2. The data can't be read synchronously when the widget is built. (All state must be established by the time the build
method is called).
createState()
mounted == true
initState()
didChangeDependencies()
build()
didUpdateWidget()
setState()
deactivate()
dispose()
mounted == false
The tldr version is that State objects are long lived, but StatefulWidgets (and all Widget subclasses) are thrown away and rebuilt
whenever configuration changes. It's very inexpensive ie cheap for Flutter to rebuild a mutable widget.
As State isn't blown away on every rebuild, it avoids expensive computations, and gets at the states property, getters, setters
etc everytime something is rebuilt frame by frame.
Important is that this is what allows Flutter animations to exist. As State isn't thrown away, it can constantly be rebuilding it's
Widget in response to data changes, and when required, if any.
https://flutterbyexample.com/lesson/stateful-widget-lifecycle 1/5
10/30/23, 2:10 AM StatefulWidget lifecycle | Flutter by Example
1. createState()
When Flutter is instructed to build a StatefulWidget, it immediately calls createState(). This method must exist. A StatefulWidget
rarely needs to be more complicated than this.
2. mounted is true
When createState creates the state class, a buildContext is assigned to that state.
A BuildContext is, overly simplified, the place in the widget tree in which this widget is placed. Here's a longer explanation.
All widgets have a bool this.mounted property. It is turns true when the buildContext is assigned. It is an error to call setState
when a widget is unmounted.
tip: This property is useful when a method on your state calls setState() but it isn't clear when or how often that method will
be called. Perhaps its being called in response to a stream updating. You can use if (mounted) {... to make sure the State
exists before calling setState().
3. initState()
This is the first method called when the widget is created (after the class constructor, of course.)
initState is called once and only once. It must also call super.initState().
1. Initialize data that relies on the specific BuildContext for the created instance of the widget.
3. Subscribe to Streams, ChangeNotifiers, or any other object that could change the data on this widget.
@override
initState() {
super.initState();
// Add listeners to this class
cartItemStream.listen((data) {
_updateWidget(data);
});
}
4. didChangeDependencies()
The didChangeDependencies method is called immediately after initState on the first time the widget is built.
It will also be called whenever an object that this widget depends on data from is called. For example, if it relies on an
InheritedWidget, which updates.
https://flutterbyexample.com/lesson/stateful-widget-lifecycle 2/5
10/30/23, 2:10 AM StatefulWidget lifecycle | Flutter by Example
build is always called after didChangeDependencies is called, so this is rarely needed. However, this method is the first change
you have to call BuildContext.inheritFromWidgetOfExactType. This essentially would make this State 'listen' to changes on a
Widget it's inheriting data from.
The docs also suggest that it could be useful if you need to do network calls (or any other expensive action) when an
InheritedWidget updates.
5. build()
This method is called often (think fps + render). It is a required, @override and must return a Widget.
Remember that in Flutter all gui is a widget with a child or children, even 'Padding', 'Center'.
6. didUpdateWidget(Widget oldWidget)
didUpdateWidget() is called if the parent widget changes and has to rebuild this widget (because it needs to give it different
data), but it's being rebuilt with the same runtimeType, then this method is called.
This is because Flutter is re-using the state, which is long lived. In this case, required is to initialize some data again, as one
would in initState().
If the state's build() method relies on a Stream or other object that can change, unsubscribe from the old object and re-
subscribe to the new instance in didUpdateWidget().
tip: This method is basically the replacement for 'initState()' if it is expected the Widget associated with the widgets's state
nrrds to to be rebuilt!
Flutter always called build() after this, so any subsequent further calls to setState is redundant.
@override
void didUpdateWidget(Widget oldWidget) {
if (oldWidget.importantProperty != widget.importantProperty) {
_init();
}
}
7. setState()
The 'setState()' method is called often from the Flutter framework itself and from the developer.
It is used to notify the framework that "data has changed", and the widget at this build context should be rebuilt.
setState() takes a callback which cannot be async. It is for this reason it can be called often as required, because repainting
is cheap :-)
8. deactivate()
https://flutterbyexample.com/lesson/stateful-widget-lifecycle 3/5
10/30/23, 2:10 AM StatefulWidget lifecycle | Flutter by Example
'deactivate()' is called when State is removed from the tree, but it might be reinserted before the current frame change is
finished. This method exists basically because State objects can be moved from one point in a tree to another.
9. dispose()
This method is where to unsubscribe and cancel all animations, streams, etc.
The state object can never remount, and an error is thrown is setState() is called.
https://flutterbyexample.com/lesson/stateful-widget-lifecycle 4/5
10/30/23, 2:10 AM StatefulWidget lifecycle | Flutter by Example
https://flutterbyexample.com/lesson/stateful-widget-lifecycle 5/5