Construire un Lecteur de Code-barres Cordova : Guide 2026

Vous êtes probablement dans l'une des deux situations. Soit vous avez hérité d'une application Cordova qui compte encore pour l'entreprise, ou vous maintenez une application hybride stable tout en laissant l'équipe se déplacer lentement vers des outils plus récents. Alors une demande de produit arrive : scanner les étiquettes de stock, les tickets, les colis ou les étiquettes de rayon avec la caméra du téléphone.

C'est là où le balayage de code de barre Cordova le travail devient intéressant. La démo de base est facile. L'intégration de production ne l'est pas. Les parties difficiles sont de choisir un plugin qui correspond à vos formats de code de barre, de configurer les permissions natives proprement et de gérer les particularités des plateformes qui ne se montrent que sur des appareils réels. Si votre application touche également les opérations de terrain ou les flux de stock, la fonction de balayage se connecte généralement à des préoccupations opérationnelles critiques comme la gestion de composants IT critiques, où l'application mobile devient partie d'un flux de service et d'actif plus large.

Cordova est toujours une pile réelle dans le travail de maintenance d'entreprise. À la mi-2010, le balayage de code de barre dans Cordova avait déjà dépassé les exemples de jouets pour atteindre des applications hybrides d'entreprise construites pour Android et connectées aux services back-end, y compris un flux documenté utilisant cordova create, cordova platform add android, et un barcodeScanner-debug.apk créé dans un exemple de construction d'application pratique de le guide de balayage de code de barre de SitePoint. Si votre équipe pèse également les choix d'architecture à long terme, cette comparaison entre les applications natives et les applications web aide à encadrer pourquoi les applications hybrides apparaissent toujours 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 maintenance
  • La valeur réside dans le flux de travail, et non dans la démonstration
  • 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 d'intégration
  • Start with the integration flow
  • Étapes d'installation de Cordova
  • Configuration native qui casse généralement en premier
• Mise en œuvre du Scanner dans votre application Code
  • Exemple de 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
  • Problèmes de permissions et de faux négatifs
  • Problèmes de build et de test de dispositif
• Conseils de performance et migration vers Capacitor
  • Une voie de migration pratique vers Capacitor

Pourquoi Ajouter un Lecteur de Codes-barres à Votre Application Cordova

Un lecteur change ce que peut faire une application Cordova sur le terrain. Au lieu de demander aux utilisateurs de taper 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 critique, il réduit le nombre de façons dont un utilisateur peut entrer une valeur incorrecte.

En pratique, le scan de codes-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 des pièces de service de terrain, l'enregistrement des visiteurs et le suivi des actifs internes bénéficient tous de cela. Un lecteur change également les attentes des utilisateurs. Une fois la caméra 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 dans le mode maintenance

Beaucoup d'équipes parlent de Cordova comme s'il avait disparu. C'est faux. Il a vieilli dans les portefeuilles d'entreprises à maintenance lourde, où remplacer une application fonctionnelle est plus difficile que l'agrandir. Si l'application gère déjà l'authentification, la synchronisation, les formulaires et le stockage hors ligne, ajouter un lecteur est souvent moins risqué que de reconstruire le produit entier.

Règle pratique : N'agissez pas sur une demande de scan comme un déclencheur de réécriture à moins que le reste de l'application ne faille déjà votre équipe opérationnellement.

Cordova a également gagné sa place car les plugins exposaient les capacités de dispositif natif d'une manière dont le web code pouvait l'utiliser. C'est pourquoi le balayage de code-barres est devenu si courant dans les applications mobiles hybrides. Il s'inscrivait dans le modèle 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 workflow, pas dans la démo

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

• Choisir les symbologies prises 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 balayage : La recherche, la validation, la navigation et la gestion des doublons comptent plus que l'interface de la caméra.
• Planifier la modernisation : Si votre équipe se tourne vers Capacitor, vous avez besoin d'une approche qui ne pousse pas la fonctionnalité dans des hypothèses de Cordova uniquement.

Ce dernier point compte. 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 balayage fonctionne toujours. La prévisualisation ne montre simplement pas où vous l'attendez.

Choisissez votre plugin de lecture de codes-barres Cordova

Avant d'écrire toute application code, déterminez ce que vous optimisez. Certains équipes ont besoin d'un large support des codes-barres. D'autres ont besoin uniquement d'une couche de caméra pour les flux QR. Le choix du mauvais plugin au début crée des retours en arrière plus tard, 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 des 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 qu'il faut savoir sur les plugins Capacitor 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.

Avant de mettre quoi que ce soit en place

N'oubliez pas de tenir compte de votre tâche de balayage avant de vous fier à la popularité seule.

Si l'application doit lire plusieurs familles de codes-barres dans différents contextes opérationnels, une large couverture des symboles est plus importante qu'un API minimal. Si l'application nécessite uniquement un QR de 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 souvent manquent, 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 gênants. »

Un bon checklist de sélection ressemble à ceci :

• Couverture des codes-barres : Confirmez les formats exacts utilisés en production.
• Attentes de la plateforme : 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.
• Tolérance à la migration : Demandez-vous si ce plugin deviendra douloureux si l'application passe à Capacitor plus tard.

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

