Покупатель выбрал товары в Mini App, нажал кнопку заказа и вышел из зоны устойчивой связи. На экране крутится индикатор. Он закрывает приложение, возвращается через минуту и снова нажимает кнопку. В этот момент бизнесу нужен понятный ответ, существует ли уже заказ и какой результат видит клиент.
Потеря сети в Mini App затрагивает несколько разных ситуаций. Запрос мог ещё остаться на телефоне или попасть на сервер. Возможен и третий случай: сервер обработал запрос, но ответ потерялся по пути. Одинаковая надпись «ошибка» скрывает эти различия. Для проверки нужен набор сценариев с заранее согласованным поведением приложения и учётной системы.
Ниже шесть таких сценариев для учебного сервиса заказа обедов. Пользователь выбирает блюда, указывает офис и ждёт подтверждения кухни. Примеры помогут составить задание разработчику и принять результат вместе с сотрудником, который обрабатывает реальные заказы.
1. Связь исчезла ещё до открытия каталога
Начните проверку с холодного запуска, когда приложение ещё не получало данные в этой сессии. Включите режим без сети и откройте Mini App предусмотренным способом. Зафиксируйте, что появляется на экране и доступно ли объяснение происходящего. Пустая белая область не сообщает клиенту, стоит ли ждать или вернуться позже.
Согласуйте текст для этого состояния. Он должен описывать наблюдаемую проблему и доступное действие, например повторную загрузку. При этом формулировка «проверьте интернет» подходит только там, где команда действительно отличает проблему соединения от других ошибок. Если причина неизвестна, точнее сказать, что каталог сейчас не удалось загрузить.
После восстановления связи попробуйте предложенное действие. Каталог должен загрузиться без лишнего повторения уже выполненных шагов, если это предусмотрено проектом. Посмотрите, меняется ли состояние кнопки, исчезает ли сообщение и появляется ли понятный результат. Кнопка, которая визуально нажимается и ничего не объясняет, оставляет человека в том же тупике.
Если приложение показывает сохранённый каталог, уточните его возраст и правила использования. Вчерашнее меню сервиса обедов может быть полезно для просмотра, но оформление требует актуальной проверки наличия. Человек должен понимать, что видит сохранённые сведения, и получить актуальный результат перед подтверждением заказа.
В официальной документации Telegram Mini Apps описаны возможности взаимодействия приложения с клиентом Telegram. Обработку сетевых ошибок вашего каталога и заказов команда проектирует отдельно. При приёмке проверяйте именно реализованный сценарий сервиса, включая ответы его сервера и учётной системы.
2. Каталог открыт, но выбор ещё не отправлен
Загрузите меню при рабочем соединении, добавьте несколько блюд и затем отключите сеть. Продолжайте действия, которые доступны в интерфейсе. Измените количество, удалите позицию, вернитесь в каталог. Запишите, какие операции остаются доступными и как приложение объясняет ограничения.
Для клиента полезно сохранить уже собранный выбор, если это допускает устройство продукта. Но место хранения и срок сохранения нужно согласовать. Данные в текущем экране, локальный черновик на устройстве и корзина на сервере имеют разные свойства. Заказчику достаточно получить понятный ответ, когда выбор переживёт закрытие приложения и где он будет виден.
Проверьте возврат после закрытия. Пользователь мог свернуть Telegram, перейти в другой чат или перезапустить Mini App. Сценарии отличаются, поэтому повторите каждый из тех, которые входят в ожидаемое поведение. Если черновик исчезает, сообщение об этом и возможность восстановить выбор должны соответствовать договорённостям.
В учебном сервисе клиент собрал обед на пять человек. После возврата удобно показать сохранённую корзину и попросить обновить наличие перед отправкой. Если цена блюда изменилась, приложение должно дать человеку пересмотреть решение. Молчаливая подмена итоговой суммы испортит доверие даже при технически успешном заказе.
Похожая задача разобрана в материале о повторном заказе в Mini App. Сохранённый состав помогает вернуться к покупке, но доступность позиций и текущие условия всё равно требуют проверки. Включите её в сценарий восстановления после потери связи, чтобы команда проверяла весь путь.
3. Кнопка нажата, ответ ещё неизвестен
Самый спорный момент наступает после отправки. Интерфейс может потерять связь уже тогда, когда сервер создал запись. Поэтому отсутствие ответа на телефоне не позволяет уверенно сообщить, что заказа нет. В требованиях нужно отдельно описать состояние, когда приложение ещё выясняет результат конкретной попытки.
Попросите разработчика подготовить тест с задержкой или потерей ответа после обработки запроса. Обычное выключение Wi-Fi вручную не всегда попадает в нужный момент. Для повторяемой проверки команда может использовать тестовое окружение и управляемую имитацию сбоя. Заказчик оценивает результат по экрану и записи у оператора.
У каждой попытки должен быть способ связать запрос с её итогом. Конкретную техническую реализацию выберет команда. Владелец бизнеса формулирует требование простыми словами: повторная проверка и повторное нажатие по той же попытке не должны случайно создавать ещё один заказ. Дубли в списке кухни легко проверить независимо от внутреннего устройства программы.
Состояние ожидания должно иметь понятный выход. Бесконечный индикатор заставляет человека закрыть приложение или нажать ещё раз. Согласуйте, когда интерфейс предлагает проверить статус, что происходит при повторной неудаче и каким способом связаться с поддержкой. Обещание автоматического восстановления проверяйте тем же сценарием до приёмки.
Для разработки Mini App полезно передать список таких переходных состояний ещё на оценке. Тогда в объём работы войдут экран ожидания и проверка результата, а вместе с ними необходимые изменения на сервере. Одна дополнительная надпись в макете эту задачу не закрывает.
