Декларативный Bottom Sheet

На мой взгляд, самый неудачный компонент в Compose из Material 2 — это Bottom Sheet. Он долгое время крашился при изменении конфигурации, его кучу раз переписывали, но все-равно на сегодняшний день он содержит много проблем:
😀 Приходится пилить костыли для работы с WindowInsets
😀 Он не прилипает к низу экрана
😀 Производительность оставляет желать лучшего
😀 Скрытие Scrim нельзя кастомизировать

А самое худшее — это его императивный API, в котором мы вынуждены управлять его показом через suspend функции show/hide, а также приходится оборачивать контент экрана в ModalBottomSheetLayout. Это очень не удобно, когда нужно показать не статический контент, а полноценный экран с динамическим отображением данных и своей логикой.

😀Решить проблему можно с помощью кастомной декларативной обертки

Как это работает
Показываем Bottom Sheet, если ассоциированный с ним стейт ≠ null, иначе скрываем

Особенности реализации
Нужно уметь показывать предыдущий контент, пока bottom sheet скрывается, несмотря на то, что данных уже нет
Нужно правильно вызывать лямбду onDismiss и здесь можно допустить ошибку:
😀 Завязываться на confirmValueChange не вариант, так как теперь этот callback вызывается множество раз
😀 Отслеживание изменения sheetState.targetValue также может привести к проблемам, так как targetValue будет Hidden даже если вы не до конца скрыли Bottom Sheet

Проблема😀
На текущий момент если скрыть Bottom Sheet через изменение стейта, то его скрытие можно перехватить жестом и тогда останемся в неконсистентном состоянии. Решить проблему можно либо скрытием Bottom Sheet без анимации, либо не занулять стейт, пока он не будет полностью скрыт.

😀 Гораздо лучше дела обстоят в Material 3, там из коробки Bottom Sheet уже декларативный и в нем было решено большинство проблем, только вот далеко не все используют M3 в своих проектах и, чтобы использовать его реализацию, придется копировать к себе кучу исходного кода, что тоже не круто. Таким образом если вы еще не перешли на компоузовский Bottom Sheet, то лучше пока и не торопиться😉

А как вы боретесь с проблемами с Bottom Sheet в своем проекте?

#Compose

Compose Snapshots

❓После доклада меня много спрашивали, а зачем мне вообще знать про снапшоты? Где эти знания применить на практике?

💡 И на мой взгляд, в первую очередь их нужно знать, чтобы разобраться, а каким образом изменение State внутри Composable функции приводит к рекомпозиции?

✳️Давайте сначала вспомним, что вообще такое Snapshot

Это механизм, используемый внутри Compose State и не только, для работы с множественными изолированными копиями состояния. Снапшоты также позволяют сделать безопасное изменение стейта конкурентно без блокировок. Можете думать про снапшоты как про транзакции в базах данных или как про ветки в git.

✳️Причем тут снапшоты и рекомпозиция?

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

private inline fun <T> composing(
    composition: ControlledComposition,
    modifiedValues: IdentityArraySet<Any>?,
    block: () -> T
): T {
    val snapshot = Snapshot.takeMutableSnapshot(
        readObserverOf(composition), writeObserverOf(composition, modifiedValues)
    )
    try {
        return snapshot.enter(block)
    } finally {
        applyAndCheck(snapshot)
    }
}

✳️Где снапшоты могут пригодиться на практике?

🟠Если вдруг вы захотите написать свою либу поверх compose runtime
🟡Для безопасного изменения стейта с нескольких потоков
🔵Для создания своего изменяемого Stable типа, отслеживаемого Compose
🔵Для всего, на что способно ваше воображение! Например, почему бы не работать с БД через Compose State? Что? Да! Это тоже возможно благодаря снапшотам.

Но самое крутое и полезное применение снапшотов я покажу в следующем посте, так что stay tuned 💻

#Compose #Snapshots

Кастомные маски для TextField в Compose

Раньше в Android View реализовать маску для номера телефона, не говоря уже про что-то кастомное было далеко не самой простой задачей и люди, чтобы облегчить себе жизнь, использовали сторонние библиотеки, такие как Decoro.

