Ünlem Bilisim: Aplicación móvil de seguimiento de códigos de barras e inventario

Datos breves

• Empresa: Ünlem Bilişim Teknolojileri A.Ş.
• Rol: Desarrollador de aplicaciones móviles en prácticas
• Período del Proyecto: 2015-2016
• Fecha de publicación de la página: 2024-08-01
• Plataformas: iOS, Android
• Tecnología: Delphi RAD Studio, FireMonkey, Object Pascal, SQLite, FireDAC, ZXing
• Limitaciones: uso sin conexión, baja capacidad del dispositivo, lectura rápida de códigos de barras

Este estudio tuvo como objetivo producir una aplicación de inventario móvil que pueda usarse en el campo como proyecto final del programa de pasantías. La atención se centró en la distribución de iOS/Android con una única base de código, operación fuera de línea y un rápido flujo de transacciones con códigos de barras. El resultado fue un producto piloto en el que los equipos de campo podían realizar transacciones de conteo y débito a través de tabletas o teléfonos.

Línea de tiempo

• 2015: Inicio de prácticas, recopilación de necesidades de campo y primer prototipo.
• 2016: Desarrollo de aplicaciones, pruebas de campo y entrega.
• 2024-08-01: Fecha de publicación de la página (fecha de publicación).

Problemas y limitaciones

En las Pymes, el conteo de inventarios y la actualización de existencias se realizaban en campo con baja calidad de conexión. Los sistemas de escritorio no eran portátiles; En el móvil, era necesario ofrecer al mismo tiempo la lectura de códigos de barras, el trabajo fuera de línea y el acceso rápido a los datos. La diversidad de dispositivos, la poca luz y los recursos de hardware limitados fueron las principales limitaciones del diseño. Los cortes de Wi-Fi en el almacén, el desgaste de los códigos de barras y las diferentes cámaras de los dispositivos dificultaron el funcionamiento estable del producto. Además, era necesario mantener el modelo de datos compatible con los servicios ERP existentes.

Resumen de la solución

Desarrollé una aplicación de inventario móvil sin conexión para iOS y Android a partir de una única base de código con Delphi/FireMonkey. El escaneo de códigos de barras, el etiquetado GPS, la base de datos SQLite local y la sincronización REST se unieron para permitir a los equipos de campo realizar operaciones rápidas y sin errores. La aplicación fue diseñada para completar todas las operaciones críticas cuando no hay conexión; Cuando llegó la conexión, los cambios se enviaron desde la cola al servidor. Los flujos de escaneo, conteo y débito de códigos de barras están diseñados para completarse con un toque mínimo.

Arquitectura de un vistazo

• Almacenamiento de datos sin conexión con SQLite local + FireDAC.
• Sincronización periódica y actualizaciones delta con API REST.
• Envío seguro de datos con registro de cambios.
• Política de conflictos simple: el último que escribe gana + control manual.
• Durabilidad de la sincronización con reintento/retroceso.
• Control de token ligero para autorización.

Esta estructura tenía como objetivo seguir siendo compatible con la grabación única en el centro y al mismo tiempo reducir la pérdida de datos en condiciones de baja conexión.

Modelo de datos y estrategia de sincronización

modelo de datos; Constaba de las tablas Productos, Inventario, Ubicación y Registro de transacciones. Se conservaron la última modificación y el ID del dispositivo para cada registro; De esta manera, fue posible rastrear qué cambios procedían de dónde. Además, las actualizaciones pendientes se pusieron en cola y se enviaron de forma segura con la tabla SyncQueue.

La sincronización se realizó con un flujo push/pull. La aplicación primero envió los cambios acumulados localmente al servidor en pequeños paquetes y luego extrajo solo los registros modificados del servidor. Cuando la red falla, la cola se conserva y los reintentos se automatizan.

Características clave

• Búsqueda y conteo rápido de productos con escaneo de códigos de barras (ZXing).
• Verificación de inventario basada en la ubicación con etiquetado GPS.
• Operación sin conexión y sincronización automática cuando se trata de red.- Interfaz sencilla y rápida: listado, detalle, conteo, búsqueda.
• Registros de débitos y movimientos de almacén.
• Búsqueda/filtro rápido (código de barras, nombre, ubicación).
• Acceso a pantalla basado en roles y autorización básica.

Se simplificaron los flujos de trabajo a través de botones grandes y formularios cortos, considerando el uso de guantes por parte del personal del almacén.

