Developer hub / public basics / Technical article
Flutter and React Native integration notes
Keep the cross-platform shell stable by owning a small native Android bridge for SUNMI-specific printing, scanning, display and device-management behavior.
Discuss your projectKeep the cross-platform shell stable by owning a small native Android bridge for SUNMI-specific printing, scanning, display and device-management behavior.
- Model scope
- Named SUNMI model, framework version, Android build tools and native bridge implementation. Framework choice does not remove device-specific validation.
- Android version
- Record the actual Android version and target SDK for the app build. Use the SUNMI matrix for model-specific expectations.
- Firmware
- Record the exact SUNMI OS or firmware for the target device set.
- SDK / interface
- SUNMI Flutter printer documentation plus native Android bridges for printer, scanner, display and Customer API surfaces. No official SUNMI React Native sample is claimed here.
- Application build
- Record the exact project build and hardware environment before deployment.
What the vendor documentation covers
- SUNMI publishes a Flutter printer integration reference and public printer API documentation.
- The checked public references do not establish a SUNMI-maintained React Native integration sample; React Native is treated as a native-bridge implementation note.
- Android permission, lifecycle and Presentation behavior remains part of the native bridge contract.
API surface
Flutter platform channel or plugin boundary for native Android callsReact Native native module boundary for Android callsSUNMI LineApi, CommandApi and QueryApiSUNMI scanner Intent or ImageScanner pathAndroid runtime permission, lifecycle and Presentation APIs
Scope and prerequisites
- Framework and native Android build versions.
- Native bridge owner and release-signing owner.
- Named SUNMI interfaces, model, Android, firmware and peripheral set.
- Typed bridge contract, fixture data and lifecycle acceptance rules.
Permissions and ownership
- Request runtime permissions in native Android code and surface denial or revocation to the framework layer.
- Package visibility and system-management authority must be declared for the target device and policy, not hidden in a plugin assumption.
- Do not include vendor binaries, private plugin code, signing keys or application secrets in a public bridge example.
Error handling
Normalize service-not-ready, permission-denied, component-not-found, decoder-busy, display-detached, printer-failed and bridge-timeout errors into stable cross-platform states.
Known limitations
- Framework plugins and platform channels do not establish support for a model, firmware or accessory.
- The official Flutter reference covers printer integration; no official React Native sample is claimed by this guide.
- Native library distribution and licensing must be handled through the vendor or project channel.
- This guide is a framework integration baseline; a compatibility conclusion belongs to a named project record.
Implementation path
- 01
Freeze the framework, Flutter or React Native version, Android Gradle and target SDK versions before implementing the bridge.
- 02
Define a small, typed native contract for print, scan, display and device status. Return structured success, pending and error states rather than leaking vendor callbacks into the UI layer.
- 03
Initialize and release vendor services with the Android lifecycle. Ensure scanner decoder ownership and secondary-display cleanup are deterministic across activity recreation.
- 04
Implement permission and package-visibility handling in native Android code, then expose only the result needed by the cross-platform layer.
- 05
Keep model-specific commands and capability checks in the native adapter. Do not make a framework plugin imply support for every SUNMI model.
- 06
For Flutter, use the official printer reference as the starting point. For React Native, document the bridge as project-owned because no official SUNMI React Native sample is asserted.
- 07
Build a framework-independent test fixture so the same acceptance cases can run against the native bridge and the final application workflow.
Verification checklist
- Record framework version, Android Gradle or build tools, target SDK, model, firmware and app build.
- Test bridge calls across cold start, hot reload or activity recreation, background and foreground transitions.
- Test printer, scanner and display failure states through the typed bridge contract.
- Verify runtime permission denial and package-not-visible behavior produces a recoverable app state.
- Run the same fixture on every named model and compare timing, data and operator-visible behavior.
- Record whether the framework integration is vendor-documented, project-curated, tested by UnitWeave or customer-accepted.
Publication gate
A published note must link a public source, keep claims within that source, show a named acceptance result and exclude private or customer material.
- At least one public source is linked and its retrieval date is recorded.
- Implementation claims stay within the named model, API and vendor-documentation scope.
- UnitWeave test status is shown separately from manufacturer documentation status.
- No private SDK, credential, customer binary, serial number or production data is included.
- A project-specific compatibility or acceptance conclusion still requires a named test record.
License and provenance
Original UnitWeave editorial synthesis with source provenance. No vendor AAR, SO, APK, private SDK, customer binary or production data is redistributed.
Sample reference
The official Flutter printer documentation is linked. No React Native vendor sample, private AAR or native library is copied into this site.
Source basis
Source provenance
The implementation content is maintained here in UnitWeave structure and wording. Source URLs remain in the provenance record for attribution and version checking; they are not a substitute for the guide.
- SUNMI Flutter printer documentationSUNMI / Flutter-facing printer integration reference. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
- APIs for Printing Thermal ReceiptsSUNMI / LineApi operations for text, barcodes, QR codes, bitmaps, columns and print transactions. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
- Using Camera-Based Barcode Scanner SDKSUNMI / Built-in scanner Intent path and camera preview plus SDK decoding path. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
- Secondary Display API DocumentationSUNMI / Presentation and DisplayManager guidance for a customer-facing secondary display. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. The page contains older overlay examples; confirm the permission and window behavior against the target Android version before implementation.
- Overview of SUNMI Customer API SDKSUNMI / Customer API modules, asynchronous service connection and model or device-scope boundaries. / Sources checked: 2026-08-30Open reference
External SUNMI documentation. Link to the current vendor page; do not redistribute vendor SDK binaries or assume every model shares the same implementation.
- Request app permissionsAndroid Developers / Runtime permission request and user-decision handling. / Sources checked: 2026-08-30Open reference
External Android documentation. Apply the guidance to the target Android API level and device policy.
- Android Presentation referenceAndroid Developers / Presentation windows and display selection for secondary-display UI. / Sources checked: 2026-08-30Open reference
External Android documentation. Apply the guidance to the target Android API level and device policy.