Tableau de comparaison des plugins

Cette table reflète un ajustement pratique, et non un scorecard. Si vous avez besoin de symbologies de détail et de logistique, la catégorie de plugin plus large est généralement le choix le plus sûr. Si vous n'avez besoin de scanner que des QR et que vous voulez une expérience de prévisualisation plus contrôlée, un chemin axé sur le QR peut être plus léger.

L'erreur que je vois le plus souvent est de choisir un outil axé sur le QR parce que la première version n'a besoin que de QR, puis de forcer l'outil à travailler avec les codes UPC ou Code 128 plus tard. Si il y a la moindre chance que vos utilisateurs commerciaux scannent des étiquettes imprimées par des imprimantes, des rayons, des conteneurs ou des documents de livraison, choisissez pour cela maintenant.

Installation et Configuration de la Plateforme

L'intégration se brise généralement avant la première lecture, et non après. La plupart des échecs proviennent d'un dérive de configuration entre les attentes JavaScript et la configuration native de la plateforme. Abordez cette partie comme un checklist, et non comme une installation rapide.

Avec une implémentation solide, commencez par ajouter le plugin ou SDK, créez le contexte de capture, restreignez les symbologies aux codes que vous utilisez en production, configurez l'interface utilisateur, et n'inscrivez un écouteur de scan que lorsque vous l'avez fait. Cette séquence est décrite dans la guide Cordova de Scandit pour SparkScan, et elle correspond à la manière 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 reconnaissance de codes-barres Cordova. Si votre application est toujours fortement hybride au niveau de l'architecture, ce guide sur le développement d'applications hybrides Cordova est un compagnon utile.

Démarrez avec la séquence d'intégration

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

1. Quels types de codes-barres l'application doit accepter.
2. Si la lecture est une action à pleine écran ou fait partie d'un flux de travail intégré.
3. Ce que l'application doit faire après une lecture réussie.
4. Quelle est la faille existante lorsque la caméra ne peut pas être utilisée.

Ce garde la mise en place du plugin liée à un workflow 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 balayage 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 de 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 cela en premier lieu.

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

Sur iOS, l'accès à la caméra doit être déclaré correctement dans les paramètres de projet natif. Si la description d'utilisation des permissions est manquante ou vague, le balayeur ne comportera pas comme une fonctionnalité fonctionnelle aux utilisateurs. Ajoutez une description de confidentialité de la caméra claire dans Info.plist qui explique pourquoi l'application a besoin de la caméra.

Sur AndroidVérifiez les entrées du manifeste 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 manifeste est propre juste parce que le plugin s'est installé avec succès.

Utilisez ce rapide checklist :

• Vérifiez les versions des plateformes : 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 suffisamment sur le comportement de la caméra.
• Gardez la portée du scanner étroite : Activez uniquement les code types que votre flux de travail accepte.

Si votre scanner nécessite uniquement un ou deux formats, configurez-les en premier. La balayage large peut sembler flexible, mais cela 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 juste une commande de terminal. C'est l'alignement du projet natif. Si Android et iOS ne sont pas configurés intentionnellement, la couche JavaScript ne vous sauvera pas.

Implémenter le Scanner dans votre Application Code

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

Le modèle de scanner Cordova courant utilise la méthode du plugin « __CAPGO_KEEP_0__ ». 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 un modèle mental plus clair pour comprendre comment les appels web code appellent les code natifs dans ces projets, cette explication de comment 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

Cela fait trois choses utiles. Il attend que

relie la scan à une action utilisateur intentionnelle, et gère explicitement les cas de réussite et d'échec. N'oubliez pas le cas annulé. Les utilisateurs se retirent souvent des flux de caméra.

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

Exemple de code TypeScript devicereadyImplémenter le Scanner dans votre Application __CAPGO_KEEP_0__

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

Si votre projet utilise TypeScript, définissez la forme de résultat vous-même afin que le reste de l'application puisse le 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 lecture de la logique métier. Cela compte car le plugin de lecture devrait uniquement capturer l'entrée. La validation, la recherche et la navigation appartiennent àilleurs.

Ce qu'il faut faire avec le résultat de la lecture

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

• Flux de recherche : Utilisez le texte lu pour récupérer un enregistrement de produit, commande ou bien d'actif.
• Flux de validation : Comparez la valeur lue contre une valeur attendue code déjà affichée à l'écran.
• Flux de navigation : Routez l'utilisateur dans une tâche liée à l'élément lu.
• Flux de capture : Enregistrez la valeur localement pour une synchronisation ultérieure.

N'empêchez pas le callback du scanner de devenir un dépôt de tout appel API, de mises à jour DOM, d'analyses et de navigation. Transférez la valeur rapidement.

Loguez également le résultat brut pendant les tests initiaux. Même si votre interface de production ne nécessite que text, le résultat retourné format est utile pour déboguer les étiquettes incohérentes. Si l'opération dit « 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é du code-barre.

Dépannage et résolution des erreurs courantes

