Una planta de producción, un almacén, seguridad en la puerta — este es un entorno en el que un empleado lleva un teléfono en la mano, a menudo con guantes, poca luz y cero paciencia para menús basados en navegador diseñados para el ratón. HIT4B3, nuestra plataforma construida en la arquitectura SPA de uniGUI, funciona genial en escritorio, pero el móvil es un mundo completamente distinto. En lugar de escribir una aplicación separada (nativa o híbrida), ampliamos el ecosistema existente con un modo móvil dedicado y lo empaquetamos como una aplicación web progresiva.
Un backend, dos interfaces
uniGUI permite ejecutar TUniForm clásico (escritorio) y TUnimForm móvil (disposición de tarjetas, botones grandes, gestos táctiles) en paralelo en el mismo proyecto. El servidor reconoce el tipo de dispositivo y sirve el conjunto adecuado de formularios: la lógica de negocio, la base de datos Firebird, el agrupamiento de conexiones e i18n se comparten 1:1 entre versiones. Cada módulo tiene su propio móvil/:
- EGO - Portal de Entrada (Inicio de sesión, Selección de Empresa, Lista de Enlaces)
- EPM - Módulo de Protección con escaneo QR y confirmación de pase
- _shr/móvil/ - Componentes compartidos entre módulos.
EGO como puerta de entrada SSO
El usuario inicia sesión una vez en EGO y, a partir de ahí, lanza enlaces web individuales. En móvil, el enlace web seleccionado se carga en un fotograma a pantalla completa y EGO gestiona la sesión en segundo plano. El mecanismo se basa en tokens cifrados de un solo uso:
- EGO genera un token de un solo uso: un conjunto cifrado de comandos
- Lo guarda en la base de datos junto con el contexto (empresa, idioma, permisos)
- Abre la dirección de enlace web de destino con el modo móvil y el interruptor del token
- El módulo destino descifra el token, lo verifica con una entrada en la base de datos y registra automáticamente al usuario
Esto garantiza que el usuario no inicie sesión una segunda vez, aunque haya procesos de aplicación separados ejecutándose debajo.
El problema más difícil: una sesión en vivo en dos aplicaciones a la vez
En el navegador móvil, tenemos dos sesiones uniGUI independientes al mismo tiempo — EGO y el enlace web incrustado en ella — y el evento nativo OnSessionIdle tiene un error confirmado y no se activa en absoluto para TUnimForm. Solución:
- Contador en lugar de evento - TUniTimer recurrente en lugar de depender del evento OnSessionIdle
- Un latido común entre fotogramas mediante window.postMessage, de modo que un solo toque en cualquier lugar reinicie el contador de inactividad de ambas sesiones
- Pantalla de advertencia consistente - Una ventana modal con una cuenta atrás antes de que finalice la sesión; si la sesión EGO expira, el mensaje también termina la sesión de enlace web incrustado
El último paso: PWA
Mínimo manifest.json (nombre, iconos, modo independiente sin barra de dirección) y intencionadamente "vacío" al Service Worker - HIT4B3 EGO es una aplicación con estado y sesión WebSocket, por lo que almacenar en caché el contenido rompería la consistencia de la sesión. Service Worker existe únicamente para cumplir con el criterio técnico de instalación en Chrome/Android. El resultado: el teléfono propone "Añadir a la pantalla de inicio" y, a partir de ese momento, HIT4B3 funciona como una aplicación nativa : sin barra de direcciones, sin icono propio, sin código móvil separado fuera de la capa de presentación.
Este enfoque ya soporta hoy el Módulo de Protección Móvil (EPM) y será la base para futuras aplicaciones web lanzadas en modo móvil.
Una descripción técnica completa de la arquitectura — con detalles sobre la implementación del token SSO, el mecanismo keepalive y la configuración de PWA — puede encontrarse en el artículo de nuestra web: HIT4B3 on the phone: how we built EGO and EPM mobile mode in the PWA architecture.
Comentarios (0)
Añadir un comentario