Mobilny EGO i EPM w architekturze PWA

Hala produkcyjna, magazyn, ochrona na bramie — to środowisko, w którym pracownik ma w ręku telefon, często w rękawicach, słabe światło i zero cierpliwości do przeglądarkowych menu zaprojektowanych pod mysz. HIT4B3, nasza platforma zbudowana w architekturze SPA na uniGUI, świetnie sprawdza się na desktopie — ale mobile to zupełnie inny świat. Zamiast pisać osobną aplikację (native albo hybrydową), rozszerzyliśmy istniejący ekosystem o dedykowany tryb mobilny i opakowaliśmy go jako Progressive Web App.

Jeden backend, dwa interfejsy

uniGUI pozwala prowadzić równolegle klasyczne TUniForm (desktop) i mobilne TUnimForm (layout kartowy, duże przyciski, gesty dotykowe) w tym samym projekcie. Serwer sam rozpoznaje typ urządzenia i serwuje odpowiedni zestaw formularzy — logika biznesowa, baza Firebird, connection pooling i i18n są współdzielone 1:1 między wersjami. Każdy moduł ma swój katalog mobile/:

• EGO — portal wejściowy (logowanie, wybór firmy, lista weblikacji)
• EPM — moduł ochrony ze skanowaniem QR i potwierdzaniem przepustek
• _shr/mobile/ — komponenty współdzielone między modułami.

EGO jako brama SSO

Użytkownik loguje się raz w EGO, a stamtąd uruchamia poszczególne weblikacje. Na mobile wybrana weblikacja ładuje się w pełnoekranowej ramce, a EGO w tle zarządza sesją. Mechanizm oparty jest o jednorazowe, zaszyfrowane tokeny:

1. EGO generuje jednorazowy token — zaszyfrowany zestaw komend
2. zapisuje go w bazie razem z kontekstem (firma, język, uprawnienia)
3. otwiera adres docelowej weblikacji z przełącznikiem trybu mobilnego i tokenu
4. moduł docelowy odszyfrowuje token, weryfikuje go z wpisem w bazie i loguje użytkownika automatycznie

Dzięki temu użytkownik nie loguje się drugi raz, mimo że pod spodem działają odrębne procesy aplikacji.

Najtrudniejszy problem: żywa sesja w dwóch aplikacjach naraz

W przeglądarce mobilnej mamy w praktyce dwie niezależne sesje uniGUI jednocześnie — EGO i osadzoną w niej weblikację — a natywne zdarzenie OnSessionIdle ma potwierdzony błąd i nie odpala się wcale dla TUnimForm. Rozwiązanie:

• Licznik zamiast zdarzenia — cykliczny TUniTimer zamiast polegania na zdarzeniu OnSessionIdle
• Wspólne bicie serca między ramkami przez window.postMessage, tak by jeden dotyk w dowolnym miejscu resetował licznik bezczynności obu sesji
• Spójny ekran ostrzeżenia — modalne okno z odliczaniem przed wygaśnięciem sesji; jeśli wygaśnie sesja EGO, komunikat kończy też sesję osadzonej weblikacji

Ostatni krok: PWA

Minimalny manifest.json (nazwa, ikony, tryb standalone bez paska adresu) i celowo „pusty” Service Worker — HIT4B3 EGO to stanowa aplikacja z sesją WebSocket, więc cache'owanie treści zepsułoby spójność sesji. Service Worker istnieje wyłącznie po to, by spełnić techniczne kryterium instalowalności w Chrome/Android. Efekt: telefon proponuje „Dodaj do ekranu głównego”, a od tego momentu HIT4B3 działa jak natywna aplikacja — bez paska adresu, z własną ikoną, bez osobnego kodu mobilnego poza warstwą prezentacji.

To podejście już dziś obsługuje mobilny moduł Ochrony (EPM) i będzie bazą dla kolejnych weblikacji uruchamianych w trybie mobilnym.

Pełny, techniczny opis architektury — z detalami implementacji tokenowego SSO, mechanizmu keepalive i konfiguracji PWA — znajdziecie w artykule na naszej stronie: HIT4B3 na telefonie: jak zbudowaliśmy tryb mobilny EGO i EPM w architekturze PWA.