Come si rileva che un tag ha lasciato il campo?

Su Android

Il flusso ordinario non ha alcun evento di uscita. La piattaforma verifica che un tag rilevato sia ancora presente, e il modo lettore lascia a un'applicazione fissare ogni quanto tramite EXTRA_READER_PRESENCE_CHECK_DELAY, che il riferimento di NfcAdapter descrive come il ritardo che la piattaforma usa per le verifiche di presenza. Quello che l'applicazione vede è la sua chiamata di ingresso e uscita successiva che fallisce con TagLostException, una sottoclasse di IOException.

isConnected() non risponde alla domanda. Il riferimento di TagTechnology dice che rende vero quando connect() è andata a termine, close() non è stata chiamata e il tag non risulta fuori portata, senza alcuna attività radio: segnala quello che la piattaforma già sa, non una verifica fresca.

Per un tag che resta al suo posto, come quello di un supporto da auto, lo strumento è NfcAdapter.ignore(), dal livello di API 24. Ferma la comunicazione con il tag mentre resta a portata e chiama un OnTagRemovedListener una volta che il tag è rimasto fuori portata per debounceMs; un tag che torna prima non viene smistato di nuovo. Il riferimento aggiunge tre limiti: il controller sonda ogni 100-500 ms, quindi un tag che entra ed esce dalla portata può essere smistato di nuovo pur non essendosene mai andato davvero; un altro tag annulla la chiamata; e un tag con un identificatore casuale la vanifica.

Su iOS

Ogni tag che Core NFC consegna eredita da NFCNDEFTag, il cui isAvailable passa a falso quando il tag viene tolto dal campo o disconnesso, secondo il riferimento di isAvailable. Nessuna chiamata al delegato lo segnala: un'applicazione che deve saperlo legge la proprietà, oppure lo apprende da un comando che fallisce con readerTransceiveErrorTagConnectionLost.

Anche una connessione può finire mentre il tag resta. Un tag resta connesso finché l'applicazione non si connette a un altro o non riavvia il sondaggio, secondo il riferimento di connect, e la nota di Apple su restartPolling() dice che i tag rilevati prima di un riavvio sono invalidi.

Una sessione NDEF aspetta da sé. Con un delegato che riceve messaggi, la sessione riavvia il sondaggio una volta che i tag rilevati sono fuori portata, come spiega la pagina dei più tag, quindi un tag tenuto fermo non viene letto due volte di fila.

Perché è sempre in ritardo

L'uscita si deduce dal silenzio. Un telefono sa che un tag se n'è andato quando una verifica di presenza o un comando non ricevono risposta, e il riferimento di NfcAdapter mette l'intervallo di sondaggio del controller fra 100 e 500 ms. L'applicazione viene a sapere dell'uscita dopo che la mano si è mossa, mai nel momento in cui si muove.

Progetta l'interfaccia attorno a quel ritardo. Una scrittura data per fatta prima che la sua chiamata sia tornata è un'ipotesi: mostra il completamento quando la chiamata torna, e tratta un'eccezione come un esito sconosciuto, come spiega la pagina delle scritture interrotte.

Le doppie letture cominciano qui

Un tag che se ne va e torna è un nuovo rilevamento. Su Android arriva come un nuovo oggetto Tag, dato che il riferimento di Tag ne crea uno ogni volta che il tag entra a portata; su iOS la sessione lo rileva di nuovo una volta che se n'è andato. La pagina del doppio scatto descrive come una mano lo produca senza volerlo.

Un'applicazione che deve agire una volta per tocco decide quindi che cosa conta come ripetizione. Confrontare l'identificatore con l'ultimo letto, dentro una finestra di tempo che l'applicazione sceglie, prende il caso comune, e ignore() fa lo stesso su Android per un tag lasciato al suo posto. Nessuno dei due funziona con identificatori casuali, dove è il lato che riceve a dover tollerare le ripetizioni, la conclusione a cui la pagina del doppio scatto arriva per i server.