Это имеет значение для mixin
s (и из-за этого также для вас )
Это парадигма , в рамках Flutter для вызова метода супер при переопределении методов жизненного цикла в State
. Вот почему даже deactivate
есть mustCallSuper
аннотация .
Кроме того , некоторые mixin
ожидают, что вы вызовите супер методы этих методов жизненного цикла в определенной точке функции.
Это означает , что вы должны следовать документации и вызов super.dispose
в конце вашего dispose
метода , потому что mixin
с на State
в рамках ожидать , что это так.
Например: TickerProviderStateMixin
и подтвердить в конце:SingleTickerProviderStateMixin
super.dispose
Все тикеры должны быть удалены перед вызовом super.dispose ().
Другой пример: AutomaticKeepAliveMixin
выполняет логику в initState
и dispose
.
Вывод
Начните initState
сsuper.initState
и заканчивайте dispose
с,super.dispose
если вы хотите быть на легкой и безопасной стороне, добавляя mixin
s к своему State
.
Кроме того, следуйте документации по другим методам жизненного цикла (любой метод, в котором вы перезаписываете State
), потому что фреймворк будет ожидать, что вы вызовете супер методы, как описано в документации.
Таким образом, вот что вы должны сделать:
void initState() {
super.initState();
//DO OTHER STUFF
}
Тем не менее, это не имеет значения для State
, что я объясню ниже, и даже для миксинов, это имеет значение только для утверждений, исходя из того, что я могу найти - так что это не повлияет на ваше производственное приложение.
Это не имеет значения для State
Я думаю , что предыдущие два ответа от Пабло Баррера и CopsOnRoad являются вводящие в заблуждение , потому что правда в том, что это на самом деле не имеет значения , и вам не нужно далеко ходить .
Единственные действия, которые super.initState
и super.dispose
выполняются в самом State
классе, - это утверждения, и так как assert
-условия оцениваются только в режиме отладки , это не имеет значения, когда вы создаете свое приложение, то есть в производственном режиме.
Далее я расскажу вам, что super.initState
и как super.dispose
делать State
, и это весь код, который будет выполняться, когда у вас нет дополнительных миксинов.
initState
Давайте посмотрим, какой код выполняется в super.initState
первую очередь ( источник ):
@protected
@mustCallSuper
void initState() {
assert(_debugLifecycleState == _StateLifecycle.created);
}
Как видите, существует только утверждение жизненного цикла, и его цель - убедиться, что ваш виджет работает правильно. Так что, пока вы звоните super.initState
куда-то по своему initState
, вы увидите, AssertionError
если ваш виджет работает не так, как задумано. Не имеет значения, предприняли ли вы какое-либо предыдущее действие, потому что assert
оно предназначено только для сообщения о том, что что-то в вашем коде в любом случае неверно, и вы увидите это, даже если вы вызовете super.initState
в самом конце вашего метода.
dispose
dispose
Метод аналогичен ( источник ):
@protected
@mustCallSuper
void dispose() {
assert(_debugLifecycleState == _StateLifecycle.ready);
assert(() {
_debugLifecycleState = _StateLifecycle.defunct;
return true;
}());
}
Как видите, он также содержит только утверждения, которые обрабатывают проверку жизненного цикла отладки . Второй assert
здесь хороший прием, поскольку он гарантирует, что значение _debugLifecycleState
изменяется только в режиме отладки (поскольку assert
-условия выполняются только в режиме отладки).
Это означает, что до тех пор, пока вы вызываете super.dispose
где-то в своем собственном методе, вы не потеряете никакой ценности без добавления дополнительных функций в миксины.