Координатор мобильной синхронизации
Восстанавливает мобильную сессию после background или потери сети через новый snapshot.
Состояния синхронизации
Иллюстрация по теме
Визуальный ориентир помогает быстрее считать сценарий страницы и не оставлять компонент абстрактным.
Контракт синхронизации
| Inputs | last known cursor, local recoverable context |
|---|---|
| Outputs | fresh state, cancelled stale requests |
| Failure mode | duplicate non-idempotent command, replay gap |
| Ownership | UI владеет представлением и recoverable context; финальное бизнес-состояние подтверждает серверный контракт. |
Где держать координатор
Компонент считается самостоятельной границей только если команда может назвать его входы, выходы и невозможные состояния. Если он требует читать provider-specific поля напрямую или хранит финальный статус операции только локально, граница выбрана слишком поздно.
При изменении контракта сначала обновляется state model и совместимость, затем визуальный слой. Это уменьшает риск ситуации, когда новый UI уже ожидает поле или статус, которого старая версия API не гарантирует.
Связанные разборы
Проверки восстановление соединения
- Reconnect всегда начинает синхронизацию с проверяемой server version.
- Устаревшие in-flight requests отменяются или их ответы игнорируются по request/version fence.
- Неидемпотентные команды не replay автоматически.
- Смена сети не создаёт параллельные активные stream sessions.
- Background дольше допустимого окна переводит клиент в full resync.
- Пользователь видит состояние восстановления, если оно влияет на доступность действия.
Почему синхронизация нужна одна на приложение
Восстановление после background — новый sync cycle. Продолжать старую socket-сессию «как будто ничего не произошло» нельзя считать надёжной моделью.
При review команда проверяет не название компонента, а его инварианты: какие данные он имеет право считать финальными, что обязан показать при деградации и как возвращается в согласованное состояние после сбоя.
Возврат после паузы как новая синхронизация
После background или смены сети coordinator создаёт новую connectivity epoch, отменяет устаревшие запросы и получает свежий snapshot. Он не обещает экранам, что старый socket «продолжился» с того же места. Благодаря этому поздний ответ из прошлой сети не может откатить уже восстановленное состояние.
Команды с необратимым результатом не повторяются автоматически. Coordinator может инициировать reconciliation, но решение о новом действии остаётся за пользовательским сценарием и server state.
Возврат после паузы — это не продолжение старой сессии
Команда часто воспринимает resume как «просто ещё один экранный event», хотя для пользователя это почти новый вход в продукт. Компонент синхронизации должен заново проверить актуальность snapshot, восстановить только безопасный локальный контекст и не показывать stale-статус как живой. Более подробно этот сценарий разобран в материале о reconnect в мобильном приложении.