feat: let apps plug a barcode scanner into form fields

[christian2denker]

Warum

Ein Barcode- bzw. QR-Scanner im Formular, ohne allen Nutzern des Pakets eine Scanner-Abhängigkeit aufzuzwingen.

Dazu kam heraus: FormFieldProperties.enableBarcodeScanner wird längst aus dem Backend geparst, aber kein Widget hat den Haken je ausgewertet. Was im Web-Frontend konfiguriert wird, verpuffte in Flutter.

Der Ansatz

Ein Scanner-Plugin im Paket hieße native Kamera-Abhängigkeiten und ein NSCameraUsageDescription für jede App, die apptive_grid_form nutzt — ob sie scannt oder nicht. Deshalb definiert das Paket das Loch und die App füllt es, genau wie beim Places-Key:

ApptiveGrid(
  options: ApptiveGridOptions(
    formWidgetConfigurations: [
      BarcodeScannerConfiguration(
        scan: (context) => Navigator.of(context).push<String>(...),
        buttonTooltip: 'Barcode scannen',
      ),
    ],
  ),
  child: ...,
)

Keine neue Dependency. Ohne Konfiguration erscheint nirgends ein Button; für Apps, die das nicht wollen, ändert sich nichts.

Wo der Button erscheint

Feld	Bedingung	Beim Scan
Text	Scanner konfiguriert und enableBarcodeScanner gesetzt	Wert landet im Feld
Cross-Reference (einfach und multi)	Scanner konfiguriert	Picker sucht danach und wählt die Zeile direkt aus, wenn genau eine passt

Cross-Reference wartet bewusst nicht auf enableBarcodeScanner: der Haken ist eine Textfeld-Einstellung, die das Backend dort nie setzt.

Der gescannte Wert läuft über einen ValueNotifier ins Auswahl-Grid, damit es einen Scan von Tippen unterscheiden kann. Die Auto-Auswahl greift nur, solange der Filter noch den gescannten Text hält — tippt jemand weiter, bleibt die Auswahl beim Nutzer.

Der Tooltip liegt in der Konfiguration

Nicht in ApptiveGridTranslation: die Übersetzungen werden von tool/update_translations.sh aus POEditor generiert. Ein lokal ergänzter String verschwände beim nächsten Lauf — und weil die Basisklasse abstrakt ist, wäre das ein Compile-Fehler, kein fehlender Text. Die App bringt das Wort mit, sie bringt ja auch den Scanner.

Auswirkung auf Tests von Consumern

Der Picker liest jetzt beim Bauen die ApptiveGridOptions, um zu sehen, ob ein Scanner da ist. Gegen einen nackten Mock von ApptiveGridClient wirft das:

type 'Null' is not a subtype of type 'ApptiveGridOptions'

Das betraf 88 Tests in diesem Paket. Statt sie einzeln zu flicken trägt MockApptiveGridClient in test/common.dart jetzt ein echtes options-Feld mit Default. Wer den Client in eigenen Widget-Tests mockt und ein Cross-Ref-Feld rendert, braucht dasselbe — steht als NOTE im CHANGELOG. ApptiveTeams ist nicht betroffen (mockt den Client, rendert aber kein Formular im Test).

Testing

• 7 neue Tests in test/barcode_scanner_test.dart: beide Verweigerungsfälle, Befüllen des Textfelds, deaktivierter Zustand, Auto-Auswahl im Picker und explizit „Cross-Ref wartet nicht auf den Haken"
• flutter test: 352/352
• melos run lint:all: SUCCESS
• flutter pub publish --dry-run: 0 Warnings

🤖 Generated with Claude Code