Crea un lettore di codici a barre Cordova: Guida 2026

Probabilmente ti trovi in una delle due situazioni. O hai ereditato un'app Cordova che ancora interessa alla società, o stai mantenendo un'app ibrida stabile mentre il team si sposta lentamente verso strumenti più nuovi. Poi arriva una richiesta di prodotto: utilizzare la fotocamera del telefono per scansionare etichette di magazzino, biglietti, pacchi o etichette di scaffale.

Quando arriva lettore di codici a barre Cordova il lavoro diventa interessante. La demo base è facile. L'integrazione di produzione non lo è. Le parti difficili sono scegliere un plugin che corrisponda ai tuoi 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 la tua app tocca anche le operazioni di campo o i flussi di magazzino, la funzione di scansione si collega generalmente a preoccupazioni operative più ampie come gestire componenti IT criticiladdove 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à andata oltre gli esempi di giocattolo per creare app ibride aziendali per Android e connesse a servizi backend, compresa una documentazione del flusso utilizzata cordova create, cordova platform add androide una generata barcodeScanner-debug.apk in un esempio di creazione di un'app pratica da il walkthrough di lettura di codici a barre di SitePoint per Cordova. Se il tuo team sta anche valutando scelte di architettura a lungo termine, questa comparazione tra applicazioni native vs applicazioni web aiuta a delineare perché gli app ibride continuano a comparire nei pipeline di consegna mobile serie.

Indice dei contenuti

• Perché aggiungere uno scanner di codici a barre alla tua app Cordova
  • Cordova ancora ha senso in modalità di manutenzione
  • Il valore risiede nel workflow, non nella demo
• Scegliere il tuo plugin di scanner di codici a barre per Cordova
  • Ciò che conta prima di installare qualcosa
  • Tabella di confronto dei plugin
• Installazione e configurazione della piattaforma
  • Inizia con il flusso di integrazione
  • Passaggi di installazione di Cordova
  • Configurazione nativa che si rompe di solito per prima
• Implementazione dello Scanner nel tuo App Code
  • Esempio di JavaScript puro
  • Esempio di TypeScript
  • Cosa fare con il risultato dello scan
• Test e risoluzione dei problemi comuni di errore
  • Il preview Android dietro il bug dell'app
  • Fallimenti di autorizzazione e falsi negativi
  • Problemi di build e testing del dispositivo
• Suggerimenti di prestazioni e migrazione a Capacitor
  • Un percorso di migrazione pratica a Capacitor

Why 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 scanning dei codici a barre si verifica 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 tutti. 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

Molti team parlano di Cordova come se fosse scomparso. Non è così. È invecchiato nel portafoglio delle aziende di mantenimento pesante, dove sostituire un'app funzionante è più difficile che estenderla. Se l'app già gestisce l'autenticazione, la sincronizzazione, i moduli e lo storage offline, aggiungere uno scanner è spesso più rischioso che ricostruire l'intero prodotto.

Regola pratica: Non trattare una richiesta di scanning come un trigger di riscrittura a meno che il resto dell'app non stia già fallendo l'operazione della tua squadra.

Il Cordova ha guadagnato il suo posto perché i plugin espongono le capacità di dispositivo nativo in un modo che il web code può utilizzare. È per questo che lo scanning dei codici a barre è diventato così comune negli app mobili ibride. Si adattava al pattern esatto per cui il Cordova è stato costruito: mettere una capacità nativa dietro un API JavaScript e lasciare che il flusso dell'app rimanga principalmente web-based.

Il valore risiede nel workflow, non nella 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 logistica inoltre.
• Gestire le autorizzazioni in modo pulito: Se l'accesso alla camera fallisce una volta, gli utenti spesso suppongono che il feature sia rotto.
• Progettare l'azione post-scanning: La ricerca, la validazione, la navigazione e la gestione delle duplicazioni sono più importanti dell'interfaccia utente della camera.
• Pianificare la modernizzazione: Se il tuo team sta spostandosi verso Capacitor, hai bisogno di un approccio che non intrappola il feature in assunzioni Cordova-only.

Questo ultimo 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 preview non mostra dove si aspettano.

Scegliere il tuo plugin di lettura barre di Cordova

