Barcode scanner
Barcode scanning is a host operation because live scanning usually owns camera permission, camera preview, autofocus, torch, and decoder selection. The app describes acceptable formats and receives portable decoded results.
This reference is for the exact API shape. If you are wiring the feature into an app for the first time, start with the Barcode scanner guide, then return here when you need operation names, request types, provider contracts, or platform configuration details.
Public API
| |
|---|
Effect helper or entrypoint | ctx.effects.barcode_scanner() |
Provider trait or host contract | |
Test provider or test entrypoint | |
| BarcodeScanRequest / BarcodeImageDecodeRequest |
| |
| |
| |
Operations
| | | |
|---|
| Open a live scanner session for selected barcode formats. | | |
| Decode an image stream without starting a live camera session. | BarcodeImageDecodeRequest | |
| Cancel the active live scan. | | |
Provider contract
Register a BarcodeScannerHost with .with_barcode_scanner_host(...). Use MemoryBarcodeScannerHost for deterministic tests. A provider can support live scanning, image decoding, or both; unsupported operations should return BarcodeScannerError.
BarcodeImageDecodeRequest carries a DataStreamId for image decode input. The shell opens that stream before passing image bytes to the provider implementation. Live scan results can still include small raw barcode payloads because those values are bounded protocol data, not large file contents.
Providers should return typed errors for unsupported operations, denied permissions, unavailable hardware, cancellation, timeouts, and platform policy restrictions. Silent success is not acceptable because reducers need a truthful result to update state and explain what happened.
The CLI adds camera-related mobile configuration because live scanning normally uses the camera. Apps that only decode existing image streams may not need camera access on every target, but the capability declaration keeps future live scanning explicit.
When a CLI value exists, fission add-capability <value> --project-dir . records the capability in fission.toml and updates generated target files where Fission can do that deterministically. Android generated configuration lives in platforms/android/AndroidManifest.xml. iOS generated configuration lives in platforms/ios/Info.plist and platforms/ios/Entitlements.plist when entitlements are required. Desktop package metadata is reviewed during packaging because Windows, macOS, and Linux use different permission and distribution systems.
Runtime behavior
Capability calls are queued from reducers through ctx.effects. The active shell resolves the request with the registered provider and then dispatches the configured success or error action. Missing providers should produce typed unsupported errors. Packaging mistakes usually show up as denied permissions, missing entitlements, missing route registration, or provider-specific failures.
Related pages