Bottom Sheet починили! ⚪️

У нас в проектах уже давно нет зависимости от Material, так как используется своя дизайн-система. Это круто, но несёт одну главную проблему: ты перестаёшь следить за обновлениями в Material и исправлениями различных багов. До вчерашнего дня я был уверен, что Bottom Sheet в Material 3 всё ещё отвратительно работает и никакие проблемы там не исправили. Но оказалось, что это не так — все старые болячки там пофиксили 🤩

На видео можно заметить существенную разницу между старой и новой версией Bottom Sheet в Material 3.

P.S. Так что, видимо, надо начинать отдельный квест по копированию исходного кода этого компонента в нашу дизайн-систему 🙃

Пока мы далеко не отошли от темы 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

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

Это небольшой, но показательный пример, где можно увидеть:
🌳 Навигацию на Decompose для SwiftUI и Jetpack Compose
🎨 Интеграцию Compose Multiplatform в SwiftUI
⚙️ Работу с moko-resources
🐘 Реализацию многомодульности с изолированным DI в каждом модуле с помощью Koin

Звездочки на репозиторий приветствуются ⭐

Один из подписчиков канала, Алексей Илларионов, написал отличную статью про новый BundledSQLiteDriver из библиотеки androidx.sqlite.

В статье вы найдете:
🔘Преимущества и недостатки своей сборки SQLite
🔘Новые фичи BundledSQLiteDriver
🔘Ограничения, про часть из которых я писал ранее
🔘Замеры производительности

Приятного чтения 📕

В этот раз посетил Mobius 😀 не в качестве спикера, хотя планировал сделать доклад о нашем опыте использования Compose Multiplatform в проде, но не случилось по личным обстоятельствам...

Уже по традиции после конференции планирую сделать обзор запомнившихся докладов и на самые интересные сделаю отдельные посты.

Если захотите пообщаться, то не стесняйтесь подходить, наверняка меня можно будет застать за фармом мерча на стендах 🤡

Буду сейчас принимать участие в стриме от Яндекса на Mobius, будем фиксить баги в прямом эфире.

Подключайтесь ✅

Как ускорить релизную сборку

Из всех докладов на Mobius, которые мне удалось посмотреть, могу выделить классный доклад о том, как в Т-Банке случайно ускорили релизную сборку в два раза.

Я думаю, у многих в проектах работа R8 занимает больше всего времени из всего процесса сборки, а в крупных проектах выполнение этой таски может доходить до 3 часов 🙀 — и это требует огромного количества оперативной памяти.

Так что же может значительно увеличивать длительность выполнения этой таски?

1. Неоптимальные правила
Обычно это правила с условием, например, такие встречаются в библиотеке kotlinx-serialization. На них тратится больше всего времени, нужно быть аккуратнее с такими правилами и не дублировать их в своём коде, так как правила для R8 уже поставляются вместе с библиотеками.

2. Огромное количество ресурсов
Таска shrinkResources может потреблять очень много оперативной памяти, и если в вашей дизайн-системе вы предоставляете большую библиотеку иконок, то, возможно, стоит пересмотреть подход и не тащить тысячи иконок, чтобы потом R8 не удалял их очень долго. Как вариант, можно рассмотреть загрузку иконок с CDN по запросу.

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

#R8 #Gradle

На сегодняший день есть множество либ для сканирования QR-кодов, но к сожалению, далеко не все из них справляются с разными видами Data Matrix.

Ранее мы использовали Google ML Kit, но он очень плох при сканировании Data Matrix, а из других бесплатных аналогов остается только ZXing или его адаптированная под Android версия, обе из которых уже давно не развиваются.

Мы сейчас проводим исследование библиотек для сканирования Data Matrix и хотели бы узнать, какие библиотеки вы используете. Напишите, пожалуйста, в комментариях какую либу вы рекомендуете, если у вас был такой опыт 💬

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

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

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

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

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

#Compose #SwiftUI

Маст-хэв кастомные Gradle-плагины

Если вы разрабатываете несколько приложений, то наверняка уже шарите какой-то общий код, вынося его в отдельные библиотеки или модули. Но не только общие модули могут быть полезны — можно ещё переиспользовать утилитарный код с помощью Gradle-плагинов.

Знаю, что многие, мягко говоря, не любят Gradle — и на то есть причины. Однако написание собственного небольшого плагина проще, чем кажется, особенно если делать это неправильно (привет afterEvaluate 🙃).

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

1️⃣ Version Catalog — очень простой плагин, который помогает удобно переиспользовать версии зависимостей между проектами. Про него я уже как-то писал здесь.
2️⃣ Code Style — обёртка над Detekt с настроенными дефолтными и кастомными правилами.
3️⃣ Git Hook — запуск тестов и проверки кода при коммите, проверка сообщения коммита и прочее.
4️⃣ Vault — плагин для получения секретов из защищённого хранилища при первоначальной настройке проекта.
5️⃣ Publish — плагин для упрощения публикации собственных плагинов, каталога версий, Android и KMP-библиотек.

🔥 Если тема интересна — ставьте реакции, и я расскажу подробнее, как создавать такие плагины и дам рекомендации как не стоит делать.

