Zacznij od czynności wykonywanych poza biurem
Aplikacja terenowa nie potrzebuje trybu offline dla każdej funkcji. Technik może wymagać dostępu do przydzielonych zleceń, listy czynności i roboczej notatki, lecz końcowe zatwierdzenie kosztu powinno odbywać się po sprawdzeniu aktualnych danych. Rozdziel zadania możliwe bez sieci od tych, które potrzebują odpowiedzi serwera. Taki podział jest ważniejszy od samego przycisku instalacji na telefonie.
W przykładowym programie pracownik odczytuje wcześniej pobrane zlecenie, zapisuje wynik oględzin i wykonuje zdjęcie. Ekran powinien informować, które dane już dotarły do biura, a które pozostają na urządzeniu. Brak tej różnicy prowadzi do sytuacji, w której technik uważa zadanie za przekazane, choć jego telefon od rana nie miał połączenia.
Oddziel zasoby aplikacji od danych zlecenia
Mechanizm service worker może wspierać dostęp do zasobów i działanie części funkcji bez sieci. Nie oznacza to automatycznie poprawnej synchronizacji danych biznesowych. PWA wymaga świadomej strategii: co przechowywać, kiedy pobierać aktualną wersję i jak reagować na brak odpowiedzi. Przeglądarka nie zastępuje zaprojektowanej kolejki zmian.
Plik stylów można odświeżyć inaczej niż status wykonania naprawy. Dla danych zlecenia pokaż czas ostatniego pobrania i zaznacz, że widok może być nieaktualny. Nie zapisuj całej historii klientów tylko dlatego, że da się ją zmieścić w pamięci urządzenia. Ograniczenie lokalnego zakresu upraszcza aktualizację, zmniejsza konsekwencje utraty telefonu i ułatwia obsługę końca dostępu pracownika.
Zapis lokalny potrzebuje własnego modelu
IndexedDB pozwala przechowywać w przeglądarce ustrukturyzowane dane i wykonywać operacje transakcyjne. Można wykorzystać ją do roboczych formularzy i listy oczekujących zmian. Trzeba jednak zaprojektować identyfikatory, wersję struktury oraz zachowanie po nieudanym zapisie. Nie wystarczy przenieść do pamięci lokalnej pojedynczy tekst z całym formularzem.
Każda operacja może otrzymać własny identyfikator, numer zlecenia i stan, na przykład „robocza”, „do wysłania” oraz „potwierdzona”. Te nazwy muszą odpowiadać rzeczywistemu etapowi. Stan „wysyłana” nie jest równoznaczny z „przyjęta”. Przy zdjęciach pokaż osobno postęp przesyłania, aby notatka z pustym załącznikiem nie wyglądała jak kompletny protokół.
Zaprojektuj powrót do połączenia
Po odzyskaniu internetu program powinien przekazać zaległe operacje i rozpoznać ich potwierdzenia. Powtórzenie tej samej operacji nie może tworzyć drugiego protokołu. Przygotuj także ręczny przycisk synchronizacji i listę problemów wymagających decyzji. Automatyzacja działająca w tle jest pomocna, ale użytkownik potrzebuje widocznej drogi odzyskania kontroli.
MyTworzymy.pl realizuje usługi dla firm w całej Polsce, dlatego przy omawianiu programu terenowego warto opisać prawdziwe warunki pracy, nie tylko wygląd telefonu. Przykładowe zlecenie wykonane w miejscu bez zasięgu jest dobrym materiałem do specyfikacji. Pozwala ustalić, co pracownik musi dokończyć samodzielnie, zanim aplikacja znów porozumie się z biurem.
Konflikt danych nie jest zwykłym błędem sieci
Podczas pracy offline dyspozytor może zmienić adres wizyty lub anulować zadanie. Po synchronizacji aplikacja nie powinna bezwarunkowo nadpisać jego decyzji starszą kopią. Porównuj wersję, na której powstała operacja, z aktualnym stanem. Oddziel bezpieczne dopisanie nowej notatki od zmiany pola, które w międzyczasie edytowała inna osoba.
Dla konfliktu przygotuj czytelne wyjaśnienie: co zapisano lokalnie, co zmieniło się na serwerze i jaka decyzja jest potrzebna. Nie zmuszaj technika do porównywania surowych danych. W niektórych procesach wystarczy zachować oba komentarze, w innych potrzebna będzie zgoda koordynatora. Reguła powinna wynikać z odpowiedzialności za sprawę, nie z przypadkowej kolejności połączeń.
Uwzględnij ograniczenia urządzenia i sesji
Pamięć przeglądarki ma limity, a zachowanie dotyczące zachowania lub usuwania danych zależy od środowiska. Nie traktuj jej jak bezwarunkowo trwałej kopii firmowej dokumentacji. Obsłuż brak miejsca i sprawdzaj, czy zapis rzeczywiście się udał. Użytkownik powinien wiedzieć, że usunięcie danych aplikacji może usunąć nieprzekazane szkice.
Z MyTworzymy.pl można omówić taki zakres PWA, w którym użyteczny tryb offline nie wymaga od razu budowy rozbudowanego systemu synchronizacji całej firmy. Dobrym początkiem bywa jedna kontrolowana ścieżka: pobranie zadania, zapis protokołu i potwierdzone przekazanie. Następne funkcje warto dodawać po sprawdzeniu tej drogi na urządzeniach używanych przez pracowników.
Przetestuj przerwy w najmniej wygodnym momencie
Odłącz sieć przed wysłaniem, podczas przesyłania załącznika i po przyjęciu danych, lecz przed pokazaniem potwierdzenia. Zamknij aplikację, uruchom ją ponownie i sprawdź zaległą kolejkę. Przetestuj także wygaśnięcie sesji oraz cofnięcie dostępu do zlecenia. Ponowne logowanie nie może prowadzić do wysłania danych pod kontem innego pracownika.
Osobno sprawdź aktualizację samej aplikacji z niewysłanymi szkicami. Nowa struktura danych nie powinna porzucać wcześniejszych notatek bez komunikatu. Wyniki testów zapisuj jako konkretne stany, a nie ogólne „offline działa”. Terenowy program jest gotowy wtedy, gdy potrafi wyjaśnić użytkownikowi, co stało się z jego pracą także przy nieudanym połączeniu.