Construire un Lecteur de Codes-barres Cordova : Guide 2026

Vous vous trouvez probablement dans l’une ou l’autre des situations. Soit vous avez hérité d’une application Cordova qui reste importante pour l’entreprise, soit vous maintenez une application hybride stable tout en laissant votre équipe se tourner progressivement vers de nouvelles technologies. Puis une demande de produit arrive : scanner les étiquettes d’inventaire, les tickets, les colis ou les étiquettes de rayon avec la caméra du téléphone.

C’est là que scanner de code-barres Cordova Le travail devient intéressant. La démo de base est facile. L'intégration de production n'est pas. Les parties difficiles sont la sélection d'un plugin qui correspond à vos formats de code-barres, la configuration des permissions natives de manière propre, et la gestion des particularités de plateforme qui ne se manifestent que sur des appareils réels. Si votre application touche également aux opérations de champ ou aux flux d'inventaire, la fonctionnalité de scanneur se connecte généralement à des préoccupations opérationnelles plus larges comme la gestion de composants IT critiques, où l'application mobile devient partie d'un flux de workflow plus large et de services d'actif.

Cordova est toujours une pile réelle dans le travail de maintenance d'entreprise. À la mi-2010, le scanneur de code-barres dans Cordova avait déjà dépassé les exemples de jouets pour se diriger vers des applications hybrides d'entreprise construites pour Android et connectées à des services backend, y compris un flux documenté utilisant cordova create, cordova platform add android, et un barcodeScanner-debug.apk en exemple de construction d'application pratique de SitePoint’s Cordova scanning walkthrough. Si votre équipe pèse également les choix d'architecture à long terme, cette comparaison de applications natives vs applications web aide à encadrer pourquoi les applications hybrides continuent à apparaître dans les pipelines de livraison mobile sérieux.

Table des matières

• Pourquoi Ajouter un Lecteur de Codes-barres à votre Application Cordova
  • Cordova est toujours pertinent dans le mode de maintenance
  • La valeur réside dans le flux de travail, et non dans la démo
• Choisir votre Plugin de Lecteur de Codes-barres Cordova
  • Ce qui compte avant d'installer quoi que ce soit
  • Tableau de comparaison des plugins
• Installation et Configuration de la Plateforme
  • Commencez par le flux de mise en œuvre
  • Étapes d'installation Cordova
  • Configuration native qui casse généralement en premier
• Mise en œuvre du Lecteur dans votre Application Code
  • Exemple de code JavaScript simple
  • Exemple de TypeScript
  • Ce que faire avec le résultat de l'analyse
• Test et dépannage des erreurs courantes
  • La prévisualisation Android derrière le bug de l'application
  • Échecs de permission et faux négatifs
  • Problèmes de construction et de test de dispositif
• Conseils de performance et migration vers Capacitor
  • Un chemin de migration pratique vers Capacitor

Pourquoi ajouter un lecteur de code-barres à votre application Cordova

Un lecteur de code-barres change ce que peut faire une application Cordova sur le terrain. Au lieu de demander aux utilisateurs de saisir des séries, des numéros d'ordre ou des codes de produits, vous laissez la caméra devenir le dispositif d'entrée. Cela réduit la friction, mais essentiellement, cela réduit le nombre de façons dont un utilisateur peut entrer une valeur incorrecte.

Dans la pratique, le scan de code-barres se présente là où les applications mobiles rencontrent des opérations réelles. La réception de stockage, la recherche de détail, la validation de pièces de service de terrain, l'enregistrement de visiteurs et le suivi des actifs internes bénéficient tous de cela. Un lecteur de code-barres change également les attentes des utilisateurs. Une fois que la caméra est disponible, les utilisateurs cessent de tolérer l'entrée manuelle code à moins qu'il n'y ait un fallback clair.

Cordova est toujours pertinent en mode maintenance