Но теперь с приходом Compose надобность в сторонних решениях практически отпала, ведь реализовать кастомную маску для TextField можно буквально в 40 строк кода 😱, и это возможно благодаря продуманному и простому API интерфейса VisualTransformation.

Фишка в том, что VisualTransformation, как бы это неожиданно не звучало, влияет всего лишь на визуальное отображение, а не реальное значение поля, и, чтобы реализовать любую маску, достаточно сделать две вещи:

🔸Определить как исходный текст будет трансформироваться в текст с маской

var out = ""
text.text.forEachIndexed { index, char ->
    when (index) {
        2 -> out += "/$char"
        4 -> out += "/$char"
        else -> out += char
    }
}

🔸Предоставить двухсторонний маппинг для правильного смещения курсора в поле ввода

val numberOffsetTranslator = object : OffsetMapping {
    override fun originalToTransformed(offset: Int): Int {
        if (offset <= 2) return offset
        if (offset <= 4) return offset + 1
        return offset + 2
    }

    override fun transformedToOriginal(offset: Int): Int {
        if (offset <= 2) return offset
        if (offset <= 5) return offset - 1
        return offset - 2
    }
}

📘Подробнее можно почтитать в статье, где разобран случай маски для ввода даты и с полностью кастомизируемой маской

#Compose

Коллега из Контура, Евгений Мельцайкин, написал статью о том, как сделать такую кнопку с помощью кастомного Layout в Compose и как оптимизировать ее, чтобы достичь минимального количества рекомпозиций. Приятного чтения 📕

Исходный код можно посмотреть здесь🐱

А вы сможете на взгляд определить какая кнопка сделана оптимально по количеству рекомпозиций?

#Compose

Скриншот-тестирование в Compose

Google не так давно выкатили свой тулинг для скриншот-тестирования в Compose в экспериментальном режиме и работает он на основе Compose Preview 👀

У меня довольно скпептическое отношение к превью, за все время работы с Compose у меня постоянно были какие-то проблемы с этим механизмом, а с приходом Compose Multiplatform заставить превьюшки работать тот ещё челлендж, более менее дела с превью обстоят только в новой IDE Fleet, но там ещё ворох других проблем.

Так вот, вернёмся к тестированию, я попробовал этот способ и что могу сказать по текущему состоянию тулинга:

👍Официальное решение для скриншот-тестирования
👍Генерация отчёта с диффом изображений
👍Уже относительно работает и можно использовать на свой страх и риск
👍Тесты прогоняются без эмулятора и соответственно прогоняются быстро

👎Названия сгенерированных скриншотов нельзя поменять
👎Нельзя выборочно обновить эталонный скриншот
👎Нужно использовать специальные gradle таски для валидации скриншотов, потребуются доработки на CI
👎Нельзя настроить минимальный порог отличий между скриншотами
👎Только для Android

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

#Compose #SnapshotTesting

Нашли серьезную уязвимость в Jetpack Navigation Compose, которая позволяет открыть любой экран в приложении, даже если там нет явных диплинков ⚠️

Эксплуатируется она максимально просто, достаточно знать имя пакета и название маршрута в графе навигации:

Intent().apply {
    setClassName("your.package", "your.package.MainActivity")
    data = Uri.parse("android-app://androidx.navigation/YOUR_DESTINATION")
    startActivity(this)
}

Как защититься

1. Разумеется лучший вариант не использовать данную навигацию, можете посмотреть мой пост со сравнением библиотек навигации для Compose и выбрать подходящую
2. Если в приложении не используются диплинки, можно частично решить проблему перетерев data в определенном intent:

val intentData = intent.dataString
if (intentData != null && intentData.startsWith("android-app://androidx.navigation")) {
    intent.setData(null)
}

#Security #Compose
@kotlin_adept

Перевернутые модификаторы

Неудивительно, что Android и iOS разработчики часто не могут найти общий язык, ведь у них (у нас) все перевернуто с ног на голову 🇦🇺

Это касается и модификаторов в декларативных UI фреймворках. На картинке видно, что цепочка из одинаковых модификаторов для Compose и SwiftUI дают один и тот же результат, при этом располагаясь в обратном порядке.

➡️ В Compose первый модификатор size задает минимальные и максимальные констрейнты и мы не можем выйти за эти ограничения, не переопределяя их.

