Что происходит, когда ваше приложение теряет интернет (и как продолжать работать)

Ваш WiFi отключается. Вы заполняете форму в приложении — половина полей готова, вы потратили на это пять минут. Что происходит дальше?

Если ваше приложение работает только онлайн, вот чем это заканчивается: страница перезагружается или обновляется. Данные исчезают. Вы начинаете заново. Вы закрываете приложение — и больше не возвращаетесь.

Если ваше приложение offline-first, история другая: вы продолжаете печатать. Данные в безопасности. Когда WiFi возвращается (через три минуты или через три дня), всё синхронизируется. Вот offline-first дизайн одним предложением: приложение продолжает работать без интернет-соединения, сохраняет ваши изменения локально и синхронизирует их в тот момент, когда вы снова онлайн.

Большинство конструкторов приложений пропускают офлайн-режим, потому что так проще строить. Но offline-first — это не сложно, это осознанно. Это разница между приложением, к которому тянется рука, и приложением, которое удаляют.

Что на самом деле происходит, когда приложение теряет интернет?

Когда приложение теряет интернет, оно либо продолжает работать, либо нет — среднего не бывает. И потеря соединения — не редкость: у пользователя в самолёте нет интернета, у пользователя в туннеле нет сигнала, у пользователя на загородной площадке нестабильное покрытие, у пользователя, чей домашний роутер перезагружается в 3 часа ночи, — мёртвый WiFi, у пользователя, подключённого через мобильный хотспот, — исчерпанный лимит.

Во всех этих случаях ваше приложение либо работает, либо нет.

Мы создавали приложение для учёта времени фрилансеров. Оно падало без интернета. Один фрилансер (работавший на стройках, где нет сигнала) перестал им пользоваться — вернулся к карандашу и бумаге, потому что карандаш работает везде. Три месяца спустя, после появления офлайн-режима, он вернулся и больше не уходил.

Механика простая: сохранять работу локально, когда интернета нет, и синхронизировать её, когда соединение возвращается. Вот и всё.

Какие бывают виды офлайна?

Есть три вида офлайна, к которым стоит готовиться: намеренный, внезапный и медленный — и каждый требует своего решения.

Намеренный офлайн — пользователь сам решил работать без сети. Он в самолёте или знает, что WiFi там плохой. Он ожидает синхронизации позже. Проще всего реализовать: просто сохранять черновики локально и отправлять их, когда соединение вернётся.

Внезапный офлайн — интернет пропал неожиданно. Пользователь был в процессе чего-то важного. Если оборвать его на полуслове, он разозлится. Решение то же самое (сохранять черновики локально), но подача мягче: показать ему, что приложение продолжает работать, и сообщить, когда он снова онлайн.

Медленный офлайн — соединение есть, но оно настолько медленное, что толку от него как от отсутствующего. Клиент заполняет форму, нажимает «отправить», а потом 20 секунд ждёт завершения отправки. К этому моменту он думает, что что-то сломалось, и нажимает «отправить» ещё раз (теперь у вас дубликат). Это самый сложный случай для тестирования, но решение честное: показать, что работа идёт (спиннер), или дать возможность уйти со страницы, не потеряв черновик.

Как попросить об офлайн-режиме у своего конструктора приложений?

Просите об этом по частям, а не как об одной большой функции — offline-first это философия дизайна, а не один переключатель. Вот пять конкретных запросов, которые можно принести своему конструктору:

Сохранять черновики локально: «Когда кто-то заполняет форму или заметку, сохраняй это на телефоне/в браузере пользователя. Если он обновит страницу, форма должна остаться заполненной». Проверка: заполните что-нибудь, закройте вкладку браузера, откройте снова — форма всё ещё на месте.
Работать офлайн: «Если интернета нет, приложение должно показывать имеющиеся данные, позволять пользователю их читать и вносить изменения, а сами изменения ставить в очередь на синхронизацию, когда интернет вернётся». Проверка: отключите WiFi, попробуйте сделать что-то полезное, затем включите WiFi обратно и посмотрите, как данные синхронизируются.
Синхронизировать незаметно: «Когда мы синхронизируем изменения, не показывай большое диалоговое окно. Покажи маленький индикатор, например «Сохранение…» сверху, и пусть он исчезает, когда всё готово. Если сохранение не удалось, оставь изменение локально и попробуй ещё раз позже».
Показывать правду: «Сообщай пользователю, какие данные свежие (только что синхронизированы с сервером), а какие — только локальные (ещё не синхронизированы). Используй небольшой индикатор или метку — не пугай, просто будь честен».
Один рабочий процесс — сначала локально: «Основная задача, ради которой пользователь заходит в приложение (проверить бронирование, написать заметку, отследить время), должна работать офлайн. Второстепенные вещи (поиск по всей истории записей, получение актуальных цен) могут требовать интернет».