A beaucoup d'équipes parlent de Cordova comme si elle avait disparu. Elle n'a pas disparu. Elle a vieilli dans les portefeuilles d'entreprises à maintenance lourde, où remplacer une application fonctionnelle est plus difficile que l'étendre. Si l'application gère déjà l'authentification, la synchronisation, les formulaires et le stockage hors ligne, ajouter un scanner est souvent moins risqué que de reconstruire tout le produit.

Règle pratique : Ne traitez pas une demande de scan comme un déclencheur de réécriture que le reste de l'application ne fonctionne pas opérationnellement.

Cordova a également mérité sa place car les plugins ont exposé les capacités de dispositif natif d'une manière que le web code pouvait utiliser. C'est pourquoi le scan de code-barres est devenu si commun dans les applications mobiles hybrides. Cela correspond au modèl’exact pour lequel Cordova a été conçu : mettre une capacité native derrière un API JavaScript et permettre au flux de l'application de rester principalement web.

La valeur réside dans le flux de travail, pas dans la démo

Un bouton de scan qui retourne du texte est la partie facile. Le travail principal est tout autour :

• Choisir les symboles pris en charge : Votre application peut avoir besoin uniquement de QR, ou elle peut avoir besoin de codes de commerce et de logistique également.
• Gérer les permissions de manière propre : Si l'accès à la caméra échoue une fois, les utilisateurs supposent souvent que la fonctionnalité est cassée.
• Concevoir l'action après le scan : La recherche, la validation, la navigation et la gestion des doublons comptent plus que l'interface de la caméra.
• Modernisation de la planification : Si votre équipe se tourne vers Capacitor, vous avez besoin d'une approche qui ne pénètre pas la fonctionnalité dans des hypothèses Cordova uniquement.

Cette dernière considération est importante. Les équipes réussissent souvent avec l'intégration Cordova initiale, puis rencontrent des difficultés lors de la migration car le modèle de rendu natif change sous le plugin. Le scanner fonctionne toujours. La prévisualisation ne montre simplement pas où vous l'attendez.

Choisir votre plugin de lecture de code à barres Cordova

Avant d'écrire n'importe quelle application code, déterminez ce que vous optimisez. Certaines équipes ont besoin d'un large support de codes à barres. D'autres n'ont besoin que d'une surcouche de caméra pour les flux QR. Le choix du mauvais plugin au début entraîne des retours en arrière ultérieurs, surtout lorsque le produit demande un autre format de code à barres après le lancement.

Le plugin que les développeurs reconnaîtront le plus est cordova-plugin-barcodescanner. Son npm package documente un scan(success, fail) API et un support pour les symbologies courantes, notamment QR_CODE, DATA_MATRIX, UPC_A, EAN_13, CODE_128, PDF_417, et AZTEC, ce qui explique pourquoi il convient à la fois aux scénarios de détail et de logistique au lieu de se limiter aux cas d'utilisation basés sur QR, comme montré dans le documentation du package du plugin sur npm.

Pour les équipes évaluant la stratégie de plugin de manière plus large, cet aperçu de ce que vous devez savoir sur les Capacitor des plugins est utile car il met en évidence les différences entre les anciennes hypothèses de plugin Cordova et les nouveaux modèles de pont natif.

Ce qui compte avant d'installer quoi que ce soit

Ne commencez pas avec la popularité seule. Commencez par votre travail de numérisation.

Si l'application doit lire plusieurs familles de codes-barres dans différents contextes opérationnels, une large couverture de symboles compte plus qu'un API minimal. Si l'application n'a besoin que de la lecture de QR pour le check-in, vous pouvez accepter un outil plus étroit si cela vous donne une expérience de caméra plus simple. Ce que les développeurs juniors manquent souvent, c'est que le travail de scanner est moins lié à « peut-il scanner » et plus à « peut-il scanner les étiquettes exactes utilisées par les opérations sans besoins de contournements. »

Un bon checklist de sélection ressemble à ceci :

