Pourquoi une commande expire-t-elle, et combien de temps attendre ?
Android laisse le code poser un délai par technologie et le remet à sa valeur par défaut quand la connexion se ferme ; cette valeur n'est pas documentée, donc lisez-la au lieu de la supposer. iOS n'expose aucun délai. Dans les deux cas, la réponse à une expiration est d'ordinaire moins de commandes, pas une attente plus longue.
Ce qu'Android expose
setTimeout() sur NfcA ou IsoDep pose la durée pendant laquelle transceive() attend. Deux détails de la référence décident de son emploi : la valeur revient à sa valeur par défaut quand la connexion se ferme, donc elle se repose après chaque connect(), et cette valeur par défaut n'est pas documentée, donc getTimeout() est la seule façon honnête de la connaître.
Une valeur plus longue sert aux opérations qui prennent du temps au tag, la génération d'une clé étant l'exemple de la référence elle-même. Elle ne fait pas répondre un tag qui ne répondrait jamais, et elle n'aide pas un tag qui est parti, lequel lève TagLostException à la place, le sujet de la page du tag perdu.
Le mode lecteur ajoute une seconde horloge : le délai que la plateforme emploie pour vérifier qu'un tag découvert est toujours présent, posé par l'extra de contrôle de présence, que couvre la page du départ du tag.
Ce qu'iOS n'expose pas
Core NFC n'a aucun délai à poser. L'application envoie une commande et attend, et le cadre signale readerTransceiveErrorRetryExceeded quand il y a eu trop de nouvelles tentatives, ou une erreur de connexion perdue quand le tag est parti.
La session a sa propre limite, une invalidation dont aucune durée n'est documentée, que reprend la page de l'invalidation. Sur iOS le seul levier est donc la quantité que l'application demande, et sa vitesse à répondre : en émulation de carte, Apple avertit qu'une réponse lente peut être lue comme une expiration par le lecteur.
Ce que coûte un aller-retour
Chaque commande est un aller-retour, et le budget d'un contact est mince. Le guide de l'émulation de carte d'Android place une borne haute raisonnable autour de 1 Ko de données échangées en quelque 300 ms, ce qui est le repère publié le plus net de ce qui tient pendant qu'une main reste immobile.
Lisez donc par les blocs que le protocole vous donne. Un READ de type 2 rend quatre pages d'un coup, seize octets pour une commande, comme le décrit la page du type 2 ; une lecture de type 4 est plafonnée par le maximum du conteneur lui-même, et demander moins que ce maximum coûte des commandes qui n'achètent rien.
Concevoir dans la fenêtre
Faites le travail avant le contact. Allez chercher ce dont l'échange a besoin, construisez les trames, ouvrez la connexion réseau, et gardez le temps du tag pour le tag : une application qui appelle un serveur pendant qu'elle tient un tag a mis un réseau sur le chemin critique d'un geste de la main.
Traitez ensuite une expiration comme inconnue plutôt que comme un échec, surtout après une écriture, et relisez le tag avant de décider quoi que ce soit. Une nouvelle tentative qui suppose que la commande précédente n'a rien fait est la façon dont un compteur s'incrémente deux fois.
Questions fréquentes
Quel est le délai par défaut sur Android ?
Non documenté. Lisez-le par getTimeout sur la technologie que vous avez ouverte, et reposez votre propre valeur après chaque connect.
Puis-je poser un délai sur iOS ?
Non. Core NFC n'en expose aucun. Il signale trop de tentatives ou une connexion perdue, et la session a sa propre limite non documentée.
Combien puis-je échanger en un contact ?
Le guide de l'émulation de carte d'Android donne environ 1 Ko en quelque 300 ms comme borne raisonnable, repère utile pour la lecture aussi.
Une expiration est-elle la même chose qu'un refus ?
Non. Un refus revient comme un mot de statut ou un drapeau d'erreur venu du tag. Une expiration veut dire que rien n'est revenu, donc l'issue est inconnue.