scrollview_observer tells a Flutter list which items are on screen

Wrap the view you already have

The package is described in one sentence: a library of widgets that can be used to listen for child widgets that are being displayed in the scroll view. The design decision that makes it usable is stated in the feature section, and it is the reason to pick this package over writing your own visibility detection.

You do not need to change the view you are currently using. You wrap a ViewObserver around the view and the listed features become available. That is a much smaller commitment than adopting a custom list widget, because the scroll view, its item builder, its controller and any existing animations stay exactly as they are. The cost is one extra widget in the tree and the observer's own bookkeeping.

The core use is knowing which items are visible. Flutter gives you scroll offsets and a scroll controller, but deriving item visibility from those is exactly the sort of arithmetic that gets subtle with slivers, reversed lists and variable item heights. A dedicated observer centralises it.

The README points to a long list of written articles, published on Medium with mirrors on WeChat and JueJin, that walk through concrete uses of the package. Reading their titles gives you a sense of the scope: getting the item information currently displayed, scrolling to a specific item, the chat session list effect, keeping IM message position when inserting or updating messages, offset and parallax effects in a PageView, half-view exposure statistics, an azlist style contact list page, syncing a detail page TabBar with modules, initial anchor behaviour for detail pages, and preventing forms in a scroll view from being occluded.

The support list covers slivers, nesting and third-party scroll views

The support section lists what the package has been made to work with, and the list is more interesting than a single version of a list widget would be.

PageView, ListView, SliverList, GridView and SliverGrid are all listed individually. Then there is mixing usage of SliverPersistentHeader, SliverList and SliverGrid, which is the case that breaks most visibility detection code, because a single scroll view can then contain children of different kinds with different geometry. NestedScrollView is supported as well, and the README links an article about that support with what it calls greater compatibility.

The last entry is the one to read carefully: ScrollView built by third-party package. Support for scroll views you did not write means the observer has to work from the rendered output rather than from assumptions about a specific widget implementation, which is a different and harder problem than supporting the standard widgets.

Two of the listed capabilities are about list behaviour rather than observation. Scrolling to a specific item in the scroll view is a separate feature with its own article and its own wiki page. And keeping the position of IM messages when inserting or updating messages, avoiding jitter, is a distinct problem: in a chat list, a new message arriving at the bottom or an edited message growing in height shifts everything else, and the user notices when their reading position jumps.

That last capability is arguably the most valuable thing here, because it is the hardest to solve correctly with framework primitives alone.

Installing is one dependency and one import

The package is published on pub.dev as scrollview_observer, and the homepage points at the package page there. Installation is the usual two steps for a Flutter package.

Add the dependency to your pubspec.yaml file:

dependencies:
  scrollview_observer: latest_version

And import it in the files that use it:

import 'package:scrollview_observer/scrollview_observer.dart';

That is the entire setup, which is worth noting because it is the low bar that makes trying the package cheap. There is no native setup, no platform channel, and no code generation step.

For evaluation without writing code, the README links an online preview hosted for the project and a set of sample images in the repository wiki under an Example page. The wiki is where the API documentation lives, with separate pages for observing the displayed child widgets, scrolling to a specified index location and the chat observer, among others.

The repository carries a full example application, with platform folders for android, ios, linux, macos, web and windows, which is the usual way to check that a package behaves as advertised across the platforms you ship on, rather than only on the platform you develop on.

The README is an index and the wiki is the manual

There is a structural characteristic of this repository worth pointing out before you judge its documentation quality.

The README does not contain API documentation, usage examples with code, or a parameter reference. It contains a description, a link to the article series, a feature checklist, a support checklist, installation instructions, and links into the wiki. The wiki then holds the pages that explain each capability, with the numbered wiki entries following the same order as the feature list.

For a package with a large surface, this is a defensible split, since the wiki can be updated without a release and the articles can show solved problems rather than API tours. The cost is that the README alone will not tell you how to configure the observer, what the callback looks like, or which parameters control things like item identification. If you are evaluating the package, you need to open the wiki and, more usefully, the example app.

