I noticed that the build method gets called often in a flutter app.
I know that if the states of the page change in a statefulWidget, the build method gets triggered. But I also noticed that the build method is called even if nothing is changed in the app.
Considering the case where you leave the app to itself, is it normal for the build method to get called frequently? If so, why and how often?
Why
The build method is called any time you call setState, your widget's dependencies update, or any of the parent widgets are rebuilt (when setState is called inside of those).
Your widget will depend on any InheritedWidget you use, e.g. Theme.of(context), MediaQuery.of(context) etc.
This means that if the theme changes for example or the screen orientation swaps, your widget will also be rebuilt.
When you use widgets like MaterialApp, Scaffold etc. that are provided by the framework, your widget will be rebuilt a lot because these parent widgets depend on many InheritedWidget's and then are rebuilt, which causes your widget to be rebuilt as well.
How often
There is no number for how many rebuilds are "normal" as this completely depends on your tree size and most importantly widgets are in that tree. If you were to run runApp(Container()), there would be no rebuilds.
Just keep in mind that all of these rebuilds probably have a good reason to occur and Flutter is built for this, so you do not need to worry about this.
The only point you should start worrying is when you have constant rebuilds that are probably caused by some builder (which calls setState internally) you are using incorrectly.
Exactly when
The documentation lists all specific cases when rebuilds can occur:
After calling initState.
After calling didUpdateWidget.
After receiving a call to setState.
After a dependency of this State object changes (e.g., an InheritedWidget referenced by the previous build changes).
After calling deactivate and then reinserting the State object into the tree at another location.
Rebuilds from parent widgets
If you want to understand how InheritedWidget works, see this answer. It also touches when a rebuild in a parent widget causes the subtree to rebuild.
After calling initState.
After calling didUpdateWidget.
After receiving a call to setState.
After a dependency of this State object changes (e.g., an InheritedWidget referenced by the previous build changes).
After calling deactivate and then reinserting the State object into the tree at another location.
Read this for more info https://api.flutter.dev/flutter/widgets/State/build.html
Related
I'm utterly confused regarding the question of state management in Flutter.
So far I have read that the states of widgets have to be nested as deep in the tree as possible (or rather as close to the affected widget as possible) for better performance.
But what if such a nested state widget (InheritedWidget for example) has another state widget somewhere above it? Does the state widget at the lower level not loose it's state when the state widget higher in the tree requests rebuild for all of its descendants?
With this line of thought have I came to the conclusion, that state widgets just have to be at the root in the end, but I guess I'm wrong somehow.
The first part of your question is correct -
If a widget's state changes, this might require all its children to redraw.
But this is precisely why it is important to nest state as deep down in the widget tree as possible!
Assume the contrary, that all state information is stored at the root of the widget tree, at the very top.
Now if any information changes, no matter how small, it will lead to a complete traversal of the widget tree, rebuilding everything in the worst case.
And aside from the tree traversal, your application will also become very memory intensive. If all state is stored at the root, flutter can never tell when it is okay to release some information from memory. If the user leaves some views and the views are dismissed from memory, the information for them will still be stored at the top. And the only way to check wether that information is still needed would be to once again check the whole tree - very expensive!
All of this can be mitigated by putting your state as close as possible to the widget that will consume it. Because then
If the state changes, only a small subtree of the whole widget tree has to be traversed - This is fast.
If a widget is dismissed, flutter can also release all of the state information that has been stored for it. This frees memory.
yes ! every state widget has its own state and they are all independent. if the state of widget X is updated, only widget X will be updated
let suppose that you have an application that sows a family tree. in widget A you get the gradfather from an API, when you click on it you will be redirected to widget B where you can find his childrens, when you click on one of his childrens you go to widget C which shows the childrens of the selected father in widget B, now let's supposse that you want to add one children to this father.
you call the add-children endpoint. the problem here is that widget A will not be updated.
one solution to this, and to understand the state tree logic, is to pass a functionthat updates widget A from widget A to widget B and pass it from widget B to widget C and call it when an update happens either on widget B or C or even on A so widget A gets updated and you got the updated family tree in widget A
So basically flutter have it's own state management that is called setState(() {}) itu will update the state of the screen where setState is called if i have a button class widget in it's own file if i press the button i want to change the button name to something else so the setState will update the state or variables in the button class/widget.
Now how if the button wants to update a state/variables in the different class but in same screen? Since setState only update it's own class, so you to give the button onTap property with function constructer like this
final Function onButtonTap;
then put it on onTap like
onTap:() {
widget.onButtonTap();
}
Then in the screen where you want to update the state just call onButtonTap then use setState there
I want to use InheritedWidget to access and change its data from anywhere in application.
I've read many articles about InheritedWidget, but I do not understand one of its behaviors.
Here it says that only widgets that are using InheritedWidget get rebuilt when data changes(which is exactly what I want).
But here it says that InheritedWidget is immutable and its data only changes when it is rebuilt itself!
So doesn't this make the whole widget tree below the InheritedWidget get rebuilt when the data changes?
How can I wrap the MaterialApp widget with InheritedWidget so I can change its data from anywhere in app and only rebuild a small Widget that is using InheritedWidget when the data changes?
I know I can implement this using provider package very easily, but in this part of application I want to use InheritedWidget if it's possible :)
An object or widget being immutable does not mean its values can't change.
You can declare a final List<widget> children, which is immutable since it is final, and still add and remove widgets from it. What is immutable is the reference.
When you use the InheritedWidget is the same. If a value changes it wont rebuild itself and all the tree below. Even it is actually changed and rebuilt, it does not necessarily rebuild all tree below, it'd happen only if the widget type or its child/children reference changed also.
In my flutter app, i use a list view inside a HookConsumerWidget, this list has a filter and once it filters the list tiles have big gaps, and i see this error:
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.
i couldn't solve it because its a HookConsumerWidget and its not flexible
try to show some code snippets of the problem or the log messages,
my concern is when you're using HookConsumerWidget you don't need to use setState as you could manage the UI changes directly with listeners or watcher with 'StateProvider' for example.
I've started to learning about Flutter's inherited widgets and i have a question.
Why do we need an InheritedWidget if we can get data from context.findAncestorOfExactType?
And that updateShouldNotify... Like, it notifies child widgets when some condition is true, and they are anyway running their build methods after InheritedWidget changed, because it's immutable and we can only chage it in some rebuild...
InheritedWidget is more useful for build method cases. When you want to get data from an ancestor inside your build method.
From the Flutter API: https://api.flutter.dev/flutter/widgets/BuildContext/findAncestorStateOfType.html
This should not be used from build methods, because the build context
will not be rebuilt if the value that would be returned by this method
changes. In general, dependOnInheritedWidgetOfExactType is more
appropriate for such cases. This method is useful for changing the
state of an ancestor widget in a one-off manner, for example, to cause
an ancestor scrolling list to scroll this build context's widget into
view, or to move the focus in response to user interaction.
Also by doing what you mention, you are coupling Widgets together which is not a good practice at all. Widgets are known to be able to moved from place to place without much modification.
There are many useful things that come from the Inherited Widget. Some of these things are very useful packages, I recommend that you take a look at them.
Provider package
InheritedWidget & InheritedModel
Redux
BLoC / Rx
GetIt
You can also take a look at the InheritedWidget documentation
I am new to Flutter and reactive programming is also new thing for me.
Let's say I want to build a timer with Flutter.
I add a Scaffold with all the necessary stuff in it and I add a IconButton which starts the Stopwatch and Text which displays elapsed time. I also add Timer.periodic to periodically (every 0.5 second) update the text.
Text Widget controls it's own state by checking if Stopwatch is running and updating it's values.
So now let's say I want to have more complicated logic that changes the text based on some actions with other buttons which are the siblings of Text. However it is not possible to call setState of Text widget directly from sibling widgets. As I understand the point of reactive paradigm is that the state can be passed down the Tree. However if I make my Scaffold as StatefulWidget and update the state of the parent every 0.5 second it will redraw my entire Scaffold with all it's children. So eventually when the Scaffold gets big enough it will have to update everything instead of single Text widget.
Am I correct? And is there any solution to this. I read something about Streams and Sinks however it looks very complicated and I think that there should be another solution.
You don't need to rebuild the whole tree, if the state only changed in a sub widget, ideally you want to call set state in that widget so only that part of the tree (the one whose state changed) is rebuilt.
Streams aren't really that complicated, it's a good way for you to send messages between different components in your app, which is what you're trying to do here.
In your case you can also use a ValueNotifier to store state in the parent widget, or maybe an AnimationController, and send its listener down to the sub widget that needs be updated on change.
In any case, the state is lifted to a parent widget, which then becomes accessible to the sub widget through a listener, or a stream. When the listener triggers a signal, you rebuild the sub widget only.
Extract out widget and call setState() form that widget and it's don't render all the widget again