La respuesta corta

Para leer códigos con un terminal Zebra desde una app Flutter no necesitas un SDK de escaneo. Los dispositivos Android de Zebra vienen con DataWedge preinstalado: un servicio que captura de todas las fuentes del terminal —lector láser, imager, banda magnética, RFID, voz, puerto serie— y entrega el dato a tu app sin que tú toques el hardware.

La decisión que hay que tomar bien es por qué canal te lo entrega. Hay tres, y en Flutter uno de ellos es una trampa.

Los tres canales de salida

Salida por pulsaciones de teclado. DataWedge simula un teclado e inyecta el dato como si el operario lo hubiera tecleado. No requiere integración: cualquier app con un campo de texto enfocado recibe el código.

Salida por intent. DataWedge envía el dato mediante un intent de Android. Y no solo el código en bruto: extrae automáticamente datos de producto estructurados —GTIN, fecha de caducidad, número de lote— cuando el símbolo los contiene.

Salida por IP. El dato se entrega por red.

Por qué el teclado es una trampa en Flutter

Es el camino que parece gratis y el que genera los tickets raros:

  • Depende de que haya un campo enfocado en el momento del disparo. En Flutter, con su propio árbol de foco y campos que se reconstruyen, eso es frágil.
  • Obliga a mantener un campo oculto para capturar, con el teclado virtual apareciendo cuando no debe.
  • Pierdes el metadato: solo llega el texto. Ni tipo de simbología, ni GTIN separado, ni caducidad.
  • Un código con caracteres especiales puede llegar transformado según la disposición de teclado.

En un almacén, «a veces no lee» es una incidencia carísima: el operario no reporta el fallo, cambia de app o teclea a mano.

La recomendación es intent output. El dato llega estructurado, no depende del foco y se puede procesar aunque la pantalla no tenga ningún campo de entrada. En Flutter se recibe con un canal de plataforma que escucha el broadcast en el lado Android y lo pasa a Dart.

Perfiles: la parte que se olvida al desplegar

DataWedge funciona con perfiles, que contienen la configuración de cómo interactúa con una o varias apps asociadas. Un perfil define qué simbologías están activas, qué canal de salida se usa y con qué parámetros.

Dos formas de crearlos, y las dos hay que planificarlas:

  • A mano, en el terminal. Vale para una prueba, no para una flota.
  • Programáticamente, con las API de intents de DataWedge: crear el perfil, asociarlo a tu paquete, configurar el escáner, consultar la versión y exportar perfiles. Sin SDK.

Lo habitual en producción es que la app cree y configure su propio perfil al arrancar por primera vez. Si no lo hace, dependes de que alguien configure trescientos terminales a mano — y de que nadie los restablezca.

Lo que hay que decidir antes de escribir código

  1. Qué simbologías hay que activar. Activar todas parece cómodo y degrada la velocidad de lectura y la tasa de acierto.
  2. Qué hace el disparo físico según la pantalla. El mismo botón del terminal significa cosas distintas en la pantalla de recepción y en la de picking.
  3. Qué pasa con una lectura inesperada: un código que no corresponde a la pantalla actual. Ignorarlo en silencio es peor que avisar.
  4. Si el terminal se usa con guantes o en frío, porque eso cambia el diseño de la interfaz más que cualquier decisión técnica.
  5. Cómo se despliega la configuración a toda la flota.

Diseñar para el almacén, no para la oficina

El terminal no es un móvil. Un par de cosas que se aprenden en la primera visita a planta:

  • La pantalla es pequeña y el guante es grueso. Objetivos táctiles grandes y pocos por pantalla.
  • El operario no mira la pantalla mientras dispara. La confirmación tiene que ser sonora o háptica, no solo visual.
  • La velocidad manda. Si el flujo exige dos toques después de cada lectura, el operario buscará la forma de saltárselo.
  • Sin cobertura en parte del almacén. Lo que se lee tiene que poder registrarse igualmente y sincronizar después — eso es otra conversación completa, en app de reparto sin cobertura.
  • Turnos completos con una carga. El consumo es un requisito, no una optimización.

Cuándo no usar DataWedge

  • Si el terminal no es Zebra. Otros fabricantes tienen sus propios mecanismos; el patrón es parecido pero la implementación no.
  • Si necesitas la cámara del móvil en lugar de un lector dedicado. Ahí sí toca librería de escaneo, con su rendimiento y sus limitaciones de enfoque.
  • Si lo que se lee es RFID a volumen, que tiene su propio flujo y su propia ergonomía.

Es el tipo de proyecto que hacemos en apps de logística y transporte: la parte que no se ve en la demo y que decide si el operario adopta la herramienta o la esquiva.

Fuente primaria, consultada el 14 de agosto de 2026: About DataWedge en la documentación técnica de Zebra.