Андроид-приложение, 49-я неделя
Обновлено 4 марта 2024 года.
Основные файлы проекта к версии 2024.2
Предупреждаю: в коде возможны семантические ошибки!
- Файл «Главная активность»: «Мэйн акти́вити . кей ти» (MainActivity.kt).
- Файл «Пример»: «Экза́мпл . кей ти» (Example.kt).
- Файл «Репозиторий примеров»: «Экза́мплс ре́по . кей ти» (ExamplesRepo.kt).
О модели представления (то есть о вью-модели)
По информации, доступной в «Ру вики»:
- Модель представления для связи модели и представления: статья «Модель — представление — модель представления».
- Контроллер для связи модели и представления: статья «Модель — представление — контроллер».
У меня в андроид-приложении пока что нет модели представления — так что версия 2024.2 работает и без неё; примеры «вшиты в код», хранятся в виде списка.
Добавить модель представления мне придётся, поскольку такова рекомендуемая курсом практика разработки под Андроид.
К тому же я собирался хранить примеры в про́то-датасто́ре.
Подготовка к использованию датастора
Ниже я попытался перечислить требуемые шаги для апгрейда версии 2024.2 в сторону использования датастора.
Подключение библиотек к проекту
В файл «бильд . грейдль» добавляю строки:
dependencies { val lifecycle_version = "2.7.0" ... // ViewModel implementation("androidx.lifecycle-viewmodel-ktx:$lifecycle_version") // ViewModel utilities for Compose implementation("androidx.lifecycle-viewmodel-compose:$lifecycle_version") // Proto DataStore implementation("androidx.datastore:datastore:1.0.0") }
Как я готовлю контейнер приложения
Создаю класс контейнера приложения в пакете приложения. Контейнер приложения будет контейнером и для датастора.
package com.example.myapp import android.app.Application class AppContainer: Application() { override fun onCreate() { super.onCreate() } }
Слой данных
Сначала создам схему данных.
(Для новичков есть пошаговые инструкции, вот для котлина.)
(Для продвинутых пользователей есть справочное руководство.)
Потом создам репозиторий, в пакете данных.
Слой ПИ
Буду использовать репозиторий в модели представления.
Держатели состояний
Слой пользовательского интерфейса состоит из двух уровней, причём на каждом из них могут располагаться держатели состояния:
- Верхний уровень — модель представления (вью-модель, ViewModel). Модель представления сама по себе частный случай держателей состояний (стейт хо́лдерс, state holders).
- Нижний уровень — элементы пользовательского интерфейса (ю-ай э́лементс, UI elements). Держатели состояний на этом уровне можно использовать в сложных макетах.
Возможная метафора спуска: данные «спускаются» от модели представления к экрану.
Возможная метафора подъёма (обобщения? переноса вовне?): держатель состояния может быть «поднят» в более широкую область видимости. (Или просто на «более высокий» уровень?)
Макет (экран приложения)
Компо́усэблы будут использовать методы класса модели представления.
О чём следует помнить
- Вызвать суспенд-функцию можно только из корутины. (Суспенд-функция — «функция, которая может ждать».)
- Модель представления не следует лишний раз делать аргументом функции (?) (Одним из параметров компо́усэбла для всего экрана будет объект модели представления.)
- Держатель состояния имеет более длительный цикл жизни, чем активность (?)
- Оператор «. стейт ин» (.stateIn) (именно оператор! не метод! не дополнительная функция!) преобразует «холодный» поток в «горячий».