• Couverture des codes-barres : Confirmez les formats exacts utilisés en production.
• Attentes du système d'exploitation : Vérifiez ce que l'équipe soutient encore aujourd'hui, et non ce que le plugin a soutenu historiquement.
• Modèle d'interface utilisateur : Certains plugins ouvrent un flux de scanner natif. D'autres attendent une approche de prévisualisation intégrée.
• La tolérance de migration : Demander si ce plugin deviendra douloureux si l'application se déplace vers Capacitor plus tard.

Un plugin qui fonctionne dans un démo mais combat votre disposition d'application, votre cycle de vie ou votre chemin de migration est généralement le mauvais plugin.

Tableau de comparaison des plugins

Flux de vérification d'entrée, d'URL, d'authentification et de code QR uniquement

L’erreur la plus fréquente que je vois est de choisir un outil centré sur les QR car la première version nécessite uniquement les QR, puis de forcer l'intégration vers les UPC ou Code 128 plus tard. Si vous avez la moindre chance que vos utilisateurs commerciaux scannent des étiquettes provenant d'imprimantes, de rayons, de conteneurs ou de documents de livraison, choisissez cela pour l'avenir maintenant.

Installation et Configuration de la Plateforme

La plupart des échecs se produisent avant la première scan, et non après. La plupart des erreurs proviennent d'un décalage entre les attentes JavaScript et la configuration de la plateforme native. Abordez cette partie comme un checklist, et non comme une installation rapide.

Un flux d'implémentation solide commence par l'ajout du plugin ou SDK, la création du contexte de capture, la limitation des symbologies aux codes utilisés en production, la configuration de l'interface utilisateur, et seulement ensuite l'enregistrement d'un écouteur de scan. Cette séquence est décrite dans la guide de Cordova de Scandit pour SparkScan, et elle correspond à la façon dont les intégrations de scanners professionnels restent maintenables dans les applications hybrides, comme décrit dans le guide du développeur de Scandit pour la lecture de codes à barres Cordova. Si votre application est toujours fortement hybride au niveau de l'architecture, ce guide à le développement d'applications hybrides Cordova est un compagnon utile.

Commencez par le flux d'intégration

Une fonctionnalité de scanner fonctionne mieux lorsque vous décidez ces éléments en premier lieu :

1. Quels types de codes à barres l'application doit accepter.
2. Quel est l'action de l'application lors de la lecture d'un code-barre : une action à plein écran ou une partie d'un flux de travail intégré.
3. Quelle est l'action que l'application doit effectuer après une lecture réussie.
4. Quelle est la solution de rechange lorsque la caméra ne peut pas être utilisée.

Qu'est-ce qui maintient l'installation du plugin liée à un flux de travail réel plutôt qu'à une capacité de dispositif générique.

Étapes d'installation de Cordova.

Pour une mise en place traditionnelle de Cordova utilisant le plugin de code-barre commun, le point de départ est la commande d'installation standard documentée par le package :

cordova plugin add cordova-plugin-barcodescanner

Une séquence de mise en place d'un projet typique ressemble à ceci :

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

Cette séquence est simple, mais ne vous arrêtez pas là. Effectuez une construction immédiatement après l'installation du plugin afin de détecter les problèmes de dépendance native avant de configurer l'interface utilisateur code. Si la construction échoue, résolvez ce problème en premier.

La configuration native qui casse généralement en premier.

On iOS, l'accès à la caméra doit être déclaré correctement dans les paramètres de projet natif. Si la description d'utilisation de la permission est manquante ou vague, le lecteur de code-barre ne comportera pas comme une fonctionnalité fonctionnelle aux utilisateurs. Ajoutez une description de confidentialité de la caméra claire dans Info.plist Expliquez pourquoi l'application nécessite la caméra.

On Android : Vérifiez les entrées du manifest et les permissions liées aux plugins après l'installation. Le plugin peut ajouter ce dont il a besoin, mais les anciens projets contiennent souvent des changements de configuration accumulés, des paramètres Gradle personnalisés ou des chevauchements de plugins qui entraînent des avertissements de construction ou de confusion au moment de l'exécution. N'assumez pas que le manifest est propre juste parce que le plugin s'est installé avec succès.

Utilisez ce tableau de bord rapide :

