W poprzednim artykule pisaliśmy, kiedy tryb offline jest w ogóle potrzebny i ile kosztuje jego wdrożenie. Temat wrócił do Was szybciej, niż się spodziewaliśmy, więc czas na konkrety – jak to wygląda, gdy klient faktycznie decyduje się na taki projekt. Pokazujemy prawdziwy case z naszego portfolio, typowy scenariusz z pracy w terenie oraz to, czego nauczyliśmy się o synchronizacji danych po kilku takich wdrożeniach.
Case: aplikacja mobilna dla handlowców pracujących w terenie
Jednym z projektów, przy których offline nie był dodatkiem, tylko wymogiem, była aplikacja mobilna stanowiąca rozszerzenie systemu CRM klienta, wspierająca pracę działu handlowego. Aplikacja miała dać handlowcom szybki dostęp do danych klientów, historii kontaktów oraz możliwość planowania i raportowania wizyt bezpośrednio ze smartfona.
Problem pojawił się szybko: handlowcy pracują w terenie, często u klientów zlokalizowanych w miejscach o słabym zasięgu – magazynach, halach produkcyjnych, mniejszych miejscowościach. Aplikacja, która przestaje działać bez internetu, w tym kontekście po prostu nie miała sensu. Musieliśmy zaprojektować mechanizm, który pozwala:
- kontynuować pracę bez połączenia – dodawać notatki, zdjęcia, statusy wizyt,
- przechowywać te dane lokalnie w bezpieczny sposób,
- automatycznie synchronizować je z systemem CRM, gdy tylko telefon złapie zasięg,
- robić to bez utraty danych i bez dublowania wpisów.
Największym wyzwaniem nie było samo zapisywanie danych offline – to stosunkowo prosta część. Trudność zaczęła się przy synchronizacji dwukierunkowej: dane wprowadzone w aplikacji mobilnej musiały natychmiast trafiać do panelu webowego i odwrotnie, bez konfliktów, gdy handlowiec i osoba w biurze pracowały na tych samych danych klienta w tym samym czasie.
Warto dodać, że lokalizacja GPS zbierana w trybie offline to nie tylko potwierdzenie wizyty u klienta. W tego typu aplikacjach dane o lokalizacji handlowca czy pracownika terenowego są później wykorzystywane do rozliczania premii i wypłat – system musi więc zapisać dokładny czas i miejsce wizyty nawet bez zasięgu, a potem przekazać te dane do rozliczeń bez opóźnień i bez możliwości ich pominięcia czy edycji przez użytkownika. To podnosi poprzeczkę: dane GPS zebrane offline muszą być traktowane tak samo rzetelnie, jak gdyby były wysyłane na bieżąco.
Drugi typowy scenariusz z naszej praktyki: dokumentacja i zbieranie danych w terenie
Poza tym projektem, offline regularnie wraca w rozmowach z klientami z zupełnie innych branż – logistyki, serwisu technicznego, inspekcji czy zbierania danych w terenie. Schemat problemu jest zaskakująco podobny za każdym razem, więc opiszemy go ogólnie, bez wskazywania konkretnego klienta.
Typowy przypadek wygląda tak: pracownik w terenie musi wypełnić formularz, zrobić zdjęcie, zeskanować kod kreskowy lub zarejestrować lokalizację GPS – ale robi to w miejscu bez internetu (piwnica, teren przemysłowy, trasa poza miastem). Rozwiązanie, które sprawdza się w praktyce, to:
- lokalna kolejka zadań – każda akcja użytkownika (formularz, zdjęcie, skan) trafia najpierw do lokalnej bazy na urządzeniu,
- automatyczna próba wysyłki w tle, gdy tylko pojawi się połączenie,
- czytelny wskaźnik w interfejsie, które dane czekają na synchronizację, a które już dotarły na serwer,
- mechanizm ponawiania wysyłki przy niestabilnym łączu, zamiast jednorazowej próby, która kończy się błędem.
Bez tego typu rozwiązania użytkownicy w terenie albo tracą dane, albo – co gorsza – przestają ufać aplikacji i wracają do notatnika czy Excela. To najczęstszy powód, dla którego klienci w ogóle przychodzą do nas z tematem offline.
Trzeci przypadek: pobieranie treści wideo na potrzeby offline
Offline nie zawsze dotyczy pracy w terenie – czasem chodzi po prostu o odtwarzanie treści bez połączenia. Tak było w projekcie aplikacji do odtwarzania filmów z tłumaczeniem na Polski Język Migowy. Użytkownik miał móc pobrać nagranie i obejrzeć je później, nawet bez internetu – to kluczowa funkcja dla dostępności, bo dobre łącze nie zawsze jest dostępne tam, gdzie użytkownik faktycznie chce obejrzeć materiał.
Problemem nie było samo pobieranie plików wideo, tylko to, co się dzieje, gdy użytkownik zamknie aplikację w trakcie pobierania. Bez odpowiedniego mechanizmu kończyło się to uszkodzonym, niekompletnym plikiem, który po powrocie do aplikacji nie dało się odtworzyć, a czasem trzeba było pobierać film od nowa. Musieliśmy zapewnić:
- wznawianie pobierania od miejsca przerwania, a nie od zera, po ponownym otwarciu aplikacji,
- kontynuację pobierania w tle, gdy aplikacja jest zminimalizowana,
- wykrywanie i czyszczenie niekompletnych, uszkodzonych plików, żeby użytkownik nigdy nie próbował odtworzyć wideo, które nie pobrało się w całości,
- czytelną informację w interfejsie o statusie pobierania, żeby użytkownik wiedział, czy materiał jest już gotowy do obejrzenia offline.
To dobry przykład na to, że offline to nie zawsze synchronizacja danych z formularzy – czasem to równie wymagająca praca nad samym zarządzaniem plikami na urządzeniu.
Czego nauczyliśmy się o synchronizacji danych
Po kilku takich wdrożeniach kilka wniosków powtarza się niezależnie od branży:
Konflikty danych trzeba przewidzieć zawczasu, a nie łatać po fakcie. Zanim napiszemy pierwszą linijkę kodu, ustalamy z klientem jasną regułę – czy wygrywa ostatnia zmiana, czy dane się scalają, czy może użytkownik ma dostać komunikat i wybrać wersję ręcznie. Brak takiej decyzji na starcie prawie zawsze kończy się przebudową logiki synchronizacji w połowie projektu.
Testowanie offline wymaga symulowania realnych warunków, nie tylko trybu samolotowego. Niestabilne łącze, nagłe zerwanie połączenia w trakcie wysyłki, przełączanie się między Wi-Fi a danymi komórkowymi – to scenariusze, które najczęściej psują synchronizację w produkcji, a najrzadziej są testowane.
Lokalne przechowywanie danych to też kwestia bezpieczeństwa, nie tylko wydajności. Dane klientów czy dokumentacja z terenu leżące lokalnie na urządzeniu muszą być odpowiednio zaszyfrowane – zwłaszcza gdy telefon może zostać zgubiony lub skradziony.
Ile to kosztuje w praktyce
W poprzednim artykule pisaliśmy, że tryb offline podnosi koszt projektu o 30-50% względem wersji wymagającej stałego połączenia. Nasze doświadczenie z realnych wdrożeń tę wycenę potwierdza – największy wzrost budżetu generuje właśnie warstwa synchronizacji i obsługa konfliktów danych, a nie samo lokalne przechowywanie informacji. Dlatego zawsze rekomendujemy, żeby na etapie planowania projektu dokładnie określić, które funkcje faktycznie muszą działać offline, a które mogą poczekać na połączenie – to często pozwala ograniczyć zakres i koszt bez utraty realnej wartości dla użytkownika.
Jak podchodzimy do tego u siebie
Zanim zaczniemy projektować rozwiązanie offline, zadajemy klientowi kilka pytań: gdzie dokładnie pracują użytkownicy i jak często brakuje im zasięgu, które akcje w aplikacji są krytyczne, a które mogą poczekać na internet, oraz co się stanie, jeśli dwie osoby zmienią te same dane w tym samym czasie. Odpowiedzi na te pytania determinują architekturę całego rozwiązania – i pozwalają uniknąć sytuacji, w której offline zostaje dodane na siłę tam, gdzie nie jest naprawdę potrzebne.
Jeśli Twoi użytkownicy pracują w terenie, w miejscach ze słabym zasięgiem, albo po prostu podejrzewacie, że brak trybu offline kosztuje Was porzucone formularze i sfrustrowanych klientów – napiszcie do nas. Chętnie przejrzymy Wasz przypadek i powiemy szczerze, czy offline faktycznie jest Wam potrzebny, i ile realnie będzie kosztować takie wdrożenie.
