Sessione NDEF o sessione di tag: quale deve aprire un'applicazione iOS?
La sessione NDEF quando il tag porta un messaggio e il compito dell'applicazione è quel messaggio. La sessione di tag quando serve il chip: un identificatore, un contatore, una password, un blocco di memoria fuori dal NDEF. La seconda costa due dichiarazioni in più e non esiste prima di iOS 13.
Che cosa fa una sessione NDEF
Core NFC legge i dati NDEF dai tag dei tipi da 1 a 5, secondo la presentazione del framework di Apple, e NFCNDEFReaderSession è la sessione fatta per questo. Consegna ogni messaggio al proprio delegato tramite readerSession(_:didDetectNDEFs:), senza oggetto tag e senza comandi.
Da iOS 13, la stessa sessione può anche consegnare i tag stessi. Un delegato che realizza readerSession(_:didDetect:) riceve oggetti NFCNDEFTag, si connette a uno di essi, e può interrogarlo, scriverlo e bloccarlo, come descrive la pagina della scrittura.
Il contrassegno invalidateAfterFirstRead decide quanto vive la sessione. Messo a vero, finisce dopo il primo tag letto con successo; messo a falso, continua a leggere finché non scade o non viene annullata. La nota di Apple sull'inizializzatore dice di metterlo a falso per una sessione che scrive.
Che cosa aggiunge una sessione di tag
NFCTagReaderSession, disponibile da iOS 13, rileva i tag per tecnologia radio invece che per contenuto. Le sue opzioni di sondaggio scelgono che cosa cerca: iso14443 per i tag compatibili con ISO 7816 e per i MIFARE, iso15693 per i tag di vicinanza, iso18092 per FeliCa, e da iOS 16 un'opzione pace.
Ogni tag rilevato arriva come un valore NFCTag il cui caso dà il protocollo: NFCISO7816Tag per le APDU, NFCISO15693Tag per i comandi a blocchi, NFCFeliCaTag, oppure NFCMiFareTag per i comandi MIFARE. Ognuno di essi è conforme anche a NFCNDEFTag, quindi una sessione di tag legge e scrive NDEF a sua volta.
Il prezzo sta nelle dichiarazioni. Oltre all'abilitazione e alla descrizione d'uso di cui ogni applicazione Core NFC ha bisogno, la documentazione della classe consegna un tag ISO 7816 solo per gli identificatori di applicazione elencati in Info.plist, come spiega la pagina delle dichiarazioni.
Una sessione alla volta
Nel sistema può essere attiva una sola sessione di lettura, di qualunque tipo, dice la documentazione della classe base, e le sessioni in più aspettano in una coda servita in ordine. Un'applicazione che avvia una seconda sessione mentre la prima è aperta aspetta che la prima finisca.
Una sessione ha anche bisogno di hardware. readingAvailable risponde prima che qualcosa venga creato, e Apple chiede alle applicazioni di guardarlo per primo; Core NFC non è affatto disponibile nelle estensioni di applicazione.
E una sessione finisce per sempre. Una volta invalidata non può più leggere, e l'applicazione ne crea una nuova, che è quello che fa l'esempio di lettore di tag di Apple dopo ogni invalidazione.
Scegliere fra le due
| Domanda | Sessione NDEF | Sessione di tag |
|---|---|---|
| Disponibile da | iOS 11 per leggere, iOS 13 per scrivere | iOS 13 |
| Che cosa consegna | Messaggi, o tag NDEF tramite didDetect | Tag per protocollo, ognuno capace di NDEF |
| Comandi al chip | Nessuno | APDU, blocchi ISO 15693, comandi FeliCa e MIFARE |
| Dichiarazioni in più | Nessuna | Identificatori di applicazione per ISO 7816, codici di sistema per FeliCa |
Scegli la sessione NDEF quando il tag porta un messaggio e il compito dell'applicazione è quel messaggio. Scegli la sessione di tag quando all'applicazione serve il chip: un identificatore, un contatore, una password, un blocco di memoria fuori dal NDEF.
Domande frequenti
Un'applicazione iOS può leggere un tag senza il foglio di lettura?
No. Una sessione di lettura mostra l'avviso di lettura del sistema per tutto il tempo in cui gira, e l'applicazione ne sceglie soltanto il messaggio, tramite alertMessage.
Una sessione di tag legge anche il NDEF?
Sì. Ogni tipo di tag che consegna è conforme anche a NFCNDEFTag, quindi l'applicazione può leggere e scrivere NDEF dopo essersi connessa.
Due sessioni possono girare insieme?
No. Nel sistema è attiva una sola sessione di lettura di qualunque tipo, e le altre aspettano in una coda servita in ordine.
Perché la mia sessione NDEF finisce dopo il primo tag?
invalidateAfterFirstRead è a vero, e il delegato riceve readerSessionInvalidationErrorFirstNDEFTagRead quando la sessione finisce. Mettilo a falso per continuare a leggere o per scrivere.