Construire une application de lecteur de code-barres Cordova : Guide 2026

Vous êtes probablement dans l’une ou l’autre des situations. Soit vous avez hérité d’une application Cordova qui compte encore pour l’entreprise, soit vous maintenez une application hybride stable tout en laissant progressivement l’équipe se tourner 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 lecteur 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 de choisir un plugin qui correspond à vos formats de code-barres, configurer les permissions natives proprement, et 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 terrain ou les flux d'inventaire, la fonctionnalité de scanneur se connecte généralement à des préoccupations opérationnelles plus larges comme gérer les composants IT critiquesoù 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 scanneur de code-barres dans Cordova avait déjà dépassé les exemples de jouets pour s'attaquer à des applications hybrides d'entreprise construites pour Android et connectées aux services backend, y compris un flux documenté utilisant cordova create, cordova platform add androidet un barcodeScanner-debug.apk généré dans un exemple de construction d'application pratique deSitePoint’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 apparaissent encore dans les pipelines de livraison mobile sérieux.

• Why Ajoutez 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
• 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 de Cordova
  • Configuration native qui casse généralement en premier
• Mise en œuvre du Lecteur de Codes-barres dans votre Application Code
  • Exemple de 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 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, cela réduit le nombre de façons dont un utilisateur peut entrer une valeur incorrecte.

Dans la 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 des 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 s'il avait disparu. C'est faux. Il a vieilli dans les portefeuilles d'entreprises axés sur la 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 si le reste de l'application échoue déjà votre opération.

Cordova a également gagné sa place car les plugins exposaient 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è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 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 ce qui l'entoure :

• Choisir les symbologies prises en charge : Votre application peut avoir besoin uniquement de QR, ou peut avoir besoin également de codes de la logistique et du commerce de détail.
• 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 de 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 pas où vous l'attendez.

Choisir votre plugin de balayage de code de Cordova

Avant d'écrire toute application code, décidez ce que vous optimisez. Certaines équipes ont besoin d'un large support de code-barres. D'autres n'ont besoin que d'une superposition de 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 est pourquoi il convient à des 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 de 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 ceci 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

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 des symboles est plus importante qu'un API minimal. Si l'application n'a besoin que de scanner des QR codes d'inscription, 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 avoir recours à des contournements maladroits. »

Un bon checklist de sélection ressemble à ceci:

• Couverture des codes-barres : Confirmez les formats exacts utilisés en production.
• Attentes du système : 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 balayage 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 se déplace vers Capacitor plus tard.

Un plugin qui fonctionne dans une 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 de plugins

Cette table reflète un ajustement 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.

La erreur la plus fréquente que je vois est de choisir un outil axé sur les QR car la première mise à jour nécessite uniquement les QR, puis de forcer ensuite les UPC ou Code 128. 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

L'intégration se brise généralement avant la première scan, et non après. La plupart des échecs 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 la mise en place d'un écouteur de scan. Cette séquence est décrite dans la guide de Scandit pour Cordova 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 détection 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

Un élément 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 que soit si le scan est une action plein écran ou partie d'un flux intégré.
3. Quel est l'action que l'application doit effectuer après une lecture réussie.
4. Quel est le recours en cas où la caméra ne peut pas être utilisée.

Cela garde l'installation du plugin liée à un flux réel plutôt qu'à une capacité de dispositif générique.

Étapes d'installation Cordova

Pour une mise en place traditionnelle de Cordova utilisant le plugin de baliseur de code 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.

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 des permissions manque ou est vague, le baliseur ne comportera pas comme un fonctionnement de feature pour les utilisateurs. Ajoutez une description de confidentialité de caméra claire dans Info.plist qui explique pourquoi l'application a besoin de la caméra.

Sur Android, passez en revue 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 rapide checklist :

• Vérifiez les versions des plateformes : Les projets Cordova anciens contiennent souvent des packages de plateforme périmés.
• 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 scanner nécessite uniquement un ou deux formats, configurez-les en premier. La balayage large 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 balayage derrière un bouton, enregistrez le résultat complet et prouvez que le flux de rappel fonctionne avant de concevoir une interface utilisateur élégante autour.

Le modèle de balayage Cordova courant 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 un modèle mental plus clair pour comprendre comment les appels web __CAPGO_KEEP_0__ appellent les __CAPGO_KEEP_1__ natifs dans ces projets, cette explication de scan(success, fail) comment 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.

Ici est une mise en œuvre minimale pour une ancienne application Cordova :

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

<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 fait trois choses utiles. Il attend que deviceready, lie la reconnaissance à 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 reconnaissance de la logique métier. Cela compte car le plugin de scanner devrait uniquement capturer l'entrée. La validation, la recherche et la navigation appartiennent àilleurs.

Ce que faire avec le résultat de la reconnaissance

Un bon flux post-reconnaissance 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 à 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 zone de notification, les analyses et la navigation. Transférez la valeur rapidement.

En outre, loguez 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 le débogage des étiquettes incohérentes. Si l'opération dit « le scanner ne peut pas lire ce code », la formatage des données vous indique souvent si le problème est le type de code-barre, et non la qualité du 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.

Le problème le plus difficile à diagnostiquer est le bug de rendu Android qui se produit pendant les migrations de Capacitor ou les configurations mixtes Cordova-Capacitor. Un développeur dans l'issue #1213 de Capacitor l'a décrit clairement : “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 background de la zone de notification web native transparent, ainsi que les changements de transparence DOM correspondants, 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 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 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 :
__CAPGO_KEEP_0__ 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. 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 au-dessus de 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 disposition peut être trompeur dans les shells de développement.

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

Les échecs de permission et les 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 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éclencher l'analyse à partir d'une action utilisateur claire : Les invites de permission ressentent moins le soupçon.
• Afficher l'entrée par défaut : L'entrée manuelle maintient la workflow en vie.
• Tester les chemins de refus puis de relecture : 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 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 layout ou un 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 encore à l'utilisateur en pratique. Le problème se manifeste généralement sous forme de latence, de clignotement, de bugs de prévisualisation de la caméra ou d'une écran d'Android qui se comporte différemment d'appareil à appareil du même pool de test.

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 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 exactement là où la mise en page webview d'Android est déjà fragile.

Un certain nombre de changements tendent à payer rapidement :

• 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.
• Logique de post-scan 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. Les étiquettes endommagées, la mauvaise éclairage et les emballages réfléchissants peuvent encore se produire dans les environnements de production.
• Surveillez de près le coût de la répintation 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 échangent le conteneur d'application, le plugin de balayage, le flux de permissions et les surcharges 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 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 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 de réécrire le scanner, l'accès aux fichiers et la gestion des permissions en même temps.

4. Remplacez les pièces de scanner fragiles dès le début.
   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 doivent être priorisés.

Le bug de la prévisualisation de la caméra Android mérite une attention particulière car il gaspille beaucoup de temps de 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 se rend noire 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 scanner. Supprimez les surimpressions décoratives. Réduisez la page au 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 UI web code. Pour la détection de code-barres, @capgo/camera-preview 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 trames en JavaScript sans que la prévisualisation ne se trouve derrière la vue web. Pour la détection 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 gère 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, de la dérive de plateforme et d'hypothèses cachées à l'intérieur des anciennes intégrations. Capacitor projets 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 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 superposition de la couche 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.