La plupart des problèmes de code-barre Cordova ne proviennent pas de la lecture du code-barre API elle-même. Ils proviennent de la frontière entre l'interface web, les vues natives et les autorisations du périphérique. Ici, les démos claires se transforment en rapports de bogues confus.

Le problème le plus difficile à diagnostiquer est le bug de rendu Android qui se produit lors des migrations Capacitor ou des configurations mixtes Cordova-Capacitor. Un développeur dans l'issue Capacitor #1213 l'a décrit simplement : “J'ai essayé ce plugin sur mon application capacitor mais il semble que le scanner soit 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 Cordova standard ne couvrent généralement pas, comme documenté dans la discussion sur le bug de rendu Android __CAPGO_KEEP_0__. Si vous déboguez une migration hybride, ce guide au débogage des applications Capacitor est utile.__CAPGO_KEEP_1__ debugging Capacitor apps vaut la peine de rester ouvert.

La prévisualisation Android derrière le bug de l'application

Symptôme
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 attendait. Sur Android dans les configurations de style Capacitor , le fond de la vue web peut rester opaque, donc la prévisualisation native existe mais reste cachée sous elle.

Solution
Appliquez un affichage transparent sur les deux côtés :

• Côté natif : Définissez le fond de la vue web sur transparent.
• Côté web : Supprimez les arrière-plans opaques des éléments de conteneur qui se trouvent sur la prévisualisation du scanner.
• Côté de la disposition : Vérifiez les conteneurs de page de framework, les coquilles modales et les enveloppes de wrappers pour les couleurs de fond par défaut.
• Côté de test : Validez sur un appareil Android physique car le comportement de disposition peut être trompeur dans les coquilles de développement.

C'est le bug qui fait que les développeurs pensent que le plugin est cassé quand il s'agit vraiment d'un problème de composition de vue.

Échecs de permissions et faux négatifs

Les permissions échouent de manière qui ressemble à des bugs 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 s'affiche pas comme prévu. Gérez le refus de permission comme une brancher normale dans l'interface utilisateur. Dites à l'utilisateur 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 aident :

• Déclenchez la balayage à partir d'une action utilisateur claire : Les invitations de permission ressentent moins de soupçons.
• Affichez une saisie de remplacement : L'entrée manuelle maintient la workflow en vie.
• Testez les chemins de refus puis de réessais : Beaucoup d'équipes n'ont testé que la voie heureuse une fois.

Problèmes de build et de test de dispositif

Certains échecs ne se manifestent que sur certains environnements.

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

Conseils de performance et migration vers Capacitor

Un lecteur de codes-barres peut décoder correctement et encore échouer à satisfaire l'utilisateur en pratique. Le problème se manifeste généralement sous forme de ralentissement, de clignotement, de glitches de 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 piscine de tests.

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

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

Un certain nombre de changements tend à rapporter des résultats rapides :

• Limitation des formats de codes-barres acceptés Si votre plugin le supporte, cela réduit les lectures fausses et rend la couverture de test plus facile à raisonner.
• Conservez la logique post-lecture courte. Analysez, validez et mettez à jour la partie UI la plus petite possible.
• Empêchez les lectures dupliquées pendant un moment. Certains appareils feront apparaître le même résultat plusieurs fois avant que l'utilisateur ne déplace la caméra.
• Concevez l'entrée manuelle dans le flux. Les étiquettes endommagées, la mauvaise luminosité et les emballages réfléchissants peuvent toujours se produire dans des environnements en direct.
• Surveillez de près le coût de la répinture d'Android. Les surimpressions 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, pas héroïque. Les équipes se mettent en difficulté lorsqu'elles échangent le conteneur d'application, le plugin de balayage, 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 comme actif, remplaçable ou risqué car il repose sur un comportement de plateforme plus ancien.

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

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

4. Remplacez les pièces de balayage fragiles en premier
   Les anciens plugins qui dépendent de couches d'interface utilisateur personnalisées, du comportement Android non documenté ou de la gestion de la caméra obsolète doivent être priorisés en haut de la liste.

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

Considérez cela comme une enquête de rendu, et non seulement une enquête 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 à 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 nette entre la gestion de la vue native et l'interface utilisateur web code. Pour le balayage de code-barres, @capgo/caméra-prévisualisation affiche une flux de caméra en direct comme une surcouche native avec des contrôles personnalisables, afin de pouvoir décoder des frames en JavaScript sans que la prévisualisation ne se trouve derrière la vue web. Pour le balayage d'entreprise sur les appareils Zebra, @capgo/capacitor-zebra-datawedge gère les profils DataWedge et les déclencheurs de balayage. Pour les workflows de tag NFC, @capgo/capacitor-nfc gère la découverte, la lecture et l'écriture de tags natifs sur iOS et Android.

Les projets Cordova tendent à se rompre en raison de l'âge des plugins, de la dérive de plateforme et d'hypothèses cachées dans les anciennes intégrations. Capacitor projets exposent des problèmes différents, principalement autour de la gestion de 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 au dispositif, 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 couche de vue web, et migrez ensuite en étapes contrôlées. Cette voie est plus lente pendant une semaine et plus rapide pour le reste du projet.