I'm newly learning and creating simple app using flutter.
I created drawer inside Scaffold for some pages and I got confused if when I click the ListTiles, should it be routing the pages or just switch the body widget using setState().
I guess setState() must perform better but I'm not sure if this is a good practice for pages. If it does not have a big difference in performance, I would like to use routing the pages since it will be uniformed.
Personal opinion:
Avoid separating widgets into functions, use StatelessWidget instead. Cause every render function will rebuild whatever parameter changes.
Avoid using setState as much as possible, especially for large Widgets, instead use provider, get or simply use ValueNotifier if you dont want library. Cause setState will mark all things to be rerender include widgets that not need to be rerender.
Do not render too many things at once, if possible only render the views that are / are about to be displayed. Example using ListView.builder instead of ListView, ... etc
With image, please resize to suit your needs, a 2000x2000 image loaded as a 24x24 icon is clearly not a good idea.
using const.
I'd suggest to redirect user to the next page as it won't require a StatefulWidget (you can use navigator to navigate user to another activity) which will be lighter to run, as if you use IndexedStack or dynamically assign the widget it'll require the StatefulWidget..
Related
I am designing an application that uses setState to refresh a screen with all its widgets, however I would like to know if there is a way to exclude a particular widget (conainer) and all its children, as if I were treating it as a new page.
I tried to use Navigator.push (context, MaterialPageRoute), but it didn't work, I would like to treat the widget as a separate page. I appreciate any help
Short answer: You can't.
Long answer: You can change where the setState is called, create a separate StatefulWidget that contains only the ones that need to be rebuilded. However in most of the cases this is not possible because of the order you need to show your widgets or many other factors. That's when State Managements tools come in handy. You should try to learn how to use Provider, Riverpod or BLoC (which i personally recommend). If you want something a litte bit easier you can start learning how to use InheritedWidget starting in the documentation right here.
use const if possible. if not,
use StatefulBuilder , if you call setState inside this widget, the outside widget is not touched. Maybe it will suit what you need
i have a page named displayData . On it there is a button if i click on it it shows DraggableScrollableSheet normally it has a button done when i click on it the icon of the page on the bakground (DisplayData) must change .i used a variable in a setState but it doesn't work it's true on the DraggableScrollableSheet but always false in display data
any help !
for this type of cases, there are several solutions, I recommend the use of providers, in this way with the use of 'extends ChangeNotifier' you will be able to detect the changes made without having to use the setState and you will be able to call from any class (or page ) the variables you need
you can use callback methods from on widget to another, if you have much complicated scenario then I suggest using state management libraries like Provider, RiverPod or Bloc.
also
Could you share your code here
As the below diagram shows Stateful widget covers what Stateless widget do, When I can do the same thing with Stateful widget, why Flutter designers added another widget? For increasing performance?
Please do not post the difference just answer the Why?
Would you always use a sword to do a knife's job? Given that you always have both of them available with easy access. The knife can't do everything a sword can, but would that mean that a sword should be used by default for everything, since it's more robust?
You'll have many widgets where the state of the elements will not change, and others where you will not have to use setState to update your UI either(given that you would rather not use higher level state management solutions).
Using stateless widgets as long as they can do the job, means more performent widget trees.
Please do not post the difference just answer the Why?
Knowing the difference between them is key to understanding 'why', and the differences are not just in the name less vs full. But sensing that you aren't interested, that's why.
Good Flutter code seperates the code into many small Widgets. In addition to better performance creating a StatefulWidget means that you have to write more code and add unnecessary complexity to your code.
For better performance. Stateless widgets are usually only called in one of these three situations:
1- widget is inserted in the tree.
2- Widget's parent changes its configuration
3- Inherited Widget it depends on changes.
I have a PageView with a large amount of pages in my app. Each of the pages is very complex with a PageView and its own pages.
I'm new to Flutter and my first hunch is that it needs optimization. So within the build() function of the outmost PageView I check the index and only make full page for current, previous and the next page(I guess swipe animation needs current page and the page next to it built ahead). For other pages I just give it an empty Container().
Is this necessary and the right thing to do? I felt this is an obvious optimization that the Flutter should do, but I can't find any related discussion online. Any suggestions are appreciated!
Flutter's PageView is lazily calling itemBuilder you provided. For an index it's called only when the page is really needed and you don't need to do anything more. But for further improvements you can make your view hierarchy simpler and prevent unnecessary build method calls. Here you can read more about Performance best practices.
No, it's not. ListView, GridView, and widgets alike are already optimized to build and render only what is needed in the moment. You get a hint of that in the PageView.builder description :
Creates a scrollable list that works page by page using widgets that
are created on demand
I think the difference between a regular PageView and a PageView.builder is that PageView initializes all children at startup, while PageView.builder are initialized lazily.
In Flutter does avoiding setState() achieve anything?
I have a StatefulWidget (screen) where I use Widgets that handle their own state completely with the exception of the FAB button. The Fab button is disabled or enabled when data has changed in order to allow the update of the DB when data has changed. I posted a question on SO as to how to use Provider to handle that and thus prevent the need to setState(), and implemented that with Provider.
When looking at another screen to implement something similar, I wondered if another solution may be better. This screen also contains Widgets that all handle their own state - TextFields with TextEditControllers, so the only place I was calling setState() was to enable or disable the FAB. I had previously created a Stateful Widget to create a CheckBox with its own state because the standard CheckBox doesn't have state. It's fairly simple and only 50 lines of code. So, I did the same with the FAB, I created a Stateful Widget (CustomFab) that encapsulates a FAB. When it needs to be enabled or disabled, it is called to set its own state, and returns a FAB that is either enabled or disabled with the appropriate color. Because I have other similar screens, I can use that same component with them.
Does it achieve anything by avoiding setState() in this situation (for mobile and Web), and if so, which is the best way to handle that (Custom-Widget or Provider or another)?
setState is merely avoided in Flutter development for two main reasons:
It rebuilds the whole widget, which may hinder performance on consecutive calls if not used correctly.
using setState only as a state management couples the business logic to the UI, which may reduce code re-usability and maintainability.
In simple apps, there are no significant issues in using setState. However, if you need more control over your code, I suggest going for more complex state management patterns.