Mobile EGO ed EPM nell'architettura PWA

12.08.2026 | Applicazioni Web

Un piano di produzione, un magazzino, la sicurezza al cancello — questo è un ambiente in cui un dipendente ha un telefono in mano, spesso con guanti, scarsa illuminazione e zero pazienza per i menu basati sul browser progettati per il mouse. HIT4B3, la nostra piattaforma costruita nell'architettura SPA su uniGUI, funziona benissimo su desktop — ma il mobile è un mondo completamente diverso. Invece di scrivere un'applicazione separata (nativa o ibrida), abbiamo ampliato l'ecosistema esistente con una modalità mobile dedicata e l'abbiamo confezionata come Progressive Web App.

 

Un backend, due interfacce

uniGUI permette di eseguire TUniForm classico (desktop) e TUnimForm mobile (layout delle schede, pulsanti grandi, gesti touch) in parallelo nello stesso progetto. Il server riconosce il tipo di dispositivo e serve il set appropriato di moduli — logica di business, database Firebird, pool di connessione e i18n sono condivisi 1:1 tra versioni. Ogni modulo ha il proprio mobile/:

  • EGO - Portale di ingresso (Login, Selezione Azienda, Lista Weblink)
  • EPM - Modulo di Protezione con scansione QR e conferma di passaggio
  • _shr/mobile/ - Componenti condivisi tra moduli.

 

EGO come gateway SSO

L'utente effettua l'accesso una volta a EGO e da lì avvia singoli weblink. Su mobile, il collegamento web selezionato si carica in un frame a schermo intero e EGO gestisce la sessione in background. Il meccanismo si basa su token cifrati a uso singolo:

  1. EGO genera un token uniuso: un insieme di comandi criptati
  2. Lo salva nel database insieme al contesto (azienda, lingua, permessi)
  3. Apre l'indirizzo del weblink di destinazione con la modalità mobile e l'interruttore token
  4. Il modulo target decripta il token, lo verifica con una voce nel database e registra automaticamente l'utente

Questo garantisce che l'utente non effettui il login una seconda volta, anche se ci sono processi applicativi separati in esecuzione sotto.

 

Il problema più difficile: una sessione live in due applicazioni contemporaneamente

Nel browser mobile, abbiamo due sessioni uniGUI indipendenti contemporaneamente — EGO e il collegamento web integrato in esso — e l'evento nativo OnSessionIdle ha un errore confermato e non si attiva affatto per TUnimForm. Soluzione:

  • Contatore invece di evento - TUniTimer ricorrente invece di affidarsi all'evento OnSessionIdle
  • Un battito cardiaco comune tra i frame tramite window.postMessage, così che un tocco ovunque resetti il contatore inattivo di entrambe le sessioni
  • Schermata di avviso coerente - Una finestra modale con un conto alla rovescia prima che la sessione scada; se la sessione EGO scade, il messaggio termina anche la sessione weblink incorporata

 

L'ultimo passaggio: PWA

Minimal manifest.json (nome, icone, modalità standalone senza barra di indirizzo) e intenzionalmente "vuoto" del Service Worker - HIT4B3 EGO è un'applicazione con stato e una sessione WebSocket, quindi memorizzare i contenuti in cache comprometterebbe la coerenza della sessione. Service Worker esiste esclusivamente per soddisfare il criterio tecnico di installabilità in Chrome/Android. Il risultato: il telefono propone "Aggiungi alla schermata principale" e da quel momento HIT4B3 funziona come un'app nativa — nessuna barra degli indirizzi, nessuna icona propria, nessun codice mobile separato fuori dal livello di presentazione.

Questo approccio supporta già oggi il Mobile Protection Module (EPM) e sarà la base per future applicazioni web lanciate in modalità mobile.

 

Una descrizione tecnica completa dell'architettura — con dettagli sull'implementazione del token SSO, del meccanismo keepalive e della configurazione PWA — si trova nell'articolo sul nostro sito web: HIT4B3 on the phone: how we built EGO and EPM mobile mode in the PWA architecture.

Tag: #AI #Weblications

Commenti (0)

Aggiungi un commento