Cosa serve a un'applicazione iOS per emulare una scheda?

Le abilitazioni vengono per prime

CardSession, da iOS 17.4, è la classe che emula una scheda, e la documentazione di Apple elenca quello che copre nello Spazio economico europeo: pagamenti in negozio, chiavi di auto, trasporto a sistema chiuso, badge aziendali, chiavi d'albergo, fedeltà e biglietti per eventi.

Tre abilitazioni la governano. com.apple.developer.nfc.hce consente l'API in generale, e senza di essa creare una sessione solleva un errore fatale. L'abilitazione dei prefissi di identificatore elenca quello per cui l'applicazione risponde: identificatori di applicazione interi, identificatori di fornitore registrati, o prefissi lunghi almeno quanto l'identificatore di fornitore. L'abilitazione dell'applicazione contactless predefinita lascia scegliere l'applicazione nelle Impostazioni come predefinita per il contactless.

Ciascuna delle tre pagine rimanda allo stesso posto, un modulo di domanda per le transazioni contactless basate su Host Card Emulation per le applicazioni bancarie e di portafoglio nello Spazio economico europeo. Il lato commerciale è coperto dalla pagina dell'emulazione su iPhone; la conseguenza tecnica è che il codice qui sotto gira solo dove Apple ha detto di sì.

Due verifiche prima che compaia qualcosa

Apple chiede tre valori prima che una sessione venga creata: NFCReaderSession.readingAvailable, CardSession.isSupported per il dispositivo, e CardSession.isEligible per il contesto del momento, che è asincrona. Il riferimento è esplicito sul perché ciascuna conti: creare una sessione su un dispositivo non sostenuto solleva un errore fatale, e una non ammissibile mostrerebbe per niente l'interfaccia di sessione di scheda del sistema.

Quindi la verifica sta prima del pulsante, non dopo. Un'applicazione che offre di presentare una scheda e poi fallisce la prova di ammissibilità ha già promesso qualcosa che il sistema non consegnerà.

La sessione, evento per evento

Una sessione di scheda è un flusso invece che un delegato. L'applicazione la crea, percorre eventStream, e riceve sessionStarted una volta che l'applicazione porta la risorsa NFC, poi readerDetected quando il dispositivo sente il campo di un lettore.

L'emulazione comincia quando l'applicazione chiama startEmulation(), che presenta l'interfaccia modale di sistema, con alertMessage messo prima. Da lì ciascun evento porta un carico utile APDU da trattare e a cui rispondere con respond(response:), e Apple avverte che un lettore può trattare una risposta tardiva come una scadenza. readerDeselected arriva quando il lettore se ne va, stopEmulation(status:) chiude l'interfaccia radio con uno stato finale mostrato a chi usa il telefono, e invalidate() libera la sessione.

startEmulation() solleva un errore dove la piattaforma rifiuta: il sistema non è disponibile, l'accesso non è stato accettato, l'ammissibilità è fallita, o la radio è spenta. Quei quattro casi meritano messaggi distinti, dato che uno solo di essi è un problema che chi usa il telefono può risolvere.

Quale applicazione raggiunge un tocco

L'applicazione contactless predefinita risponde a un tocco a meno che un'altra applicazione non chieda il campo. NFCPresentmentIntentAssertion è quella richiesta: acquisita dal primo piano, impedisce all'applicazione predefinita di sistema di avviarsi in risposta a un gesto o al campo di un lettore, e Apple la lega a una persona che sceglie attivamente una credenziale nella tua applicazione.

Non dura. L'asserzione scade quando l'oggetto viene deinizializzato, quando l'applicazione passa in fondo, o dopo quindici secondi, e una nuova si può acquisire solo dopo una pausa di quindici secondi. Non è nemmeno necessaria prima di presentare il foglio.

Android organizza la stessa domanda diversamente, con un ruolo di portafoglio e una preferenza di primo piano che qualsiasi applicazione può usare; la pagina dell'instradamento lo copre. Le piattaforme concordano su un punto: è chi usa il telefono, non il lettore, a decidere quale applicazione parla.