Как приложение обсерватории должно себя вести при прерывистой и ограниченной связи

Что проверяют

Умеете ли вы проектировать offline-first, а не просто «показывать тост, когда нет сети». Обсерватория здесь задаёт контекст: удалённая площадка, слабый канал, крупные файлы снимков и мелкая телеметрия. Следом спросят, как не потерять и не задвоить данные при обрывах.

Как отвечать

Каркас архитектуры:

• локальная база как источник правды: UI подписан на Flow из Room, сеть только синхронизирует базу. Нет связи, экран всё равно показывает последние данные с отметкой времени обновления;
• очередь исходящих (outbox): каждое действие пользователя сначала пишется в таблицу, потом отправляется. Каждой записи клиент выдаёт UUID, и сервер по нему игнорирует повтор, так отправка становится идемпотентной;
• WorkManager для синхронизации: Constraints с setRequiredNetworkType(NetworkType.CONNECTED), экспоненциальный setBackoffCriteria, enqueueUniqueWork, чтобы не плодить параллельные задачи. Работа переживает смерть процесса и перезагрузку;
• приоритеты трафика: сначала метаданные и телеметрия, тяжёлые снимки только на безлимитной сети (NetworkType.UNMETERED) и частями, с докачкой с места обрыва;
• состояние сети: ConnectivityManager.registerDefaultNetworkCallback и проверка NET_CAPABILITY_VALIDATED вместо устаревшего NetworkInfo. Лимитная ли сеть, скажет isActiveNetworkMetered().

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

Для пользователя: явный индикатор «офлайн, изменения отправятся позже», счётчик неотправленного и понятный статус у каждой записи.

Где спотыкаются

Проверяют «есть ли сеть» перед каждым запросом вместо обработки ошибки. Сеть может быть подключена без выхода в интернет, а может пропасть через секунду после проверки.

Отправляют данные из корутины во ViewModel. Пользователь свернул приложение, система убила процесс, данные потеряны. Длительная отправка должна жить в WorkManager.

Повторяют запросы без backoff и без идемпотентности. На плохом канале это разряжает батарею, забивает очередь и создаёт дубли на сервере.