Perché una lettura fallisce con un errore di tag perso?
Perché il tag ha lasciato il campo prima che lo scambio finisse, cosa che una mano fa in mezzo secondo. Android solleva TagLostException da qualunque operazione che tocchi la radio, iOS fallisce con un errore di connessione persa, e una scrittura interrotta così lascia un esito che nessuno conosce ancora.
Cosa solleva ogni piattaforma
Su Android ogni operazione che tocca la radio può sollevarlo. Il riferimento di TagLostException ne fa una sottoclasse di IOException, e connect(), transceive(), readPages() e writePage() lo dichiarano tutti. Un errore diverso vuol dire un problema diverso: riusare un oggetto Tag dopo che il suo tag è andato via solleva SecurityException, perché quell'oggetto apparteneva a una sola comparsa.
Su iOS lo stesso evento arriva come codice di errore. readerTransceiveErrorTagConnectionLost dice che il lettore ha perso la connessione al tag, e i suoi vicini nominano gli altri casi: readerTransceiveErrorTagNotConnected quando il tag non è nello stato collegato, readerTransceiveErrorSessionInvalidated quando la sessione è finita sotto di lui, readerTransceiveErrorRetryExceeded quando i tentativi sono stati troppi.
Prima la mano, poi il codice
Le cause fisiche vengono per prime perché sono quelle frequenti. Una scrittura dura più di una lettura, quindi un gesto che legge in modo affidabile può essere troppo breve per scrivere, cosa che la pagina della scrittura a metà descrive dal lato di chi usa. Una custodia spessa, un tag piccolo o un angolo scomodo non lasciano margine, e il tag esce dalla portata con un millimetro di movimento.
Le cause di codice sono più sottili. Ogni comando è un'andata e ritorno, quindi una sequenza di venti lascia venti occasioni di perdere il tag, e il lavoro fatto fra due comandi, un calcolo o peggio una chiamata di rete, tiene il tag aperto per niente. Aprire un'altra classe di tecnologia a metà sequenza può far riselezionare il tag alla piattaforma, cosa che la pagina dell'autenticazione copre dove costa di più.
Cosa fare del tag che hai perso
Tratta un tag perso durante una scrittura come un esito sconosciuto e non come un guasto. Il comando può aver raggiunto il tag prima che la risposta si perdesse, quindi il passo successivo è rileggere la memoria, non riscrivere, e un ordine che non lascia nulla a metà rende la cosa leggibile: la pagina delle scritture interrotte lo espone.
Poi riparti dall'inizio. Il tag che torna è un rilevamento nuovo, un oggetto Tag nuovo su Android e un rilevamento nuovo su iOS, ogni autenticazione è sparita, e una sequenza non si può riprendere da metà. Il codice che conserva uno stato attraverso una perdita deve riconciliarlo con quello che rilegge.
Allargare abbastanza la finestra
Accorcia lo scambio invece di allungare la scadenza. Leggi nei blocchi più grandi che il protocollo offre, tieni basso il numero di comandi, e fai prima del tocco tutto quello che non ha bisogno del tag, il conto che la pagina delle scadenze rende esplicito.
Poi disegna l'interfaccia per una mano. Di' a chi usa quando allontanarsi, mostra il completamento solo quando la chiamata è tornata, e prova con il telefono in mano invece che appoggiato sulla scrivania, dove la finestra non si chiude mai e il difetto non compare mai.
Domande frequenti
Un errore di tag perso vuol dire che il tag è rotto?
Quasi mai. Vuol dire che il tag ha lasciato il campo a metà scambio. Lo stesso tag di solito si legge al tentativo successivo se il telefono sta fermo.
Posso riprendere uno scambio dopo che il tag torna?
No. Il tag che torna è un rilevamento nuovo, e ogni autenticazione è sparita. Riparti dal rilevamento, e rileggi prima di riscrivere.
Perché una scrittura fallisce più spesso di una lettura?
Dura di più, quindi ha bisogno di una tenuta più lunga. Un gesto che legge in modo affidabile è regolarmente troppo breve per scrivere.
Che ci fa SecurityException qui?
Vuol dire che il codice ha riusato un oggetto Tag di una comparsa precedente. Ogni rilevamento dà un oggetto nuovo, e funziona solo il più recente.