Page web ou application native : laquelle pour un projet NFC ?
Ni l'une ni l'autre dans la plupart des projets publics : un lien écrit sur le tag est ouvert par le téléphone lui même. Quand du code est nécessaire, la page sert un parc Android sous Chrome, et l'application dès qu'il y a des iPhone ou quoi que ce soit sous le NDEF.
Lire le tag ou ouvrir une page
La plupart des projets publics ne lisent jamais un tag par du code. Un lien écrit sur le tag est ouvert par le téléphone lui même, sur Android comme sur iPhone, et la page à l'autre bout n'a besoin d'aucune API NFC. La page du tag qui marche sur tous les téléphones en donne la recette.
Le code entre en jeu quand quelque chose doit se passer entre le contact et la page : lire plusieurs tags à la suite, en écrire, vérifier un identifiant, ou parler à la puce. C'est là que commence le choix entre une page et une application.
Ce que chacune atteint
| Question | Page web | Application native |
|---|---|---|
| Téléphones atteints | Chrome sur Android | Android et iPhone |
| Contenu | NDEF seulement | NDEF et commandes brutes |
| Émulation de carte | Non | Sur Android, par émulation de carte par l'hôte |
| Lancée par un tag quand elle est fermée | Non | Sur Android par le manifeste, sur iPhone par un lien que l'application revendique |
| Distribution | Une adresse web | Une fiche de boutique |
Le tableau penche volontairement d'un côté. L'article de Chrome sur Web NFC explique que l'API a été limitée au NDEF parce que les propriétés de sécurité de la lecture et de l'écriture de données NDEF sont plus faciles à quantifier.
Quand la page gagne
Pour un outil interne sur des téléphones que le projet maîtrise, la page est difficile à battre : pas de validation en boutique, pas d'installation, et une mise à jour est un déploiement du site. Les exemples de l'article sont de cette nature, gestion d'inventaire et contrôle de badges dans une conférence.
Ses conditions conviennent à ce cadre. Chrome sur Android peut être exigé d'un parc, la permission est accordée une fois par site, et la page reste affichée pendant que les gens travaillent.
Quand l'application gagne
Dès que des iPhone doivent lire ou écrire des tags, la page est hors jeu. L'entrée de statut de plateforme de Chrome ne liste aucune prise en charge iOS, et la position publiée de WebKit s'oppose à l'API. Un iPhone lit les tags par Core NFC, dans une application.
L'application gagne aussi sous le NDEF, pour les mots de passe, les compteurs, les signatures et l'émulation de carte, et partout où un tag doit la lancer sans que l'utilisateur ouvre quoi que ce soit d'abord, ce que seule une application installée sait organiser.
Un cadre multiplateforme peut partager le code entre les deux applications, dans les limites décrites sur la page des cadres.
Questions fréquentes
Une seule page web peut-elle couvrir Android et iPhone ?
Pour lire ou écrire des tags, non : Web NFC ne tourne que dans Chrome sur Android. Pour ouvrir une page depuis un tag, oui : écrivez son adresse sur le tag et les deux plateformes l'ouvrent.
Web NFC est-il un standard du web ?
Il est spécifié dans un groupe communautaire du W3C, ce que le statut de plateforme de Chrome décrit comme une incubation, et seul Chrome le livre. La position publiée de WebKit s'y oppose et celle de Mozilla est négative.
Laquelle coûte le moins cher à construire ?
La page, pour du personnel sur des téléphones Android sous Chrome. L'application, dès qu'il y a des iPhone ou quoi que ce soit sous le NDEF, que la page ne peut atteindre à aucun prix.
Un tag peut-il ouvrir une page qui lit ensuite d'autres tags ?
Sur Android avec Chrome, oui : le tag ouvre la page, et la page démarre le scan après un appui sur un bouton. Le premier tag est traité par le téléphone lui même, pas par la page.