Flaem

Flaem po stronie web to pełne centrum dowodzenia klienta: zamawianie serwerów, konsola, pliki, statystyki, rozliczenia. Wszystko, czego administrator potrzebuje, żeby jego serwer gry stał i działał. Problem w tym, że to centrum dowodzenia jest przykute do biurka.

Administrator nie pracuje od dziewiątej do siedemnastej przy monitorze. Awaria nie sprawdza kalendarza - przychodzi w autobusie, na obiedzie, w środku nocy, kiedy na serwerze akurat jest komplet graczy. Wtedy liczy się jedno: jak szybko z telefonu w kieszeni dojdziesz do restartu i konsoli, zanim gracze zaczną odchodzić.

Dlatego wersję mobilną Flaem zbudowaliśmy jako pełnoprawny sposób obsługi platformy, a nie doczepkę do panelu web. W praktyce to dwie osobne aplikacje pisane w natywnych językach platform - Android w Kotlinie, iOS w Swifcie - sięgające po dokładnie to samo API co panel w przeglądarce.

Kiedy serwer pada w środku prime time, każda minuta to gracze, którzy nie wracają. W takim momencie nie odpalasz laptopa, nie logujesz się do panelu web, nie szukasz zakładki. Wyjmujesz telefon, który i tak masz w ręku, i chcesz być na konsoli w dwa dotknięcia.

To zmienia wymagania wobec aplikacji. Narzędzie, po które sięgasz w stresie awarii, musi uruchamiać się natychmiast, reagować bez zacięć i prowadzić do celu bez błąkania się po menu. Każda sekunda zwłoki między dotknięciem ikony a widokiem konsoli to sekunda, w której serwer dalej leży.

Najprostsza i najtańsza droga na mobilkę to opakować istniejący panel web w WebView i wysłać do sklepu jako "aplikację". Kod już jest, wystarczy go otoczyć oknem. Tyle że efekt zdradza skrót na każdym kroku: aplikacja startuje wolno, bo najpierw musi wstać silnik przeglądarki, gubi natywne gesty, powiadamia słabo albo wcale i wygląda jak strona w cienkiej ramce.

Dla panelu, w którym klikasz raz na jakiś czas, byłoby to akceptowalnym kompromisem. Dla narzędzia ratunkowego - nie. Dlatego poszliśmy drogą trudniejszą: osobny, natywny interfejs na każdej platformie, który wygląda i zachowuje się jak aplikacja z danego systemu, a nie ta sama makieta wciśnięta na Androida i iOS naraz.

Wspólne dla obu aplikacji jest to, co pod spodem: API i model danych. Osobny jest interfejs, bo Android i iOS mają swoje wzorce nawigacji, swój język gestów i swoje oczekiwania wobec tego, jak aplikacja ma się zachowywać. Próba wymuszenia jednego, wspólnego UI na obu kończy się tym, że na obu wygląda obco.

Kluczowe jest to, że mobilny klient rozmawia z dokładnie tym samym API co panel web. Nie ma "wersji mobilnej na skróty" z okrojonymi możliwościami - restart serwera z telefonu idzie tym samym kontraktem co restart z przeglądarki. Dzięki temu na telefonie robisz realnie to, co przy biurku, a nie wybrany podzbiór.

Aplikacja ma dwie strony. Operator nosi w telefonie dyżur: alarmy z czasem zdarzenia i przyciskiem, którym bierze sprawę na siebie, kolejkę spraw z KSeF, zgłoszeń i zatwierdzeń oraz stan węzłów z pamięcią i kopiami zapasowymi. Klient ma sklep, w którym wybiera pakiet, wariant i okres rozliczeniowy, płaci BLIK-iem wpisanym prosto w aplikacji, a do tego stronę stanu usług i zaproszenie na serwer z adresem do skopiowania i instrukcją dołączenia.

Powiadomienia to nie ozdoba, tylko rdzeń całego pomysłu na mobilkę. To one sprawiają, że dowiadujesz się o awarii, zanim napisze o niej pierwszy gracz. Bez nich aplikacja byłaby biernym oknem, które trzeba samemu otworzyć w odpowiednim momencie - a odpowiedni moment to zwykle ten, w którym o niczym nie wiesz.

Zdarzenie z backendu ma prosty, jednoznaczny kształt i to ono decyduje, gdzie wrzuci cię kliknięcie w powiadomienie. Deep link prowadzi nie do ekranu głównego, tylko wprost do konsoli tego konkretnego serwera, który ma problem. Zero szukania, zero nawigacji - od dźwięku telefonu do miejsca, w którym możesz działać, jest jedno dotknięcie.

Efekt to narzędzie, które realnie ratuje serwer z telefonu, a nie ścieżka awaryjna, z której korzystasz raz i wracasz do laptopa. Administrator dostaje na telefonie pełnię panelu: status, konsolę, akcje mocy, rozliczenia - i dowiaduje się o problemie w chwili, w której on powstaje, a nie wtedy, gdy przypadkiem zajrzy.

Po stronie Flaem zysk jest równie konkretny: mobilka nie jest osobnym produktem żyjącym własnym życiem, tylko kolejnym klientem tego samego API. Nowa możliwość w backendzie jest do sięgnięcia z telefonu tak samo jak z przeglądarki, bez przepisywania logiki drugi i trzeci raz.