Описание проблемы

Задача

Я — андроид разработчик. Обычно ко мне приходят с фразой вроде “вот мы тут придумали фичу, сделаешь?” и с макетом дизайна, вроде такого.

Я смотрю на это всё и вижу: вот экраны, эти данные на них — статические, а вот эти динамические, значит их надо откуда-то взять; вот тут интерактивные компоненты: при взаимодействии с ними надо что-то сделать. Иногда просто открыть другой экран или виджет, иногда выполнить логику. Исходя из этого я проектирую то, как будет выглядеть логика фичи. Описываю ее в компонентах архитектуры, разбиваю на задачи, узнаю где и как взаимодействовать с сервером, и прочее.

Скрытые кейсы

Но потом я обнаруживаю, что далеко не все переходы такие простые, как нарисовано на дизайне, например, как в случае с авторизацией. Не все явно присутствуют, как, например, переходы назад. А в некоторых случаях не хватает всевозможных экранов ожидания, экранов “пустых” состояний и экранов ошибок.

Знакомо?

Наблюдение

В общем я долго думал и пришел к выводу, что я все это время смотрел на новые фичи и приложения не с той стороны.

Что я имею ввиду?

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

Другой подход

Пример

В качестве примера используем одну из типичных задач из учебников по программированию — это задача с CRUD, то есть с созданием, чтением, изменением и удалением. И на самом деле даже обрежем ее до создания, удаления и отображения.

Вообще изначально я думал сделать шахматы, но в какой-то момент понял, что это слишком сложный пример, и мы засядем с ним очень надолго.

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

И вот макет такого приложения.

Первые фичи

Вопрос, с чего начать? В целом, начать можно было бы с чего угодно, но я подумал, что логичнее начать с core-фичи: отображение списка элементов.

Но зачем мне — приложению — его показывать?

И это очень правильный вопрос. Потому что приложению не надо взаимодействовать с пользователем, пока оно может принимать решения самостоятельно. Например, решение о том, как найти элемент в списке и удалить его. Но приложение не может принять решение о том, какой элемент надо удалить, по крайней мере в этом случае. Так что мы делегируем это решение пользователю.

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

Теперь у нас (все еще как у приложения) два вопроса, и описаны они в виде входных параметров: откуда взять список и откуда взять элемент для удаления?

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

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

Масштабируемость: добавляем создание элемента

И так, как приложение мы можем добавить элемент в список, но не знаем как именно этот элемент выглядит, что он содержит? Давайте пойдем от понятного.

Функция добавления нового элемента имеет сигнатуру похожую на функцию удаления элемента. Разве что имена разные. Ну и выполняемые действия =)

Далее мы сталкиваемся все с тем же вопросом: “откуда брать элемент для добавления?” А так как мы не можем сами его решить, то снова делегируем это пользователю и красиво запаковываем в “create and add”.

Но есть ощущение, как будто мы все это уже делали. А где же обещанная масштабируемость? Она заключается в том, что теперь мы можем запустить эти две программы параллельно, таким образом объединив их в одну и в то же время не внося изменения ни в одну их них.

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

Теперь у нас есть кросс-платформенное описание логики приложения, не привязанное к конкретному UI. На бумаге…

Реализация

Логика

Теперь надо превратить это описание в код. Как?

Каждый блок превращается в функцию. В моем случае в suspend-функцию в kotlin, но это не так важно. И я обязательно покажу почему в другой раз.

Проходя сверху-вниз по нашей таблице, последовательно реализуем “example app”, “create or remove”, “select and remove” и остальные функции.

suspend fun <Item> exampleApp(items: List<Item>): Nothing {
    updateLoop(items) {
        createOrRemove(it)
    }
}

suspend fun <Item> createOrRemove(items: List<Item>): List<Item> {
    return parallel(
        { selectAndRemoveItem(items) },
        { createAndAdd(items) }
    )
}

suspend fun <Item> selectAndRemoveItem(items: List<Item>): List<Item> {
    val item = selectItem(items)

    return removeItem(items, item)
}

