Brak sieci jest normalnym stanem pracy
Garaż podziemny, parking poza miastem, hala serwisowa lub chwilowe przeciążenie sieci to codzienne sytuacje. Pracownik nie powinien wstrzymywać wydania tylko dlatego, że telefon stracił zasięg. Jednocześnie aplikacja nie może udawać sukcesu, jeśli nie ma potwierdzenia zapisu po stronie systemu.
Projektowanie offline-first zaczyna się od uznania, że połączenie jest zasobem okresowo dostępnym. Formularz musi najpierw zabezpieczyć pracę lokalnie, a następnie świadomie zsynchronizować ją, gdy warunki na to pozwolą.
Draft to więcej niż zawartość pól formularza
Trwały draft powinien przetrwać zamknięcie aplikacji, restart telefonu i ponowne logowanie tej samej uprawnionej osoby. Oprócz wartości pól przechowuje kontekst operacji, wersję danych, informacje o wymaganych zdjęciach i zależności między kolejnymi krokami.
Dane lokalne muszą być oddzielone według firmy i użytkownika. Telefon współdzielony przez dwóch pracowników nie może pokazać ani wysłać draftu osoby, która pracowała na poprzedniej zmianie. Sam zapis na urządzeniu nie zwalnia z kontroli dostępu po ponownym połączeniu.
Każda próba potrzebuje własnej tożsamości
Jeśli pracownik dotknie przycisku wysyłki, połączenie może zerwać się po zapisaniu danych na serwerze, ale przed otrzymaniem odpowiedzi. Ponowienie bez identyfikatora mogłoby utworzyć drugi zwrot, drugie rozliczenie lub kolejny dokument. Dlatego operacja otrzymuje unikalny identyfikator jeszcze przed pierwszą wysyłką.
Serwer wykorzystuje ten identyfikator do rozpoznania powtórzenia. Aplikacja może bezpiecznie zapytać o wcześniejszy rezultat zamiast zgadywać, czy powinna wykonać wszystko od początku. To szczególnie ważne dla operacji finansowych i finalizacji dokumentów.
Zdjęcia tworzą kolejkę zależności
Zdjęcia są większe niż zwykły formularz i mogą wysyłać się dłużej. Bezpieczny proces najpierw przygotowuje pliki, kontroluje ich format i rozmiar, a następnie przesyła je do prywatnego magazynu. Dopiero potwierdzone zasoby mogą zostać dołączone do finalnego protokołu.
Aplikacja musi wiedzieć, że finalizacja zależy od wcześniejszych uploadów. Samo ponawianie wszystkich żądań w przypadkowej kolejności może stworzyć dokument bez wymaganych zdjęć albo pozostawić osierocone pliki bez powiązania z operacją.
Konflikt wymaga decyzji, nie automatycznego nadpisania
Podczas pracy offline sytuacja w systemie może się zmienić. Inna osoba może przypisać pojazd, anulować rezerwację lub zakończyć proces. Po odzyskaniu połączenia aplikacja nie powinna bezwarunkowo nadpisywać nowszego stanu lokalną kopią.
Dla krytycznych operacji potrzebne są reguły domenowe: sprawdzenie aktualnej wersji, wykrycie konfliktu i przedstawienie użytkownikowi bezpiecznej ścieżki. Czasem będzie to odświeżenie danych, czasem powtórzenie wybranego kroku, a czasem eskalacja do osoby z większymi uprawnieniami.
Pięć pytań, które warto zadać dostawcy aplikacji
Deklarację działania offline warto przełożyć na konkretne scenariusze. Poproś o demonstrację rozpoczęcia procesu online, utraty sieci, zamknięcia aplikacji, ponownego uruchomienia i późniejszej synchronizacji. Sprawdź, czy użytkownik przez cały czas rozumie stan swojej pracy.
- Czy draft przetrwa restart aplikacji i urządzenia?
- Czy użytkownik widzi, które operacje nadal czekają na wysłanie?
- Jak system zapobiega podwójnemu zapisowi po ponowieniu?
- Co dzieje się ze zdjęciami, które nie zdążyły się wysłać?
- Jak aplikacja reaguje, gdy dane na serwerze zmieniły się podczas pracy offline?