Compensaciones de ingeniería

• La velocidad de la base de código única se ha equilibrado limitando algunas optimizaciones específicas de la plataforma.
• La conveniencia de que el último escritor gane creó la necesidad de aprobación manual en áreas críticas.
• El enfoque offline priorizó la continuidad sobre la actualización de los datos.
• Se aplicó muestreo porque la alta resolución reduce la velocidad de lectura de códigos de barras.
• La sensibilidad del GPS se ha equilibrado con el consumo de batería.

Resolución de conflictos e integridad de los datos

Utilicé un enfoque en el que el último escrito gana para evitar la posibilidad de que los trabajadores de campo actualicen el mismo producto en diferentes momentos. Para conflictos críticos, le di al usuario una "advertencia de última actualización" y agregué un flujo de verificación manual. Mantuve la integridad de los datos con la gestión de transacciones SQLite y FireDAC. Para reducir la tasa de superposición, mantuve el intervalo de sincronización corto y envié paquetes de cambio en pequeños lotes.

Notas de rendimiento

• La carga de la CPU se redujo con el muestreo de cuadros y la reducción de imágenes en el escaneo de códigos de barras.
• La búsqueda de códigos de barras y nombres de productos se ha acelerado con índices SQLite.
• La sincronización en segundo plano está diseñada para no bloquear el hilo de la interfaz de usuario.
• El uso de la memoria se ha equilibrado con la paginación en las pantallas de listado.
• Se utilizaron preferencias de exposición automática para condiciones de poca luz en la vista previa de la cámara.

Estas optimizaciones aseguraron que la aplicación se mantuviera fluida, especialmente en dispositivos Android más antiguos. El objetivo principal era evitar retrasos entre la pantalla de escaneo y la pantalla de lista para un conteo rápido en el campo.

Resultados / Impacto

• Aceleración del proceso en uso piloto - 20% - período: piloto de 3 semanas - fuente: comentarios de campo (informados por el cliente).
• Facilidad de uso y acceso móvil - mejora cualitativa - fuente: opiniones de usuarios (observadas internamente).
• Oferta a tiempo parcial después de la pasantía - retroalimentación basada en el resultado del proyecto (anecdótico).
• Satisfacción con el uso offline - mejora cualitativa - fuente: notas de campo (observadas internamente).

Lecciones aprendidas

• Arquitectura fuera de línea, el mayor valor en escenarios de campo.
• UI simple, crítica para usuarios no técnicos.
• El rendimiento en dispositivos móviles se mantiene con un muestreo e indexación correctos.
• La medición del contexto y el mantenimiento de registros son de gran importancia en los proyectos de prácticas.
• La estrategia de sincronización afecta directamente la coherencia de los datos.
• Comentarios reales de los usuarios, verificación más rápida del diseño.

Esta experiencia me enseñó a asumir la responsabilidad integral del desarrollo de productos móviles.

Instantánea del proyecto

• Empresa: Ünlem Bilişim Teknolojileri A.Ş.
• Tipo de Proyecto: Proyecto final de prácticas
• Rol: Desarrollador de aplicaciones móviles
• Período del Proyecto: 2015-2016
• Fecha de finalización: agosto de 2016
• Fecha de la página: 2024-08-01
• Plataforma: iOS, Android
• Tecnología: Delphi RAD Studio, FireMonkey, Object Pascal
• Base de datos: SQLite + FireDAC
• Integración: API REST, JSON, ZXing, GPS

Preguntas frecuentes

¿Cómo fue el rendimiento de la aplicación móvil con Delphi?

El rendimiento fue adecuado gracias a la compilación nativa con FireMonkey; La optimización se aplicó en puntos críticos.

¿Cómo se gestionaron los escenarios fuera de línea?

Se guardó una copia local con SQLite y la sincronización se realizó mediante REST cuando llegó la red.

¿La lectura del código de barras fue estable?

Se logró una lectura estable con técnicas de muestreo ZXing y reducción de resolución.

¿Por qué se prefirió FireMonkey?

Se lanzará para iOS y Android con una única base de código y será compatible con el ecosistema Delphi existente.

¿Cómo se resolvieron los conflictos?

Se implementaron las victorias de última escritura y se ofreció verificación al usuario en situaciones críticas.

¿Para qué se utilizó la etiqueta GPS?

Para verificación de ubicación de productos y registro en almacén en operaciones de campo.