Perché un comando scade, e quanto deve aspettare il codice?
Android lascia al codice fissare una scadenza per tecnologia e la riporta al valore di partenza quando la connessione si chiude; il valore predefinito non è documentato, quindi va letto invece che dato per scontato. iOS non espone alcuna scadenza. In tutti e due i casi la risposta a una scadenza è di solito meno comandi, non un'attesa più lunga.
Quello che Android espone
setTimeout() su NfcA o su IsoDep fissa quanto aspetta transceive(). Due dettagli del riferimento decidono come si usa: il valore torna a quello di partenza quando la connessione si chiude, quindi si rimette dopo ogni connect(), e il valore di partenza non è documentato, quindi getTimeout() è l'unico modo onesto di conoscerlo.
Un valore più lungo serve alle operazioni che prendono tempo al tag, e la generazione di una chiave è l'esempio del riferimento stesso. Non fa rispondere un tag che non risponderebbe mai, e non aiuta un tag che è andato via, che solleva invece TagLostException, l'argomento della pagina del tag perso.
Il modo lettore aggiunge un secondo orologio: il ritardo che la piattaforma usa per verificare che un tag rilevato sia ancora presente, fissato tramite l'extra della verifica di presenza, che la pagina dell'uscita dal campo copre.
Quello che iOS non espone
Core NFC non ha alcuna scadenza da fissare. L'applicazione manda un comando e aspetta, e il framework segnala readerTransceiveErrorRetryExceeded quando i tentativi sono stati troppi, oppure un errore di connessione persa quando il tag è andato via.
La sessione ha un limite suo, un'invalidazione senza durata documentata, che la pagina dell'invalidazione riprende. Quindi su iOS l'unica leva è quanto l'applicazione chiede, e quanto in fretta risponde: nell'emulazione di scheda Apple avverte che il lettore può trattare una risposta tardiva come una scadenza.
Quanto costa un'andata e ritorno
Ogni comando è un'andata e ritorno, e il bilancio di un tocco è piccolo. La guida all'emulazione di scheda di Android mette un limite superiore ragionevole intorno a 1 KB di dati scambiati in circa 300 ms, che è il riferimento pubblicato più chiaro di quello che sta dentro una mano ferma.
Leggi quindi nei blocchi che il protocollo ti dà. Un READ di tipo 2 rende quattro pagine in una volta, sedici byte per un comando, come descrive la pagina del tipo 2; una lettura di tipo 4 è limitata dal massimo del contenitore stesso, e chiedere meno di quel massimo costa comandi che non comprano niente.
Progettare dentro la finestra
Fai il lavoro prima del tocco. Vai a prendere quello che serve allo scambio, costruisci le trame, apri la connessione di rete, e tieni il tempo del tag per il tag: un'applicazione che chiama un server mentre tiene un tag ha messo una rete sul cammino critico di un gesto della mano.
Poi tratta una scadenza come sconosciuta e non come fallita, soprattutto dopo una scrittura, e rileggi il tag prima di decidere qualsiasi cosa. Un nuovo tentativo che dà per scontato che il comando precedente non abbia fatto niente è il modo in cui un contatore viene incrementato due volte.
Domande frequenti
Qual è la scadenza predefinita su Android?
Non è documentata. Leggila con getTimeout sulla tecnologia che hai aperto, e rimetti il tuo valore dopo ogni connect.
Posso fissare una scadenza su iOS?
No. Core NFC non ne espone nessuna. Segnala troppi tentativi o una connessione persa, e la sessione ha un limite suo non documentato.
Quanto posso scambiare in un tocco?
La guida all'emulazione di scheda di Android dà circa 1 KB in circa 300 ms come limite ragionevole, che è un riferimento utile anche per la lettura.
Una scadenza è la stessa cosa di un rifiuto?
No. Un rifiuto torna come byte di stato o come contrassegno di errore del tag. Una scadenza vuol dire che non è tornato niente, quindi l'esito è sconosciuto.