Опишите данные отдельно от элементов экрана
Представим учебный список книг. У записи есть название и признак прочтения. Java позволяет описать такие данные классом, а несколько записей хранить в подходящей коллекции. Кнопка и текстовое поле относятся к представлению: они дают человеку возможность увидеть данные и изменить их. Если единственный экземпляр важного значения находится в надписи кнопки, дальнейшая логика становится хрупкой. Сначала определите модель, затем правила изменения и способ отображения. Полезно проговорить сценарий без названий экранных компонентов: пользователь отметил книгу прочитанной, запись изменилась, список показал новое состояние.
У экрана бывает несколько нормальных состояний
Список может ещё загружаться, содержать записи, оказаться пустым или показывать ошибку. Пустой результат и неудачный запрос требуют разных сообщений. Если оба выглядят одинаково, человек не понимает, нужно ли добавить первую книгу или повторить попытку. Для каждого состояния продумайте доступные действия и понятную обратную связь. Во время ожидания не следует изображать успешное завершение. Повторное нажатие также требует определённого поведения: игнорирование, отмена или новый запрос выбираются осознанно. Это часть проектирования интерфейса, которую полезно сделать до украшения экрана.
Пересоздание экрана не равно сохранению данных
Android может пересоздать Activity, например при изменении конфигурации. Значение в обычном поле её экземпляра не является надёжным хранилищем состояния. ViewModel помогает удерживать данные экрана при таких изменениях в пределах своей области жизни, но не переживает уничтожение процесса сама по себе. Для восстановления небольшого необходимого состояния существуют механизмы сохранённого состояния, включая SavedStateHandle. Данные, которые должны оставаться надолго, требуют постоянного хранилища. Полезно различать три задачи: пережить поворот, восстановиться после системного завершения процесса и сохранить список между независимыми запусками. Одно название библиотеки не решает их автоматически.
Длительная работа не должна задерживать интерфейс
Сетевые операции нельзя выполнять в основном потоке интерфейса. Пока он занят длительной работой, приложение перестаёт нормально отвечать на действия пользователя. Подходящий механизм выполнения зависит от используемых библиотек и архитектуры; для Java также доступны асинхронные способы работы. Однако перенос запроса в фон не отменяет ошибок, отмены и устаревших результатов. Если человек уже сменил запрос, пришедший позже старый ответ не должен бездумно подменять новый. Для первого проекта полезнее проверить несколько таких сценариев, чем подключить много библиотек без понимания их роли. Актуальные возможности уточняют по документации выбранных компонентов.
Попробуйте на практике
Спроектируйте на бумаге экран списка книг для будущего приложения на Java, не устанавливая программы и не отправляя запросы.
- Опишите поля одной записи и действия, которые могут менять её состояние.
- Нарисуйте четыре варианта экрана: загрузка, список, пустой результат и ошибка.
- Для каждого варианта определите доступное действие и сообщение пользователю.
- Отдельно отметьте, какие данные нужны после поворота, после системного уничтожения процесса и после нового запуска.
- Разыграйте два запроса, завершившихся в обратном порядке, и объясните, какой ответ должен остаться на экране.
Как проверить результат. Модель данных отделена от внешнего вида. Вы не называете ViewModel постоянным хранилищем и различаете пустой результат, ошибку и ожидание.
Частые вопросы
Достаточно ли знать синтаксис Java для готового приложения?
Нет. Нужны также понимание компонентов Android, состояния, жизненного цикла и взаимодействия с пользователем. Синтаксис помогает выразить решения, но не выбирает их.
Если данные пережили поворот, они сохранятся навсегда?
Нет. Проверка изменения конфигурации не равна проверке уничтожения процесса или постоянного хранения. Эти сценарии нужно рассматривать отдельно.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.