Costruisci un'applicazione di lettore di codici a barre Cordova: Guida 2026

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ù nuovi. 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.

È lì che lettore di codici a barre Cordova Il lavoro diventa interessante. La demo di base è facile. L'integrazione di produzione non lo è. Le parti difficili sono scegliere un plugin che corrisponde ai formati di codici a barre, configurare le autorizzazioni native in modo pulito e gestire le caratteristiche dei 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à andata oltre gli esempi di giocattolo a hybrid enterprise app costruite per Android e connesse ai servizi backend, inclusa una documentazione del flusso utilizzando cordova create, cordova platform add android, e un barcodeScanner-debug.apk generato in un esempio di costruzione di app pratica daSitePoint’s Cordova scanning walkthrough . Se il tuo team sta anche valutando le scelte di architettura a lungo termine, questa comparazione di applicazioni native vs applicazioni web

aiuta a delineare perché gli app hybrid continuano a comparire nei pipeline di consegna mobile serie.

• Perché Aggiungere uno Scannatore di Codici a Barre alla tua App Cordova
  • Cordova ha ancora senso in modalità di manutenzione
  • Il valore risiede nel workflow, non nella demo
• Scegliere il tuo Plugin di Scannatore di Codici a Barre per Cordova
  • Ciò che conta prima di installare qualsiasi cosa
  • 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 Scannatore nella tua App Code
  • Esempio di JavaScript puro
  • Esempio di TypeScript
  • Cosa fare con il risultato dello scansionamento
• Test e risoluzione dei problemi comuni di errore
  • La anteprima Android dietro il bug dell'app
  • Il fallimento delle autorizzazioni e gli errori falsi negativi
  • I problemi di costruzione e di testing del dispositivo
• Suggerimenti di prestazioni e migrazione a Capacitor
  • Un percorso di migrazione pratico a Capacitor

Perché aggiungere uno scanner di codici a barre alla tua app Cordova

Gli scanner di codici a barre cambiano 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 presenta dove le app mobili incontrano le operazioni reali. La ricezione dei magazzini, la ricerca dei dettagli dei prodotti, la validazione dei pezzi di servizio per il campo, l'iscrizione dei visitatori e la tracciatura degli asset interni ne beneficiano tutti. Gli scanner cambiano 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 sensato in modalità di manutenzione

A molti team parlano di Cordova come se fosse scomparso. Non è così. È invecchiato nel mantenimento dei portafogli aziendali pesanti, 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 più rischioso che ricostruire l'intero prodotto.

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

Cordova ha guadagnato il suo posto perché i plugin hanno esposto le capacità del dispositivo nativo in modo che il web code potesse utilizzarlo. È per questo che la scansione dei codici a barre è diventata così comune negli app mobili ibride. Si adattava al pattern esatto per cui Cordova è stato costruito: mettere una capacità nativa dietro un API JavaScript e lasciare che il flusso dell'app rimanesse principalmente basato sul web.

Il valore è nel workflow, non nel demo

Un pulsante di scansione 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 assumono che il feature sia rotto.
• Progettare l'azione post-scansione: La ricerca, la validazione, la navigazione e la gestione delle duplicazioni contano più dell'interfaccia utente della camera.
• La pianificazione della modernizzazione: Se il tuo team sta muovendosi verso Capacitor, hai bisogno di un approccio che non intrappoli la funzionalità nelle 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 anteprima non mostra 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, specialmente 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, 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 di logistica, 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 minimo. Se l'app ha bisogno solo di QR check-in, puoi accettare uno strumento più ristretto se offre un'esperienza della camera più semplice. Cosa spesso manca ai giovani sviluppatori è che il lavoro di scanner è meno su “può scansionare” e più su “può scansionare gli esatti etichette utilizzate dalle operazioni senza workarounds scomodi.”

Un checklist di selezione corretta assomiglia a questo:

• Copertura dei codici a barre: Conferma i formati esatti 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 scansione nativa. Altri aspettano un approccio di anteprima incorporata.
• Tolleranza di migrazione: Domanda se questo plugin diventerà fastidioso se l'app si sposta in Capacitor in seguito.

Un plugin che funziona in un demo ma combatte il 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 la compatibilità pratica, non un punteggio. Se hai bisogno di simbologie per il retail e la logistica, la categoria del plugin più ampia è spesso la scelta più sicura. Se scansi solo QR e vuoi un'esperienza di anteprima più controllata, un percorso orientato a QR può essere più sottile.

La maggior parte degli errori che vedo è scegliere uno strumento focalizzato sui codici QR perché la prima rilascio richiede solo QR, poi costringere a UPC o Code 128 lavoro più tardi. Se c'è anche solo una possibilità che i vostri utenti aziendali scanneranno etichette da stampanti, scaffali, contenitori o documenti di spedizione, scegliete 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 della piattaforma nativa. Trattate 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, riducendo le simbologie ai codici che si utilizzano in produzione, configurando l'interfaccia utente e solo poi registrando un ascoltatore di scansione. Questa sequenza è indicata nella guida di Scandit per Cordova per SparkScan, e corrisponde a come le integrazioni di scanner professionale rimangono mantenibili negli app ibridi, come descritto nella guida dello sviluppatore di Scandit per il Cordova barcode scanning. Se il vostro app è ancora fortemente ibrido a livello di architettura, questa guida a sviluppo di app ibride con 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 fa parte di un workflow incorporato.
3. Cosa l'applicazione dovrebbe fare dopo una lettura riuscita.
4. Cosa esiste come fallback quando la camera non può essere utilizzata.

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

