Co się dzieje, gdy Twoja aplikacja traci internet (i jak dalej pracować)

Twoje WiFi pada. Wypełniasz formularz w aplikacji — połowa pól jest już gotowa, spędziłeś na tym pięć minut. Co się teraz dzieje?

Jeśli Twoja aplikacja działa wyłącznie online, historia wygląda tak: strona się przeładowuje. Twoje dane znikają. Zaczynasz od nowa. Zamykasz aplikację i już nigdy do niej nie wracasz.

Jeśli Twoja aplikacja jest offline-first, historia jest inna: piszesz dalej. Twoje dane są bezpieczne. Gdy WiFi wraca (trzy minuty później albo trzy dni później), wszystko się synchronizuje. To jest projektowanie offline-first w jednym zdaniu: aplikacja działa dalej bez połączenia z internetem, zapisuje Twoje zmiany lokalnie i synchronizuje je w momencie, gdy wracasz online.

Większość kreatorów aplikacji pomija offline, bo tak jest po prostu prościej. Ale offline-first nie jest skomplikowane — jest przemyślane. To różnica między aplikacją, po którą ktoś sięga, a aplikacją, którą usuwa.

Co naprawdę się dzieje, gdy Twoja aplikacja traci internet?

Kiedy Twoja aplikacja traci internet, albo dalej działa, albo nie — nie ma stanu pośredniego. A utrata połączenia nie jest rzadkością: użytkownik w samolocie nie ma internetu, użytkownik w tunelu nie ma zasięgu, użytkownik na wiejskiej sali eventowej ma słaby zasięg, użytkownikowi router restartuje się o 3 nad ranem i zostaje bez WiFi, użytkownik korzystający z hotspotu w telefonie wyczerpuje limit danych.

We wszystkich tych przypadkach Twoja aplikacja albo działa, albo nie.

Zbudowaliśmy aplikację do śledzenia czasu pracy dla freelancerów. Bez internetu się zawieszała. Jeden freelancer (korzystający z niej na budowach, bez zasięgu) przestał jej używać — wrócił do ołówka i papieru, bo ołówek działa wszędzie. Trzy miesiące później, po wprowadzeniu trybu offline, wrócił i już nie odszedł.

Mechanika jest prosta: zapisuj pracę lokalnie, gdy nie ma internetu, synchronizuj ją, gdy połączenie wraca. To wszystko.

Jakie są różne rodzaje bycia offline?

Są trzy rodzaje offline, na które warto się przygotować: świadomy, zaskakujący i wolny — i każdy wymaga innego rozwiązania.

Świadomy offline — użytkownik sam zdecydował się pracować offline. Jest w samolocie albo wie, że WiFi jest słabe. Spodziewa się zsynchronizować dane później. Najprostszy do zbudowania: wystarczy zapisywać wersje robocze lokalnie i wysyłać je, gdy połączenie wróci.

Zaskakujący offline — internet padł niespodziewanie. Użytkownik był w trakcie czegoś. Jeśli odetniesz go w połowie zdania, będzie zły. Rozwiązanie jest to samo (zapisuj wersje robocze lokalnie), ale UX powinien być łagodniejszy: pokaż, że aplikacja nadal działa, i poinformuj, kiedy użytkownik wraca online.

Wolny offline — połączenie jest, ale tak wolne, że równie dobrze mogłoby go nie być. Klient wypełnia formularz, klika wyślij, a potem czeka 20 sekund na zakończenie wysyłki. W tym czasie myśli, że coś się popsuło, i klika wyślij ponownie (teraz masz duplikat). To najtrudniejszy przypadek do przetestowania, ale rozwiązanie jest uczciwe: pokaż, że coś się dzieje (spinner), albo pozwól użytkownikowi opuścić stronę bez utraty wersji roboczej.

Jak poprosić swojego kreatora o tryb offline?

Prosisz o to etapami, nie jako jedną wielką funkcję — offline-first to filozofia projektowania, a nie pojedynczy przełącznik. Oto pięć konkretnych próśb, z którymi możesz zgłosić się do swojego kreatora:

Zapisuj wersje robocze lokalnie: „Kiedy ktoś wypełnia formularz albo notatkę, zapisz to na jego telefonie/w przeglądarce. Jeśli odświeży stronę, formularz nadal powinien być wypełniony.” Sprawdź to: wypełnij coś, zamknij kartę przeglądarki, otwórz ją ponownie — formularz nadal tam jest.
Działaj offline: „Jeśli nie ma internetu, aplikacja powinna pokazywać dane, które już mamy, pozwalać użytkownikowi je czytać i zmieniać, i kolejkować zmiany do synchronizacji, gdy internet wróci.” Sprawdź to: wyłącz WiFi, spróbuj zrobić coś użytecznego, a potem włącz WiFi z powrotem i obserwuj, jak dane się synchronizują.
Synchronizuj po cichu: „Kiedy synchronizujemy zmiany, nie pokazuj wielkiego okna dialogowego. Pokaż mały wskaźnik, na przykład ‘Zapisywanie…’ u góry, który znika, gdy skończy. Jeśli zapis się nie uda, zachowaj zmianę lokalnie i spróbuj ponownie później.”
Pokazuj prawdę: „Poinformuj użytkownika, które dane są świeże (właśnie zsynchronizowane z serwerem), a które są tylko lokalne (jeszcze niezsynchronizowane). Użyj małego wskaźnika lub etykiety — niech to nie będzie straszące, po prostu uczciwe.”
Jeden proces, najpierw lokalnie: „Kluczowa rzecz, po którą użytkownik przychodzi do aplikacji (sprawdzić rezerwację, napisać notatkę, śledzić czas pracy) powinna działać offline. Rzeczy dodatkowe (przeszukiwanie wszystkich dawnych wpisów, pobieranie aktualnych cen na żywo) mogą wymagać internetu.”