Prima di scrivere qualsiasi app code, decidi cosa stai ottimizzando. Alcune squadre hanno bisogno di un supporto barre di larga gamma. Altre hanno bisogno solo di un overlay della fotocamera per i flussi QR. Scegliere il plugin sbagliato all'inizio crea lavoro di riciclo in seguito, soprattutto quando il prodotto chiede un altro formato di barre dopo il lancio.

Il plugin che i maggiori sviluppatori riconosceranno è cordova-plugin-barcodescanner. Il suo npm pacchetto documenta un scan(success, fail) API e supporto per le simbologie comuni, compreso 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 valutano la strategia dei plugin in modo più ampio, questa panoramica di cosa sapere sui plugin Capacitor è utile perché mette in evidenza le differenze tra le vecchie ipotesi di plugin Cordova e i nuovi modelli di ponte nativi.

What 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 dei simboli è più importante di un minimo API. Se l'app ha bisogno solo di QR check-in, puoi accettare uno strumento più stretto se ti offre un'esperienza di camera più semplice. Ciò che i giovani sviluppatori spesso trascurano è che il lavoro dello scanner è meno su 'può scansionare' e più su 'può scansionare gli etichette esatte utilizzate dalle operazioni senza workarounds scomodi.'

Un buon elenco di controllo della selezione assomiglia a questo:

• Copertura dei codici a barre: Conferma gli esatti formati utilizzati in produzione.
• Aspettative della piattaforma: Controlla cosa il team supporta ancora oggi, non cosa il plugin supportava storicamente.
• Modello di interfaccia utente: Alcuni plugin aprono un flusso di scanner nativo. Altri aspettano un approccio di anteprima incorporato.
• Tolleranza della migrazione: Domanda se questo plugin diventerà doloroso se l'app si sposta su Capacitor in futuro.

A plugin che funziona in un demo ma combatte il tuo layout, il ciclo di vita o il percorso di migrazione dell'app è di solito il plugin sbagliato.

Tabella di confronto dei plugin

Quella tabella riflette l'adattamento pratico, non un punteggio. Se hai bisogno di codici a barre di retail e logistica, la categoria del plugin più ampia è spesso la scelta più sicura. Se invece scansioni solo QR e vuoi un'esperienza di anteprima più controllata, un percorso orientato a QR può essere più sottile.

L'errore che vedo più spesso è scegliere uno strumento focalizzato su QR perché la prima versione richiede solo QR, poi costringerlo a UPC o Code 128 in seguito. Se c'è anche solo una possibilità che i tuoi utenti aziendali scansionino 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 distacco di configurazione tra le aspettative JavaScript e la configurazione della piattaforma nativa. Tratta questa parte come un elenco di controllo, non come un'installazione veloce.

Ampia implementazione del flusso inizia aggiungendo il plugin o SDK, creando il contesto di cattura, riducendo le simbologie ai codici utilizzati in produzione, configurando l'interfaccia utente e registrando un ascoltatore di scansione solo allora. Tale sequenza è indicata nella guida di Scandit per Cordova per SparkScan e corrisponde a come le integrazioni di scanner professionale rimangono mantenibili negli app ibride, come descritto in La 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 a 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 prima:

1. Quali tipi di codici a barre l'app dovrebbe accettare.
2. Se lo scansionamento è un'azione a schermo intero o parte di un flusso di lavoro incorporato.
3. Cosa l'app dovrebbe fare dopo una lettura riuscita.
4. Cosa esiste come fallback quando la camera non può essere utilizzata.

That mantiene l'installazione del plugin legata a un workflow reale invece di una capacità di dispositivo generica.

Cordova install steps

Per un setup tradizionale di Cordova utilizzando il plugin di scansione del codice a barre comune, il punto di partenza è il comando di installazione standard documentato dal pacchetto:

cordova plugin add cordova-plugin-barcodescanner

Una 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 ios

Quella 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 la costruzione 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 delle autorizzazioni manca o è vaga, lo scanner non funzionerà come una funzionalità funzionante per gli utenti. Aggiungi una descrizione di privacy della camera chiara in Info.plist che spiega perché l'app necessita della camera.

Su AndroidVerifica le voci del manifesto e le autorizzazioni relative ai 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 costruzione 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:

