Null check operator used on a null value

[LennartMart]

I've got an error report on this line:

barcode_scanner/lib/src/ai_barcode_scanner.dart

Line 273 in 46f02b9

setState(() {});

"Null check operator used on a null value".
Seems to be that after the await, the widget was destroyed. So attempting to set state on a destroyed widget => error.

Is it sufficient to add this check after an await and before setState?
if (!mounted) return;

[itsarvinddev]

Confirmed, and fixed in #190 (v8.0.0). Your diagnosis was right, and the exact mechanism is worth writing down.

Root cause. The line is setState(() {}) immediately after await _controller.switchCamera(). The null-check operator is inside Flutter itself, not this package: State.setState puts the friendly "setState() called after dispose()" FlutterError inside an assert, which is compiled out in release builds, and then unconditionally runs _element!.markNeedsBuild(). StatefulElement.unmount() has already set _element = null, so in release you get Null check operator used on a null value — exactly what your crash reports show, and why it never reproduces in debug.

(For the record, the other ! on that screen — Alignment.lerp(...)! — can never throw, since Alignment.lerp only returns null when both arguments are null. It has been removed anyway.)

Fix. if (!mounted) return; would have worked, but it treats the symptom. The real problem was that the chrome was being refreshed by manual setState calls at all: the platform pushes torch, zoom and orientation updates through the controller's ValueNotifier, and none of those repainted the buttons. So a torch turned on by the OS, or a zoom change from a pinch, left the icons stale.

8.0.0 drives the whole chrome from ValueListenableBuilder<MobileScannerState> and has no setState in any control handler. There is a test asserting the torch icon updates from a platform-pushed state change rather than from the button tap.

Thanks — this one had a real release-only failure mode behind it.

[itsarvinddev]

Fixed in 8.0.0, merged in #190 (f765ee5).

No setState remains in any control handler; the chrome is driven by the controller's ValueNotifier, so it also now reflects torch and zoom changes the platform reports on its own — which the old code silently missed. Your if (!mounted) return; would have stopped the crash; this removes the reason the setState was there at all.

[itsarvinddev]

ai_barcode_scanner 8.0.0 is now live on pub.dev — this fix is installable with ai_barcode_scanner: ^8.0.0.

It is a major version; the migration guide covers the breaking changes, most of which are a one-line edit.