ListView class

A scrollable list of widgets arranged linearly.

ListView is the most commonly used scrolling widget. It displays its children one after another in the scroll direction. In the cross axis, the children are required to fill the ListView.

If non-null, the itemExtent forces the children to have the given extent in the scroll direction. Specifying an itemExtent is more efficient than letting the children determine their own extent because the scrolling machinery can make use of the foreknowledge of the children's extent to save work, for example when the scroll position changes drastically.

There are four options for constructing a ListView:

1. The default constructor takes an explicit List<Widget> of children. This constructor is appropriate for list views with a small number of children because constructing the List requires doing work for every child that could possibly be displayed in the list view instead of just those children that are actually visible.

2. The ListView.builder constructor takes an IndexedWidgetBuilder, which builds the children 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.

3. The ListView.separated constructor takes two IndexedWidgetBuilders: itemBuilder builds child items on demand, and separatorBuilder similarly builds separator children which appear in between the child items. This constructor is appropriate for list views with a fixed number of children.

4. The ListView.custom constructor takes a SliverChildDelegate, which provides the ability to customize additional aspects of the child model. For example, a SliverChildDelegate can control the algorithm used to estimate the size of children that are not actually visible.

To control the initial scroll offset of the scroll view, provide a controller with its ScrollController.initialScrollOffset property set.

By default, ListView will automatically pad the list's scrollable extremities to avoid partial obstructions indicated by MediaQuery's padding. To avoid this behavior, override with a zero padding property.

ListView.builder(
  padding: EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return Text('entry $index');
  },
)

Child elements' lifecycle

Creation

While laying out the list, visible children's elements, states and render objects will be created lazily based on existing widgets (such as when using the default constructor) or lazily provided ones (such as when using the ListView.builder constructor).

Destruction

When a child is scrolled out of view, the associated element subtree, states and render objects are destroyed. A new child at the same position in the list will be lazily recreated along with new elements, states and render objects when it is scrolled back.

Destruction mitigation

In order to preserve state as child elements are scrolled in and out of view, the following options are possible:

• Moving the ownership of non-trivial UI-state-driving business logic out of the list child subtree. For instance, if a list contains posts with their number of upvotes coming from a cached network response, store the list of posts and upvote number in a data model outside the list. Let the list child UI subtree be easily recreate-able from the source-of-truth model object. Use StatefulWidgets in the child widget subtree to store instantaneous UI state only.

• Letting KeepAlive be the root widget of the list child widget subtree that needs to be preserved. The KeepAlive widget marks the child subtree's top render object child for keep-alive. When the associated top render object is scrolled out of view, the list keeps the child's render object (and by extension, its associated elements and states) in a cache list instead of destroying them. When scrolled back into view, the render object is repainted as-is (if it wasn't marked dirty in the interim).

  This only works if addAutomaticKeepAlives and addRepaintBoundaries are false since those parameters cause the ListView to wrap each child widget subtree with other widgets.

• Using AutomaticKeepAlive widgets (inserted by default when addAutomaticKeepAlives is true). Instead of unconditionally caching the child element subtree when scrolling off-screen like KeepAlive, AutomaticKeepAlive can let whether to cache the subtree be determined by descendant logic in the subtree.

  As an example, the EditableText widget signals its list child element subtree to stay alive while its text field has input focus. If it doesn't have focus and no other descendants signaled for keep-alive via a KeepAliveNotification, the list child element subtree will be destroyed when scrolled away.

  AutomaticKeepAlive descendants typically signal it to be kept alive by using the AutomaticKeepAliveClientMixin, then implementing the wantKeepAlive getter and calling updateKeepAlive.

Transitioning to CustomScrollView

A ListView is basically a CustomScrollView with a single SliverList in its CustomScrollView.slivers property.

If ListView is no longer sufficient, for example because the scroll view is to have both a list and a grid, or because the list is to be combined with a SliverAppBar, etc, it is straight-forward to port code from using ListView to using CustomScrollView directly.

The key, scrollDirection, reverse, controller, primary, physics, and shrinkWrap properties on ListView map directly to the identically named properties on CustomScrollView.

The CustomScrollView.slivers property should be a list containing either a SliverList or a SliverFixedExtentList; the former if itemExtent on the ListView was null, and the latter if itemExtent was not null.

The childrenDelegate property on ListView corresponds to the SliverList.delegate (or SliverFixedExtentList.delegate) property. The new ListView constructor's children argument corresponds to the childrenDelegate being a SliverChildListDelegate with that same argument. The new ListView.builder constructor's itemBuilder and childCount arguments correspond to the childrenDelegate being a SliverChildBuilderDelegate with the matching arguments.

The padding property corresponds to having a SliverPadding in the CustomScrollView.slivers property instead of the list itself, and having the SliverList instead be a child of the SliverPadding.

CustomScrollViews don't automatically avoid obstructions from MediaQuery like ListViews do. To reproduce the behavior, wrap the slivers in SliverSafeAreas.

Once code has been ported to use CustomScrollView, other slivers, such as SliverGrid or SliverAppBar, can be put in the CustomScrollView.slivers list.

ListView(
  shrinkWrap: true,
  padding: const EdgeInsets.all(20.0),
  children: <Widget>[
    const Text('I\'m dedicating every day to you'),
    const Text('Domestic life was never quite my style'),
    const Text('When you smile, you knock me out, I fall apart'),
    const Text('And I thought I was so smart'),
  ],
)

CustomScrollView(
  shrinkWrap: true,
  slivers: <Widget>[
    SliverPadding(
      padding: const EdgeInsets.all(20.0),
      sliver: SliverList(
        delegate: SliverChildListDelegate(
          <Widget>[
            const Text('I\'m dedicating every day to you'),
            const Text('Domestic life was never quite my style'),
            const Text('When you smile, you knock me out, I fall apart'),
            const Text('And I thought I was so smart'),
          ],
        ),
      ),
    ),
  ],
)

See also:

• SingleChildScrollView, which is a scrollable widget that has a single child.
• PageView, which is a scrolling list of child widgets that are each the size of the viewport.
• GridView, which is scrollable, 2D array of widgets.
• CustomScrollView, which is a scrollable widget that creates custom scroll effects using slivers.
• ListBody, which arranges its children in a similar manner, but without scrolling.
• ScrollNotification and NotificationListener, which can be used to watch the scroll position without using a ScrollController.