Андроид-приложение, 49-я неделя

Обновлено 4 марта 2024 года.

Основные файлы проекта к версии 2024.2

Предупреждаю: в коде возможны семантические ошибки!

О модели представления (то есть о вью-модели)

По информации, доступной в «Ру вики»:

У меня в андроид-приложении пока что нет модели представления — так что версия 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()
    }
}

Слой данных

Сначала создам схему данных.

(Для новичков есть пошаговые инструкции, вот для котлина.)

(Для продвинутых пользователей есть справочное руководство.)

Потом создам репозиторий, в пакете данных.

Слой ПИ

Буду использовать репозиторий в модели представления.

Держатели состояний

Слой пользовательского интерфейса состоит из двух уровней, причём на каждом из них могут располагаться держатели состояния:

  1. Верхний уровень — модель представления (вью-модель, ViewModel). Модель представления сама по себе частный случай держателей состояний (стейт хо́лдерс, state holders).
  2. Нижний уровень — элементы пользовательского интерфейса (ю-ай э́лементс, UI elements). Держатели состояний на этом уровне можно использовать в сложных макетах.

Возможная метафора спуска: данные «спускаются» от модели представления к экрану.

Возможная метафора подъёма (обобщения? переноса вовне?): держатель состояния может быть «поднят» в более широкую область видимости. (Или просто на «более высокий» уровень?)

Макет (экран приложения)

Компо́усэблы будут использовать методы класса модели представления.

О чём следует помнить

  • Вызвать суспенд-функцию можно только из корутины. (Суспенд-функция — «функция, которая может ждать».)
  • Модель представления не следует лишний раз делать аргументом функции (?) (Одним из параметров компо́усэбла для всего экрана будет объект модели представления.)
  • Держатель состояния имеет более длительный цикл жизни, чем активность (?)
  • Оператор «. стейт ин» (.stateIn) (именно оператор! не метод! не дополнительная функция!) преобразует «холодный» поток в «горячий».