Extract from framework.dart
/// [State] objects have the following lifecycle:
///
/// * The framework creates a [State] object by calling
/// [StatefulWidget.createState].
/// * The newly created [State] object is associated with a [BuildContext].
/// This association is permanent: the [State] object will never change its
/// [BuildContext]. However, the [BuildContext] itself can be moved around
/// the tree along with its subtree. At this point, the [State] object is
/// considered [mounted].
/// * The framework calls [initState]. Subclasses of [State] should override
/// [initState] to perform one-time initialization that depends on the
/// [BuildContext] or the widget, which are available as the [context] and
/// [widget] properties, respectively, when the [initState] method is
/// called.
Above is a extract from framework.dart file which explains the lifecycle of a state object.
In this it says that initstate() can be used to initialize context. But when i try to run the code given below, It gives an error which says that when initstate() is called the context is not available, which to me seems is in contradiction to what the framework.dart says in the lifecycle section. Can anyone explain this.
Code
#override
void initState() {
// TODO: implement initState
super.initState();
if (!_initial) {
final arguments =
ModalRoute.of(context)!.settings.arguments as Map<String, dynamic>;
categoryTitle = arguments['item'];
categoryId = arguments['id'];
categoryMeals = dummyMeals.where((meal) {
return meal.categories.contains(categoryId);
}).toList();
}
_initial = true;
}
Error Message
The following assertion was thrown building Builder:
dependOnInheritedWidgetOfExactType<_ModalScopeStatus>() or dependOnInheritedElement() was called before _MealScreenState.initState() completed.
When an inherited widget changes, for example if the value of Theme.of() changes, its dependent widgets are rebuilt. If the dependent widget's reference to the inherited widget is in a constructor or an initState() method, then the rebuilt dependent widget will not reflect the changes in the inherited widget.
Typically references to inherited widgets should occur in widget build() methods. Alternatively, initialization based on inherited widgets can be placed in the didChangeDependencies method, which is called after initState and whenever the dependencies change thereafter.
You should use this
WidgetsBinding.instance!.addPostFrameCallback((timeStamp) {
--- your code here ---
});
in your initState();
You are facing that issue because you are trying to use a context that hasn't finished yet to build. The addPostFrameCallback execute your code after all the Widget is built.
initState runs once before the widget is inserted into the widget tree. The context is available at that time, but the problem with your code is that in initState you are relying on something that can change after the widget is inserted.
The solution is to move this logic into an overridden didChangeDependencies method, which will be called not only once, but every time the dependencies changed:
#override
void didChangeDependencies() {
super.didChangeDependencies();
// put your logic from initState here
}
See this SO question for example for a detailed explanation.
Related
Using Flutter, I display a list of elements in an app.
I have a StatefulWidget (ObjectList) that holds a list of items in its State (ObjectListState).
The state has a method (_populateList) to update the list of items.
I want the list to be updated when a method (updateList) is called on the widget.
To achieve this, I save a reference (_state) to the state in the widget. The value is set in createState. Then the method on the state can be called from the widget itself.
class ObjectList extends StatefulWidget {
const ObjectList({super.key});
static late ObjectListState _state;
#override
State<ObjectList> createState() {
_state = ObjectListState();
return _state;
}
void updateList() {
_state._populateList();
}
}
class ObjectListState extends State<ObjectList> {
List<Object>? objects;
void _populateList() {
setState(() {
// objects = API().getObjects();
});
}
// ... return ListView in build
}
The problem is that this raises a no_logic_in_create_state warning. Since I'm not "passing data to State objects" I assume this is fine, but I would still like to avoid the warning.
Is there a way to do any of these?
Saving the reference to the state without violating no_logic_in_create_state.
Accessing the state from the widget, without saving the reference.
Calling the method of the state from the outside without going through the widget.
It make no sense to put the updateList() method in the widget. You will not be able to call it anyway. Widgets are part of a widget tree, and you do not store or use a reference to them (unlike in other frameworks, such as Qt).
To update information in a widget, use a StreamBuilder widget and create the widget to be updated in the build function, passing the updated list to as a parameter to the widget.
Then, you store the list inside the widget. Possibly this may then be implemented as a stateless widget.
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();
}
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.
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().
As you could see in the classes from the framework, you should do everything after the widget is initialized, meaning after super.initState().
I case of dispose would be logically in the other way, first do everything and then call super.dispose().
#override
void initState() {
super.initState();
// DO STUFF
}
#override
void dispose() {
// DO STUFF
super.dispose();
}
initState called up by default whenever a new stateful widget is added into a widget tree.
Now the super.initState performs the default implementation of the base class of your widget.If you call anything before super.initState that depends on the base class then this might cause problem.
That's why it's recommended that you call initState in this fashion:
#override
void initState() {
super.initState();
// DO STUFF
}
I was trying to make my function works with a Timer to fetch a list of actions from Database and display them without leaving the screen and re-enter again.
I tried the following :
void initState() {
super.initState();
Timer.periodic(timeDelay, (Timer t) => fetchFournisseurs());
}
It's working now , but my debug console is showing some infos :
State.setState.<anonymous closure> (package:flutter/src/widgets/fr<…>
[VERBOSE-2:ui_dart_state.cc(209)] Unhandled Exception: setState() called after dispose(): _listeDocumentState#c0f9f(lifecycle state: defunct, not mounted)
This error happens if you call setState() on a State object for a widget that no longer appears in the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error can occur when code calls setState() from a timer or an animation callback.
The preferred solution is to cancel the timer or stop listening to the animation in the dispose() callback. Another solution is to check the "mounted" property of this object before calling setState() to ensure the object is still in the tree.
This error might indicate a memory leak if setState() is being called because another object is retaining a reference to this State object after it has been removed from the tree. To avoid memory leaks, consider breaking the reference to this object during dispose().
Is there a better way to make it and prevent memory leak or anything bad ?
Thank you.
All of the information is in the error message itself.
This error happens if you call setState() on a State object for a widget that no longer appears in the widget tree (e.g., whose parent widget no longer includes the widget in its build).
For example if you navigate to a page containing this widget, and then close that page, the widget would no longer be in the widget tree, but the Timer you created is still running periodically.
This error can occur when code calls setState() from a timer or an animation callback.
Presumably fetchFournisseurs is calling setState.
The preferred solution is to cancel the timer or stop listening to the animation in the dispose() callback.
In other words your state class should do something along these lines.
class _ExampleState extends State<Example> {
final Duration timeDelay = ...;
// Create a variable to hold the timer.
Timer? _timer;
#override
void initState() {
super.initState();
// Assign timer to the variable.
_timer = Timer.periodic(timeDelay, (Timer t) => fetchFournisseurs());
}
#override
void dispose() {
// Cancel the timer in the dispose() callback.
_timer?.cancel();
super.dispose();
}
void fetchFournisseurs() {
// presumably fetchFournisseurs calls setState at some point.
setState(() {
...
});
}
#override
Widget build(BuildContext context) {
return ...;
}
}
Another solution is to check the "mounted" property of this object before calling setState() to ensure the object is still in the tree.
Which means to do the following.
void fetchFournisseurs() {
// check if the widget is mounted before proceeding
if (!mounted) return;
setState(() {
...
});
}
This error might indicate a memory leak if setState() is being called because another object is retaining a reference to this State object after it has been removed from the tree. To avoid memory leaks, consider breaking the reference to this object during dispose().
Another reminder to cancel the Timer in dispose to avoid memory leaks.
I have a StreamBuilder that I want to be able to pause and unpause and, since StreamBuilder doesn't expose it's underlying StreamSubscription, I have to create a proxy stream to forward the source stream's elements while exposing a StreamSubscription that I can pause and unpause. This forces me to convert my stateless widget into a stateful widget so I have access to dispose and can close it's StreamController.
I'm following the didUpdateWidget documentation's instructions:
In initState, subscribe to the object.
In didUpdateWidget unsubscribe from the old object and subscribe to the new one if the updated widget configuration requires replacing the object.
In dispose, unsubscribe from the object.
I need to replace the Stream whenever the user types in a new search query. My stateful widget is re-constructed within a ChangeNotifier whenever a new stream is received.
Here's the relevant part of my stateful widget:
final Stream<List<Entry>> _entryStream;
StreamController<List<Entry>> _entryStreamController;
StreamSubscription<List<Entry>> _entryStreamSubscription;
_EntryListState(this._entryStream);
void initStream() {
_entryStreamController?.close();
_entryStreamController = StreamController();
_entryStreamSubscription = _entryStream.listen((event) {
_entryStreamController.add(event);
}
)..onDone(() => _entryStreamController.close());
}
#override
void initState() {
initStream();
super.initState();
}
#override
void dispose() {
_entryStreamController?.close();
super.dispose();
}
#override
void didUpdateWidget(EntryList oldEntryList) {
// Initialize the stream only if it has changed
if (oldEntryList._entryStream != _entryStream) initStream();
super.didUpdateWidget(oldEntryList);
}
This is the line throwing the BadState error:
_entryStreamSubscription = _entryStream.listen((event) {
_entryStreamController.add(event);
}
And here is where my widget is being constructed:
child: Consumer<SearchStringModel>(
builder: (context, searchStringModel, child) {
print('rebuilding with: ${searchStringModel.searchString}');
var entryStream = _getEntries(searchStringModel.searchString);
return EntryList(entryStream);
}
),
I don't think I understand didUpdateWidget in particular and suspect that's where the two issues (bad state, and not updating) are coming from? I'm also re-constructed the stateful widget instead of just modifying its state which is a little confusing, but the widget is intended to act as a stateless widget for all intents and purposes so it'd be a pain to update it to update state instead of reconstructing. Any advice?
I had not read the "didUpdateWidget" documentation closely enough. This is the key paragraph:
/// If the parent widget rebuilds and request that this location in the tree
/// update to display a new widget with the same [runtimeType] and
/// [Widget.key], the framework will update the [widget] property of this
/// [State] object to refer to the new widget and then call this method
/// with the previous widget as an argument.
In my consumer, I'm rebuilding with a new EntryList. As the above paragraph describes, the framework will then call didUpdateWidget on the same state object (as opposed to a new one). In order to check whether or not the configuration has changed and, if it has, to access the new configuration, I need to access the widget property of my state object. With this in mind, here is my new implementation of didUpdateWidget:
#override
void didUpdateWidget(EntryList oldEntryList) {
super.didUpdateWidget(oldEntryList);
// Initialize the stream only if it has changed
if (widget._entryStream != _entryStream) {
_entryStream = widget._entryStream;
initStream();
}
}
Note that I am now checking widet._entryStream and then setting the state's _entryStream to it if it's changed.
Hopefully someone else running into a similar problem will be helped by this!
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();
}
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.
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().
As you could see in the classes from the framework, you should do everything after the widget is initialized, meaning after super.initState().
I case of dispose would be logically in the other way, first do everything and then call super.dispose().
#override
void initState() {
super.initState();
// DO STUFF
}
#override
void dispose() {
// DO STUFF
super.dispose();
}
initState called up by default whenever a new stateful widget is added into a widget tree.
Now the super.initState performs the default implementation of the base class of your widget.If you call anything before super.initState that depends on the base class then this might cause problem.
That's why it's recommended that you call initState in this fashion:
#override
void initState() {
super.initState();
// DO STUFF
}