Возврат в мобильное приложение после потери сети без повторных действий

Подключение — это не один флаг

Телефон может иметь Wi‑Fi без доступа к интернету, приложение может вернуться из background с давно мёртвым socket, DNS может восстановиться позже API. Поэтому coordinator опирается на реальные успехи запросов и состояние lifecycle, а reachability использует только как подсказку.

Восстановление соединения начинается со снимок

После заметного разрыва приложение не пытается продолжить stream «с места на глаз». Оно отменяет устаревшие reads, получает свежий snapshot активного экрана, затем открывает поток от новой версии. Это проще доказать корректным.

Не всё нужно автоматически повторять

GET и безопасные reads можно retry с backoff. Команды изменения состояния повторяются только при наличии idempotency key и определённого серверного контракта. Иначе приложение должно показать «проверяем результат», а не отправлять действие снова вслепую.

Единый координатор вместо повтора в каждом экране

Экран не должен самостоятельно слушать network callback и запускать пять запросов. Sync coordinator выдаёт событие fresh-session-needed, а feature-модули регистрируют свой refresh. Так легче поставить jitter и избежать одновременного шторма после возврата сети.

Старый ответ после нового снимок

Все запросы получают generation id текущего sync cycle. Ответ предыдущего поколения игнорируется. Это защищает от ситуации, когда медленный запрос из offline-перехода перезаписывает уже свежие данные.

Сценарии, которые нужно прогнать на устройстве

Reconnect стоит тестировать не только выключением Wi-Fi. Реальные сбои выглядят сложнее: приложение уходит в background, сеть меняется с Wi-Fi на LTE, DNS отвечает с задержкой, socket формально открыт, но поток уже не жив, а старый HTTP-ответ приходит после нового snapshot.

Единый coordinator помогает собрать эти случаи в одну последовательность: остановить старые подписки, получить актуальный snapshot, сбросить устаревшие запросы и только затем восстановить live-канал. Пользователь видит краткое обновление состояния, а не каскад независимых retry от каждого экрана.

• Тестировать смену сети без полного offline-состояния.
• Отменять или игнорировать ответы запросов, созданных до нового snapshot.
• Не повторять автоматически команды с финансовым или необратимым эффектом.

Восстановление соединения лучше проверять как новый вход в продукт

Начните матч, откройте live-screen, затем выключите сеть на несколько секунд и отправьте приложение в background. Пока клиент отсутствует, измените счёт и состояние рынка. После возврата правильный сценарий не пытается «доиграть» все старые сообщения; он получает свежий snapshot, отменяет устаревшие запросы и только после этого снова включает интерактивность.

MobileSyncCoordinator помогает сделать эту логику одной системной границей. Экраны сообщают, какой context им нужен, а coordinator управляет connectivity epoch и новой синхронизацией. Так исчезают десятки локальных retry-loop, которые начинают соревноваться друг с другом после восстановления сети.

Отдельно тестируются команды с неизвестным исходом. Если placement ушёл до disconnect, приложение не отправляет его ещё раз автоматически. Сначала оно спрашивает сервер о результате по idempotency key или перечитывает состояние аккаунта.

Разделяем проблемы сети и деградацию программного интерфейса

В telemetry записывается coarse network state, причина refresh и outcome, но не SSID или лишние сведения о сети. Так видно, что проблема массовая на API, а не просто обычные мобильные переключения.