• Vérifiez les versions de la plateforme : Les projets Cordova anciens contiennent souvent des packages de plateforme obsolètes.
• Vérifiez les invitations de permission : La formulation et le timing comptent pour la confiance des utilisateurs.
• Testez sur un appareil réel tôt : Les émulateurs ne vous diront pas assez sur le comportement de la caméra.
• Gardez la portée du scanner étroite : Activer uniquement les types code que votre flux de travail accepte.

Si votre scanner nécessite uniquement un ou deux formats, configurez-les en premier. La lecture large des codes barres peut sembler flexible, mais elle rend souvent la débogage plus lent car chaque étiquette non lisible devient ambiguë.

Pour les développeurs juniors, la leçon clé est celle-ci : l'installation n'est pas seulement une commande de terminal. C'est une alignement de projet natif. Si Android et iOS ne sont pas configurés intentionnellement, la couche JavaScript ne vous sauvera pas.

Mettre en œuvre le Scanner dans votre Application Code

Une fois le plugin installé et l'application construite, gardez la première mise en œuvre simple. Placez l'action de scan derrière un bouton, enregistrez le résultat complet, et prouvez que le flux de rappel fonctionne avant de concevoir une interface utilisateur polie autour de cela.

Le modèle de lecture de codes barres Cordova commun utilise la méthode du plugin. scan(success, fail) Ce style de rappel est ancien, mais il est fiable dans les anciens codebases et facile à envelopper ultérieurement si votre application a migré vers des promesses ou des abstractions TypeScript. Si vous souhaitez une représentation mentale plus claire de la façon dont les appels web code appellent les code natifs dans ces projets, cette explication de la façon dont code relie les web et les code natifs vous aidera, même si vous codez encore en Cordova aujourd'hui. how Capacitor bridges web and native code Exemple de code JavaScript simple

Une personne tenant un smartphone utilisant une application de caméra pour scanner un code barre sur une boîte en carton.

Exemple de code JavaScript simple

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

Ce faisait trois choses utiles. Il attend que devicereadylie les balayages à une action utilisateur intentionnelle et gère à la fois le succès et l'échec de manière explicite. N'oubliez pas le cas annulé. Les utilisateurs se retirent des flux de caméra tout le temps.

Exemple de TypeScript

Si votre projet utilise TypeScript, définissez la forme de la réponse vous-même afin que le reste de l'application puisse la consommer proprement :

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

Cette version sépare la balayage de la logique métier. Cela compte car le plugin de balayage doit uniquement capturer les entrées. La validation, la recherche et la navigation appartiennent àilleurs.

Ce que faire avec le résultat de la balayage

Un bon flux post-balayage est généralement l'un de ces :

• Flux de recherche : Utilisez le texte balayé pour récupérer un enregistrement de produit, d'ordre ou d'actif.
• Flux de validation : Comparez la valeur balayée avec une valeur attendue code déjà affichée sur l'écran.
• Flux de navigation : Dirigez l'utilisateur vers une tâche liée à l'élément scanné.
• Capture de flux : Enregistrez la valeur localement pour une synchronisation ultérieure.

Ne laissez pas l'appel de la scanner devenir un dépotoir pour les appels API, les mises à jour de la page DOM, les analyses et les navigations. Transférez la valeur rapidement.

En outre, enregistrez le résultat brut pendant les tests initiaux. Même si votre interface de production ne nécessite que textle résultat retourné format est utile pour déboguer les étiquettes incohérentes. Si les opérations disent « le scanner ne peut pas lire ce code », la mise en forme des données vous indique souvent si le problème est le type de code-barre, et non la qualité de la lecture.

Diagnostic et résolution des erreurs courantes

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: “J'ai essayé ce plugin dans mon application capacitor mais il semble que le scanner est derrière l'application”, et la correction nécessite de rendre le background de la vue web native transparent, ainsi que les changements de transparence DOM correspondants, ce que les tutoriels de Cordova standard ne couvrent généralement pas, comme documenté dans le Capacitor Problème de rendu Android. Si vous déboguez une migration hybride, ce guide sur la débogage des __CAPGO_KEEP_0__ applications est utile à garder ouvert. debugging Capacitor apps Symptôme

