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

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

Умеете ли вы строить приложение по принципу offline-first, где сеть это редкое событие, а не данность. Следом почти всегда спрашивают, как вы разрешите конфликт, если команду телескопу отправили из двух мест, пока связи не было.

Как отвечать

Начните с уточнений: связь пропадает на минуты или на сутки, есть ли на месте локальная сеть до контроллера обсерватории, какие команды опасны (открыть купол, навести телескоп). От этого зависит архитектура.

• источник правды локально: UI читает только из Room, сеть лишь обновляет базу. Экран подписан на Flow из DAO через ViewModel и StateFlow, поэтому данные видны и без связи;
• очередь исходящих команд: каждое действие пишется в таблицу outbox со статусом и идемпотентным ключом, чтобы повторная отправка не навела телескоп дважды;
• синхронизация: WorkManager с ограничением NetworkType.CONNECTED и экспоненциальным BackoffPolicy, работа переживает перезапуск процесса и устройства;
• экономный протокол: дельты вместо полных выгрузок, сжатие, телеметрия важнее снимков, крупные файлы докачиваются частями;
• статус соединения: ConnectivityManager.NetworkCallback плюс метка последней синхронизации на экране, чтобы оператор видел, насколько свежи данные;
• время: метки событий в UTC, иначе порядок команд после восстановления связи не восстановить.

Отдельно проговорите команды реального времени. Наведение или аварийное закрытие купола не должны сутки висеть в очереди: у команды есть срок годности, устаревшая отклоняется явно. Критичную защиту держите на контроллере, а не в телефоне.

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

Предлагают LiveData и «кэш на всякий случай», но не объясняют, откуда UI берёт данные без сети. Кэш поверх сетевого слоя ещё не офлайн-режим.

Забывают про идемпотентность. При плохой связи теряется чаще ответ, чем запрос, и без ключа повтор выполнит команду второй раз.

Молчат о конфликтах. Две правки расписания наблюдений, сделанные офлайн, сливаются по понятному правилу: по версии записи, по времени или через выбор оператора.