#Gradle

🎨 Наверное, только ленивый не написал о том, что Compose Multiplatform для iOS стал Stable. Но что это значит? Действительно ли все болячки пофиксили, и можно с лёгкостью портировать любое Android-приложение на iOS?

Действительно, стало гораздо проще адаптировать какой-нибудь простой Jetpack Compose-пример на iOS, буквально перенося файлы из одной папки в другую, но с реальными приложениями всё не так гладко. И вот какие проблемы я вижу на текущий момент:

🔘Мало библиотек, которые полностью избавляют от написания платформенного кода

Во Flutter, например, есть огромное количество библиотек на любой вкус и цвет, которые покрывают все платформенные API в общем коде: работу с разрешениями, камерой, геолокацией и другими. В CMP же в большинстве случаев придётся реализовывать это нативно, что требует хотя бы минимальных знаний платформы и языка.

🔘Отсутствуют адаптивные виджеты для платформ

Сейчас «из коробки» доступны только Material-виджеты, и, несмотря на то что у многих приложений своя дизайн-система, всё равно хотелось бы адаптировать часть виджетов под платформу. Например, Android-овский PullToRefresh выглядит максимально инородно на iOS и в целом плохо дружит с физикой скролла на iOS.

🔘Производительность

В анонсе сказано, что производительность CMP сравнима со SwiftUI и, судя по графикам, даже превосходит его. Но это всего лишь один бенчмарк ленивого списка. Если вы начнёте сравнивать приложение на SwiftUI и CMP на каком-нибудь iPhone 13, то невооружённым глазом увидите разницу не в пользу Compose. Очевидно, что проблема кроется в Skia, от которой Flutter и отказался из-за проблем с производительностью. Будем надеяться, что в будущем команда CMP тоже предпримет какие-то шаги в этом направлении.

📌Подводя итог, хочется сказать: круто, что CMP уже стал стабильным и его можно использовать в проде, но это всё ещё не будет лёгкой прогулкой, и технологии есть куда расти.

#ComposeMultiplatform #CMP

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

Обновить зависимости так, чтобы ничего не отвалилось, та ещё задача, а в KMP-проектах добавляется ещё больше веселья.

Например, хотим запустить проект на Xcode 16.3 — для этого нужен Kotlin 2.1.21, а для него требуется новый KSP, в котором сломали обратную совместимость. И какая-нибудь либа в проекте, использующая KSP, благополучно перестаёт работать. 

К счастью, отключить вторую версию KSP можно в gradle.properties, и это спасёт на какое-то время:

ksp.useKSP2=false

Хуже этого только борьба с Java-версиями. Когда в каком-нибудь кастомном detekt-правиле забыли указать jvmToolchain с нужной версией, приключение на весь день точно будет обеспечено 👍

#Gradle #KSP

UI-тестирование в Compose 🎨

Если вы хотите реализовать UI-тесты в Compose, то на сегодняшний день есть три основных решения: официальная библиотека от Google и обёртки над ней — Kakao/Kaspresso и Ultron. Про официальное решение сегодня говорить не будем, а рассмотрим поближе другие библиотеки.

Мы уже много лет используем Kaspresso для UI-тестов, но недавно я решил поближе познакомиться с библиотекой Ultron и сравнить оба решения. На самом деле, по функциональности они очень схожи.

🟡Ultron выглядит довольно заманчиво: у него есть два ключевых преимущества перед конкурентами — при написании тестов на Ultron практически отсутствует какой-либо бойлерплейт-код, а также Ultron поддерживает Compose Multiplatform. Ещё из плюсов можно выделить качественную документацию. Из недостатков я бы отметил довольно небольшое комьюнити у библиотеки, а также, лично для меня, оказалось непривычным отсутствие связей parent-child между PageObject. Подробнее узнать про Ultron можно в недавно опубликованном докладе от автора библиотеки — Алексея Тюрина.

🔘Kakao/Kaspresso — проверенные временем библиотеки с большим комьюнити, но описание PageObject в Kakao до версии 1.0 требовало довольно много бойлерплейт-кода, особенно при работе с Lazy-списками. Также механизм flaky safety в Kaspresso не совсем хорошо работает с виртуальным временем в Compose-тестах. Об этом подробно рассказал Паша Стрельченко в своём докладе.

💬 А что используете вы для UI-тестирования в Compose? И оправдан ли тренд на уход от дорогих UI-тестов в проекте?

#Compose #UiTesting

Решил я, значит, повайбкодить и сделать CLI-приложение на Kotlin для сканирования Data Matrix с помощью библиотеки ZXing. На вход бы передавался архив с датасетом из реальных изображений продуктов с кодами, а на выходе получали бы отчёт: какие Data Matrix удалось распарсить, а какие — нет.

Первую версию я сделал с помощью ChatGPT, и, несмотря на то что модельки стали писать рабочий код с первого раза, результат получился катастрофическим — распозналось всего 10% Data Matrix из всего датасета на тысячи кодов. Зато работало это довольно быстро.

