NFC
Near field communication is short-range hardware interaction. The app should describe what it wants to do, then let the host open the platform NFC session, display the platform prompt, read or write the tag, and return typed records.
This reference is for the exact API shape. If you are wiring the feature into an app for the first time, start with the NFC guide, then return here when you need operation names, request types, provider contracts, or platform configuration details.
Public API
| |
|---|
Effect helper or entrypoint | |
Provider trait or host contract | |
Test provider or test entrypoint | |
| NfcScanRequest / NfcWriteRequest / NfcEmulationRequest |
| NfcAvailability / NfcTag / NfcSessionReceipt |
| |
| |
Operations
| | | |
|---|
| Read whether NFC is supported, enabled, and which modes are available. | | |
| Start a one-shot NFC reader session. | | |
| Write portable records to a writable tag. | | |
| Ask the host to emulate a tag where supported. | | |
| Cancel an active reader/write/emulation session. | | |
Provider contract
Register an NfcHost with .with_nfc_host(...). Use MemoryNfcHost in tests. Real providers should report availability before scanning and return NfcError::unsupported(...) for operations the device cannot perform.
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 Android NFC permission and optional hardware feature metadata. iOS needs an NFC usage description and reader-session entitlement. Desktop targets usually need a product-specific hardware provider for the reader you ship or support.
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