Que doit faire une application quand le NFC est coupé ou absent ?
Distinguer les états avant d'écrire le moindre message. Sur Android : aucun contrôleur, un contrôleur que l'utilisateur a coupé, et, depuis Android 16, des tags refusés à votre application. Sur iPhone : disponible ou non. Dites ensuite lequel c'est, et laissez le reste de l'application fonctionner.
Trois états sur Android
Ils demandent des réponses différentes, et la page des limites du contrôleur les lit à l'exécution. getDefaultAdapter() rend null quand le téléphone n'a aucun contrôleur NFC : la fonction n'existe pas et n'existera jamais sur cet appareil. isEnabled() rend faux quand l'utilisateur a coupé le NFC, ce qui est à un réglage d'être réglé. Et depuis Android 16 un utilisateur peut refuser les intents de tag à une application, ce que isTagIntentAllowed() signale pendant que l'adaptateur se dit allumé.
Le troisième est celui qui produit les meilleurs rapports de bug, parce que tout a l'air juste : le NFC est activé, l'application est installée, le manifeste est correct, et aucun tag n'arrive jamais.
Deux sur iPhone
Core NFC répond avant qu'une session existe : readingAvailable dit si l'appareil sait lire. Au-delà, ce sont les erreurs qui portent le reste, readerErrorRadioDisabled pour une radio éteinte et readerErrorUnsupportedFeature pour quelque chose que la session ne sait pas faire.
Il n'existe aucun équivalent de l'écran de réglages Android où envoyer l'utilisateur, ce qui change la formulation plutôt que la logique : un iPhone qui ne sait pas lire est un fait d'appareil, et le travail de l'application est de le dire une fois et de passer à autre chose. Quels iPhone lisent est le sujet de la page des modèles.
Quoi dire pour chacun
Aucun matériel : masquez la fonction plutôt que de l'expliquer. Un bouton qui ne peut pas marcher sur ce téléphone est une demande de support en attente, et son absence n'a besoin d'aucune phrase.
Coupé : proposez le réglage. Android expose l'écran des réglages NFC comme un intent, et y envoyer l'utilisateur vaut mieux que de décrire où il se trouve, puisque le chemin diffère d'un fabricant à l'autre, ce que montre la page de l'activation.
Refusé à l'application : dites-le, parce que rien d'autre dans l'interface ne le fera. L'utilisateur l'a choisi, peut-être par accident, et seul votre message relie le silence au réglage.
Ne jamais bloquer le reste
Un contact est une entrée parmi d'autres. Une application qui refuse de démarrer sans NFC a transformé une commodité en exigence, et l'utilisateur qui ne peut pas s'en servir est celui qui avait besoin de la solution de repli.
Gardez le chemin manuel : un code à saisir, une recherche, un scan, quoi que le tag ait abrégé. Et décidez séparément si l'application doit s'installer sur un téléphone sans la radio, ce qui est une question de magasin plutôt que d'exécution : la page du magasin la reprend.
Questions fréquentes
Comment savoir que le téléphone n'a aucun NFC ?
getDefaultAdapter rend null sur Android, et readingAvailable est faux sur iOS. Ce sont deux faits d'appareil, pas des réglages.
Puis-je activer le NFC depuis mon application ?
Non. Vous pouvez envoyer l'utilisateur vers l'écran des réglages NFC sur Android ; l'interrupteur appartient à l'utilisateur.
Pourquoi rien n'arrive-t-il alors que le NFC est activé ?
Depuis Android 16 l'utilisateur peut refuser les intents de tag à une application. isTagIntentAllowed le signale, et rien d'autre dans l'interface ne le fera.
L'application doit-elle refuser de tourner sans NFC ?
Non. Gardez le chemin manuel et laissez le reste de l'application fonctionner. Qu'elle s'installe ou non est une décision distincte, au niveau du magasin.