Passaggi di installazione Cordova

Per una configurazione 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 questa:

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

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 si comporterà 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 fotocamera.

On AndroidDopo l'installazione, esaminare le voci del manifesto e le autorizzazioni relative ai plugin. 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:

• Verifica le versioni delle piattaforme: I progetti Cordova più vecchi spesso contengono pacchetti di piattaforma obsoleti.
• Esamina 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 sul comportamento della fotocamera.
• Mantieni lo scopo dello scanner stretto: 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.

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 App 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 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 le chiamate web code chiamano 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 con un'app di fotocamera per scansionare un codice a barre su un cartone di un box.

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

targetLanguage

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

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 fotocamera 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 commerciale. 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 estrarre un record di prodotto, ordine o asset.
• Flusso di validazione: Confronta il valore scansito con un code atteso già sullo schermo.
• Flusso di navigazione: Ridireziona l'utente in una task legata all'oggetto scannerizzato.
• Flusso di cattura: Salva il valore localmente per una sincronizzazione successiva.

Non lasciare che il callback dello scanner diventi un contenitore di chiamate 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 interfaccia di produzione ha bisogno solo di 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 degli 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.

The hardest issue to diagnose is the Android rendering bug that shows up during Capacitor migrations or mixed Cordova-Capacitor setups. A developer in Capacitor issue #1213 described it plainly: “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 nel Capacitor problema di rendering AndroidSe stai debuggando una migrazione ibrida, questa guida per debuggare Capacitor app è utile tenere aperta.

Il bug del preview Android

Sintomo
Inizia lo scanner. I permessi sembrano essere ok. Nessun crash evidente accade. Ma il preview della camera appare invisibile, bloccato 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, il background della vista web può rimanere opaco, quindi il preview nativo esiste ma rimane nascosto sotto di esso.

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

• Lato nativo: Imposta il background della vista web a trasparente.
• Sito web: Elimina i background opachi dagli elementi del contenitore che si trovano sopra la preview dello scanner.
• Lato layout: Controlla i contenitori delle pagine di framework, le conchiglie modal e i wrapper a schermo intero per i colori di sfondo predefiniti.
• Lato di testing: Valida su un dispositivo Android fisico perché il comportamento del layout 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 di permessi

I permessi falliscono in modi che sembrano bug dello scanner.

Se l'utente rifiuta l'accesso alla camera, il callback può evidenziare un errore generico o lo scanner non si presenta 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.

Alcune abitudini aiutano:

• Avvia lo scanning da un'azione utente chiara: Il prompt dei permessi sembra meno sospetto.
• Mostra l'input di fallback: L'ingresso manuale mantiene la workflow in vita.
• Testa le vie di negazione e di retry: Molti team testano solo la via felice una volta.

I problemi di build e di testing del dispositivo

Il problema si manifesta 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 è di solito il layout o il contenitore di app code, non il plugin.

Consigli per la prestazione e la 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 delle viste 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 suo ambito. Se la schermata è destinata a scansare etichette di inventario, lasciala scansare etichette di inventario. I filtri aggiuntivi, le finestre animate 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 ragionare sulla copertura dei test.
• Tieni la logica post-scansione breve. Analizza, validati e aggiorna la parte UI più piccola possibile.
• Blocca 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 imballaggio riflettente 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 telecamera all'interno di un webview Cordova.

Un percorso di migrazione pratico per Capacitor

La migrazione più pulita da Cordova a Capacitor è programmata, non eroica. Gli squadre si mettono in difficoltà quando scambiano il contenitore dell'app, il plugin del lettore, il flusso delle autorizzazioni e gli overlay 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 tutti i plugin Cordova e segnare ogni uno come attivo, sostituibile o a rischio perché dipende da comportamenti di piattaforma più vecchi.

2. Sposta il contenitore dell'app per primo
   Eseguire l'app web esistente all'interno di Capacitor prima di sostituire il lettore code. Ciò separa le questioni relative al contenitore da quelle relative ai plugin.

3. Conserva i plugin Cordova per una breve transizione se necessario
   La compatibilità temporanea è spesso più sicura che non riscrivere lo scanner, l'accesso ai file e la gestione delle autorizzazioni nello stesso momento.

4. 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 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 le 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 punto, 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 dello scanner. Elimina gli overlay decorativi. Riduci la pagina alla preview, un trigger e un campo di risultato. Se la preview diventa stabile dopo questo, il problema è di solito 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à una frontiera più pulita tra la gestione delle viste native e la UI web code. Per la scansione 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 la preview 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 del sistema operativo e delle ipotesi nascoste all'interno delle integrazioni più vecchie. 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 serie di patch 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.