Un cadre multiplateforme atteint-il toutes les fonctions NFC ?
Seulement ce que son greffon a enveloppé de chaque API native. Les déclarations restent celles des plateformes, manifeste Android et droit d'accès iOS comprises, et les fonctions qui n'existent que d'un côté obligent soit à les cacher, soit à rebrancher les deux chemins de code que le cadre devait supprimer.
Un greffon est du code natif
Les cadres multiplateformes atteignent les API des plateformes par du code natif. Flutter documente les canaux de plateforme pour appeler les API d'une plateforme depuis Kotlin ou Java sur Android et Swift ou Objective-C sur iOS, et React Native documente les modules natifs pour les API de plateforme que ni lui ni une bibliothèque existante ne fournit.
Un greffon NFC pour l'un ou l'autre est du code de cette nature. Sur Android il appelle les classes de technologie et la distribution que couvre cette rubrique, et sur iOS il appelle Core NFC. Il peut exposer ce que ces API offrent, et seulement la part que son auteur a enveloppée.
Les déclarations restent natives
Un cadre ne supprime pas ce que chaque plateforme exige. La permission NFC, les filtres d'Intent et, depuis Android 17, la permission de distribution sur l'activité qui reçoit vivent tous dans le manifeste Android, comme le décrit la page du manifeste.
Sur iOS, la capacité de lecture et son texte d'usage appartiennent au projet iOS que le cadre construit, exactement comme pour une application écrite en Swift.
Là où les deux plateformes diffèrent
Une API unique posée sur deux plateformes doit décider quoi faire de ce qu'une seule offre. Android sait lancer une application depuis un tag par son manifeste, choisir entre mode lecteur et dispatch au premier plan, et émuler une carte par émulation de carte par l'hôte ; iOS lit à l'intérieur d'une session que le système affiche.
Un greffon expose soit la seule part commune, soit des appels propres à une plateforme sur lesquels le code partagé doit brancher. Le premier cache les fonctions d'Android, le second ramène les deux chemins de code que le cadre devait supprimer.
Les applications rendues dans une WebView
Les cadres qui affichent l'application dans une vue web sont un cas à part. L'entrée de statut de plateforme de Chrome liste Web NFC dans Chrome sur Android seulement, sans prise en charge de la WebView d'Android : une page qui fonctionne dans Chrome n'obtient rien à l'intérieur d'une telle application.
Ces applications atteignent elles aussi le NFC par un greffon natif, ce qui leur laisse les mêmes limites que les cadres ci dessus.
Ce qu'il faut vérifier avant de choisir
Énumérez les appels dont le projet a besoin sur chaque plateforme, puis vérifiez-les un à un contre le greffon avant la première ligne de code : lecture et écriture NDEF, verrouillage, commandes brutes par technologie, lancement de l'application depuis un tag, et émulation de carte là où elle compte.
Puis testez sur de vrais téléphones des deux plateformes. Le champ se comporte de la même façon quel que soit le langage qui l'a appelé, et les échecs qui comptent, un tag qui part au milieu d'une écriture ou une puce qui refuse une commande, ne se montrent que là.
Questions fréquentes
Un cadre dispense-t-il du droit d'accès iOS ?
Non. Le droit d'accès appartient au projet iOS que le cadre construit, comme pour une application écrite en Swift, et Core NFC l'exige avant d'ouvrir une session.
Une application hybride peut-elle employer Web NFC dans sa WebView ?
Non. Le statut de plateforme de Chrome ne liste aucune prise en charge de la WebView pour Web NFC : une application hybride atteint le NFC par un greffon natif.
Un greffon expose-t-il l'émulation de carte par l'hôte ?
Seulement si son auteur l'a enveloppée, et seulement sur Android, où la plateforme l'offre aux applications. L'émulation de carte sur iPhone dépend des conditions d'Apple plutôt que du greffon.
Que vérifier en premier dans un greffon ?
Que chaque appel dont le projet a besoin existe sur chaque plateforme : lecture, écriture et verrouillage NDEF, commandes brutes, lancement de l'application depuis un tag, et émulation de carte si elle compte. Un appel manquant coûte moins cher à trouver avant d'écrire du code.