Что нужно учесть при написании сетевого запроса в Activity

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

Понимаете ли, что сетевой запрос живёт дольше экрана: пока он идёт, пользователь повернёт устройство, свернёт приложение или уйдёт назад. Вопрос в первую очередь про жизненный цикл, а не про выбор библиотеки.

Как отвечать

Перечислить, что учитываете:

• запрос не в главном потоке, иначе система бросит NetworkOnMainThreadException. Сегодня это приостанавливаемая функция на Dispatchers.IO внутри репозитория;
• владелец запроса не Activity, а ViewModel: viewModelScope переживает поворот экрана, и повторный запрос после пересоздания не уходит;
• подписка на результат привязана к состоянию: сбор потока внутри repeatOnLifecycle, чтобы не обновлять уничтоженный интерфейс;
• в манифесте разрешение android.permission.INTERNET, а обычный HTTP по умолчанию запрещён, для исключений нужен файл network security config;
• один общий экземпляр HTTP-клиента на приложение: у него пул соединений и кэш, клиент на каждый экран это лишние сокеты и потоки;
• состояние экрана описано явно: загрузка, данные, ошибка, пусто. Таймауты, повтор с нарастающей паузой, разбор кодов ответа и понятное сообщение вместо пустого экрана;
• секреты и токены не в коде, ответы кэшируются, повторный вход на экран не дёргает сеть заново.

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

Стартуют запрос в onCreate и держат в колбэке ссылку на Activity или на её вьюхи. После поворота экрана появляется новый экземпляр, запрос уходит второй раз, а ответ первого обновляет уже мёртвый интерфейс. Отсюда и утечки, и мигание данных.

Берут устаревший AsyncTask или создают собственную область корутин прямо в Activity. Такая область никем не отменяется: при уходе с экрана работа продолжается, результат идёт в никуда, а при обращении к уничтоженному фрагменту падает.

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