Реальные истории

Организатор свадеб создала приложение для управления списком гостей. Она распечатывала список, ходила с ним по площадке и отмечала ответы. Но WiFi на площадках обычно ужасен. Она попросила offline-first: сохранять чек-лист локально, синхронизировать по возвращении домой. Теперь это её основной инструмент — даже когда есть сигнал телефона, приложение работает, не дожидаясь загрузки данных. Она в восторге.

Учительница использовала приложение для отслеживания успеваемости учеников. Постоянно теряла правки, переходя между кабинетами с нестабильным покрытием. Офлайн-режим дал ей возможность работать свободно, синхронизироваться позже — и не выбирать между телефоном и работой. Одно изменение — огромный прирост доверия.

Страховой оценщик заполнял отчёты о повреждениях на месте (в некоторых сельских районах нет сигнала). Изначальное приложение требовало интернет для отправки. Мы добавили офлайн-черновики. Теперь он заполняет форму, отправляет её офлайн, а синхронизация происходит, пока он едет обратно. Больше никакого «я ничего не могу отправить, пока не доберусь домой».

Все три случая можно было бы решить фразой «просто найдите WiFi получше», но реальный мир так не работает. Offline-first оказался куда более значимым сдвигом доверия, чем просто более быстрая синхронизация.

Делает ли offline-first ваше приложение быстрее?

Да — offline-first приложения ощущаются быстрее, потому что вам не нужно ждать сервер. Вы печатаете, приложение сохраняет данные локально (мгновенно) и синхронизирует их в фоне. Никаких спиннеров, никакого ожидания. Даже при наличии интернета работа ощущается более отзывчивой, потому что сервер не стоит на пути.

Приложению, работающему только онлайн, приходится ждать подтверждения сервера на каждое изменение. Нажатие клавиши → сетевой запрос → проверка на сервере → ответ → показ пользователю. Обычно это нормально, но на медленных сетях (или на мобильном при медленном сервере) каждое действие подвисает.

Сколько стоит реализовать offline-first?

Offline-first требует дополнительного времени разработки на старте. Вашему конструктору нужно продумать:

Локальное хранилище: как сохранять данные на телефоне/в браузере так, чтобы они не пропадали при сбое приложения. Не сложно, но требует осознанного подхода.
Разрешение конфликтов: если пользователь меняет поле офлайн, а потом кто-то другой (или другое устройство) меняет то же поле до синхронизации — чья версия победит? Обычно та, что онлайн (она свежее), но пользователя нужно предупредить, а не удивлять. Реальный пример: два телефона редактируют одну и ту же заметку офлайн, оба выходят в сеть — побеждает тот, кто синхронизировался вторым, а первый пользователь видит: «Ваша версия устарела, вот актуальная».
Устаревшие данные: если пользователь был офлайн три дня, должно ли приложение при подключении молча обновить всё, или сначала спросить? Спросить безопаснее — со старыми данными могут быть связаны несохранённые изменения.

Всё это требует продумывания, но проще, чем кажется.

Награда: приложения, которым люди доверяют. Offline-first приложение не оправдывается («вам нужен интернет, чтобы этим пользоваться») и не теряет вашу работу. Это очень много значит.

Как проверить, работает ли ваше приложение офлайн?

Не нужно лететь на самолёте, чтобы это протестировать — авиарежим на вашем телефоне и есть ваш полигон для тестов. Вот как это сделать:

Откройте и заполните что-нибудь: сделайте что-то обычное (заполните форму, добавьте заметку).
Уйдите в офлайн: включите авиарежим или выключите WiFi.
Продолжайте работать: попробуйте сделать то же самое ещё раз. Если приложение отказывается — offline-first ещё не реализован. Если работает — хорошо. Если это сбивает с толку — попросите своего конструктора добавить чёткий индикатор «Вы офлайн».
Вернитесь онлайн: выключите авиарежим.
Проверьте синхронизацию: изменения синхронизировались автоматически? Если пришлось нажимать кнопку «синхронизировать» или обновлять страницу — значит, это ещё не совсем то.

Лучшие offline-приложения ощущаются настолько естественно, что вы даже не замечаете, что вы офлайн — вы просто замечаете, что приложение всё ещё работает.

Действительно ли вашему приложению нужно работать офлайн? Если ответ «у моих пользователей нестабильный интернет, или они работают там, где нет сигнала» — то да. Если это «они всегда на стабильном WiFi» — пока можно этот вопрос пропустить. Но в тот момент, когда кто-то скажет «я потерял свою работу», вы пожалеете, что не спросили об этом раньше.