suspend fun <Item> removeItem(items: List<Item>, item: Item): List<Item> {
    return items - item
}

suspend fun <Item> createAndAdd(items: List<Item>): List<Item> {
    val item: Item = createItem()

    return addItem(items, item)
}

suspend fun <Item> addItem(items: List<Item>, item: Item): List<Item> {
    return items + item
}

Но тут мы упираемся вот в эту часть, где нам надо взаимодействовать с пользователем.

suspend fun <Item> selectItem(items: List<Item>): Item {
    TODO("Interact with user")
}

suspend fun <Item> createItem(): Item {
    TODO("Interact with user")
}

Это внешняя зависимость по отношению к нашей логике. “Внешняя” значит, что мы должны как-то получить ее откуда-то снаружи. И как бы это сделать?

Зависимости

Я предлагаю описать зависимости этих функции в виде интерфейсов. И пусть его реализацией займётся внешняя система, которая хочет запускать наше приложение.

suspend fun <Item> SelectItemDependencies<Item>.selectItem(items: List<Item>): Item {
    return select(items)
}

interface SelectItemDependencies<Item> {
    suspend fun select(items: List<Item>): Item
}

suspend fun <Item> CreateItemDependencies<Item>.createItem(): Item {
    return create()
}

interface CreateItemDependencies<Item> {
    suspend fun create(): Item
}

Правда теперь “внешней системой” становятся вызывающие функции.

С точки зрения вызывающей функции мы теперь должны реализовать этот интерфейс или запросить его извне. Но в таком случае мы сильно привяжем себя именно к этой функции и к этому интерфейсу, а мне — как вызывающей функции — это не нужно. Мне достаточно сигнатур этих функций, не реализаций. То есть в целом можно провернуть тот же трюк, что и для selectItem и createItem: вынести зависимости в интерфейс. А затем это можно сделать рекурсивно вплоть до exampleApp.

suspend fun <Item> ExampleAppDependencies<Item>.exampleApp(items: List<Item>): Nothing {
    updateLoop(items) {
        createOrRemove(it)
    }
}

interface ExampleAppDependencies<Item> {
    suspend fun createOrRemove(items: List<Item>): List<Item>
}

suspend fun <Item> CreateOrRemoveDependencies<Item>.createOrRemove(items: List<Item>): List<Item> {
    return parallel(
        { selectAndRemoveItem(items) },
        { createAndAdd(items) }
    )
}

interface CreateOrRemoveDependencies<Item> {
    suspend fun selectAndRemoveItem(items: List<Item>): List<Item>
    suspend fun createAndAdd(items: List<Item>): List<Item>
}

suspend fun <Item> SelectAndRemoveItemDependencies<Item>.selectAndRemoveItem(items: List<Item>): List<Item> {
    val item = selectItem(items)

    return removeItem(items, item)
}

interface SelectAndRemoveItemDependencies<Item> {
    suspend fun selectItem(items: List<Item>): Item
    suspend fun removeItem(items: List<Item>, item: Item): List<Item>
}

suspend fun <Item> removeItem(items: List<Item>, item: Item): List<Item> {
    return items - item
}

suspend fun <Item> CreateAndAddDependencies<Item>.createAndAdd(items: List<Item>): List<Item> {
    val item = createItem()

    return addItem(items, item)
}

interface CreateAndAddDependencies<Item> {
    suspend fun createItem(): Item
    suspend fun addItem(items: List<Item>, item: Item): List<Item>
}

suspend fun <Item> addItem(items: List<Item>, item: Item): List<Item> {
    return items + item
}

suspend fun <Item> SelectItemDependencies<Item>.selectItem(items: List<Item>): Item {
    return select(items)
}

interface SelectItemDependencies<Item> {
    suspend fun select(items: List<Item>): Item
}

suspend fun <Item> CreateItemDependencies<Item>.createItem(): Item {
    return create()
}

interface CreateItemDependencies<Item> {
    suspend fun create(): Item
}

Теперь, когда наши функции настолько отделены друг от друга, нам надо собрать их обратно в полноценную программу.

