Página web ou aplicativo nativo: qual escolher para um projeto NFC?
Depende primeiro dos celulares. Uma página com Web NFC alcança o Chrome do Android e mais nada, enquanto um aplicativo nativo alcança os iPhones, os comandos brutos e a emulação de cartão. Muitos projetos não precisam de nenhum dos dois: quando a tag só tem de abrir uma página, o link funciona nas duas plataformas sem código NFC algum.
Ler a tag ou abrir uma página
A maior parte dos projetos abertos ao público nunca lê uma tag em código. Um link gravado na tag é aberto pelo próprio celular, no Android e no iPhone, e a página do outro lado não precisa de API de NFC alguma. A página de uma tag para todo celular dá a receita.
O código entra quando alguma coisa tem de acontecer entre o toque e a página: ler várias tags em sequência, gravar tags, conferir um identificador, ou falar com o chip. É aí que começa a escolha entre uma página e um aplicativo.
O que cada um alcança
| Pergunta | Página web | Aplicativo nativo |
|---|---|---|
| Celulares alcançados | O Chrome no Android | Android e iPhone |
| Conteúdo | Só NDEF | NDEF e comandos brutos |
| Emulação de cartão | Não | No Android, pela emulação de cartão pelo host |
| Aberto por uma tag estando fechado | Não | No Android pelo manifesto, no iPhone por um link que ele reivindica |
| Distribuição | Um endereço da web | Uma publicação numa loja |
A tabela é desequilibrada de propósito. O artigo do Chrome sobre o Web NFC explica que a API foi limitada ao NDEF porque as propriedades de segurança de ler e gravar dados NDEF são mais fáceis de quantificar.
Quando a página ganha
Para ferramentas de equipe em celulares que o projeto controla, uma página é difícil de bater: nenhuma análise de loja, nenhuma instalação, e uma atualização é uma publicação do site. Os exemplos do próprio artigo são desse tipo, gestão de inventário e conferência de crachás num evento.
As condições dela combinam com esse cenário. O Chrome no Android pode ser exigido de um parque, a permissão é concedida uma vez por site, e a página fica aberta na tela enquanto as pessoas trabalham.
Quando o aplicativo ganha
Assim que os iPhones tiverem de ler ou gravar tags, a página está fora. A entrada do estado das plataformas do Chrome não lista suporte no iOS, e a posição publicada do WebKit se opõe à API. Um iPhone lê tags pelo Core NFC, dentro de um aplicativo.
O aplicativo também ganha abaixo do NDEF, para as senhas, os contadores, as assinaturas e a emulação de cartão, e em todo lugar em que uma tag deva abri-lo sem o usuário abrir nada antes, o que só um aplicativo instalado consegue arranjar.
Um framework multiplataforma consegue compartilhar o código entre os dois aplicativos, dentro dos limites descritos na página dos frameworks.
Perguntas frequentes
Uma página web consegue cobrir o Android e o iPhone?
Para ler ou gravar tags, não: o Web NFC roda só no Chrome do Android. Para abrir uma página a partir de uma tag, sim: grave o endereço dela na tag e as duas plataformas a abrem.
O Web NFC é uma norma da web?
Ele é especificado num Community Group do W3C, o que a entrada do estado das plataformas do Chrome descreve como incubação, e só o Chrome o traz. A posição publicada do WebKit se opõe a ele e a da Mozilla é negativa.
Qual dos dois é mais barato de construir?
A página, para equipes em celulares Android com o Chrome. O aplicativo, assim que os iPhones ou qualquer coisa abaixo do NDEF estiverem envolvidos, já que a página não os alcança a preço algum.
Uma tag consegue abrir uma página que depois lê outras tags?
No Android com o Chrome, sim: a tag abre a página, e a página começa a ler depois de um toque num botão. A primeira tag é tratada pelo próprio celular, e não pela página.