¿Página web o aplicación nativa para un proyecto NFC?
Depende primero de los teléfonos. Una página con Web NFC llega a Chrome en Android y a nada más; una aplicación nativa llega a los iPhone, a los comandos en bruto y a la emulación de tarjeta. Muchos proyectos no necesitan ninguna: cuando la etiqueta solo tiene que abrir una página, un enlace basta en las dos plataformas.
Leer la etiqueta o abrir una página
La mayoría de los proyectos públicos no leen nunca una etiqueta en código. Un enlace escrito en la etiqueta lo abre el teléfono mismo, en Android y en el iPhone, y la página del otro extremo no necesita ninguna API NFC. La página de una etiqueta para todos los móviles da la receta.
El código entra cuando algo tiene que ocurrir entre el toque y la página: leer varias etiquetas seguidas, escribir etiquetas, comprobar un identificador, o hablar con el chip. Ahí empieza la elección entre una página y una aplicación.
A qué llega cada una
| Pregunta | Página web | Aplicación nativa |
|---|---|---|
| Teléfonos a los que llega | Chrome en Android | Android y iPhone |
| Contenido | Solo NDEF | NDEF y comandos en bruto |
| Emulación de tarjeta | No | En Android, mediante la emulación de tarjeta host |
| La arranca una etiqueta estando cerrada | No | En Android mediante el manifiesto, en el iPhone mediante un enlace que la aplicación reclama |
| Distribución | Una dirección web | Una ficha en una tienda |
La tabla está desequilibrada a propósito. El artículo de Chrome sobre Web NFC explica que la API se limitó al NDEF porque las propiedades de seguridad de leer y escribir datos NDEF son más fáciles de cuantificar.
Cuándo gana la página
Para las herramientas del personal en teléfonos que el proyecto controla, una página es difícil de batir: sin revisión de tienda, sin instalación, y una actualización es un despliegue del sitio. Los propios ejemplos del artículo son de ese tipo, gestión de existencias y comprobación de credenciales en un congreso.
Sus condiciones encajan con ese entorno. Chrome en Android se puede exigir a un parque de teléfonos, el permiso se concede una vez por sitio, y la página se queda abierta en pantalla mientras se trabaja.
Cuándo gana la aplicación
En cuanto los iPhone tienen que leer o escribir etiquetas, la página queda fuera. La ficha de estado de la plataforma Chrome no enumera compatibilidad con iOS, y la posición publicada de WebKit se opone a la API. Un iPhone lee etiquetas mediante Core NFC, dentro de una aplicación.
La aplicación gana también por debajo del NDEF, para contraseñas, contadores, firmas y emulación de tarjeta, y siempre que una etiqueta deba arrancarla sin que nadie abra nada antes, lo que solo puede arreglar una aplicación instalada.
Un marco multiplataforma puede compartir el código entre las dos aplicaciones, dentro de los límites que describe la página de los marcos.
Preguntas frecuentes
¿Puede una sola página web cubrir Android y el iPhone?
Para leer o escribir etiquetas no: Web NFC corre solo en Chrome para Android. Para abrir una página desde una etiqueta sí: escribe su dirección en la etiqueta y las dos plataformas la abren.
¿Web NFC es un estándar web?
Está especificada en un grupo comunitario del W3C, lo que la ficha de estado de Chrome describe como incubación, y solo Chrome la trae. La posición publicada de WebKit se opone y la de Mozilla es negativa.
¿Cuál sale más barata de construir?
La página, para personal con teléfonos Android que usan Chrome. La aplicación, en cuanto haya iPhone o cualquier cosa por debajo del NDEF, ya que la página no llega a ellos a ningún precio.
¿Puede una etiqueta abrir una página que después lea otras etiquetas?
En Android con Chrome sí: la etiqueta abre la página, y la página empieza a escanear tras tocar un botón. La primera etiqueta la trata el teléfono mismo, no la página.