Это не сложно. Все что нам требуется — это сделать реализацию всех интерфейсов и правильно их скомпоновать.

val selectAndRemoveContext = object : SelectAndRemoveItemDependencies<String> {
    override suspend fun selectItem(items: List<String>): String {
        // ui-interaction here
    }

    override suspend fun removeItem(items: List<String>, item: String): List<String> =
        com.genovich.cpa.removeItem(items, item)
}

val createAndAddContext = object : CreateAndAddDependencies<String> {
    override suspend fun createItem(): String {
        // ui-interaction here
    }

    override suspend fun addItem(items: List<String>, item: String): List<String> =
        com.genovich.cpa.addItem(items, item)
}

val createOrRemoveContext = object : CreateOrRemoveDependencies<String> {
    override suspend fun selectAndRemoveItem(items: List<String>): List<String> =
        selectAndRemoveContext.selectAndRemoveItem(items)

    override suspend fun createAndAdd(items: List<String>): List<String> =
        createAndAddContext.createAndAdd(items)
}

val exampleAppContext = object : ExampleAppDependencies<String> {
    override suspend fun createOrRemove(items: List<String>): List<String> =
        createOrRemoveContext.createOrRemove(items)
}

Здесь я просто последовательно реализую все интерфейсы и подставляю вызовы функций там, где это нужно. Мы, конечно, могли бы обсудить громоздкость решения, и почему я не выносил зависимости для добавления и удаления элемента, но лучше сделать это в комментариях или на патреоне, бусти и телеграмме.

Консольный UI

В итоге мы должны запустить exampleApp используя собранный граф зависимостей как контекст для его выполнения. Также я добавил очередь сообщений и ответов, чтобы пользователь мог взаимодействовать с приложением.

fun main() {
    val outputFlow = MutableSharedFlow<String>(1)
    val inputFlow = MutableSharedFlow<OneOf<String, Int>>(
        extraBufferCapacity = 1,
        onBufferOverflow = BufferOverflow.DROP_OLDEST
    )

    val selectAndRemoveContext = object : SelectAndRemoveItemDependencies<String> {
        override suspend fun selectItem(items: List<String>): String {
            outputFlow.emit(
                items.withIndex().joinToString("\n") { (index, item) -> "$index. $item" })
            return inputFlow.filterIsInstance<OneOf.Second<Int>>()
                .mapNotNull { items.getOrNull(it.second) }
                .first()
        }

        override suspend fun removeItem(items: List<String>, item: String): List<String> =
            com.genovich.cpa.removeItem(items, item)
    }

    val createAndAddContext = object : CreateAndAddDependencies<String> {
        override suspend fun createItem(): String {
            return inputFlow.filterIsInstance<OneOf.First<String>>()
                .map { it.first }
                .first()
        }

        override suspend fun addItem(items: List<String>, item: String): List<String> =
            com.genovich.cpa.addItem(items, item)
    }

    val createOrRemoveContext = object : CreateOrRemoveDependencies<String> {
        override suspend fun selectAndRemoveItem(items: List<String>): List<String> =
            selectAndRemoveContext.selectAndRemoveItem(items)

        override suspend fun createAndAdd(items: List<String>): List<String> =
            createAndAddContext.createAndAdd(items)
    }

    val exampleAppContext = object : ExampleAppDependencies<String> {
        override suspend fun createOrRemove(items: List<String>): List<String> =
            createOrRemoveContext.createOrRemove(items)
    }

    runBlocking {
        launch(Dispatchers.Default) { exampleAppContext.exampleApp(emptyList()) }
        outputFlow.collectLatest { text ->
            println("Items:")
            println(text)
            print("Enter item number to delete or item name to add: ")

            val input = readln()

            inputFlow.emit(
                input.toIntOrNull()?.let { OneOf.Second(it) } ?: OneOf.First(input)
            )
        }
    }
}

Вот так, смотря на логику с точки зрения приложения, мы можем делать связанный, масштабируемый и тестируемый код для наших приложений.

Мобильный UI

