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 gradualmente 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 corrisponde ai formati di codice 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 a 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 scelte di architettura a lungo termine, questa comparazione di 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 degli errori comuni
- 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 i numeri di serie, gli ID degli ordini o i codici dei prodotti, si 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 compare 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.
Cordova ancora ha senso in modalità di manutenzione
A molti team si parla di Cordova come se fosse sparito. Non è così. È invecchiato e ora è parte di portafogli aziendali di manutenzione pesante, dove sostituire un'app funzionante è più difficile che estenderla. Se l'app già gestisce l'autenticazione, la sincronizzazione, i form e lo storage offline, aggiungere uno scanner è spesso più 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 espongono le capacità native del dispositivo in modo che il web code possa utilizzarle. È 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.
Il valore è nella workflow, non nel demo
Un pulsante di scanner che restituisce il testo è la parte facile. Il lavoro principale è tutto ciò che lo circonda:
- Scegliere le simbologie supportate: La tua app potrebbe avere bisogno solo di QR, o potrebbe avere bisogno di codici di retail e logistici.
- 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 il trattamento delle duplicati sono più importanti dell'interfaccia del 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à nelle assunzioni di Cordova solo.
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 solo dove ti aspetti.
Scegliere il tuo plugin di lettura di codici a barre di 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, inclusi 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 di logistica, anziché solo ai casi di utilizzo basati su QR, come mostrato nel documento di documentazione del pacchetto del plugin su npm.
Per le squadre che valutano 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 diversi contesti operativi, la copertura di simbologia più ampia conta più di un API minimale. Se l'app ha bisogno solo di QR check-in, puoi accettare uno strumento più stretto se offre un'esperienza della 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 gli esatti formati 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.
- Tolleranza di migrazione: Chiedi se questo plugin diventerà fastidioso se l'app si sposta a Capacitor in seguito.
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 | Familiarità del modello di callback in molti progetti Cordova di vecchia data | Scegliuto spesso per casi d'uso di anteprima della camera in tempo reale |
| Barcodi: ambito di formato | Più adatto quando il prodotto richiede più di QR | Più adatto quando QR è l'unica richiesta difficile |
| Rischio di migrazione | Funziona, ma le vecchie assunzioni possono emergere durante le migrazioni del ponte moderno | Le approcci con anteprima possono esporre più velocemente gli issue di rendering |
| Scelta migliore | Flussi di lavorazione dei barcodi retail, logistici, di asset e misti | Flussi di controllo-in, 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 scansioni solo QR e vuoi un'esperienza di anteprima più controllata, un percorso orientato a QR può essere più leggero.
La maggior parte degli errori che vedo è scegliere uno strumento focalizzato su 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 scanneranno 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 una deriva di configurazione tra le aspettative JavaScript e la configurazione nativa della piattaforma. 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 allora. 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 la scansione dei codici a barre di Cordova. Se il tuo app è ancora fortemente ibrido a livello di architettura, questa guida alla 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 flusso di lavoro integrato.
- Cosa l'applicazione dovrebbe fare dopo una lettura riuscita.
- Qual è il fallback quando la camera non può essere utilizzata.
Quello che tiene l'installazione del plugin legata a un flusso di lavoro reale invece di una capacità di dispositivo generica.
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 subito 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.
Configurazione nativa che rompe di solito per prima
Su iOS, l'accesso alla camera deve essere dichiarato correttamente nelle impostazioni dei progetti nativi. Se la descrizione dell'utilizzo della privacy della camera manca o è vaga, lo scanner non si comporterà come una funzione funzionante per gli utenti. Aggiungi una descrizione di privacy della camera chiara in Info.plist Spiega perché l'app necessita della fotocamera.
On SulAndroid
, 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 dei plugin che causano avvisi di compilazione o confusione di esecuzione. Non supporre 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 timing sono importanti per la fiducia dell'utente. Testa su un dispositivo reale presto:
- Gli emulatori non ti diranno abbastanza sul comportamento della fotocamera. Abilita solo i tipi code che il tuo workflow accetta.
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.
Per i giovani sviluppatori, la lezione chiave è 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 nel tuo Applicazione Code
Una volta installato il plugin e l'app è stata costruita, 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 di 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 devicereadylega la scansione a un'azione dell'utente intenzionale e gestisce sia il successo che il fallimento in modo esplicito. Non saltare il caso annullato. Gli utenti si allontanano dalle flussi della camera tutto il tempo.
Esempio TypeScript
Se il tuo progetto utilizza TypeScript, definisci la forma del risultato da solo 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ò è importante perché il plugin dello scanner dovrebbe solo catturare 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 richiede 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
La maggior parte degli errori di scanner Cordova non provengono dallo scan API stesso. Provenienti dalla frontiera tra l'interfaccia web, le viste native e le autorizzazioni del dispositivo. Ecco, i demo puliti si trasformano in rapporti di bug confusi.
L'errore più difficile da diagnosticare è il bug di rendering Android che si manifesta durante le Capacitor delle migrazioni o le configurazioni miste Cordova-Capacitor. Un sviluppatore in Capacitor issue #1213 lo descriveva 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 le guide standard di Cordova non coprono, come documentato nella Capacitor Problema di rendering Android. Se stai debuggando una migrazione ibrida, questa guida per il debug dei __CAPGO_KEEP_0__ app è utile da tenere aperta. debugging Capacitor apps Sintomo
Inizia lo scanner. I permessi sembrano essere a posto. Non c'è un evidente crash. Ma la preview della camera appare invisibile, bloccata o 'dietro' l'interfaccia utente dell'app.
Causa
La vista dello scanner nativo e la vista web sono strati in modo diverso rispetto al plugin Cordova originale. Su Android nei set di configurazione __CAPGO_KEEP_0__-style, il background della vista web può rimanere opaco, quindi la preview nativa esiste ma rimane nascosta sotto di esso.
Soluzione
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.
Lato nativo:
__CAPGO_KEEP_0__-style setups
- __CAPGO_KEEP_0__ apps Imposta lo sfondo della vista web a trasparente.
- Parte web: Elimina i fondi opachi dagli elementi del contenitore che si trovano sopra la anteprima dello scanner.
- Parte di layout: Controlla i contenitori di pagina dei framework, le conchiglie modal e i wrapper a schermo intero per i colori di sfondo predefiniti.
- Parte di testing: Valida su un dispositivo Android fisico perché il comportamento di layout può essere ingannevole nelle shell di sviluppo.
Questo è il bug che fa pensare ai developer che il plugin sia rotto quando in realtà è un problema di composizione della vista.
Fallimenti e falsi negativi di autorizzazione
Gli errori di autorizzazione si verificano in modi che sembrano bug dello scanner.
Se l'utente rifiuta l'accesso alla camera, il callback potrebbe visualizzare un errore generico o lo scanner potrebbe non presentarsi come previsto. Tratta la negazione dell'autorizzazione 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 di autorizzazione non chiaro crea disprezzo prima che l'utente veda lo scanner.
Un paio di abitudini aiutano:
- Avvia la scansione da un'azione utente chiara: I suggerimenti 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 e riprovare: Molti team testano solo la via felice una volta.
Problemi di build e di dispositivo
Alcuni errori si manifestano solo su determinati ambienti.
| Problema | Causa probabile | Soluzione pratica |
|---|---|---|
| Il lettore 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 | Drift di piattaforma o dipendenza in un progetto più vecchio | Riconosci 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 fino 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 pulsante e un elemento di risultato quando si debugga. Se il lettore funziona lì, il tuo problema è di solito la disposizione o il contenitore di app code, non il plugin.
Consigli di prestazioni 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 uno schermo 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. Analizzare, validare e aggiornare 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. Etichette danneggiate, scarsa illuminazione e imballaggi riflettenti possono ancora verificarsi in ambienti di produzione.
- Segui attentamente il costo di ripainting di Android. Sfondi pesanti, transizioni CSS e componenti sovrapposti possono destabilizzare la preview della camera all'interno di un webview Cordova.
Un percorso di migrazione pratico per Capacitor
La migrazione più pulita da Cordova a Capacitor è in fasi, non eroica. Gli squadre si mettono in difficoltà quando scambiano il contenitore dell'app, il plugin di scansione, il flusso di autorizzazioni e gli sfondi di interfaccia utente in un'unica passata, poi non riescono a capire quale cambiamento ha causato il guasto.
Usa invece questo ordine:
-
Esegui un audit dei 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. -
Muovi il contenitore dell'app per primo
Esegui 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 overlay personalizzati, il comportamento Android non documentato o la gestione della camera obsoleta dovrebbero essere spostati in cima alla coda.
La bug della anteprima della camera Android merita una particolare attenzione perché spreca molto tempo di debug. Ho visto schermate 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 e non solo come un'indagine di scanner. Elimina gli overlay decorativi. Riduci la pagina al preview, un trigger e un campo di risultato. Se il preview diventa stabile dopo questo, il problema è di solito la tua struttura dello schermo o il CSS e non la decodifica.
Questo è anche dove inizia a giustificarsi la migrazione a Capacitor. Capacitor non elimina ogni bug della camera, ma di solito ti dà una frontiera più pulita tra la gestione delle viste native e l'UI web code. Per la scansione dei codici a barre @capgo/camera-preview visualizza una feed di camera in tempo reale come un overlay nativo 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 di 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.
Il progetto Cordova tende a rompersi a causa dell'età del plugin, della deriva del sistema operativo e delle ipotesi nascoste all'interno delle integrazioni più vecchie. Capacitor i progetti espongono problemi diversi, soprattutto in materia di gestione del ciclo di vita e di layering nativo, ma quei fallimenti sono più facili da tracciare perché il lato nativo è più esplicito.
Se il tuo attuale scanner Cordova funziona solo dopo una serie di patch specifiche per dispositivo, smetti di aggiungere patch. Stabilizza 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.
