Comments 6
В этой статье еще есть описание работы Compose.
Вы смотрели как это в итоге всё рисуется на экране? Судя по описанию, используется Canvas API.
Интересует сравнение по объёму кода, скорости работы, сложности написания интерфейса в сравнении с подходом на xml вёрстке и чисто программного подхода с использованием addView, ViewParam. А также какие проблемы помог решить переход на Compose?
Да, compose использует Canvas API под капотом. Существует отличная статья на эту тему с небольшими примерами.
Если сравнивать, то вот моё субъективное мнение.
Объем кода:
Jetpack Compose. Тенденция к меньшему объему кода, поскольку Compose позволяет создавать UI-компоненты в декларативном стиле, что обычно делает код более чистым и кратким.
XML. Обычно требует больше шаблонного кода. XML разделяет структуру интерфейса и логику, что может увеличивать объем кода.
Программное добавление вьюх. Зависит от сложности интерфейса, но часто может быть громоздким.
Скорость работы:
Jetpack Compose. Оптимизирован для производительности и создан с учетом современных практик.
XML и программное добавление вьюх. Могут быть оптимизированы, но в некоторых случаях Compose может предложить более высокую производительность из-за своих особенностей и оптимизаций на уровне фреймворка.
Про производительность. Мы не проводили замеры производительности и скорости отрисовки элементов. Могу сказать, что визуально опыт использования никак не ухудшился. Мне понравилась статья на эту темя, очень рекомендую.
Сложность написания интерфейса:
Jetpack Compose. Относительно прост (на самом деле кому как, но кажется, что для большинства это справедливо) в изучении для новых разработчиков и позволяет быстро создавать сложные интерфейсы с помощью встроенных компонентов.
XML. Может быть сложным для создания динамических и сложных интерфейсов.
Программное добавление вьюх. Может быть гибким, но часто требует больше кода и времени на реализацию сложных интерфейсов.
Решение проблем:
Jetpack Compose. Упростилось создание динамических и реактивных интерфейсов. Было легко интегрировать с нашей существующей архитектурой. Улучшило поддержку тем и стилей.
Compose может упростить процесс разработки и сделать код более читаемым и поддерживаемым, но выбор между Compose и традиционными подходами зависит от конкретных требований проекта и опыта команды.
Jetpack Compose. Тенденция к меньшему объему кода,
поскольку Compose позволяет создавать UI-компоненты в декларативном
стиле, что обычно делает код более чистым и кратким.Программное добавление вьюх. Зависит от сложности интерфейса, но часто может быть громоздким.
Почему так? Ведь в программном добавлении вюьх точно также организуются блоки.
Улучшило поддержку тем и стилей.
А как реализуется когда надо несколько тем и разные экраны? if или switch в composable фунциях? Скажем, если на экране мобильника 5 кнопок помещается, а на планшете 10.
И вдогонку: как думаете, технология будет развиваться или через годик её объявят устаревшей и выкатят compose2?
Обычно делается тема приложения и она лежит на самом верхнем уровне (fragment/activity/composeview), а все контейнеры с конкретными compose экранами уже складываются внутрь неё
В итоге получается что то вродеsetContent {
AppTheme() {
ComposeScreen()
}
}
Где
setContent - выставление Compose контента
AppTheme с набором ресурсов приложения, привязанных к dark/light/fold
Compose screen - любой экран на Compose, тут в приложении будет скорее всего лежать NavHost
Когда меняется тема приложения - меняется AppTheme все Compose функции внутри неё, которые пользуются её dimens/colors/etc. получают сигнал о рекомпозии и перестраиваются. По идее то же самое должно происходить при изменении любой конфигурации устройства, включая складывание foldable устройства, но я пока не занимался поддержкой foldable на Compose и не могу дать точный ответ
И вдогонку: как думаете, технология будет развиваться или через годик её объявят устаревшей и выкатят compose2?
Разве одно другому противоречит?
Сейчас явно понятно одно: Compose и концепцию декларативного ui уже никто не забросит – это явно будущее. И, если у гугла возникнут идеи для мажорного обновления Compose-библиотек, и они выпустят Compose-2/3/4, то разве это будет говорить об отсутствии развития Compose? Кажется, что наоборот. Как и с любыми другими библиотеками
Compose это библиотека поверх стандартного Андроида, так что развести руками, сказать, что не получилось и выкинуть проблемы не составит. Для десктопа Kotlin multiplatform использует под капотом Swing, так что выгода не очень понятна. Никак не могу уяснить выгоду декларативного подхода по сранению с императивным. В одном вы пишете функцию с параметрами и в другом пишете функцию с параметрами. Когда есть xml можно теоретически сказать, что вы отделили представление от кода и что интерфейс может сделать человек не знакомый с программированием. С Compose же уже сложнее.
Compose-recompose: почему происходят рекомпозиции и как уменьшить их количество