Comment écrire un message NDEF depuis une application Android ?

Construire le message

La classe NdefRecord construit pour vous les enregistrements courants : createUri depuis le niveau d'API 14, createMime depuis le niveau 16 et createTextRecord depuis le niveau 21. Assembler les octets à la main est le point de départ des erreurs d'encodage, et ces fabriques en dispensent.

createMime passe le type MIME en minuscules pour suivre les règles de filtrage d'Android : le type écrit sur le tag correspond donc déjà à un filtre écrit en minuscules.

Placez en premier l'enregistrement qui compte. Android distribue sur le premier enregistrement, et un message qui s'ouvre sur un enregistrement de texte est distribué comme text/plain, quoi qu'il vienne ensuite. Ce que contiennent les enregistrements est couvert par la page sur la structure d'un message.

Ce qu'il faut vérifier avant d'écrire

Trois valeurs s'obtiennent sans toucher à la radio. isWritable() dit si le tag est en lecture seule, et getMaxSize() donne le plus grand message NDEF qu'il accepte, en octets. Le message connaît sa propre taille : la référence de NdefMessage documente getByteArrayLength() comme la longueur qu'il occupera une fois sérialisé.

Comparez les deux dernières avant d'appeler quoi que ce soit qui écrive. Un message trop long d'un octet échoue à l'écriture, après que l'utilisateur a tenu son téléphone immobile pour rien, et la comparaison ne coûte rien.

getCachedNdefMessage() peut rendre null sur un tag formaté qui ne porte encore aucun message, ce que la référence appelle l'état initialisé. C'est un tag prêt à être écrit, et non un tag dont la lecture a échoué.

L'écriture elle même

connect(), puis writeNdefMessage(), puis close(), sur un fil autre que le principal. La référence de Ndef marque l'écriture comme bloquante et comme écrasant le message que le tag portait.

Un tag vierge passe plutôt par NdefFormatable.format(), qui le formate et y écrit un premier message en un seul appel. La référence décrit un processus en plusieurs étapes qui lève IOException si l'une d'elles échoue : une exception dit donc que le processus s'est arrêté, pas où.

Quatre exceptions appellent quatre réponses. FormatException signale un message mal formé. TagLostException signale que le tag a quitté le champ. IOException couvre les autres échecs et une annulation. SecurityException signale un objet Tag périmé, employé après le départ de son tag.

Après une TagLostException, ne supposez rien. Relisez le tag avant de réessayer, puisque l'écriture peut avoir abouti, échoué ou s'être arrêtée en chemin, le cas que la page de l'écriture interrompue traite du côté de l'utilisateur.

La lecture seule ne se défait pas

makeReadOnly() passe le conteneur de capacités en lecture seule et, là où le tag le permet, pose les bits de verrouillage définitivement. La référence parle d'un processus à sens unique qui ne peut pas être annulé.

Vérifiez d'abord canMakeReadOnly(), et n'attachez jamais cet appel au même bouton que l'écriture. NdefFormatable.formatReadOnly() fait les deux en un appel, ce qui supprime la dernière occasion de vérifier le contenu avant de le figer.

Verrouillez à la fin d'une série vérifiée, si vous verrouillez. Le moment où le verrouillage est la bonne décision est traité par la page du verrouillage.

Relire ce qui a été écrit

Vérifiez avec getNdefMessage(), qui lit le tag, et jamais avec le message en cache, qui décrit encore le tag tel qu'il était avant l'écriture.

Puis relisez le tag avec autre chose que votre code, et sur l'autre plateforme. Un bogue qui écrit le mauvais type d'enregistrement le décode de la même mauvaise façon, et un iPhone peut ignorer un enregistrement que votre analyseur Android accepte.