➡️ В SwiftUI таких ограничений нет и там всегда padding применяется во вне, что может быть даже удобнее, так как не приходится об этом задумываться.

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

#Compose #SwiftUI
@kotlin_adept

Пока готовился к докладу, нашел неплохой репозиторий с набором разных анимаций для Compose Multiplatform.

Там вы найдете множество разных примеров:
🟣Анимации заставок разных приложений (Netflix, Twitter, GitHub, Slack и др.)
🟣Кастомный pull-to-refresh
🟣Анимация горения свечи
🟣Упоротая сова из Duolingo

А если вы iOS разработчик, то вот вам еще более классный репозиторий с кучей красивых анимаций для SwiftUI 💅

#Animation #Compose #KMP #SwiftUI
@kotlin_adept

Адаптивный UI проще, чем кажется

Раньше с Android View, если требовалось поддержать верстку для планшетов, довольно часто просто делали отдельную верстку с нуля, и несмотря на то, что можно было расположить несколько фрагментов на одном экране, это не избавляло от сложностей навигации 🥲

Теперь же с приходом Compose и нового api делать адаптивную верстку стало значительно проще. И вот несколько рекомендаций как сделать современный адаптивный UI:

1️⃣ Не используйте флаги вроде isTablet и т.д., используйте window size classes для динамического определения размера окна: Compact, Medium, Expanded

2️⃣ Используйте готовые адаптивные компоненты вроде ListDetailPaneScaffold, SupportingPaneScaffold, NavigationSuiteScaffold

3️⃣ Рассмотрите возможность использования LazyGrid вместо LazyList

4️⃣ Меняйте расположение UI компонентов с помощью BoxWithConstraint и movableContentOf во избежание лишних рекомпозиций

5️⃣ Не блокируйте ориентацию экрана и не отключайте resizeableActivity

6️⃣ Меняйте размер и соотношение сторон у UI компонентов в зависимости от размеров окна

🌳 В Decompose также появилась поддержка адаптивной навигации и благодаря ChildPanels реализовать list-detail навигацию стало очень просто без лишнего бойлерплейта.

А есть ли адаптивная верстка в вашем приложении ❓
🫡 — только screenOrientation portrait, только хардкор
😎 — есть адаптивная верстка под любые экраны

#Compose #AdaptiveUI
@kotlin_adept

Compose Multiplatform в проде

Хочу поделиться новостью: мы выпустили первое приложение, полностью написанное на Compose Multiplatform для iOS 😌

Изначально приложение разрабатывалось только для Android, но использовался Kotlin-стек (Decompose, Ktor, SqlDelight, Koin) и обычный Jetpack Compose. Чтобы запустить его в каком-то виде на iOS, потребовалось всего 4 дня! Конечно, доведение до релиза заняло значительно больше времени, но всё равно это оказалось гораздо быстрее, чем полноценная разработка аналогичного проекта с нуля.

Что по итогам:
🟣Compose в релизной версии вполне прилично работает, особенно на новых устройствах с поддержкой 120 Гц
🟣Управление жестами удалось легко реализовать благодаря Decompose
🟣Скролл подлагивает и не ощущается как нативный
🟣BottomSheet, как всегда причиняет боль 😬
🟣Есть некоторые баги с TextField
🟣Некоторые контролы пришлось реализовать нативно, например, WebView, TimePicker и т.д.

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

#iOS #Compose

Как подружить Web History и Compose resources

Недавно столкнулся с проблемой: после добавления поддержки Web History в проект с Compose для Web у меня перестали работать ресурсы, причём это происходило только на вложенных экранах.

Изначально я предположил, что проблема связана с настройками веб-сервера, но нет. В Compose для Web ресурсы загружаются по относительному пути. Это означает, что к текущему URL в браузере добавляется путь до ресурсов. Соответственно, если вы находитесь не на главной странице, то по такому пути ресурсы окажутся недоступными 🫥

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

configureWebResources {
    resourcePathMapping { path -> "${location.origin}/$path" }
}

Добавляем этот код в функцию main в сорсете jsMain, и пути до ресурсов снова становятся корректными.

#Compose #JS #WEB