Lorsque vous démarrez le scanner. Les autorisations semblent correctes. Aucun crash évident n'arrive. Mais la prévisualisation de la caméra apparaît invisible, bloquée ou « derrière » l'interface utilisateur de l'application.

Cause
La vue de scanner natif et la vue web sont disposées différemment que le plugin Cordova original ne l'attendait. Sur Android dans les configurations de type __CAPGO_KEEP_0__, le fond de la vue web peut rester opaque, donc la prévisualisation native existe mais reste cachée sous elle.

Solution
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.

Côté natif :
Côté web :

• Côté web : Fixez la couleur d'arrière-plan de la vue web en transparent.
• Du côté web : Supprimez les arrière-plans opaques des éléments de conteneur qui se trouvent sur la prévisualisation du scanner.
• Du côté de la disposition : Vérifiez les conteneurs de page de framework, les boîtes de dialogue modales et les enveloppes de plein écran pour les couleurs de fond par défaut.
• Du côté de test : Validez sur un appareil Android physique car le comportement de la disposition peut être trompeur dans les shells de développement.

Ceci est le bogue qui fait croire aux développeurs que le plugin est cassé alors qu'il s'agit vraiment d'un problème de composition de vue.

Échecs de permission et faux négatifs

Les permissions échouent de manière qui ressemble à des bogues de scanner.

Si l'utilisateur refuse l'accès à la caméra, votre callback peut afficher une erreur générique ou le scanner ne peut pas se présenter comme prévu. Gérez le refus de permission comme une brancher normale dans l'interface utilisateur. Informez l'utilisateur de ce qui s'est passé et comment réessayer après avoir activé l'accès. Sur iOS en particulier, le texte de permission flou crée de la méfiance avant que l'utilisateur ne voie le scanner.

Un ou deux habitudes vous aideront :

• Activez l'activation de l'application à partir d'une action utilisateur claire : Les invites de permission semblent moins suspectes.
• Affichez l'entrée par défaut : La saisie manuelle maintient le flux de travail en vie.
• Testez les chemins de refus puis de réessayage : Beaucoup d'équipes n'ont testé que la voie heureuse une fois.

Problèmes de construction et de test de périphérique

Certains échecs ne se montrent que sur certains environnements.

Réduisez la page à un bouton et un élément de résultat lors du débogage. Si le lecteur fonctionne là, votre problème est généralement un problème de layout ou de shell d'application code, et non le plugin.

Conseils de performance et migration vers Capacitor

Un lecteur de codes-barres peut déchiffrer correctement et échouer tout de même à l'usage. Le problème se manifeste généralement sous forme de ralentissement, de clignotement, de bugs dans la prévisualisation de la caméra ou d'une écran d'Android qui se comporte différemment d'appareil en appareil dans la même pool de tests.

Dans les anciens applications Cordova, le décodeur n'est souvent pas le point faible. La vue web, la couche de vue et le code qui réagit aux résultats de scan sont souvent plus gênants que la reconnaissance des codes-barres elle-même.

Commencez par restreindre l'écran de scan à un champ étroit. Si l'écran est destiné à scanner des étiquettes d'inventaire, laissez-le scanner des étiquettes d'inventaire. Les filtres supplémentaires, les panneaux animés et les mises à jour d'état larges ajoutent du travail de redessin précisément là où la mise en page webview d'Android est déjà fragile.

Un certain nombre de changements peuvent rapporter rapidement :

• Limitation des formats de codes-barres acceptés Si votre plugin le supporte. Cela réduit les lectures fausses et rend la couverture des tests plus facile à raisonner.
• Logique de scan postérieure courte Analyse, validation et mise à jour de la plus petite partie possible de l'interface utilisateur.
• Empêchez les lectures dupliquées pendant un moment. Certains appareils feront feu plusieurs fois le même résultat avant que l'utilisateur ne déplace la caméra.
• Concevez l'entrée manuelle dans le flux. Dans des environnements réels, les étiquettes endommagées, la mauvaise luminosité et les emballages réfléchissants peuvent encore se produire.
• Suivez de près le coût de la répintion Android. Les surcharges lourdes, les transitions CSS et les composants superposés peuvent destabiliser la prévisualisation de la caméra à l'intérieur d'un webview Cordova.

