Comment écrire et verrouiller un tag NDEF depuis une application iOS ?
Dans une session qui reste ouverte : le drapeau de fin à la première lecture passe à faux, l'application se connecte à un tag, interroge son état et sa capacité, puis écrit le message entier en un appel. Le verrouillage est un second geste, et il ne se défait pas.
Une session qui reste ouverte
L'écriture se passe à l'intérieur d'une session de lecture : la session ne doit donc pas se terminer à la première lecture. La note d'Apple sur l'initialiseur demande de passer faux à invalidateAfterFirstRead dans une session qui écrit, ce qui la garde active jusqu'à ce que l'application en ait fini.
Le délégué implémente readerSession(_:didDetect:), disponible depuis iOS 13, pour recevoir des objets NFCNDEFTag plutôt que des messages, puis appelle connect(to:) sur celui qu'il veut. Un tag reste connecté jusqu'à ce que l'application en connecte un autre ou relance l'interrogation.
Deux tags dans le champ est un cas réel. L'exemple de lecteur de tags d'Apple compte les tags avant d'écrire, demande à l'utilisateur par alertMessage de les retirer tous, et relance l'interrogation après un court délai plutôt que d'écrire sur le mauvais.
L'état et la capacité d'abord
queryNDEFStatus rend deux valeurs qui décident de la suite : un état, notSupported, readOnly ou readWrite, et la capacité, c'est à dire le plus grand message NDEF que le tag peut stocker, en octets.
Comparez la capacité au message avant d'écrire. Un message qui ne tient pas échoue par ndefReaderSessionErrorTagSizeTooSmall, après que l'utilisateur a tenu son téléphone immobile pour rien.
L'écriture
writeNDEF(_:) enregistre le message entier en un appel et rend compte à son gestionnaire de fin, ou lève dans sa forme asynchrone. Sa référence la lie à l'état : n'écrivez que si queryNDEFStatus a rendu readWrite.
Les erreurs disent quelle étape a échoué : ndefReaderSessionErrorTagNotWritable pour un tag en lecture seule, ndefReaderSessionErrorTagSizeTooSmall pour un message trop long, ndefReaderSessionErrorTagUpdateFailure pour une mise à jour qui n'a pas abouti, et readerTransceiveErrorTagConnectionLost quand le tag a quitté le champ.
Après une mise à jour échouée ou une connexion perdue, relisez le tag avant de réessayer. L'écriture peut s'être arrêtée en chemin, le cas que la page de l'écriture interrompue traite du côté de l'utilisateur.
Quand l'écriture réussit, dites-le dans la feuille et terminez la session par invalidate(). Jusque là, l'utilisateur ignore qu'il peut bouger le téléphone.
Le verrouillage est définitif
writeLock() fait passer l'état du tag en lecture seule. Sa documentation explique qu'il met à jour l'octet de condition d'accès en écriture du contrôle de fichier NDEF du tag, et parle d'une action permanente qui ne peut pas être annulée.
Gardez-le comme une action distincte de l'écriture, prise une fois le contenu relu et vérifié sur l'autre plateforme. La question de savoir s'il faut verrouiller est traitée par la page du verrouillage.
Ce que les appels NDEF ne font pas
Les appels NDEF s'arrêtent au message. Un mot de passe, un compteur ou une page de configuration sont des commandes de puce, atteintes par une session de tag et le protocole propre au tag, sendMiFareCommand sur un tag MIFARE par exemple, les commandes venant de la fiche technique de la puce.
Ce travail quitte entièrement la session NDEF, ce qui explique que le choix de la session vienne en premier, sur la page des sessions.
Questions fréquentes
Pourquoi mon écriture échoue-t-elle par ndefReaderSessionErrorTagSizeTooSmall ?
Le message est plus grand que ce que le tag peut stocker. queryNDEFStatus rend la capacité en octets : comparez les deux avant d'écrire.
Un tag verrouillé peut-il être déverrouillé depuis iOS ?
Non. Apple décrit writeLock comme une action permanente qui ne peut pas être annulée.
Une application iPhone peut-elle poser un mot de passe sur un tag ?
Pas avec les appels NDEF. Un mot de passe se pose par des commandes de puce, envoyées dans une session de tag par le protocole du tag, les commandes venant de la fiche technique.
Pourquoi la session doit-elle rester ouverte après la lecture ?
L'écriture s'y passe. Avec invalidateAfterFirstRead à vrai, la session se termine après la première lecture et ne laisse rien avec quoi écrire.