Probabilmente ti trovi in una delle due situazioni. O hai ereditato un'applicazione Cordova che ancora interessa alla società, o stai mantenendo un'applicazione ibrida stabile mentre il team si sposta lentamente verso strumenti più recenti. Poi arriva una richiesta di prodotto: scansione dei codici a barre degli etichetti di magazzino, dei biglietti, dei pacchi o delle etichette delle mensole con la fotocamera del telefono.
Quello è il momento in cui lettore di codici a barre Cordova il lavoro diventa interessante. Il demo base è facile. L'integrazione di produzione non lo è. Le parti difficili sono scegliere un plugin che corrisponda ai formati di codici a barre, configurare le autorizzazioni native in modo pulito e gestire le caratteristiche dei singoli dispositivi che si manifestano solo su dispositivi reali. Se il tuo app tocca anche le operazioni di campo o i flussi di inventario, la funzione di scansione si collega generalmente a preoccupazioni operative più ampie come gestire componenti IT critici, dove l'app mobile diventa parte di un flusso di attività e servizi più ampio.
Cordova è ancora una pila reale nel lavoro di manutenzione aziendale. A metà degli anni 2010, la scansione dei codici a barre in Cordova era già passata oltre gli esempi di giocattolo per app ibride aziendali costruite per Android e connesse ai servizi backend, compreso un flusso documentato utilizzando cordova create, cordova platform add androide un barcodeScanner-debug.apk generato in un esempio di costruzione di app pratico da di SitePoint’s Cordova scanning walkthrough. Se il tuo team sta anche valutando le scelte di architettura a lungo termine, questa comparazione tra applicazioni native vs applicazioni web aiuta a delineare perché le app ibride continuano a comparire nei pipeline di consegna mobile serie.
Tavola dei contenuti
- Perché Aggiungere uno Scanner di Codici a Barre alla tua App Cordova
- Scegliere il tuo Plugin di Scanner di Codici a Barre per Cordova
- Installazione e Configurazione della Piattaforma
- Implementazione dello Scanner nella tua App Code
- Test e risoluzione dei problemi comuni di errore
- Suggerimenti di prestazioni e migrazione a Capacitor
Perché aggiungere uno scanner di codici a barre alla tua app Cordova
Uno scanner cambia ciò che un'app Cordova può fare sul campo. Invece di chiedere agli utenti di digitare numeri di serie, ID di ordine o codici di prodotto, lascia che la camera diventi il dispositivo di input. Ciò riduce la frizione, ma criticamente, riduce anche il numero di modi in cui un utente può inserire un valore sbagliato.
In pratica, lo scansionamento dei codici a barre si presenta dove le app mobili incontrano operazioni reali. La ricezione dei magazzini, la ricerca dei dettagli dei prodotti, la validazione dei pezzi di servizio sul campo, l'iscrizione dei visitatori e la tracciatura degli asset interni ne beneficiano. Uno scanner cambia anche le aspettative degli utenti. Una volta disponibile la camera, gli utenti smettono di tollerare l'ingresso manuale code a meno che non ci sia un fallback chiaro.
L'applicazione Cordova ha ancora senso in modalità di manutenzione
A molti team si parla di Cordova come se fosse sparito. Non è così. È invecchiato e ora è mantenuto da portafogli aziendali, dove sostituire un'applicazione funzionante è più difficile che estenderla. Se l'app già gestisce l'autenticazione, la sincronizzazione, i form e lo storage offline, aggiungere uno scanner è spesso meno rischioso che ricostruire l'intero prodotto.
Regola pratica: Non trattare una richiesta di scansione come un trigger di ri-scrittura a meno che il resto dell'app non stia già fallendo l'operazione del tuo team.
Cordova ha guadagnato il suo posto perché i plugin hanno esposto le capacità native del dispositivo in un modo che il web code poteva utilizzare. È per questo che la scansione dei codici a barre è diventata così comune negli app mobili ibride. Si adattava perfettamente al modello per cui Cordova è stato costruito: mettere una capacità nativa dietro un API JavaScript e lasciare che il flusso dell'app rimanga principalmente basato sul web.
La valenza è nel workflow, non nel demo
Un pulsante dello scanner che restituisce il testo è la parte facile. Il lavoro principale è tutto ciò che lo circonda:
- Scegliere le simbologie supportate: L'app potrebbe avere bisogno solo di QR, o potrebbe avere bisogno di codici di retail e logistica.
- Gestire le autorizzazioni in modo pulito: Se l'accesso alla camera fallisce una volta, gli utenti spesso assumono che il feature sia rotto.
- Progettare l'azione post-scansione: La ricerca, la validazione, la navigazione e la gestione delle duplicazioni sono più importanti dell'interfaccia della camera UI.
- La modernizzazione del piano di lavoro: Se il tuo team sta spostandosi verso Capacitor, hai bisogno di un approccio che non intrappoli la funzionalità in assunzioni Cordova-only.
Quel punto è importante. Gli squadre spesso hanno successo con l'integrazione Cordova iniziale, poi incontrano problemi durante la migrazione perché il modello di rendering nativo cambia sotto il plugin. Lo scanner funziona ancora. La anteprima non mostra però dove ti aspetti.
Scegliere il tuo plugin di lettura di codici a barre Cordova
Prima di scrivere qualsiasi app code, decidi cosa stai ottimizzando. Alcune squadre hanno bisogno di un supporto di codici a barre ampio. Altre hanno bisogno solo di un overlay della fotocamera per flussi QR. Scegliere il plugin sbagliato all'inizio crea lavoro di riparazione in seguito, soprattutto quando il prodotto chiede un altro formato di codice a barre dopo il lancio.
Il plugin che più sviluppatori riconosceranno è cordova-plugin-barcodescanner. Il suo npm pacchetto documenta un scan(success, fail) API e supporto per le simbologie comuni, compresi QR_CODE, DATA_MATRIX, UPC_A, EAN_13, CODE_128, PDF_417, e AZTEC, il che è il motivo per cui si adatta sia ai casi di utilizzo retail che logistici, anziché solo ai casi di utilizzo basati su QR, come mostrato nel documento di documentazione del pacchetto plugin su npm.
Per le squadre che stanno valutando la strategia del plugin più ampiamente, questa panoramica di cosa sapere sui plugin Capacitor è utile perché evidenzia le differenze tra le vecchie ipotesi di plugin Cordova e i nuovi modelli di ponte nativo.
Cosa conta prima di installare qualcosa
Non iniziare con la popolarità sola. Inizia con il tuo lavoro di scansione.
Se l'app deve leggere più famiglie di codici a barre in contesti operativi diversi, la copertura di simbologie più ampia conta più di un API minimale. Se l'app ha bisogno solo di QR check-in, puoi accettare uno strumento più ristretto se offre un'esperienza di camera più semplice. Ciò che i giovani sviluppatori spesso trascurano è che il lavoro di scanner è meno 'può farlo' e più 'può farlo con le etichette esatte utilizzate dalle operazioni senza workarounds scomodi'.
Un elenco di controllo di selezione deve assomigliare a questo:
- Copertura dei codici a barre: Conferma i formati esatti utilizzati in produzione.
- Aspettative del sistema: Controlla cosa il team supporta ancora oggi, non cosa il plugin supportava storicamente.
- Modello di interfaccia utente: Alcuni plugin aprono un flusso di scansione nativa. Altri aspettano un approccio di anteprima incorporata.
- La tolleranza di migrazione: Chiedi se questo plugin diventerà doloroso se l'app si sposta in Capacitor in futuro.
Un plugin che funziona in un demo ma combatte la tua impostazione di layout, ciclo di vita o percorso di migrazione è di solito il plugin sbagliato.
Tabella di confronto dei plugin
| Caratteristica | phonegap-plugin-barcodescanner | cordova-plugin-qrscanner |
|---|---|---|
| Utilizzo principale | Scanning dei codici a barre ampio e across multiple formati | Flussi di scansione focalizzati su QR |
| API style | Familiar pattern di callback in molti progetti Cordova legacy | Spesso scelto per casi d'uso di anteprima della camera in diretta |
| Campo di formato del codice a barre | Più adatto quando il prodotto richiede più del QR | Più adatto quando il QR è l'unica richiesta difficile |
| Rischio di migrazione | Funziona, ma possono emergere vecchie assunzioni durante le migrazioni del ponte moderno | Le approcci con anteprima possono esporre più velocemente problemi di rendering |
| Più adatto | Flussi di lavoro dei codici a barre retail, logistici, di asset e misti | Flussi di controllo di accesso, URL, autenticazione e solo QR |
Quella tabella riflette la compatibilità pratica, non un punteggio. Se hai bisogno di simbologie retail e logistici, la categoria di plugin più ampia è spesso la scelta più sicura. Se scansi solo QR e vuoi un'esperienza di anteprima più controllata, un percorso orientato al QR può essere più leggero
La cosa più comune che vedo è scegliere uno strumento focalizzato sui QR perché la prima versione richiede solo QR, poi costringerlo a UPC o Code 128 per lavorare in seguito. Se c'è anche solo una possibilità che i tuoi utenti aziendali scannerino etichette da stampanti, scaffali, contenitori o documenti di spedizione, scegli per quel futuro ora.
Installazione e Configurazione della Piattaforma
L'integrazione si rompe di solito prima della prima scansione, non dopo. La maggior parte degli errori deriva da un disallineamento tra le aspettative JavaScript e la configurazione della piattaforma nativa. Tratta questa parte come un elenco di controllo, non come un'installazione rapida.
Un flusso di implementazione solido inizia aggiungendo il plugin o SDK, creando il contesto di cattura, limitando le simbologie ai codici che si utilizzano in produzione, configurando l'interfaccia utente e registrando un ascoltatore di scansione solo dopo. Questa sequenza è indicata nella guida di Scandit per SparkScan per Cordova e corrisponde a come le integrazioni di scanner professioniste rimangono mantenibili negli app hybrid, come descritto nella guida del developer di Scandit per il codice di scansione dei codici a barre di Cordova. Se il tuo app è ancora fortemente ibrido a livello di architettura, questa guida al sviluppo di app ibride di Cordova è un utile compagno.
Inizia con il flusso di integrazione
Una funzionalità di scanner funziona meglio quando decidi questi elementi per primo:
- Quali tipi di codici a barre l'app dovrebbe accettare.
- Se lo scansionamento è un'azione a schermo intero o parte di un workflow incorporato.
- Scegli cosa fare dopo una lettura riuscita.
- Cosa succede quando non si può utilizzare la camera.
Quello che tiene l'installazione del plugin legata a un workflow reale e non a una capacità di dispositivo generica.
I passaggi di installazione di Cordova.
Per un setup tradizionale di Cordova utilizzando il plugin di scansionatore di codici a barre comune, il punto di partenza è il comando di installazione standard documentato dal pacchetto:
cordova plugin add cordova-plugin-barcodescannerUna sequenza di configurazione del progetto tipica assomiglia a questo:
cordova create barcodeScannerApp
cd barcodeScannerApp
cordova platform add android
cordova platform add ios
cordova plugin add cordova-plugin-barcodescanner
cordova build android
cordova build iosQuella sequenza è semplice, ma non fermarti lì. Costruisci immediatamente dopo l'installazione del plugin per catturare le questioni di dipendenza nativa prima di collegare l'interfaccia utente code. Se il build fallisce, risolvi quella prima.
La configurazione nativa che si rompe di solito per prima.
Sul Sul sistema operativo iOSè necessario dichiarare correttamente l'accesso alla camera nelle impostazioni del progetto nativo. Se la descrizione dell'utilizzo della privacy della camera è mancante o vaga, lo scanner non funzionerà come una funzionalità funzionante per gli utenti. Aggiungi una descrizione di privacy della camera chiara in Info.plist Spiega perché l'app necessiti della fotocamera.
On Android, controlla le voci del manifesto e le autorizzazioni dei plugin dopo l'installazione. Il plugin potrebbe aggiungere ciò di cui ha bisogno, ma i progetti più vecchi spesso contengono modifiche di configurazione accumulate, impostazioni Gradle personalizzate o sovrapposizioni di plugin che causano avvisi di compilazione o confusione di esecuzione. Non assumere che il manifesto sia pulito solo perché il plugin è stato installato con successo.
Usa questo elenco di controllo rapido:
- Controlla le versioni delle piattaforme: I progetti Cordova più vecchi spesso contengono pacchetti di piattaforma obsoleti.
- Controlla le richieste di autorizzazione: La formulazione e il momento sono importanti per la fiducia dell'utente.
- Testa su un dispositivo reale presto: Gli emulatori non ti diranno abbastanza sulla comportamento della fotocamera.
- Limita lo scopo dello scanner: Abilita solo i tipi code accettati dal tuo workflow.
Se il tuo scanner ha bisogno di solo uno o due formati, configurali per primi. La scansione ampia sembra flessibile, ma spesso rende la debuggistica più lenta perché ogni etichetta non leggibile diventa ambigua.
Il lezione chiave per i junior developer è questa: l'installazione non è solo un comando della riga di comando. È l'allineamento del progetto nativo. Se Android e iOS non sono configurati intenzionalmente, il layer JavaScript non ti salverà.
Implementare lo Scanner nella tua App Code
Una volta installato il plugin e costruita l'app, mantieni la prima implementazione noiosa. Metti l'azione di scansione dietro un pulsante, registra il risultato completo e dimostra che il flusso di callback funziona prima di progettare un'interfaccia utente raffinata.
Il modello di scansione Cordova comune utilizza il metodo della scan(success, fail) La modalità di callback è vecchia, ma è affidabile nei codici di base legacy e facile da avvolgere in seguito se il tuo app ha spostato verso promesse o astrazioni TypeScript. Se desideri un modello mentale più chiaro per come le chiamate web code chiamano native code in questi progetti, questa spiegazione di come Capacitor collega web e native code aiuta, anche se sei ancora a codificare in Cordova oggi.
Esempio di JavaScript puro
Ecco un'implementazione minima per un'app Cordova più vecchia:
<button id="scan-button">Scan barcode</button>
<div id="scan-result"></div>document.addEventListener('deviceready', function () {
var button = document.getElementById('scan-button');
var resultEl = document.getElementById('scan-result');
button.addEventListener('click', function () {
cordova.plugins.barcodeScanner.scan(
function (result) {
if (result.cancelled) {
resultEl.textContent = 'Scan cancelled';
return;
}
resultEl.textContent =
'Text: ' + result.text +
' | Format: ' + result.format;
},
function (error) {
resultEl.textContent = 'Scan failed: ' + error;
}
);
});
});Questo fa tre cose utili. Aspetta per deviceready, lega la scansione a un'azione di utilizzo intenzionale dell'utente e gestisce sia il successo che il fallimento in modo esplicito. Non saltare il caso annullato. Gli utenti escono dai flussi della camera tutto il tempo.
Esempio di TypeScript
Se il tuo progetto utilizza TypeScript, definisci la forma del risultato da te stesso in modo che il resto dell'app possa consumarlo in modo pulito:
interface BarcodeScanResult {
text: string;
format: string;
cancelled: boolean;
}
function scanBarcode(): void {
cordova.plugins.barcodeScanner.scan(
(result: BarcodeScanResult) => {
if (result.cancelled) {
renderStatus('Scan cancelled');
return;
}
handleScannedCode(result);
},
(error: unknown) => {
renderStatus(`Scan failed: ${String(error)}`);
}
);
}
function handleScannedCode(result: BarcodeScanResult): void {
renderStatus(`Scanned ${result.format}: ${result.text}`);
if (!result.text) {
renderStatus('Empty scan result');
return;
}
lookupItemByCode(result.text);
}
function renderStatus(message: string): void {
const el = document.getElementById('scan-result');
if (el) el.textContent = message;
}
function lookupItemByCode(code: string): void {
console.log('Lookup code:', code);
}Questa versione separa la scansione dalla logica di business. Ciò conta perché il plugin della scansione dovrebbe catturare solo l'input. La validazione, la ricerca e la navigazione appartengono altrove.
Cosa fare con il risultato della scansione
Un buon flusso post-scansione è di solito uno di questi:
- Flusso di ricerca: Utilizza il testo scansito per recuperare un record di prodotto, ordine o asset.
- Flusso di validazione: Confronta il valore scansito con un valore atteso code già sullo schermo.
- Flusso di navigazione: Guida l'utente in una task legata all'oggetto scansito.
- Flusso di cattura: Salva il valore localmente per una sincronizzazione successiva.
Non lasciare che il callback dello scanner diventi un contenitore per chiamate di API, aggiornamenti DOM, analisi e navigazione. Passa il valore velocemente.
Anche, registra il risultato raw durante le prime fasi di testing. Anche se la tua UI di produzione ha bisogno solo textil valore restituito format è utile per la risoluzione dei problemi di etichette non corrispondenti. Se le operazioni dicono “lo scanner non può leggere questo code,” il formato dei dati spesso ti dice se il problema è il tipo di codice a barre, non la qualità del codice a barre.
Test e Risoluzione dei Problemi dei Errori Comuni
Most barcode scanner Cordova issues don’t come from the scan API itself. They come from the boundary between web UI, native views, and device permissions. Here, clean demos turn into confusing bug reports.
L'errore più difficile da diagnosticare è il bug di rendering Android che si manifesta durante le migrazioni di Capacitor o le configurazioni miste Cordova-Capacitor. Un sviluppatore in Capacitor issue #1213 lo descrisse semplicemente: “Ho provato questo plugin sul mio capacitor app ma sembra che lo scanner sia dietro l'app”e la soluzione richiede di rendere il background del webview nativo trasparente insieme alle modifiche di trasparenza DOM, che i tutorial standard di Cordova non coprono, come documentato nel Capacitor Problemi di rendering Android. Se stai debuggando una migrazione ibrida, questa guida per il debug di __CAPGO_KEEP_0__ app è utile da tenere aperta. debugging Capacitor apps La vista di anteprima Android dietro il bug dell'app
Simptoma
Inizia lo scanner. I permessi sembrano essere a posto. Non accade nessun crash evidente. Ma la vista di anteprima della camera appare invisibile, bloccata o 'dietro' l'interfaccia utente dell'app.
Causa
La vista di scanner nativa e la vista web sono stratificate in modo diverso rispetto alla plugin Cordova originale previsto. Su Android nei set di configurazione __CAPGO_KEEP_0__-style, il background della vista web può rimanere opaco, quindi la vista di anteprima nativa esiste ma rimane nascosta sotto di esso.
The native scanner view and the webview are layered differently than the original Cordova plugin expected. On Android in Capacitor-style setups, the webview background can remain opaque, so the native preview exists but stays hidden beneath it.
Applica un setup di vista trasparente su entrambi i lati:
Lato nativo:
- __CAPGO_KEEP_0__ Problemi di rendering Android discussion Imposta il background della vista web a trasparente.
- Parte web: Elimina i fondi opachi dagli elementi del contenitore che si trovano sopra la preview dello scanner.
- Parte layout: Controlla i contenitori di pagina dei framework, le conchiglie modal e i wrapper a schermo intero per colori di fondo predefiniti.
- Parte di testing: Valida su un dispositivo Android fisico perché il comportamento della layout può essere ingannevole nelle shell di sviluppo.
Questo è il bug che fa pensare ai sviluppatori che il plugin sia rotto quando in realtà è un problema di composizione della vista.
Fallimenti e falsi negativi di permessi
I permessi falliscono in modi che sembrano bug dello scanner.
Se l'utente rifiuta l'accesso alla camera, il callback potrebbe mostrare un errore generico o lo scanner potrebbe non presentarsi come previsto. Tratta la negazione dei permessi come una normale branch nella UI. Informati l'utente su cosa è successo e come riprovare dopo aver abilitato l'accesso. Soprattutto su iOS, il testo dei permessi non chiaro crea disprezzo prima che l'utente veda lo scanner.
Un paio di abitudini aiutano:
- Avvia la scansione da un'azione utente chiara: Gli avvisi di autorizzazione sembrano meno sospetti.
- Mostra l'input di fallback: L'ingresso manuale mantiene il workflow in vita.
- Testa le vie di rifiuto dopo aver negato: Molti team testano solo la via felice una volta.
I problemi di costruzione e di dispositivo
Alcuni errori si manifestano solo in determinati ambienti.
| Problema | Causa probabile | Soluzione pratica |
|---|---|---|
| Lo scanner si apre ma non restituisce alcun risultato utile. | Formato di codice a barre non supportato o inaspettato | Testa con etichette note che corrispondono al tuo caso di utilizzo configurato |
| La build si interrompe dopo l'installazione del plugin | Un progetto più vecchio presenta un cambiamento di piattaforma o dipendenza | Riconcilia i pacchetti di piattaforma prima di modificare l'app code |
| Funziona in un contenitore di app ma non in un altro | Interferenza di layer di visualizzazione o CSS | Rimuovi lo schermo a un layout minimale e aggiungi gli stili gradualmente |
| Il comportamento dell'emulatore è ingannevole | La simulazione della fotocamera non riflette la realtà del dispositivo | Testa l'app su hardware Android e iPhone fisico presto |
Riduci la pagina a un solo bottone e un elemento di risultato quando si debugga. Se lo scanner funziona lì, il tuo problema è di solito il layout o il contenitore di app code, non il plugin.
Consigli di prestazione e Migrazione a Capacitor
Un lettore di codici a barre può decodificare correttamente e fallire comunque l'utente nella pratica. Il problema si manifesta spesso come ritardo, scintille, glitch della anteprima della fotocamera o una schermata Android che si comporta in modo diverso su dispositivi dello stesso pool di test.
In vecchie applicazioni Cordova, il decoder è spesso il punto debole. La webview, la layering della vista e il code che reagisce ai risultati di scansione causano più problemi del riconoscimento dei codici a barre stesso.
Inizia a mantenere la schermata di scansione ristretta nel campo di applicazione. Se la schermata è destinata a scansionare etichette di inventario, lasciala scansionare etichette di inventario. I filtri aggiuntivi, i pannelli animati e gli aggiornamenti di stato ampi aggiungono lavoro di ridisegno proprio dove la rendering della webview Android è già fragile.
Un paio di modifiche tende a dare risultati rapidi:
- Limitare i formati di codici a barre accettati Se il tuo plugin lo supporta. Ciò riduce le letture false e rende più facile da ragionare sulla copertura dei test.
- Tenere la logica post-scansione breve. Analizza, valuta e aggiorna la parte UI più piccola possibile.
- Bloccare le letture duplicate per un momento. Alcuni dispositivi invieranno lo stesso risultato più volte prima che l'utente sposti la fotocamera.
- Progettare l'ingresso manuale nel flusso. Danni ai etichetti, scarsa illuminazione e imballaggi riflettenti possono ancora verificarsi in ambienti di produzione.
- Segui attentamente il costo di ripainting di Android. Overlays pesanti, transizioni CSS e componenti stratificati possono destabilizzare la preview della camera all'interno di un webview Cordova.
Un percorso di migrazione pratico a Capacitor
La migrazione più pulita da Cordova a Capacitor è in fasi, non eroica. Gli squadri si mettono in difficoltà quando scambiano il contenitore dell'app, il plugin di scansione, il flusso di autorizzazioni e gli overlay di interfaccia utente in un passaggio, poi non riescono a capire quale cambiamento ha causato il guasto.
Usa questo ordine invece:
-
Verifica i plugin attuali
Elencare tutti i plugin Cordova e segnare ogni uno come attivo, sostituibile o a rischio perché dipende da comportamenti di piattaforma più vecchi. -
Sposta il contenitore dell'app per primo
Eseguire l'app web esistente all'interno di Capacitor prima di sostituire il plugin di scansione code. Ciò separa le questioni relative al contenitore da quelle relative ai plugin. -
Conserva i plugin Cordova per una breve transizione se necessario
La compatibilità temporanea è spesso più sicura della riscrittura dello scanner, dell'accesso ai file e della gestione delle autorizzazioni nello stesso momento. -
Sostituire le parti dello scanner fragili in anticipo
Gli antichi plugin che si basano su sovraimposte personalizzate, il comportamento Android non documentato o la gestione della fotocamera obsoleta dovrebbero essere spostati in cima alla coda.
La bug della anteprima della fotocamera Android merita una particolare attenzione perché spreca molto tempo di debug. Ho visto schermi dello scanner fallire perché la anteprima nativa si trova dietro la vista web, si taglia ai bordi o si rende nero su dispositivi Android specifici. In quel momento, il plugin del codice a barre viene incolpato per primo, anche se la composizione della vista è l'aspetto sottostante.
Trattalo come un'indagine di rendering, non solo come un'indagine dello scanner. Elimina le sovraimposte decorative. Riduci la pagina alla anteprima, un trigger e un campo di risultato. Se la anteprima diventa stabile dopo questo, il problema è generalmente la tua struttura dello schermo o il CSS, non il decoding.
Questo è anche dove una migrazione a Capacitor inizia a giustificarsi. Capacitor non elimina ogni bug della fotocamera, ma di solito ti dà un confine più pulito tra la gestione della vista nativa e l'interfaccia web code. Per la scansione dei codici a barre: @capgo/camera-preview visualizza una anteprima della fotocamera in tempo reale come sovraimposta nativa con controlli personalizzabili, quindi puoi decodificare le frame in JavaScript senza che la anteprima si trovi dietro la vista web. Per la scansione aziendale su dispositivi Zebra: @capgo/capacitor-zebra-datawedge gestisce i profili DataWedge e i trigger di scansione. Per i flussi di lavoro dei tag NFC: @capgo/capacitor-nfc gestisce la scoperta, la lettura e la scrittura di tag nativi su iOS e Android.
I progetti Cordova tendono a rompersi a causa dell'età dei plugin, della deriva di piattaforma e delle ipotesi nascoste all'interno delle integrazioni più vecchie. I progetti Capacitor espongono problemi diversi, soprattutto inerenti alla gestione del ciclo di vita e alla layering nativa, ma quelle fallite sono più facili da tracciare perché il lato nativo è più esplicito.
Se il tuo attuale scanner Cordova funziona solo dopo una pila di correzioni specifiche per dispositivo, smetti di aggiungere patch. Stabilisci lo schermo di scansione, conferma se il bug di anteprima Android è veramente un problema di layering webview e poi migra in passaggi controllati. Quel percorso è più lento per una settimana e più veloce per il resto del progetto.