• Verifica le versioni delle piattaforme: I progetti Cordova più vecchi spesso contengono pacchetti di piattaforma obsoleti.
• Verifica 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 sulla comportamento della fotocamera.
• Limita lo scopo dello scanner: Abilita solo i code tipi che il tuo workflow accetta.

Se lo scanner ha bisogno di solo uno o due formati, configuralo per quelli prima. La scansione ampia sembra flessibile, ma spesso rende la debuggatura più lenta perché ogni etichetta non letta diventa ambigua.

Per i giovani sviluppatori, la lezione chiave è questa: l'installazione non è solo un comando della riga di comando. È 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, logga il risultato completo e dimostra che il flusso di callback funziona prima di progettare un'interfaccia utente curata.

Il modello di scanner Cordova comune utilizza il metodo del plugin. scan(success, fail) Lo stile di callback è vecchio, ma è affidabile nei codici 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 capire come web code chiama native code in questi progetti, questa spiegazione di come code collega web e native code how Capacitor bridges web and native code Una persona che tiene uno smartphone utilizzando un'app di fotocamera per scansionare un codice a barre su una scatola di cartone.

Ecco una implementazione minima per un'app Cordova più vecchia:

Questo fa tre cose utili. Aspetta

<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;
      }
    );
  });
});

, lega la scansione a un'azione di un utente intenzionale e gestisce sia il successo che il fallimento in modo esplicito. Non saltare il caso annullato. Gli utenti si allontanano dalle flussi di fotocamera tutto il tempo. devicereadyEsempio di TypeScript

Ecco un esempio di come potresti implementare lo scanner in un'app Cordova più moderna:

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 dello scanner 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 code atteso già sullo schermo.
• Flusso di navigazione: Diriga 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 luogo di scarico per le chiamate API, gli aggiornamenti DOM, le analisi e la navigazione. Passa il valore velocemente.

Inoltre, registra il risultato raw durante le prime fasi di testing. Anche se la tua interfaccia di produzione ha bisogno solo di text, il valore restituito format è utile per la risoluzione dei bug relativi a 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.

Testing e Risoluzione dei Problemi Comuni

La maggior parte degli errori relativi allo scanner Cordova non provengono dallo scan API stesso. Provenienti dalla frontiera tra l'interfaccia web, le viste native e le autorizzazioni del dispositivo. Qui, le demo pulite si trasformano in rapporti di bug confusi.

Il problema più difficile da diagnosticare è il bug di rendering Android che si manifesta durante le migrazioni Capacitor o le configurazioni miste Cordova-Capacitor. Un sviluppatore nel problema #1213 di Capacitor lo descriveva chiaramente: ‘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 nella Capacitor discussione del bug di rendering Android.Se stai debuggando una migrazione ibrida, consulta la guida alla debugging degli app Capacitor is worth keeping open.

Il bug di anteprima Android dietro l'app

Sintomo
Avvia lo scanner. I permessi sembrano essere ok. Nessun crash evidente accade. Ma la preview della fotocamera 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 previsto. Su Android nei settaggi di tipo Capacitor-style, il background della vista web può rimanere opaco, quindi la preview nativa esiste ma rimane nascosta sotto di esso.

Soluzione
Applica un setup di vista trasparente su entrambi i lati:

• Lato nativo: Imposta il background della vista web a trasparente.
• Lato web: Elimina i background opachi dagli elementi di contenuto che si trovano sopra la preview dello scanner.
• Layout laterale: Controlla i contenitori di sfondo predefiniti per le schermate a schermo intero, le conchiglie modali e i contenitori di pagina del framework.
• Lato di testing: Valuta su un dispositivo Android fisico perché il comportamento della griglia può essere ingannevole nelle conchiglie 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 delle autorizzazioni

Le autorizzazioni falliscono in modi che sembrano bug dello scanner.

Se l'utente rifiuta l'accesso alla camera, il callback può visualizzare un errore generico o lo scanner non si presenta come previsto. Tratta il rifiuto delle autorizzazioni 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 delle autorizzazioni poco chiaro crea disaffezione prima che l'utente veda lo scanner.

Un paio di abitudini aiutano:

