GM
ES/EN
Volver a proyectos

Aplicación Android industrial / Producción

SpeedPrintLINK

Aplicación Android para control de transferencia de custodia en estaciones de dispensación, con base de datos local, integración de hardware y sincronización con la plataforma cloud.

Rol: Mantenimiento, evolución, integración y pruebas Duración: 4+ años Speed Solutions 2021 — hoy

El problema

La transferencia de custodia es el momento en que un volumen de producto cambia de responsable, y la medición de ese momento tiene consecuencias legales y comerciales. El equipo que la registra está en piso, conectado a hardware por protocolos propietarios, y la red del sitio no siempre está disponible. La aplicación tiene que seguir operando sin conexión y reconciliarse después sin perder ni duplicar una sola operación.

Centralización SpeedPrintLINK ↔ SpeedFlowLink Diagrama de secuencia entre el dispositivo Android y la plataforma cloud: registro de estructura, descarga de configuración, operación sin conexión y conciliación posterior. Dispositivo ANDROID · SQLITE LOCAL Plataforma CLOUD · SQL SERVER Publica su estructura física Devuelve identidad en el sistema Solicita configuración Entrega configuración vigente Sin conexión La operación continúa contra la base local. Na da se pierde y nada se duplica. Concilia lo registrado al recuperar la red
Centralización SpeedPrintLINK ↔ SpeedFlowLink

Restricciones

  • La operación no puede detenerse porque se caiga la red
  • Convivencia de una base de código heredada con una capa moderna
  • Integración con hardware de distintos fabricantes y protocolos
  • Dispositivos en campo que no se actualizan a demanda

Decisiones

Decidí Mantener la base heredada y construir las capacidades nuevas en capas modernas junto a ella
En lugar de Reescribir la aplicación desde cero
Porque Una reescritura habría congelado la entrega de valor durante meses sobre un producto en operación. Convivir cuesta disciplina, pero permite avanzar y modernizar por partes.
Decidí Base de datos local como fuente de verdad de la operación, con sincronización posterior hacia el cloud
En lugar de Requerir conexión permanente contra la API
Porque En sitio la conectividad es intermitente. Que la operación dependa de la red es un requisito que el negocio no puede cumplir.
Decidí Sincronización explícita por flujo — estructura de dispositivo, configuración, reemplazo — en lugar de un sincronizador genérico
En lugar de Un mecanismo único que replicara tablas
Porque Cada flujo tiene reglas de conflicto distintas. Un replicador genérico habría escondido esas reglas donde nadie las revisa.
Decidí Inyección de dependencias en puntos de composición definidos, no registros dispersos
En lugar de Registrar servicios donde hiciera falta
Porque En una base con dos arquitecturas conviviendo, los puntos de composición son el mapa que evita que la nueva se contagie del desorden de la anterior.

Resultado

  • Registro de estructura de dispositivos hacia el cloud y descarga de su configuración
  • Reemplazo de dispositivo en campo con trazabilidad del cambio
  • Operación sin conexión con conciliación posterior
  • Estado de hardware en tiempo real hacia la plataforma web
  • Cobertura de pruebas unitarias sobre las capas modernas, más pruebas sobre dispositivo físico

El problema de fondo

La aplicación vive en el punto donde se encuentran tres mundos que no se llevan bien: hardware con protocolos propietarios, una operación que no admite pausas, y una plataforma cloud que necesita recibir todo lo que pasó. El diseño se organiza alrededor de esa tensión.

La centralización entre ambos productos

El trabajo del que más he aprendido es la integración entre esta aplicación y la plataforma cloud. No es un endpoint: es un conjunto de flujos con reglas propias.

  • Registro de estructura — el dispositivo publica su configuración física hacia el cloud, que la reconoce y le devuelve su identidad dentro del sistema.
  • Descarga de configuración — la plataforma es la autoridad sobre la configuración; la aplicación la consume y la aplica localmente.
  • Reemplazo de dispositivo — cuando un equipo se cambia en campo, el histórico debe seguir siendo coherente. La identidad del dispositivo y la de sus datos se resuelven por separado.
  • Operación sin conexión — lo registrado localmente se concilia después, sin duplicar ni perder.

Cada flujo tuvo que decidir qué lado gana en caso de conflicto. Escribirlo por flujo, en lugar de construir un sincronizador genérico, hace que esa decisión sea visible en el código.

Convivencia de dos arquitecturas

La base combina una capa heredada —estática, con acceso directo a datos y gestores— y una capa moderna con inyección de dependencias, MVVM y servicios. Conviven a propósito.

La regla que seguí: lo nuevo se construye en la capa moderna, lo heredado se toca solo cuando el requerimiento lo obliga, y ninguna capa nueva adopta patrones de la anterior por comodidad. Es más lento que reescribir, pero el producto nunca dejó de entregar.

Por qué está aquí

Porque describe el trabajo real de mantener software que ya está en producción: crecer sus capacidades, integrarlo con otro sistema, cubrirlo con pruebas y sostenerlo durante años sin el lujo de empezar de cero.

El código es propiedad de Speed Solutions. Este caso describe arquitectura y decisiones, sin incluir código fuente, datos de clientes ni cifras de negocio.