Praktyka
Aplikacje offline dla techników w terenie
„Tryb offline" w ofertach systemów terenowych oznacza zwykle jedno z dwóch: albo aplikacja pokazuje ostatnio wczytane dane i nie pozwala nic zapisać, albo pozwala zapisać i po powrocie zasięgu gubi połowę. Poniżej opisuję, jak wygląda offline, który faktycznie wytrzymuje dzień pracy — na podstawie systemów, które utrzymuję produkcyjnie.
Dlaczego to jest trudniejsze, niż wygląda
Aplikacja online ma jedno źródło prawdy: bazę na serwerze. Aplikacja offline ma ich tyle, ile urządzeń w terenie. Każdy telefon przez kilka godzin jest samodzielną bazą danych, która nie wie, co w tym czasie zrobili inni.
Z tego bierze się większość problemów: konflikty zapisów, kolejność zdarzeń, identyfikatory nowych rekordów utworzonych bez połączenia i pytanie, co pokazać użytkownikowi, gdy synchronizacja się nie powiedzie. Dopisanie tego do gotowej aplikacji online prawie zawsze kończy się przepisaniem jej od nowa — dlatego offline jest decyzją architektoniczną z pierwszego dnia, a nie funkcją do dodania w drugim etapie.
Cztery elementy, na których to stoi
1. Wstępne pobranie danych
Zanim technik straci zasięg, urządzenie musi mieć wszystko, czego potrzebuje: przydzielone obiekty, urządzenia, szablony checklist, historię poprzednich przeglądów i słowniki. Pobranie następuje przy starcie dnia i w tle, gdy tylko jest połączenie.
Kluczowe pytanie brzmi: ile danych pobrać. Cała baza klientów to za dużo — długo się ładuje i jest problemem, jeśli telefon zginie. Ograniczam zakres do tego, co przydzielone danemu technikowi na najbliższe dni.
2. Kolejka zapisów
Każda zmiana wykonana bez zasięgu trafia do lokalnej kolejki jako osobne zdarzenie: „dodano wpis do checklisty", „dołączono zdjęcie", „złożono podpis". Kolejka jest trwała — przeżywa zamknięcie aplikacji, restart telefonu i rozładowanie baterii.
Zdarzenia wysyłają się w kolejności powstania, a każde ma identyfikator nadany na urządzeniu. Dzięki temu ponowna wysyłka tego samego zdarzenia nie tworzy duplikatu — serwer rozpoznaje, że już je widział.
3. Rozwiązywanie konfliktów
Tu najczęściej upada „offline z ulotki". Moje podejście zależy od typu danych:
| Typ danych | Strategia | Dlaczego |
|---|---|---|
| Wpisy checklisty, zdjęcia, uwagi | Append-only — każdy wpis to nowe zdarzenie | Dwie osoby nie mogą się nadpisać, bo nic nie jest nadpisywane. Powstaje pełna historia. |
| Status zlecenia, przypisanie technika | Wygrywa nowszy zapis, starszy zostaje w historii | Pole ma fizycznie jedną wartość. Ważne, żeby dało się odtworzyć, kto i kiedy ją zmienił. |
| Dokument podpisany | Blokada — po podpisie rekord jest zamknięty | Dokument, który zmienia się po złożeniu podpisu, nie broni się przed nikim. |
4. Widoczny stan synchronizacji
Technik musi wiedzieć, czy jego praca dotarła na serwer. Nie w formie technicznego komunikatu, tylko prostej informacji: ile pozycji czeka na wysłanie i kiedy była ostatnia udana synchronizacja.
Brak tej informacji jest częstszą przyczyną utraty zaufania do systemu niż faktyczna utrata danych — bo użytkownik, który nie wie, czy zapis przeszedł, na wszelki wypadek robi zdjęcie protokołu telefonem. I wraca do papieru.
Rzeczy, które zaskakują przy pierwszym wdrożeniu
- Zdjęcia to 95% problemu z pamięcią. Zdjęcie z nowoczesnego telefonu to kilka megabajtów. Dwadzieścia urządzeń na obiekcie i limit przeglądarki kończy się w połowie dnia. Kompresja przed zapisem jest obowiązkowa, nie opcjonalna.
- Zasięg „jest" częściej, niż go nie ma — i to gorzej. Jedna kreska bywa gorsza od zera kresek, bo zapytania nie kończą się błędem, tylko wiszą. Krótkie limity czasu i szybkie przejście w tryb offline działają lepiej niż czekanie.
- Zegar w telefonie bywa przestawiony. Kolejność zdarzeń oparta wyłącznie o czas z urządzenia potrafi się posypać. Serwer musi stemplować własnym czasem odbioru, zachowując czas urządzenia jako informację pomocniczą.
- Użytkownik zamknie aplikację w najgorszym momencie. Zapis do lokalnej bazy musi być zatwierdzony, zanim interfejs pokaże, że coś się udało.
- Aktualizacja aplikacji w trakcie pracy. Nowa wersja nie może pojawić się w środku wypełniania protokołu. Aktualizacja czeka na moment, w którym nie ma niezapisanych danych.
PWA czy aplikacja ze sklepu
Dla większości firm serwisowych progresywna aplikacja webowa (PWA) wystarcza. Instaluje się ze strony, działa bez zasięgu, aktualizuje się sama i nie wymaga przechodzenia przez proces publikacji przy każdej poprawce — co przy pilotażu ma realne znaczenie.
Sklep bywa potrzebny z innych powodów niż techniczne: wymogi klienta korporacyjnego, zarządzanie flotą urządzeń, dystrybucja przez dział IT. Wtedy tę samą aplikację pakuję do formy instalowalnej — tak zrobiłem z Safe-Pro na Androida, bez pisania osobnej wersji.
Najczęstsze pytania
Czym różni się aplikacja offline od zwykłej strony w telefonie?
Zwykła strona przy braku połączenia pokazuje błąd, bo każdy widok pobiera dane z serwera. Aplikacja offline trzyma komplet danych potrzebnych do pracy lokalnie na urządzeniu i zapisuje zmiany do własnej kolejki.
Serwer jest jej potrzebny wyłącznie do synchronizacji, która może nastąpić kilka godzin później.
Czy aplikacja offline musi być instalowana ze sklepu?
Nie. PWA instaluje się bezpośrednio ze strony i działa bez zasięgu tak samo jak aplikacja ze sklepu.
Sklep bywa potrzebny z powodów organizacyjnych — wymogów klienta korporacyjnego, zarządzania flotą urządzeń albo dostępu do funkcji, których przeglądarka nie udostępnia.
Co się dzieje, gdy dwie osoby zmienią ten sam rekord bez zasięgu?
Zależy od typu danych. Dla checklisty stosuję model append-only: każdy wpis jest osobnym zdarzeniem z autorem i czasem, więc dwie osoby nie nadpisują się nawzajem.
Dla danych, które fizycznie mają jedną wartość — jak status zlecenia — wygrywa nowszy zapis, ale starszy zostaje w historii zmian, a użytkownik dostaje informację o rozbieżności.
Ile danych zmieści się w telefonie technika?
Sam tekst i struktura danych to rzędy megabajtów — kilkaset obiektów z historią mieści się bez problemu.
Realnym ograniczeniem są zdjęcia. Dlatego kompresuję je na urządzeniu przed zapisem i usuwam oryginały z pamięci lokalnej po potwierdzonej synchronizacji.
Macie proces, który dzieje się poza zasięgiem?
Napiszcie, gdzie pracują Wasi technicy i jaki dokument muszą stamtąd przywieźć. Odpowiadam w ciągu jednego dnia roboczego.
Napisz do mnie Zobacz przykład wdrożenia