Should I call super.initState at the end or at the beginning?
It does matter for mixin
s (and because of that for you as well)
It is a paradigm in the Flutter framework to call the super method when overriding lifecycle methods in a State
. This is why even deactivate
has a mustCallSuper
annotation.
Additionally, some mixin
s expect that you call the super methods of those lifecycle methods at a particular point in the function.
This means that you should follow the documentation and call super.dispose
at the end of your dispose
method because mixin
s on State
in the framework expect that this is the case.
For example: TickerProviderStateMixin
and SingleTickerProviderStateMixin
assert super.dispose
at the end:
All Tickers must [..] be disposed before calling super.dispose().
Another example: AutomaticKeepAliveMixin
executes logic in initState
and dispose
.
Conclusion
Start your initState
with super.initState
and end your dispose
with super.dispose
if you want to be on the easy and safe side adding mixin
s to your State
.
Furthermore, follow the documentation for other lifecycle methods (any method you overwrite in State
) because the framework will expect that you call the super methods as described in the documentation.
Thus, the following is what you should do:
@override
void initState() {
super.initState();
// DO YOUR STUFF
}
@override
void dispose() {
// DO YOUR STUFF
super.dispose();
}
However, it does not really matter for State
, which I will explain in the following and even for mixins, it only matters for assertions judging from what I could find - so it would not affect your production app.
It does not matter for State
I think that the previous two answers from Pablo Barrera and CopsOnRoad are misleading because the truth of the matter is that it really does not matter and you do not need to look far.
The only actions that super.initState
and super.dispose
take in the State
class itself are assertions and since assert
-statements are only evaluated in debug mode, it does not matter at all once build your app, i.e. in production mode.
In the following, I will guide you through what super.initState
and super.dispose
do in State
, which is all the code that will be executed when you have no additional mixins.
initState
Let us look exactly what code is executed in super.initState
first (source):
@protected
@mustCallSuper
void initState() {
assert(_debugLifecycleState == _StateLifecycle.created);
}
As you can see, there is only a lifecycle assertion and the purpose of it is to ensure that your widget works correctly. So as long as you call super.initState
somewhere in your own initState
, you will see an AssertionError
if your widget is not working as intended. It does not matter if you took some prior action because the assert
is only meant to report that something in your code is wrong anyway and you will see that even if you call super.initState
at the very end of your method.
dispose
The dispose
method is analogous (source):
@protected
@mustCallSuper
void dispose() {
assert(_debugLifecycleState == _StateLifecycle.ready);
assert(() {
_debugLifecycleState = _StateLifecycle.defunct;
return true;
}());
}
As you can see, it also only contains assertions that handle debug lifecycle checking. The second assert
here is a nice trick because it ensures that the _debugLifecycleState
is only changed in debug mode (as assert
-statements are only executed in debug mode).
This means that as long as you call super.dispose
somewhere in your own method, you will not lose any value without mixins adding additional functionality.
super.initState()
should always be the first line in your initState
method.
From docs:
initState(): If you override this, make sure your method starts with a call to super.initState().