Brak zasięgu w magazynie, na budowie i w trasie jest stanem normalnym. Aplikacja, która wtedy nie działa, nie działa w połowie przypadków użycia.
Dane wprowadzone bez połączenia zostają w urządzeniu i czekają. Komunikat o błędzie sieci zamiast zapisu oznacza utratę pracy.
Zapisywać trzeba na bieżąco, przy każdym wypełnionym polu, a nie dopiero przy zatwierdzeniu formularza. Rozładowany telefon i przypadkowe zamknięcie aplikacji zdarzają się częściej niż awarie sieci.
Użytkownik musi wiedzieć, ile pozycji czeka na wysłanie. Cicha kolejka kończy się przekonaniem, że dane są w systemie, gdy leżą w telefonie.
Potrzebny jest też ręczny przycisk wysyłki i czytelny komunikat o pozycji, której wysłać się nie udało. Błąd, który znika po chwili, zostawia dziurę w danych zauważaną dopiero przy rozliczeniu.
Dwie osoby zmieniły ten sam rekord bez połączenia. Reguła rozstrzygania musi zostać ustalona z góry: kto wygrywa, czy zapisujemy obie wersje, kto to zatwierdza.
Najmniej kłopotów sprawia układ, w którym urządzenia dopisują zdarzenia, zamiast nadpisywać stan. Zamiast „stan wynosi dwanaście" zapisujemy „wydano trzy sztuki". Takie zapisy da się połączyć w dowolnej kolejności i konflikt w ogóle nie powstaje. Tak działa większość rozwiązań magazynowych na urządzeniu mobilnym.
Zwykle wszystko poza operacjami wymagającymi bieżącego stanu — rezerwacją towaru czy sprawdzeniem limitu klienta. Te ograniczenia muszą być widoczne, a nie objawiać się błędem.
Dobrą praktyką jest wyraźne oznaczenie trybu pracy bez połączenia i wyszarzenie funkcji, które w nim nie działają. Użytkownik wie wtedy, na czym stoi, zamiast zgadywać, czy aplikacja się zawiesiła.
Cały cennik i pełna kartoteka rzadko mieszczą się rozsądnie w urządzeniu. Zwykle wystarcza zakres przypisany do użytkownika.
Trzeba też ustalić, jak stare mogą być dane pobrane na urządzenie i kiedy wymuszamy odświeżenie. Cena sprzed tygodnia podana klientowi jako aktualna to problem handlowy, nie techniczny.
Dane leżące lokalnie jadą wraz z telefonem. Potrzebna jest blokada ekranu, możliwość zdalnego wyczyszczenia i ograniczenie zakresu do tego, co naprawdę niezbędne. To argument za pobieraniem wycinka zamiast całości.
Próby przy pełnym zasięgu nie dowodzą niczego. Aplikację trzeba sprawdzić tam, gdzie połączenie realnie zanika.
Najtrudniejszy jest nie brak sieci, tylko połączenie słabe i przerywane — wtedy wysyłka rusza i urywa się w połowie. Ten przypadek trzeba wywołać celowo, w hali albo w terenie, przy wypełnianiu formularzy z załącznikami, gdzie objawia się najostrzej.
Gdy narzędzie jest używane wyłącznie w biurze przy stabilnej sieci. Obsługa pracy bez połączenia to osobny mechanizm do zbudowania i utrzymania — zwykła strona mobilna wystarcza wtedy w zupełności.