Construirez 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 le temps au personnel pour se tourner vers des outils plus récents. 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-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 la sélection d'un plugin qui correspond à vos formats de code-barre, 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 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'actif.

Cordova est toujours une pile réelle dans le travail de maintenance d'entreprise. À la mi-2010, le balayage de code-barre dans Cordova avait déjà dépassé les exemples de jouets pour se diriger vers 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 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 retrouvent encore dans les pipelines de livraison mobile sérieux.

Sommaire des chapitres

• Why ajoutez-vous 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émonstration.
• Choisissez 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.
  • Démarrez par le flux d'intégration.
  • Étapes d'installation Cordova.
  • Configuration native qui casse généralement en premier.
• Implémenter le 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
  • Problèmes de permissions et faux négatifs
  • Problèmes de construction et de test de périphérique
• Conseils de performance et migration vers Capacitor
  • Un chemin de migration pratique vers Capacitor

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

Un lecteur de codes-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 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 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 codes-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 lourds en maintenance, 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 l'ensemble du 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. Il s'inscrivait dans le 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 de QR uniquement, 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 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 lecteur de code-barres 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 des 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 supplémentaire 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 la 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 plugins Capacitor ce qui le rend utile est qu'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

N'oubliez pas de ne pas commencer par la popularité seule. Commencez par votre tâche d'analyse.

Si l'application doit lire plusieurs familles de codes-barres dans différents contextes opérationnels, une large couverture de symboles est plus importante qu'un API minimal. Si l'application n'a besoin que de la lecture 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.
• 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 QR uniquement

L’erreur la plus fréquente que je vois est de choisir un outil centré sur les codes QR parce que la première version n'a besoin que de QR, puis de forcer l'intégration pour les codes 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 proviennent de la dérive de la configuration entre les attentes JavaScript et la configuration native de la plateforme. 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 la mise en place 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 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.

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. Quelle que soit l'action de balayage, elle s'effectue en mode plein écran ou fait 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.

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 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 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 cela en premier.

Configuration native qui casse généralement en premier

Sur iOS, l'accès à la caméra doit être déclaré correctement dans les paramètres du projet natif. Si la description d'utilisation de la permission manque ou est vague, le balayeur ne comportera pas comme un fonctionnement de caractère pour les 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 plugins en chevauchement 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 tableau de bord rapide :

• Vérifiez les versions de plateforme : Les projets Cordova anciens contiennent souvent des packages de plateforme obsolètes.
• Passez en revue 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 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 compilée, gardez la première mise en œuvre ennuyeuse. 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 Cordova utilise la méthode du plugin. 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 __CAPGO_KEEP_0__ appellent les __CAPGO_KEEP_1__ natifs dans ces projets, cette explication de la façon dont __CAPGO_KEEP_0__ relie les web et les __CAPGO_KEEP_1__ natifs vous aidera, même si vous codez encore en Cordova aujourd'hui. scan(success, fail) method. That callback style is old, but it’s dependable in legacy codebases and easy to wrap later if your app has moved toward promises or TypeScript abstractions. If you want a clearer mental model for how web code calls native code in these projects, this explanation of how Capacitor bridges web and native code Voici une mise en œuvre minimale pour une ancienne application Cordova :

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 __CAPGO_KEEP_0__

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

Cela réalise trois choses utiles. Il attend que devicereadylié à 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 lecture de la logique métier. Cela compte car le plugin de lecture ne doit capturer que l'entrée. La validation, la recherche et la navigation appartiennent àilleurs.

Ce que faire avec le résultat de la lecture

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

• Flux de recherche : Utilisez le texte scanné pour récupérer un enregistrement de produit, commande ou bien.
• Flux de validation : Comparez la valeur scannée avec une valeur attendue code déjà affichée sur l'écran.
• Flux de navigation : Routez l'utilisateur dans 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.

Loguez également 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 code-barre.

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 capacitor application 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 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 lecteur de codes-barres. Les autorisations semblent correctes. Aucun crash évident n'arrive. Mais l'aperçu de la caméra apparaît invisible, bloqué ou « derrière » l'interface utilisateur de l'application.

Cause
La vue de lecture de codes-barres native 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 l'aperçu native existe mais reste caché 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 :

• Paramètres de vue web : Définissez la couleur d'arrière-plan de la vue web en transparent.
• Côté web : Supprimez les arrières-plans opaques des éléments de conteneur situés au-dessus de la prévisualisation du scanner.
• 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 d'arrière-plan par défaut.
• 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.

C'est le bug 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 permission 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 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 le scan à partir d'une action utilisateur claire : Les invites de permission semblent moins suspectes.
• Affichez l'entrée par défaut : L'entrée manuelle maintient le flux de travail en vie.
• Testez les chemins de refus puis de réessayage : Beaucoup d'équipes ne testent que la voie heureuse une fois.

Problèmes de build et de test de dispositif

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 d'appareil code, et non le plugin.

Conseils de performance et migration vers Capacitor

Un lecteur de codes-barres peut décoder correctement et échouer encore à l'utilisateur 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 Android qui se comporte différemment sur différents appareils provenant du 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 généralement plus difficiles à gérer 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 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.
• Conservez la logique post-lecture courte. Analysez, validez et mettez à jour 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 les 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 peinture 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 mettent 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 de réécrire la gestion du scanner, l'accès aux fichiers et les autorisations en même temps.

4. Remplacez les pièces de scanner 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 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-barre est souvent blâmé en premier, même si la composition de la vue est la vraie cause.

Traitez cela comme une investigation de rendu et non seulement comme une investigation de code-barre. Supprimez les surimpressions décoratives. Réduisez la page au seul aperçu, un seul déclencheur et un seul champ de résultat. Si l'aperçu 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 l’UI web code. Pour la lecture de code-barres, @capgo/camera-preview affiche un flux de caméra en direct sous forme d'une surimpression native avec des contrôles personnalisables, vous permettant de décoder des frames en JavaScript sans que l'aperçu ne se trouve derrière la vue web. Pour la lecture 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 des hypothèses cachées à l'intérieur des 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é native 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.