In the article https://flutter.dev/docs/cookbook/lists/long-lists, they say you could use a list view builder when dealing with long lists. But what does 'Long Lists' mean? Is it hundreds, thousands or tens of thousands of entries? Or does it just mean a dynamic list?
In my code, i've been making decisions on how to build the app based on trying to use list view builder (e.g. i haven't been nesting lists within other scroll views as that appears to remove the builder functionality), but this makes my code more complicated.
I ran an app in --profile mode with 10000 ListTile widgets and found them both to be very performant during scrolling and initial load. I couldn't really see a difference from the performance overlay. So I don't really know what to conclude about ListView.builder.
Edit: Should note that I tested on a cheap Samsung Galaxy A10
Both ListView and ListView.Builder extends ScrollView internally which Creates a scrollable, linear array of widgets from an explicit [List].
This ListView is appropriate for list views with a large (or
infinite) number of children because the builder is called only for
those children that are actually visible.
ListView calculates maximum scroll extent for all items in the list, that is actually taking time, but performance-wise not such an impact where user can see by their eyes.
The ListView.Builder should actually create the widget instances when called.
Avoid using a builder that returns a previously-constructed widget. So it's only calculating scroll intent for visible items which in case of Listview missing.
So there is no specific count that should be considered in-between, but if we have 100 items with the large widget tree, it will have some impact on memory usage of scrolling.
For it, memory profiling should be used.
Related
Calling validate() on a Form within a ListView does not validate FormFields that are beyond the visible area since the ListView lazily creates children and the fields haven't been created yet.
I've found two ways to ensure that all form fields, including those beyond the viewport, are created when the screen loads
Set ListView cacheExtent to double.maxFinite
Replace the ListView with a SingleChildScrollView with a Column. The SingleChildScrollView doc gives an example for a Column containing fixed height content. However, it also mentions that
If the viewport is expected to usually contain content beyond the dimensions of the screen, then SingleChildScrollView would be very expensive.
Is setting ListView cacheExtent to double.maxFinite a better approach than using SingleChildScrollView or are they essentially the same thing?
My forms are not large e.g. user profile, so I'm willing to trade minor performance loss for proper form validation.
What is the maximum number of items that a Dart List can store? I cant find any resources regarding the maximum length of a list. Dart API only mentioned growable list, but I am curious about the maximum number of elements a list can hold.
En, to your question, there's no limitation on how many items can be added to a list but you do have a restriction at hardware device which consumes memory to actually load the list it self.
That's why there are two main types of lists, with out a builder and the other with builder.
Using a list with out a builder, will load all elements on the list at once, which is perfect when you know in advance you won't have many, for example top ten articles, a drawer etc..
Using a list with builder, is basically used to prevent loading (in this lame example) 1000 records at once, rather load them on demand while you start scrolling and dismissing the items in memory when you scroll enough.
Think about this, if you have 10 items it should not be a problem using a normal list, but imagine you have 1000.
First, 1000 won't fit on the screen, each of them will consume a bit of memory leading to battery consumption and stuttering depending on performance. That's why when you know in advance you will have lots of items, using a list builder is recommended, flutter will dismiss previous elements of the list and load new ones while scrolling preventing the case I mention of using a normal list.
So, about your question i'm not sure if there is a limit in dart list items count.
But, what we should do if there an limit !! in this case we must use if statement the check the list length if it reach the limit then store the data in second list.
the idea is to split your data in this case to multiple of lists.
I've been trying to understand the difference between these two widget constructors (not sure if that's the right term, I'm new to Flutter).
The way you use them seems to be pretty similar. I'm working through a tutorial and ListView.builder seems to be the way to build long lists efficiently since it only builds what needs to be displayed on screen. Does ListView.custom do this too?
This docs for ListView.builder state:
https://api.flutter.dev/flutter/widgets/ListView/ListView.builder.html
Creates a scrollable, linear array of widgets that are created on demand.
This constructor is appropriate for list views with a large (or infinite) number of children because the builder is called only for those children that are actually visible.
For ListView.custom it says:
https://api.flutter.dev/flutter/widgets/ListView/ListView.custom.html
Creates a scrollable, linear array of widgets with a custom child model.
For example, a custom child model can control the algorithm used to estimate the size of children that are not actually visible.
It's not quite clear what the difference is, when to use which, etc. Can anyone give some more insight into these two features?
I need to display a big amount(1000+) of similar widgets (each widget
contains photo + descrption - about 400*400 px total) in a table -
say, 10 rows and 2 columns per page. I don't need option to select,
drag, highlight or do smth else with these widgets - just display
them.
It seems that FlexTable doesn't support paging. CellTable does, but it
seems to be too complicated and best suited for displaying different
data in different columns while I need just to place similar widgets
in each cell.
So, I'm a bit confused about what table to use and need some help
about this.
Thanks in advance!
Celltable and family are definitely the way to go. From the docs :
Cell widgets (data presentation widgets) are high-performance,
lightweight widgets composed of Cells for displaying data. Examples
are lists, tables, trees and browsers. These widgets are designed to
handle and display very large sets of data quickly.
https://developers.google.com/web-toolkit/doc/latest/DevGuideUiCellWidgets
And they support server side paging...
Your case from what I read.
We are attempting to create an editable grid using CellTable. The use
case is fairly high volume data entry for accountants who are used to
10-key entry into spreadsheets. We are trying to replicate spreadsheet-
style keyboard navigation as closely as possible.
Is there any way to avoid having to hit Enter to get into edit mode
for a TextInputCell? I have tried overriding
TextInputCell.onBrowserEvent() to call onEnterKeyDown() when a focus
event is received, but that didn't work.
Is there any way to use Tab and Shift-Tab to navigate between
columns instead of LEFT-ARROW and RIGHT-ARROW? CellTable seems to be
hardcoded to use left and right arrows and difficult to extend.
After quite a bit of work trying, we determined that CellTable was not extensible enough to do what we needed. We ended up extending GWT's Grid class, taking design cues from CellTable to make it perform well enough for our needs.
In our use case, 80% of page views will display less than 10 rows and we will never have more than 600 rows by 10 columns (< 0.5% of cases have more than 500 rows). Instead of a full-fledged flyweight pattern, we used a lazy loading pattern. When the Grid is initially populated, display-only widgets are used to show the data from the underlying value objects. A FocusHandler is attached to each display-only widget. When a user clicks or tabs into a display widget, the FocusHander swaps out the display-only widgets for that row with the editable widgets.
Display-only widgets are restricted to lightweight widgets such as TextBox and CheckBox, so rendering time is acceptable. 100 rows x 5 columns render in less than 2 seconds. SuggestBoxes, DateBoxes, and other Composites are limited to only being used as editable widgets.
Advantages
Flexibility to use any of the
standard widgets
Extensibility - we're not limited by
the implementation choices made in
CellTable
Ease of development - prototyped in
less than 3 days of development
Performs well enough to fit our
needs
Tabs work out of the box as you would expect
Disadvantages
Not as scalable as CellTable. This
implementation is not going to render
thousands of rows
We have to maintain it ourselves