• Attiva la scansione da un'azione utente chiara: I prompt delle autorizzazioni sembrano meno sospetti.
• Mostra l'input di fallback: L'ingresso manuale mantiene la workflow in vita.
• Percorsi di test: negare e riprovare Molti team testano solo la path felice una volta.

Problemi di build e testing del dispositivo

Alcuni fallimenti si manifestano solo su certi ambienti.

Riduci la pagina a un solo bottone e un elemento di risultato quando si debugga. Se il lettore funziona lì, il tuo problema è spesso la layout o il contenitore di app code, non il plugin.

Consigli di prestazioni e Migrazione a Capacitor

Un lettore a barre di codici può decodificare correttamente e fallire comunque l'utente nella pratica. Il problema si manifesta spesso come rallentamento, scintille, glitch della anteprima della camera o uno schermo Android che si comporta in modo diverso su dispositivi diversi dallo stesso pool di test.

In vecchie app Cordova, il decoder è spesso il punto debole. La view layering, il webview e il code che reagisce ai risultati di scansione causano più problemi del riconoscimento delle barre di codici stesso.

Comincia mantenendo lo schermo di scansione ristretto nel suo ambito. Se lo schermo è destinato a scansionare etichette di inventario, lascialo scansionare le etichette di inventario. Gli aggiuntivi filtri, i pannelli animati e gli aggiornamenti di stato ampi aggiungono lavoro di ridisegno proprio dove la rendering del webview Android è già fragile.

Un paio di modifiche tende a dare frutti velocemente:

• Limita i formati di codice a barre accettati se il tuo plugin lo supporta. Ciò taglia le letture false e rende la copertura dei test più facile da ragionare.
• Tieni la logica post-scansione breve. Analizza, valuta e aggiorna la parte più piccola possibile dell'interfaccia utente.
• Blocca le letture duplicate per un momento. Alcuni dispositivi faranno partire lo stesso risultato diverse volte prima che l'utente sposti la camera.
• Progetta l'ingresso manuale nel flusso. Etichette danneggiate, scarsa illuminazione e imballaggi riflettenti ancora accadono in ambienti di produzione.
• Guarda il costo di ripaint di Android da vicino. Ovverci, sovrapposizioni pesanti, transizioni CSS e componenti stratificati possono destabilizzare la anteprima 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 le sovrapposizioni di interfaccia utente in un'unica passata, poi non riescono a capire quale cambiamento ha causato il guasto.

Usa questo ordine invece:

1. Valuta i plugin attuali
   Elencare ogni plugin Cordova e segnare ogni uno come attivo, sostituibile o a rischio perché dipende da comportamenti di piattaforma più vecchi.

2. Muovi il contenitore dell'app per primo
   Esegui l'app web esistente all'interno di Capacitor prima di sostituire code. Ciò separa le questioni del contenitore da quelle dei plugin.

3. Tieni i plugin Cordova per un breve periodo di transizione se necessario
   La compatibilità temporanea è spesso più sicura che non riscrivere la scansione, l'accesso ai file e il gestionale delle autorizzazioni nello stesso momento.

4. Sostituisci le parti della scansione fragili presto
   I plugin vecchi che dipendono da sovrapposizioni personalizzate, dal comportamento Android non documentato o dalla 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 di 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 punto, il plugin del codice a barre viene incolpato per primo, anche se la composizione della vista è l'issue sottostante.

Trattalo come un'indagine di rendering, non solo come un'indagine del codice a barre. 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 è solitamente la struttura dello schermo o il CSS, non il decoding.

Questa è anche dove inizia a giustificarsi una migrazione a Capacitor. Capacitor non elimina ogni bug della fotocamera, ma di solito ti dà un confine più pulito tra la gestione della vista nativa e l'UI web code. Per lo scanning dei codici a barre, @capgo/camera-preview visualizza una feed di fotocamera in tempo reale come un overlay nativo con controlli personalizzabili, quindi puoi decodificare le frame in JavaScript senza che il preview si trovi dietro la vista web. Per lo scanning 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 dei tag nativi su iOS e Android.

Progetti Cordova tendono a rompersi a causa dell'età dei plugin, della deriva della piattaforma e di ipotesi nascoste all'interno di integrazioni più vecchie. Capacitor esposti problemi diversi, soprattutto intorno al trattamento della vita ciclo 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 fix specifici 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.