Offline-first:
decyzja na lata

Większość klientów pyta o offline-first za późno. Aplikacja jest już wdrożona, użytkownicy narzekają, że „apka się zawiesza w terenie”, a deweloper tłumaczy, że poprawka wymagałaby przepisania połowy projektu. Ten artykuł wyjaśnia, dlaczego offline-first to decyzja architektoniczna podejmowana na początku projektu, a nie funkcja dodawana później na życzenie.

Czym jest offline-first

Offline-first oznacza, że aplikacja działa poprawnie bez połączenia z siecią. Nie wyświetla komunikatu o błędzie, nie blokuje użytkownika, nie traci danych. Zapis odbywa się lokalnie, a synchronizacja z serwerem następuje w tle, gdy sieć jest dostępna.

To nie to samo co „cache”. Cache to optymalizacja wydajności. Offline-first to inne podejście do architektury danych, gdzie lokalna baza urządzenia jest źródłem prawdy, a sieć jest mechanizmem synchronizacji.

Kiedy brak offline-first kosztuje klientów i pieniądze

Trzy scenariusze, które regularnie pojawiają się w projektach mobilnych dla firm:

Pracownik magazynowy bez zasięgu

Hala magazynowa z metalową konstrukcją, sygnał GPS praktycznie zerowy, Wi-Fi tylko przy bramie. Pracownik skanuje paczki przez zmianę, a każda operacja wymaga połączenia z API. Rezultat: kółko ładowania co 10 sekund, operacje odrzucane, stany magazynowe niespójne. Pracownik wraca do papierowego zeszytu „bo apka nie działa”. System kosztował 200 000 zł, a nikt go nie używa.

Serwisant w terenie

Technik jedzie do klienta, ma zlecenie w aplikacji. W budynku przemysłowym zasięg ginie. Nie może wyświetlić historii usterek, nie może zapisać notatki z wizyty, nie może oznaczyć zlecenia jako wykonanego. Wraca na koniec dnia i uzupełnia wszystko ręcznie. Automatyzacja, która miała oszczędzać czas, generuje podwójną pracę.

Aplikacja w tunelu metra lub w samolocie

Tu sprawa jest prostsza. Jeśli Twoi użytkownicy korzystają z aplikacji w czasie dojazdu do pracy, tracisz ich uwagę i dane za każdym razem, gdy wjeżdżają pod ziemię. Dla aplikacji konsumenckich to bezpośrednio przekłada się na retencję.

Koszt naprawy braku offline-first po wdrożeniu jest zwykle 3–5 razy wyższy niż zaprojektowanie go od początku. Warstwa synchronizacji musi zostać dodana do każdego ekranu, każdej operacji i każdego przepływu danych w aplikacji.

Co to oznacza w praktyce projektowania

Offline-first zmienia sposób myślenia o danych na trzech poziomach:

Modelowanie danych. Każdy rekord musi mieć informację o swoim stanie synchronizacji: czy jest już zsynchronizowany z serwerem, czy czeka na wysłanie, czy był modyfikowany offline. To dodaje złożoność do schematu bazy danych od samego początku.

enum class SyncStatus { SYNCED, PENDING, MODIFIED_OFFLINE }

@Entity
data class TaskEntity(
    @PrimaryKey val id: String,
    val title: String,
    val completedAt: Long?,
    val syncStatus: SyncStatus = SyncStatus.PENDING,
    val lastModifiedLocal: Long = System.currentTimeMillis()
)

Synchronizacja w tle. Aplikacja musi wiedzieć, kiedy pojawiła się sieć, i uruchomić synchronizację bez udziału użytkownika. Musi też obsłużyć sytuacje, gdy synchronizacja się nie powiedzie, i ponowić próbę później. To nie jest try-catch wokół requestu HTTP.

Stan w interfejsie. Użytkownik powinien wiedzieć, że jego dane czekają na synchronizację. Ikona, subtelny komunikat, znacznik czasu ostatniej synchronizacji. Ukrywanie tego stanu prowadzi do zgłoszeń „zniknęły mi dane”, bo użytkownik nie wie, że rekord jest lokalny i nie dotarł jeszcze na serwer.

Strategie rozwiązywania konfliktów

Tu robi się interesująco z biznesowego punktu widzenia. Co się dzieje, gdy dwóch użytkowników edytuje ten sam rekord offline, a potem oboje synchronizują dane?

Serwer zawsze ma rację

Prosta strategia: gdy dane lokalne kolidują z tym, co jest na serwerze, lokalne zmiany są nadpisywane. Dobre dla danych finansowych, stanów magazynowych w czasie rzeczywistym, wszędzie gdzie spójność jest ważniejsza niż to, co zrobił jeden użytkownik offline.

Wada: jeśli użytkownik wypełnił formularz offline przez 20 minut, a serwer ma nowszą wersję, traci całą pracę bez ostrzeżenia. To frustrujące.

Merge, czyli łączenie zmian

Inteligentniejsza strategia: aplikacja łączy zmiany z obu źródeł. Jeden użytkownik zmienił imię klienta, drugi zmienił numer telefonu — merge połączy obie zmiany bez konfliktu.

Kiedy to ma sens: aplikacje do pracy zespołowej, systemy CRM, narzędzia do zarządzania projektem. Wszędzie tam, gdzie kilka osób pracuje na tych samych danych i każda zmiana ma wartość. Wada: złożoność implementacyjna jest wyraźnie wyższa.

Kiedy offline-first NIE ma sensu

Uczciwa odpowiedź: nie każda aplikacja tego potrzebuje, a inwestycja w offline-first przy nieodpowiednim projekcie to przepalanie budżetu.

Dashboardy i raporty analityczne. Jeśli aplikacja służy do przeglądania danych, a nie ich tworzenia, lokalne przechowywanie przestarzałych liczb jest gorsze niż komunikat „brak sieci, sprawdź połączenie”. Decyzje biznesowe podejmowane na podstawie danych sprzed 3 dni mogą kosztować więcej niż chwilowy brak dostępu.

Aplikacje B2B w biurze. Jeśli wszyscy użytkownicy są na Wi-Fi firmowym przez cały czas pracy, offline-first to niepotrzebna złożoność. Solidna obsługa błędów sieciowych i dobre komunikaty wystarczą.

Mały budżet i ciasny deadline. Offline-first podwaja złożoność warstwy danych. Jeśli budżet jest napięty, lepiej dostarczyć prostszą aplikację działającą dobrze w trybie online, niż pokomplikowaną aplikację z błędami synchronizacji.

Pytania, które warto zadać przed podpisaniem umowy

Zanim zlecisz projekt aplikacji mobilnej dla pracowników terenowych lub obsługi klienta, zadaj deweloperowi lub agencji trzy pytania:

Offline-first to inwestycja, która zwraca się w aplikacjach dla pracowników w terenie, handlowców, serwisantów, kierowców i wszystkich, których praca odbywa się poza stałym dostępem do internetu. Dla aplikacji wewnętrznych w biurze lub dashboardów analitycznych, ta inwestycja najczęściej się nie zwraca.