Pagina web o applicazione nativa: quale per un progetto NFC?
Dipende prima dai telefoni. Una pagina che usa Web NFC raggiunge Chrome su Android e nient'altro, mentre un'applicazione nativa raggiunge gli iPhone, i comandi grezzi e l'emulazione di scheda. A molti progetti non serve né l'una né l'altra: quando il tag deve solo aprire una pagina, un collegamento sul tag funziona su tutt'e due le piattaforme senza codice NFC.
Leggere il tag o aprire una pagina
La maggior parte dei progetti pubblici non legge mai un tag in codice. Un collegamento scritto sul tag viene aperto dal telefono stesso, su Android e su iPhone, e la pagina dall'altro capo non ha bisogno di alcuna API NFC. La pagina del tag che funziona su ogni telefono dà la ricetta.
Il codice entra in scena quando qualcosa deve succedere fra il tocco e la pagina: leggere diversi tag di fila, scrivere tag, verificare un identificatore, o parlare al chip. È lì che comincia la scelta fra una pagina e un'applicazione.
Che cosa raggiunge ciascuna
| Domanda | Pagina web | Applicazione nativa |
|---|---|---|
| Telefoni raggiunti | Chrome su Android | Android e iPhone |
| Contenuto | Solo NDEF | NDEF e comandi grezzi |
| Emulazione di scheda | No | Su Android, tramite Host Card Emulation |
| Avviata da un tag quando è chiusa | No | Su Android tramite il manifest, su iPhone tramite un collegamento che rivendica |
| Distribuzione | Un indirizzo web | Una scheda su uno store |
La tabella è sbilanciata di proposito. L'articolo di Chrome su Web NFC spiega che l'API è stata limitata al NDEF perché le proprietà di sicurezza della lettura e della scrittura di dati NDEF sono più facili da quantificare.
Quando vince la pagina
Per gli strumenti interni su telefoni che il progetto controlla, una pagina è difficile da battere: nessun esame di uno store, nessuna installazione, e un aggiornamento è una pubblicazione del sito. Gli esempi dell'articolo stesso sono di quel genere, gestione di inventario e controllo dei badge a un convegno.
Le sue condizioni si addicono a quel contesto. Chrome su Android si può imporre a un parco, il permesso viene concesso una volta per sito, e la pagina resta aperta sullo schermo mentre si lavora.
Quando vince l'applicazione
Appena degli iPhone devono leggere o scrivere tag, la pagina è fuori. La scheda di stato della piattaforma Chrome non elenca alcun sostegno per iOS, e la posizione pubblicata di WebKit si oppone all'API. Un iPhone legge i tag tramite Core NFC, dentro un'applicazione.
L'applicazione vince anche sotto il NDEF, per password, contatori, firme ed emulazione di scheda, e ovunque un tag debba avviarla senza che si apra prima qualcosa, cosa che solo un'applicazione installata sa predisporre.
Un framework multipiattaforma può condividere il codice fra le due applicazioni, entro i limiti descritti nella pagina dei framework.
Domande frequenti
Una sola pagina web può coprire Android e iPhone?
Per leggere o scrivere tag no: Web NFC gira nel solo Chrome su Android. Per aprire una pagina da un tag sì: scrivi il suo indirizzo sul tag e le due piattaforme lo aprono.
Web NFC è uno standard del web?
È specificato in un Community Group del W3C, che la scheda di stato della piattaforma Chrome descrive come incubazione, e solo Chrome lo porta. La posizione pubblicata di WebKit si oppone e quella di Mozilla è negativa.
Quale costa meno da costruire?
La pagina, per il personale su telefoni Android con Chrome. L'applicazione, appena entrano in gioco gli iPhone o qualcosa sotto il NDEF, dato che la pagina non li raggiunge a nessun costo.
Un tag può aprire una pagina che poi legge altri tag?
Su Android con Chrome sì: il tag apre la pagina, e la pagina comincia a leggere dopo un tocco su un pulsante. Il primo tag è trattato dal telefono stesso, non dalla pagina.