Todos los fabricantes de RFID incluyen una app de demostración que lee una etiqueta en noventa segundos. Y todos los despliegues gastan después tres meses descubriendo que esa demo no respondió ninguna de las preguntas que importan a las cuatro de la tarde en un almacén: por qué dejó de responder el gatillo, por qué la batería murió en la sexta hora, por qué la lista se desplazaba tan lenta que los operarios dejaron de confiar en ella.

Este artículo trata de la distancia entre esas dos apps. El SDK es una parte pequeña de esa distancia.

El panorama de SDK: qué estás integrando en realidad

Tres API, tres supuestos de diseño distintos, y confundirlos es el primer error.

El SDK de RFID es una librería nativa envuelta en Java: posee una antena, un hilo de lector y una interfaz de callback.
La API de código de barras (DataWedge o EMDK) es un subsistema aparte con reglas de ciclo de vida aparte, incluso en el mismo dispositivo.
Los eventos de código de barras y de RFID llegan por callbacks distintos y deben fusionarse en un solo modelo de escaneo antes de que la UI vea nada.
Los SDK de fabricante difieren en garantías de hilos; si la documentación no declara seguridad de hilos, asume que no la hay.
Fija la versión del SDK por modelo de dispositivo y trata cada actualización como un release, porque el comportamiento cambia entre versiones menores.

Hilos, callbacks y el gatillo

El gatillo es la pieza más tocada de la app y la fuente más común de "dejó de funcionar".

Los callbacks del lector llegan en un hilo del SDK; nunca toques UI ni base de datos desde ahí, pasa el trabajo a una cola.
Pulsar el gatillo inicia una sesión de lectura y soltarlo la detiene; haz ambos idempotentes, porque los eventos de hardware se duplican.
Si se inicia una sesión mientras otra corre, no abras una segunda; coalesce, o el lector reportará errores que perseguirás durante semanas.
Toda sesión necesita un watchdog: si no llega ningún evento en N segundos, desmonta y reinicializa el lector en lugar de esperar para siempre.
Reinicializa tras cada reanudación de la app, porque el estado del lector no sobrevive a la muerte del proceso ni a un reinicio.

La configuración de lectura no es la de un lector fijo

Los valores por defecto del handheld están afinados para una demo sobre una mesa, y un almacén no es una mesa.

La potencia de transmisión debe seguir al flujo de trabajo: baja para precisión en estantería, alta para un palé alto, nunca máxima por defecto.
La elección de sesión importa más que en un portal: la sesión uno mantiene las etiquetas calladas entre lecturas, lo que conviene para contar la misma estantería repetidamente.
Filtrar por prefijo EPC antes de la singulación es la forma más barata de dejar de leer el stock del pasillo vecino.
Una ventana de deduplicación corta en la app es normal; una larga oculta etiquetas duplicadas reales.
El modo batch mejora el rendimiento pero retrasa el primer resultado; la UI debe mostrar que se está leyendo, o el operario pulsará más fuerte.

Diseño de interfaz para lectura masiva

Una pantalla de lectura masiva no es una lista; es un indicador de progreso con excepciones.

Muestra un contador en marcha como número principal, no una lista que se desplaza; el contador es lo que el operario intenta establecer.
Muestra las últimas lecturas para dar confianza, pero limita las filas visibles, porque una lista de mil filas es una pantalla congelada.
Distingue visualmente tres estados: leyendo, inactivo y fallo; los operarios diagnostican por color mucho antes de leer un mensaje.
Pon la excepción delante: etiqueta desconocida, ubicación errónea, ya contada, para que el operario actúe en el momento del escaneo.
Haz que el gatillo y el botón en pantalla hagan lo mismo, porque los guantes y el sol rompen cualquier supuesto sobre el tacto.

Primero offline, después sincronización

Los almacenes tienen zonas muertas, y un conteo que no se puede guardar es un conteo que se repetirá.

Guarda cada lectura localmente primero, en un almacén por sesión, y sincroniza después; nunca bloquees el bucle de escaneo con una llamada de red.
Haz que la unidad de sincronización sea la sesión, no la etiqueta, para que una subida parcial se reanude sin duplicados.
Usa un número de secuencia local monótono y un identificador de dispositivo para la idempotencia en el servidor.
Muestra el estado de sincronización de forma explícita: pendiente, sincronizando, fallido con contador de reintentos, para que nadie asuma un tick verde que nunca ocurrió.
Resuelve conflictos en el servidor con una regla que el equipo de campo conozca, no con last-write-wins en el dispositivo.

Batería, temperatura y la realidad de un turno de ocho horas

La RFID consume mucho, y suele añadirse a una app que ya iba justa.

Leer a alta potencia de forma continua puede reducir la batería a la mitad; presupuesta el turno, no la demo.
Mantén el lector alimentado solo durante una sesión y liberarlo en reposo, porque una antena activa consume aunque nadie escanee.
Vigila la temperatura: la lectura sostenida en un equipo caliente provoca throttling, que parece un problema de alcance.
Desactiva la ubicación en segundo plano y las radios que no necesites; la radio RFID no es el único consumidor de la app.
Da al operario un umbral de batería visible y un aviso temprano, para que un conteo no se pierda al noventa por ciento.

Gestión de flota: una app, muchos dispositivos

Una flota de handhelds se desvía, y la desviación es invisible hasta que una sede reporta cifras distintas.

Fija versión de app, versión de SDK y perfil de configuración por modelo, y regístralos en el payload de escaneo.
Envía la configuración desde el servidor, no desde una pantalla de ajustes, para que un nivel de potencia mal puesto no persista meses.
Usa un MDM para empujar actualizaciones y para impedir que un operario instale otra versión "para probar".
Registra la identidad del dispositivo en cada sesión; cuando las cifras de una sede parecen raras, la primera pregunta es qué build corría.
Retira dispositivos explícitamente y revoca sus credenciales, para que un handheld perdido no siga escribiendo inventario.

Probar en estanterías reales, no en un escritorio

La demo pasa en una mesa. La release tiene que pasar en una estantería metálica con cien prendas.

Prueba con la etiqueta real y la colocación real, porque una etiqueta textil doblada se lee distinto que un inlay plano.
Prueba en el peor punto del edificio: la esquina lejana, la estantería metálica, el pasillo junto a la puerta del muelle.
Prueba el turno completo: empieza con batería baja, lee dos horas, manda la app a segundo plano, vuelve y comprueba que la sesión sobrevivió.
Prueba con guantes y a pleno sol, porque ambos cambian cómo se usan realmente el gatillo y la pantalla.
Mantén un conteo de regresión de una estantería conocida: misma estantería, mismo número esperado, en cada release antes de publicar.

El patrón de todo esto es poco glamuroso: trata el lector como un periférico poco fiable, la red como ausente, la batería como finita y al operario como alguien con guantes y mala luz. Las apps construidas sobre esos supuestos sobreviven al primer lunes; las construidas sobre la demo, no.