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

Большую часть времени пользователь взаимодействует с мобильным приложением в стандартном режиме. То есть, приложение отображает дизайн и выполняет свои бизнес-функции.
Но всё это - "позитивный кейс", а значит, существуют ситуации, когда "что-то идёт не по плану". Нам, как тестировщикам, нужно предвидеть такие ситуации и подготовить приложение к ним. Одним из кейсов, когда пользователь не может получить полноценный доступ ко всем функциям приложения, является отсутствие соединения с интернетом. Если мы создаём приложение категории "тонкого клиента", то потеря соединения будет сравнима с его удалением с устройства.
✨Прежде всего проговорим, какой тип соединения доступен на современном смартфоне:
🟦Wi-Fi
🟦Мобильный интернет (тот, что мы получаем от мобильного оператора)
Несмотря на то что мы можем получать сравнимое качество соединения (а для обычного пользователя оно вообще кажется одинаковым), это всё же две независимые системы, работающие по-разному. Интересный факт — при смене соединения происходит, пусть и кратковременная, но потеря связи.
Для примера: у нас есть приложение по заказу пиццы, и мы находимся на экране оформления заказа. Наш пользователь едет в древнем вагоне метро, где не существует Wi-Fi и не пробивается ни одна сотовая вышка. В момент, когда пользователь поехал в вагоне метро, связь с миром пропадает полностью. Что стоит сделать мобильному приложению в таком случае? Здесь есть внешняя реакция и реакция "под капотом" т.е. то что пользователь не видит напрямую.
🔵Варианты внешней реакции:
🔵Вариант один
Выдать пользователю алерт о том, что нет соединения с интернетом, но сохранить доступ до функций приложения.
Дополнительно может быть введен частичный запрет на какие-либо действия в приложении что бы не вводить пользователя в заблуждение. Например сделать неактивной кнопку “оформить заказ”.
🔵Вариант два
Плейсхолдер на экране с уведомлением о том, что соединения нет и перекрытие всего экрана для взаимодействия.
Это достаточно яркий способ показать пользователю состояние приложения и при этом полностью ограничить его от функционала приложения.
Некоторые приложения добавляют кнопку "Обновить". После тапа на эту кнопку происходит запрос на проверку соединения с интернетом. И если соединение восстановилось, то экран приложения обновляется. Такая кнопка - это хороший шаг что бы дать пользователю чувство контроля над приложением.
Но плейсхолдер с ограничением на действия с приложением не всегда верный шаг — лучше отталкиваться от бизнес-функционала приложения и смотреть возможно ли оставить пользователю доступ к части функций или нет.
🟦Варианты внутренней реакции:
🟦Вариант первый
Если пользователь отправил, например, оформленный заказ, во время когда потерлось соединение с интернетом, то стоит продумать систему, при которой неотправленные сообщения хранятся в кэше и автоматически отправляются, когда приложение получает доступ к интернету. Важно проверить, чтобы сообщение автоматически отправилось при восстановлении соединения с интернетом и удаляется из кэша.
🟦Вариант два
Проверяем что нет циклической и неконтролируемой отправки файлов после восстановления соединения или во время его потери. В противном случае приложение может постоянно отправлять один и тот же файл, что приводит к "утечке памяти" и быстрому разряду аккумулятора.
🟦Вариант три
Проверка соединения с интернетом помимо действий пользователя.
Выше мы рассмотрели вариант когда пользователь может сам обновить состояние экрана тапнув на кнопку “Обновить”. Но проверить состояние соединения с интернетом может приложение самостоятельно через циклические запросы к системе. и в случае когда соединение восстановлено автоматически восстановить соединение.
Резюмируя, можно уверенно сказать, что в случае потери соединения с интернетом задача приложения - предоставить пользователю ясное понимание того, что происходит в смартфоне, и обработать запросы, которые могут возникнуть в приложении, чтобы оптимизировать работу.

Пример реакции популярных мобильных приложений