Комментарии 8
Какой самый болезненный момент при переходе с XML на Compose в живом проекте?
Могу слегка помочь автору. Часть боли он уже сказал, это webView и работа с картами. Где ещё могут быть небольшие трудности:
Переезд мышления на парадигму UDF (https://developer.android.com/develop/ui/compose/architecture), имутабельный интерфейс и необходимость привыкнуть к тому, что все изменения UI, это изменение стейта,
Переходный период миграции на Compose в большом проекте. Какое-то время будет зоопарк из классических Fragment + View, и Compose. Все переезжают по-разному, но как по мне, самый безопасный вариант, это не встройка отдельных Compose View, а переписывание всего контента на Compose в рамках одного Fragment.
Часть стандартных компонентов из Compose Material имеют встроенные padding/margin, которые не убрать через modifier.
Не совсем привычная работа с BottomSheet и ему подобными
Работа с modifier (фон, отступы, рамки и прочее), где на внешний вид влияет порядок вызова модификаторов. Первое время надо будет привыкать
Scope родительской Compostable функции, который определяет возможности части modifier вложенных элементов. Для кастомных UI элементов, иногда нужно явно указывать Scope родительского контейнера, чтобы применять нужные модификаторы (modifier)
Во время миграции могут возникнуть проблемы с влиянием жизненного цикла Fragment/Activity на отрисовку Compose внутри (https://medium.com/@tangkegaga/why-viewcompositionstrategy-compose-and-view-work-together-905933a8ac99)
Для более оптимальной работы Compose ещё стоит получше изучить рекомпозицию и стабильные функции (https://habr.com/ru/companies/yandex/articles/841154/)
Но все это решаемо, описано в официальной документации или давно разобрано сообществом. Поэтому больших трудности при миграции не будет. А новый проект/фичу написать на Compose будет ещё проще
Самый больной момент — это то, что XML и Compose вообще не дружат, нельзя просто взять и переписать код частично. Приходится каждый экран полностью переписывать, и если архитектура не отделяет логику от UI, то можно здорово напортачить и потратить кучу времени. Навигация в Compose тоже часто вызывает боль — там всё сложнее и запутаннее, чем в XML. И ещё куча мелких проблем с импортами, компонентами и багами в Material3, из-за которых иногда хочется вернуться к XML. В общем, переход — это не просто смена синтаксиса, а реальный ребилд экранов и переосмысление архитектуры, так что готовься к долгому и мучительному процессу
Верно, но можно сделать промежуточный шаг это Fragment + ComposeView, чтобы остаться вначале на вашей навигации. А потом уже отдельно переехать на новую навигацию если посчитаете нужным
Если на проекте уже есть кастомные View или сложные анимации, связка XML и ComposeView может превратиться в ад с мерцаниями и артефактами. Плюс, если логика завязана на ViewModel внутри Fragment'а, при полном переходе на Compose её всё равно придётся рефакторить — так что это временный костыль, а не решение
Спасибо за материал, все по делу.
Часть 2: XML или Compose — что выбрать, и что нужно знать перед выбором