Construire une application de 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 le temps progressivement se tourner vers des outils plus récents. Alors 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à où scanner de code de barre 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 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 de plateforme qui ne se montrent que sur des appareils réels. Si votre application touche également les opérations de champ ou les flux d'inventaire, la fonction de balayage 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'actifs.

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 s'intégrer dans des applications hybrides d'entreprise conçues 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 balayage de code de barre de Cordova. 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 se montrent encore 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 en mode 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 d'intégration
  • É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
  • Qu'est-ce 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.

En 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 sur le 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.

Le Cordova est toujours pertinent en mode maintenance

A beaucoup d'équipes parlent de Cordova comme s'il avait disparu. C'est faux. Il a vieilli dans les portefeuilles d'entreprises axés sur la 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 votre équipe.

Cordova a également mérité sa place car les plugins ont exposé les capacités de dispositif natif de manière à ce que le web code puisse l'utiliser. C'est pourquoi le scan de code-barres est devenu si courant 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, et non 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 la logistique et du commerce de détail é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 post-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 les fonctionnalités dans des hypothèses Cordova uniquement.

Cette dernière point est important. 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 tout simplement pas où vous l'attendez.

Choisir votre plugin de lecture de code à barres Cordova

Avant d'écrire toute 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 superposition de la caméra pour les flux QR. Le choix du mauvais plugin au début crée du travail à refaire 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 pour les symbologies courantes, y compris 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 plus largement leur stratégie de plugin, 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 des symboles est plus importante qu'un API minimal. Si l'application n'a besoin que de la reconnaissance de QR, 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.
• Tolérance de migration : Demandez-vous si ce plugin deviendra douloureux si l'application passe à 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

Cette table reflète une adaptation pratique, et non un classement. 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 plus sûr. Si vous n'avez besoin que de scanner le QR et que vous voulez une expérience de prévisualisation plus contrôlée, un chemin orienté QR peut être plus léger.

L’erreur la plus fréquente que je vois est de choisir un outil axé 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 il y a 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 surviennent avant la première scan, et non après. Les 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 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 lecture de codes à barres dans Cordova. Si votre application est toujours fortement hybride au niveau architectural, ce guide sur le développement d'applications hybrides dans 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 :

1. Quels types de codes à barres l'application doit accepter.
2. Quelle que soit l'action de scanneur, elle s'effectue en mode plein écran ou fait partie d'un flux de travail intégré.
3. Qu'est-ce que l'application doit faire après une lecture réussie.
4. Quelle est la solution de rechange lorsque la caméra ne peut pas être utilisée.

Cela garde 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 Cordova

Pour une configuration Cordova traditionnelle utilisant le plugin de scanneur de code-barres 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 configuration 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à. Créez immédiatement après l'installation du plugin afin de détecter les problèmes de dépendance native avant de mettre en place l'interface utilisateur code. Si la compilation faille, résolvez cela en premier.

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 manque ou est vague, le scanneur ne comportera pas comme une fonctionnalité fonctionnelle aux utilisateurs. Ajoutez une description de confidentialité de la caméra claire dans Info.plist Ce qui explique pourquoi l'application nécessite la caméra.

On Android, passez en revue les entrées de 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 checklist rapide :

• Vérifiez les versions de plateforme : Les projets Cordova plus anciens contiennent souvent des packages de plateforme dépassés.
• Passez en revue les invitations de permission : La formulation et l'heure sont importantes pour la confiance des utilisateurs.
• Testez sur un appareil réel dès que possible : Les émulateurs ne vous diront pas assez sur le comportement de la caméra.
• Gardez la portée du scanner étroite : Activer uniquement les code types que votre flux de travail accepte.

Si votre lecteur nécessite uniquement un ou deux formats, configurez-les en premier. La lecture large semble 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 courant de Cordova utilise la méthode du plugin. scan(success, fail) La méthode de rappel est ancienne, mais elle 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 modélisation 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 how Capacitor bridges web and native code Une personne tenant un smartphone utilisant une application de caméra pour scanner un code-barres sur une boîte en carton.

Voici une mise en œuvre minimale pour une ancienne application Cordova :

Voici une mise en œuvre minimale pour une ancienne application Cordova :

<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 du 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 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 balayage

Un bon flux après balayage est généralement l'un de ces :

• Flux de recherche : Utilisez le texte balayé pour récupérer un enregistrement de produit, commande ou bien.
• Flux de validation : Comparez la valeur balayée contre une valeur attendue code déjà affichée.
• 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 balise de scanner devenir un dépotoir pour les appels API, les mises à jour de la zone de contenu, 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 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é 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 sur mon application capacitor mais il semble que le scanner est derrière l'application”, et la correction nécessite de rendre le fond de la vue web native transparent, ainsi que les changements de transparence de la zone de contenu DOM, ce qui n'est généralement pas couvert dans les tutoriels Cordova standard, comme documenté dans le Capacitor Problème de rendu Android. Si vous déboguez une migration hybride, ce guide sur la débogage des applications __CAPGO_KEEP_0__ est utile à garder ouvert. debugging Capacitor apps Symptôme

Vous lancez 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 __CAPGO_KEEP_0__-style, 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 le fond de la vue web en transparent.
• Volet côté web : Supprimez les arrière-plans opaques des éléments de conteneur situés au-dessus de la prévisualisation du scanner.
• Volet côté layout : 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.
• Volet côté test : Validez sur un appareil Android physique car le comportement de mise en page peut être trompeur dans les shells de développement.

Ceci est le bogue qui fait croire aux développeurs 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 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 s'afficher 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 :

• Déclenchez la lecture à partir d'une action utilisateur claire : Les invites de permission semblent moins suspectes.
• Afficher l'entrée par défaut : L'entrée manuelle maintient le flux de travail en vie.
• Tester les chemins de refus puis de réessais : Beaucoup d'équipes n'ont testé que la voie heureuse une fois.

Problèmes de construction et de test de dispositif

Certains échecs ne se montrent que dans 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 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écoder correctement et échouer tout de même en pratique. 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 piscine 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 l'analyse sont souvent plus gênants 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 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 facilite la couverture des tests.
• Logique post-lecture courte. Analyse, validation et mise à jour de la plus petite partie 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. Les étiquettes endommagées, la mauvaise luminosité et les emballages réfléchissants peuvent encore se produire dans des environnements de production.
• Surveillez 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, pas héroïque. Les équipes se mettent en difficulté lorsqu'elles remplacent 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 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 plugin de balayage 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 dès que possible.
   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 des écrans d'analyseur de code-barres échouer car la prévisualisation native se trouvait derrière la vue web, était coupée aux bords ou rendait 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 la vraie cause.

Traitez cela comme une enquête sur la mise en page, 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 de l'é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 mise en page web code. Pour l'analyse de code-barres, @capgo/prévisualisation-de-la-caméra affiche une prise en charge de caméra en direct comme une surimpression native avec des contrôles personnalisables, de sorte que vous puissiez décoder des 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 d'analyse. Pour les workflows de tag NFC, @capgo/capacitor-nfc gestion de la découverte, de la lecture et de 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 ceux-ci sont plus faciles à suivre car le côté native est plus explicite.

Si votre scanner Cordova actuel ne fonctionne que après une pile de correctifs spécifiques au appareil, 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.