Un chemin de migration pratique vers Capacitor

La migration la plus propre de Cordova vers Capacitor est étalée, et non héroïque. Les équipes se retrouvent en difficulté lorsqu'elles remplacent le conteneur d'application, le plugin de scanner, le flux de permissions et les couches d'interface utilisateur en une seule passe, puis ne peuvent pas déterminer laquelle des modifications a causé la rupture.

Utilisez cet ordre à la place :

1. Effectuez un audit des plugins actuels
   Listez tous les plugins Cordova et marquez chaque un d'eux comme actif, remplaçable ou risqué car il dépend d'une ancienne comportement de plateforme.

2. Déplacez le conteneur d'application en premier
   Exécutez l'application web existante à l'intérieur de Capacitor avant de remplacer le scanner code. Cela sépare les problèmes de conteneur des problèmes de plugin.

3. Conservez les plugins Cordova pendant une courte transition si nécessaire
   La compatibilité temporaire est souvent plus sûre que la réécriture de l'analyseur de code-barres, l'accès aux fichiers et la gestion des permissions en même temps.

4. Remplacez les pièces de l'analyseur de code-barres fragiles tôt.
   Les anciens plugins qui dépendent de surimpressions personnalisées, du comportement Android non documenté ou de la gestion de la caméra obsolète devraient être prioritaires.

Le bug de la prévisualisation de la caméra Android mérite une attention particulière car il consomme beaucoup de temps de débogage. J'ai vu les écrans d'analyseur de code-barres échouer car la prévisualisation native se trouve derrière la vue web, est coupée aux bords ou est affichée en noir sur certains appareils Android. À ce stade, le plugin de code-barres est souvent blâmé en premier, même si la composition de la vue est l'issue sous-jacente.

Traitez cela comme une enquête de rendu et non seulement comme une enquête sur l'analyseur de code-barres. Supprimez les surimpressions décoratives. Réduisez la page à la prévisualisation, un déclencheur et un champ de résultat. Si la prévisualisation devient stable après cela, le problème est généralement votre structure d'écran ou votre CSS et non la décodification.

C'est également là où une migration vers Capacitor commence à se justifier. Capacitor ne supprime pas tous les bugs de la caméra, mais il donne généralement une frontière plus claire entre la gestion de la vue native et la vue web code. Pour l'analyse de code-barres, @capgo/prévisualisation-de-la-caméra affiche une flux de caméra en direct comme une surimpression native avec des contrôles personnalisables, de sorte que vous puissiez décoder les frames en JavaScript sans que la prévisualisation ne se trouve derrière la vue web. Pour l'analyse de code-barres d'entreprise sur les appareils Zebra, @capgo/capacitor-zebra-datawedge gère les profils DataWedge et les déclencheurs de scan. Pour les workflows de tag NFC, @capgo/capacitor-nfc gestionne la découverte, la lecture et l'écriture de balises natives sur iOS et Android.

Les projets Cordova tendent à se rompre en raison de l'âge des plugins, du dérive de plateforme et d'hypothèses cachées dans les anciennes intégrations. Les projets Capacitor exposent des problèmes différents, principalement autour de la gestion du cycle de vie et de la couche native, mais ces échecs sont plus faciles à suivre car le côté natif est plus explicite.

Si votre scanner Cordova actuel ne fonctionne que après une pile de correctifs spécifiques aux appareils, arrêtez d'ajouter des correctifs. Stabilisez l'écran de scan, confirmez si le bug de prévisualisation Android est vraiment un problème de couches de WebView et migrez ensuite en étapes contrôlées. Cette voie est plus lente pendant une semaine et plus rapide pour le reste du projet.