The article series is where the package's real teaching value sits. Each entry covers one problem, from getting visible item information, to scrolling to a specific item, to the chat list effect, to observing a scroll view built by another package, to waterfall flow video, to exposure statistics, to nested scroll view support, to PageView offset and parallax effects. Several of them are written with the kind of framing that suggests a specific workaround was needed, which is useful: if your problem resembles one of those titles, the article is probably the fastest route to a working implementation.

Two of the features are marked as fixed in the checklist with wording that describes a limitation as much as a capability, namely keeping message position when inserting or updating messages and the support for third-party scroll views. Both read as solved problems that were hard.

Maintenance is frequent and the project is openly bilingual

The package is MIT licensed, and the repository sits under the fluttercandies organisation with the maintainer identified as LinXunFeng, who is also the author of the article series.

The release cadence is unusually fast. The published versions are 1.27.3 on 2026-09-14, 1.27.2 on 2026-09-13 and 1.27.1 on 2026-08-22, and the last push was on 2026-09-14. Patch releases one day apart are the pattern here, which is normal for a package maintained by a single active maintainer shipping small fixes continuously rather than batching them into occasional versions.

That has a practical consequence for your dependency policy. A package at 1.27.3 with daily patch releases is a package that moves fast under your feet, and if you pin an exact version you will accumulate patches; if you take the latest you take changes you did not test. Since the changes are described as small, the safer habit is to take the latest and rely on your own test suite, rather than pinning and lagging behind fixes.

The repository also maintains a Chinese version of the README, README-zh.md, and the README itself offers the document in English or Chinese. The audience is evidently bilingual, which matches the WeChat group link and the mirrored articles.

The repository structure is conventional for a Flutter package: a lib directory, a test directory, an example directory, pubspec.yaml and pubspec.lock, an analysis_options.yaml for lint rules, a CHANGELOG.md, a CODEOWNERS file and a LICENSE.

Where this package is the wrong choice

Three situations argue against it, and one is about cost rather than capability.

The first is a simple list with no requirement to know what is visible. If you want a fade-in animation on the first appearance of an item, Flutter's own animation and visibility APIs can cover that without a dependency, and every additional package is a dependency you must keep compatible with your Flutter version.

The second is a case where the chat-position feature does not apply to your data model. The IM message position feature exists for lists where messages are inserted or updated and the reading position must not move. If your list is append-only and the user is pinned to the bottom anyway, that feature adds nothing, and the remaining benefits of the observer do not obviously justify the dependency.

The third is the third-party scroll view case. The support list claims it, but the README does not explain how the observer identifies children in a scroll view it does not own, so if your list comes from another package you will want to read the corresponding article before relying on it. Support for an unfamiliar widget is the kind of claim that works until the other package changes how it lays out its children.

On cost: the package is small in scope but the feature set is broad, and the value of a package like this is unevenly distributed across its capabilities. If you only need scrolling to a specific index, that is a few lines of controller code and the observer is overhead. If you need reliable visible-item detection across nested and mixed slivers, the observer earns its place. Decide which of the two you are before you take the dependency.

One operational caveat: with daily patch releases and no long-term support branch visible in the repository listing, there is no obvious place to report a regression and wait for a fix on a stable line. The channels offered in the README are the standard ones, issues and discussions in the repository.

Editorial conclusion

scrollview_observer fits a Flutter team that needs to know which list items are on screen for effects, exposure tracking or list navigation, or that needs to preserve scroll position when chat messages arrive, and it does not fit an app that has no such requirement, since it adds a wrapper and a dependency for something Flutter does not do natively. Before adopting it, read the wiki pages for the specific effect you want, because the README lists capabilities without showing the API calls, and check that your scroll view type appears in the support list, since coverage of third-party scroll views is supported but not explained. The package is MIT licensed, version 1.27.3 was published on 2026-09-14, and the last push was on 2026-09-14.

Frequently asked questions

Official sources

1. fluttercandies/flutter_scrollview_observer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases