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

Неудивительно, что 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

Пока мы далеко не отошли от темы Bottom Sheet, хочу снова немного побомбить на то, какой API нам предоставили разработчики этого компонента в Material 3.

Я уже как-то поднимал тему декларативного Bottom Sheet, когда решение о том, показывать его или нет, определяется исключительно состоянием. То есть мы показываем шторку, если ассоциированный с ней стейт ≠ null, иначе скрываем.

И казалось бы, в Material 3 сделали именно так: достаточно просто установить значение false в переменной showBottomSheet, чтобы скрыть его. Но тогда это произойдет без анимации сворачивания компонента⚠️

Чтобы это исправить, придется явно вызывать suspend-функцию hide, но делать это каждый раз, мягко говоря, неудобно. Можно попробовать написать свою декларативную обертку, но придется решить несколько проблем:

🔘Как сохранять контент при анимации скрытия, если стейта уже нет?
🔘Как запретить перехватывать Bottom Sheet жестом, пока он сворачивается?

И вторая проблема самая неприятная, так как в Bottom Sheet нельзя отключить обработку жестов, пока он скрывается. Но нам обязательно нужно скрыть его, если ассоциированный стейт уже null, иначе получим неконсистентное состояние.

Как ни странно, в SwiftUI таких проблем нет — декларативная обертка пишется буквально в несколько строчек, что можно увидеть на изображении.

Обертку для Bottom Sheet из Material 3, которая отлично подходит для Slot навигации в Decompose, я уже реализовал и чуть позже поделюсь ею с вами, когда обновлю свой пример KMP-проекта.

#Compose #SwiftUI #BottomSheet

Обычно SwiftUI и Compose очень похожи между собой, и, как правило, стейт для экранов можно формировать одинаково — это очень удобно при работе с KMP.

Но иногда бывают сильные отличия в API, например, PullToRefresh: если в Compose индикатор показывается по изменению состояния, то в SwiftUI — это асинхронная таска 🤬

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

Чтобы исправить это, придётся в стейте сразу хранить словарь и в зависимости от типа ячейки, на которую кликнули, выбирать нужный набор значений.

💬 А какие ошибки допускали вы при формировании стейта экрана?

#Compose #SwiftUI

Как встроить SwiftUI в Compose Multiplatform

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

И при работе с Compose Multiplatform я подсмотрел классное применение этого механизма для встраивания SwiftUI вьюшек в Composable функции.

1. В сорсете iosMain создаём CompositionLocal и интерфейс NativeViewFactory.
2. На стороне Swift реализуем этот интерфейс и передаём его в функцию создания UIViewController.
3. В этой функции пробрасываем фабрику через CompositionLocalProvider.
4. Далее в любом месте поддерева в iosMain можно получить доступ к этой нативной вьюшке.

🌐 Посмотреть пример приложения для сканирования QR-кодов с этим подходом можно в репозитории, который я подготовил для лекции в онлайн-университете.

#Compose #SwiftUI