Далее я попробовал все последние модели, доступные без платной подписки: GPT-4o, Gemini 2.5 Flash, Deepseek R1, Claude Sonnet 4 и Grok 3. Попросил их улучшить текущее распознавание кодов.

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

Единственным, кто смог хоть что-то улучшить со второй попытки, оказался Grok — но и то разница получилась не драматической: условно, из 20 кодов распозналось не 2, а 4.

Так что на этом мой вайбкодинг закончился — придётся дальше всё делать самому 🥲

Фоновая работа в Android и iOS

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

➖ На текущий момент не существует хорошего решения для KMP-проектов, которое предоставляло бы общий API для работы с фоновыми задачами. Это вполне объяснимо: API сильно отличаются между платформами.

🤖 Для решения задачи синхронизации данных в фоне в Android существует несколько решений, например, WorkManager, который имеет довольно удобный API и позволяет запускать задачи с интервалом не менее 15 минут. Он позволяет задать условия запуска задачи, порядок выполнения воркеров и определить поведение при повторном планировании одной и той же задачи.

🍏 В iOS есть два стула: BGAppRefreshTaskRequest и BGProcessingTaskRequest.

Первый предназначен для относительно быстрых операций длительностью до 30 секунд и может выполняться чаще, второй — для более долгих задач, которые могут выполняться в течение нескольких минут и даже часов. Разумеется, можно указать минимальное время, через которое должна быть выполнена синхронизация. В интернетах рекомендуют устанавливать интервал в один час, однако iOS конечно же не гарантирует, что задача будет выполнена вообще 🙃

С появлением SwiftUI стало удобнее работать с фоновыми задачами — достаточно запланировать их с помощью BGTaskScheduler и обрабатывать через модификатор backgroundTask. Однако, по сравнению с WorkManager, многое приходится делать вручную — например, явно обрабатывать ситуацию, когда задача уже запланирована, иначе интервал её запуска может быть сброшен.

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

#iOS #Android #Background #KMP

Хочу порекомендовать вам классный канал Dev Easy Notes про разработку на около-андроидную тематику и не только. Там можно найти много всего интересного:

🔘Серия постов о том, как работает Android
🔘Когда нужно использовать статику вместо DI
🔘Что не так с книгой "Чистый код"
🔘Самое странное собеседование
🔘Серия постов про то, как работает CI

На канале нет бесконечных репостов с Medium, зато есть качественный авторский контент с щепоткой хорошего юмора. Так что, если хотите прокачиваться не только в мобильной разработке, этот канал определённо будет вам полезен 😉

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

Сейчас мы все такие модные и молодёжные: пишем KMP-проекты и запускаем тесты через Gradle-таску allTests, которая прогоняет все тесты в проекте и даже делает это на всех таргетах, если тесты написаны в общем коде.

В обычных Android-проектах для запуска Unit-тестов есть стандартная таска test, которая прогоняет тесты для всех BuildVariant. В своё время мы подумали: а зачем гонять тесты вхолостую, тратить больше времени? Достаточно же прогнать только релизную сборку — testReleaseUnitTest.

Но когда в проекте появляются Flavors (да, это зло, но иногда вынужденное), то для модуля app, где эти Flavors описаны, нужная таска превращается в test<Flavor><BuildType>UnitTest. Мы были уверены, что, запустив её, все тесты в других модулях тоже выполнятся. Но, конечно же, никто ничего не проверил 🌟

А если в других модулях Flavors нет, то тесты по этой таске просто не прогоняются! Для них нужно явно вызывать таску без Flavor.

Звучит очень глупо — как можно было так ошибиться? Но когда ты видишь зелёный pipeline, в голову почему-то не приходит специально сломать какой-нибудь тест в отдельном модуле, чтобы проверить, что всё работает 🌟

Вот такая вот кринж-история. А какие факапы были у вас?

Must-have материалы для углубления в Compose

Если вы хотели глубже разобраться в Compose, то ловите список материалов в открытом доступе, которые точно заслуживают вашего внимания:

Доклады

- Мой доклад о том, что скрывает стейт в Compose
- Наш с Димой Григорьевым квиз по Compose
- Доклады от Димы о том, как работает позиционная мемоизация и как устроена композиция в Compose
- Доклад от Асахра Айдарова про устройство компиляторного плагина в Compose
- Доклад от Алексея Гладкова про то, как работает Compose for iOS
- Доклад от Leland Richardson. Как работают модификаторы [en]
- Доклад про создание UI фреймворка для PowerPoint на основе Compose Runtime [en].
- Хардкорный доклад от Jake Wharton про запуск Compose на контроллере от настольной лампы [en].

Репозитории

- Пример реализации автоматических анимаций на основе состояния
- Репозиторий с реализацией анимаций разной сложности
- Compose для терминала от Jake Wharton

Блоги

- Compose Broadcast
- Mobile Compose
- Блог от Zach Klippenstein [en]

Книги

- Jetpack Compose Internals - Jorge Castillo

Ну и не забывайте про официальную документацию — там целая кладезь полезной инфы про Compose, которую часто просто копируют авторы различных статей на Medium.

Если вы знаете ещё какие-то интересные материалы про устройство Compose, то обязательно делитесь ссылками в комментариях ⬇️