Ой, хотя я же обещал мобильное приложение. Тогда давайте так: заменим ту часть, что взаимодействует с пользователем на более подходящую. Я называю ее Т-функция. Ее базовую идею я описал в конце своей статьи про решение проблем MVX архитектур.

Что про нее нужно знать сейчас: она отправляет “запрос” связанный с callback’ом в канал и ждёт, пока принимающая сторона вызовет этот callback. Также как мы обычно взаимодействуем с backend’ом. А ещё Андроид-разработчики могут знать такой подход по Handler.replyTo.

object Logic

@Composable
fun App(
    selectItemsFlow: MutableStateFlow<UiState<List<String>, String>?> = MutableStateFlow(null),
    createItemsFlow: MutableStateFlow<UiState<Unit, String>?> = MutableStateFlow(null),
) {
    MaterialTheme {
        // ПРЕДУПРЕЖДЕНИЕ: не повторяйте это дома!!!
        // Логика не должна быть частью @Compose-функции!
        // В идеале она должна запускаться за пределами App() и передавать selectItemsFlow и createItemsFlow как параметры
        // Логика должна иметь возможность "жить" дольше, чем UI
        // Да и передавать огромную пачку платформенных зависимостей в App() будет запарно, если будете использовать такой подход
        LaunchedEffect(Logic) {
            val selectAndRemoveContext = object : SelectAndRemoveItemDependencies<String> {
                override suspend fun selectItem(items: List<String>): String {
                    return selectItemsFlow.showAndGetResult(items)
                }

                override suspend fun removeItem(items: List<String>, item: String): List<String> =
                    com.genovich.cpa.removeItem(items, item)
            }
            val createAndAddContext = object : CreateAndAddDependencies<String> {
                override suspend fun createItem(): String {
                    return createItemsFlow.showAndGetResult(Unit)
                }

                override suspend fun addItem(items: List<String>, item: String): List<String> =
                    com.genovich.cpa.addItem(items, item)
            }

            val createOrRemoveContext = object : CreateOrRemoveDependencies<String> {
                override suspend fun selectAndRemoveItem(items: List<String>): List<String> =
                    selectAndRemoveContext.selectAndRemoveItem(items)

                override suspend fun createAndAdd(items: List<String>): List<String> =
                    createAndAddContext.createAndAdd(items)
            }

            val exampleAppContext = object : ExampleAppDependencies<String> {
                override suspend fun createOrRemove(items: List<String>): List<String> =
                    createOrRemoveContext.createOrRemove(items)
            }

            exampleAppContext.exampleApp(emptyList())
        }

        Column {
            val selectItems by selectItemsFlow.collectAsState()
            selectItems?.also { (items, select) ->
                LazyColumn(
                    modifier = Modifier.weight(1f),
                    reverseLayout = true,
                ) {
                    items(items.asReversed()) { item ->
                        Text(
                            modifier = Modifier
                                .fillMaxWidth()
                                .clickable { select(item) }
                                .padding(16.dp),
                            text = item,
                        )
                    }
                }
            }

            val createItem by createItemsFlow.collectAsState()
            createItem?.also { (_, create) ->
                Row(Modifier.fillMaxWidth()) {
                    var value by remember(create) { mutableStateOf("") }
                    TextField(
                        modifier = Modifier.weight(1f),
                        value = value,
                        onValueChange = { value = it },
                    )
                    Button(
                        onClick = { create(value) },
                    ) {
                        Text(text = "Create")
                    }
                }
            }
        }
    }

Тут отдельно стоит поговорить про масштабирование и композицию потоков событий для UI. Но я и так уже много сказал.

Вывод

Главное, на что я хотел бы обратить ваше внимание — это то, насколько логика становится целостной, если проектировать ее с точки зрения приложения, а не пользовательского интерфейса. А ещё насколько она гибкая, тестируемая и масштабируемая, если каждая функция отделена от своих зависимостей на уровне действий (функций), а не объектов.

Я думаю мы ещё сможем поговорить про эти аспекты отдельно. А пока что спасибо за внимание. Увидимся!

P.S. вот ссылка на проект, сделанный в статье, а также гитхаб проекта с использованными функциями