Prawdziwe historie

Organizatorka wesel zbudowała aplikację do zarządzania listą gości i potwierdzeń przybycia. Drukowała listę, chodziła po sali podczas wydarzeń i odhaczała odpowiedzi. Ale WiFi w salach eventowych bywa fatalne. Poprosiła o offline-first: zapisuj listę kontrolną lokalnie, synchronizuj po powrocie do domu. Teraz to jej główne narzędzie — nawet mając zasięg w telefonie, aplikacja działa bez czekania na dane. Bardzo ją sobie ceni.

Nauczycielka w szkole korzystała z aplikacji do śledzenia postępów uczniów. Ciągle traciła zmiany, przechodząc między salami o słabym zasięgu. Tryb offline oznaczał, że może pracować swobodnie, synchronizować później i nie musieć wybierać między telefonem a pracą. Jedna zmiana, ogromny wzrost zaufania.

Rzeczoznawca ubezpieczeniowy wypełniał raporty szkód na miejscu (bez zasięgu w niektórych wiejskich okolicach). Pierwotna aplikacja wymagała internetu do wysłania formularza. Dodaliśmy wersje robocze offline. Teraz wypełnia formularz, wysyła go offline, a synchronizacja zachodzi, gdy wraca samochodem. Koniec z „nie mogę niczego wysłać, dopóki nie będę w domu”.

Wszystkie trzy przypadki można by próbować rozwiązać hasłem „po prostu zdobądź lepsze WiFi”, ale świat rzeczywisty tak nie działa. Offline-first oznaczało większą zmianę w zaufaniu niż lepsza synchronizacja.

Czy offline-first sprawia, że Twoja aplikacja działa szybciej?

Tak — aplikacje offline-first sprawiają wrażenie szybszych, bo nie czekasz na serwer. Piszesz, aplikacja zapisuje lokalnie (natychmiast) i synchronizuje w tle. Bez spinnera, bez czekania. Nawet z internetem doświadczenie jest bardziej responsywne, bo serwer nie stoi na drodze.

Aplikacja działająca wyłącznie online musi czekać na potwierdzenie każdej zmiany przez serwer. Naciśnięcie klawisza → żądanie sieciowe → walidacja po stronie serwera → odpowiedź → pokazanie użytkownikowi. Zwykle to nie problem, ale przy wolnych sieciach (albo na komórce z wolnym serwerem) każda interakcja się zacina.

Ile kosztuje zbudowanie trybu offline-first?

Offline-first kosztuje więcej czasu inżynierskiego z góry. Twój kreator musi przemyśleć:

Pamięć lokalną: jak zapisywać dane na telefonie/w przeglądarce tak, by nie znikały w razie awarii aplikacji. Niełatwe, ale musi być przemyślane.
Rozwiązywanie konfliktów: jeśli użytkownik zmienia pole offline, a potem ktoś inny (albo to samo urządzenie, ale inne) zmienia to samo pole przed synchronizacją, które wygrywa? Zwykle to online (jest świeższe), ale użytkownik powinien zostać ostrzeżony, a nie zaskoczony. Realny przykład: dwa telefony edytują tę samą notatkę offline, oba wracają online — wygrywa ten, który synchronizuje się jako drugi, a pierwszy użytkownik widzi „Twoja wersja była starsza, oto aktualna”.
Nieaktualne dane: jeśli użytkownik był offline przez trzy dni, czy aplikacja powinna po cichu odświeżyć wszystko po ponownym połączeniu, czy najpierw zapytać? Zapytanie jest bezpieczniejsze — do starych danych mogły być dołączone niezapisane zmiany.

Przemyślenie tego nie jest darmowe, ale prostsze, niż mogłoby się wydawać.

Korzyść: aplikacje, którym ludzie ufają. Aplikacja offline-first nie tłumaczy się wymówkami („żeby z tego korzystać, potrzebujesz internetu”) i nie gubi Twojej pracy. To ogromna sprawa.

Jak sprawdzić, czy Twoja aplikacja działa offline?

Nie musisz lecieć samolotem, żeby to przetestować — tryb samolotowy w telefonie to Twój poligon testowy. Oto jak:

Otwórz i coś wypełnij: zrób coś normalnego (wypełnij formularz, dodaj notatkę).
Przejdź offline: włącz tryb samolotowy albo wyłącz WiFi.
Pracuj dalej: spróbuj zrobić to samo jeszcze raz. Jeśli aplikacja odmawia, offline-first jeszcze tam nie ma. Jeśli działa — dobrze. Jeśli jest to mylące, poproś swojego kreatora o wyraźny wskaźnik „Jesteś offline”.
Wróć online: wyłącz tryb samolotowy.
Sprawdź synchronizację: czy Twoje zmiany zsynchronizowały się automatycznie? Jeśli musiałeś kliknąć przycisk „synchronizuj” albo odświeżyć stronę, to jeszcze nie do końca to.

Najlepsze aplikacje offline sprawiają wrażenie tak normalnych, że nie zauważasz, że są offline — po prostu zauważasz, że aplikacja nadal działa.

Czy aplikacja, którą zbudowałeś, naprawdę musi działać offline? Jeśli odpowiedź brzmi „moi użytkownicy mają słaby internet albo pracują w miejscach bez zasięgu” — to tak. Jeśli brzmi „zawsze są na stabilnym WiFi” — możesz na razie to pominąć. Ale w momencie, gdy ktoś powie „straciłem swoją pracę”, pożałujesz, że nie poprosiłeś o to wcześniej.