Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should I call super.initState at the end or at the beginning?

Tags:

flutter

dart

I am confused as to where to call the super.initSate() in Flutter? In some code examples, it's called at the beginning and in others at the end. Is there a difference?

I have tried to google this but haven't found any explanation on the position of this function call.

Which one is correct?

void initState() {   super.initState();       //DO OTHER STUFF } 

or

void initState() {       //DO OTHER STUFF   super.initState();     } 
like image 843
K Vij Avatar asked Oct 15 '19 17:10

K Vij


People also ask

Is initState called before build flutter?

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.

What does Super initState () do?

initState In Flutter? initState() is a method that is called once when the Stateful Widget is inserted in the widget tree. We generally override this method if we need to do some sort of initialization work like registering a listener because, unlike build(), this method is called once.

How do you call an initState method in flutter?

In Flutter this can be done using a stateful widget and calling your code in the initState function. What if you want to call it from a stateless widget? Well, that's possible too. Use a stateful widget as a your root widget that you can provide a callback function too to execute your startup logic.


1 Answers

It does matter for mixins (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 mixins 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 mixins 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 mixins 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.

like image 144
creativecreatorormaybenot Avatar answered Sep 24 '22 14:09

creativecreatorormaybenot