Разработка
Jetpack Compose: отличная идея, но плохая реализация? — обсуждение на Reddit
Все, что выходит за рамки основ, кажется чрезмерно сложным, удивительно недоработанным и откровенно болезненным в использовании.
Я начал изучать Jetpack Compose на прошлой неделе и поначалу был очень взволнован — с простыми примерами было легко работать, и это такой приятный, свежий подход. Иметь весь свой код в одном месте, а не прыгать между XML и Kotlin, тоже здорово.
Но я очень быстро протрезвел — все, что выходит за рамки основ, кажется чрезмерно сложным, удивительно недоработанным и откровенно болезненным в использовании.
Например, основные проблемы, которые я обнаружил:
- Постоянно ломающиеся автоимпорты, которые, судя по всему, не исправлялись годами. Пресловутые
{mutableStateOf(...)}, требующиеsetValueиgetValue, но также ничего не импортирующие автоматически — тонны функций расширения и буквально каждая строка требует ручного импорта. И в половине случаев при импорте вы получаете всплывающее окно с вопросом, какой именно вы хотите сделать, потому что есть 3 конкурирующих «вкуса» (ui, material, material3). Тьфу. Это начинает раздражать через некоторое время… Я занимаюсь Андроидом уже более 10 лет, но не думаю, что мне когда-либо приходилось вручную импортировать так много вещей. - Навигация в Compose — честно говоря, это очень плохо. Это что, писал стажер? То, что было так просто и интуитивно понятно в XML и занимало 5-10 строк простого кода, теперь занимает часы на понимание и в 10 раз больше строк в Compose, а в конце все еще выглядит уродливо и грязно. Неудивительно, что существует несколько библиотек, решающих эту проблему….Но действительно, должны ли мы использовать такие библиотеки, как Appyx или Compose Destinations для таких элементарных вещей? Навигация Compose плохо написана.
- Плохо написанные/пропущенные компоненты — многие /components очень сложны в использовании, используют странные обходные пути или вообще отсутствуют (особенно в material3). Больше всего мне нравится snackbar (то, что раньше было 2 строками в XML, стало Scaffold с 20 строками в Compose и теперь это очень сложно передать в виде лямбды, когда вы просто хотите показать простой Snackbar после нажатия на какую-то кнопку — серьезно? Это то, как Google думает, что мы должны создавать легко повторно используемые компоненты?). Или вот еще один пример — диалог выбора времени для Material3 даже не работает из коробки lol. Копировать-вставить не получается, AS выкидывает ошибки, приходится долго гуглить, чтобы выяснить, что это в Material3 даже не доделано. Вообще, такое количество компонентов больше похоже на альфу/бету…
- Документация неполная, часто устаревшая, даже официальные примеры обычно не работают. Одним из примеров для всех вышеперечисленных проблем был Time Picker Dialog, но я нашел по крайней мере дюжину таких примеров всего за 1 неделю. Учиться больно… Поэтому я пытался найти действительно функциональные компоненты на StackOverflow, что помогает, но отнимает много времени — часто есть 2-3 разных способа сделать что-то, но даже примеры от 2023 года часто уже не работают. Ну если он так часто меняется, то он точно не стабилен! Или есть какие-то лучшие ресурсы? Какие?
- Изменения и рендеринг иногда происходят медленно, иногда не работают. Каким-то образом, по каким-то загадочным причинам, они работают большую часть времени, но не всегда. Загадочные ошибки, которые исчезают после перестройки, и иногда мой ноутбук нагревается от всего этого рендеринга — и это 32-гигабайтный mac pro. Так что я не знаю, является ли это теперь минимумом для разработки Android?
Ладно, это только то, что я думаю, конечно, будет больше, но это довольно много для одной недели.
Резюме
В целом мне очень нравится идея Jetpack Compose, но я думаю:
- реализация часто плохая/переусложненная/неполная
- документация как всегда оставляет желать лучшего (все, что выходит за рамки Hello World, трудно изучить)
- в целом, слишком много проблем на данный момент (по состоянию на июль 2024 года), на мой взгляд.
Лично я чувствую, что Compose в лучшем случае находится в состоянии бета-версии, если вообще не альфы, и не ощущается «завершенным». Может быть, через 1-2-3 года, но не сейчас. Мне приходится гуглить большинство примеров с Compose вместо того, чтобы пользоваться документацией. Этим все сказано… Я понимаю, это относительно новая парадигма, но все же я не думаю, что ее следует называть стабильной, имея столько проблем.
Вопросы
С чем вы чаще всего сталкиваетесь? Есть ли примеры, на которых лучше учиться (помимо официальной документации)? Есть ли рекомендуемые библиотеки компонентов, которые вы используете, чтобы облегчить себе жизнь? Спасибо!
Jetpack Compose — отличная идея, но плохая реализация?
Вот некоторые ответы:
Я работаю с Compose последние 2.5 года в нескольких компаниях — и мне очень нравится, несмотря на его недостатки.
Мои два цента.
Compose прошел долгий путь за последние пару лет — очевидно, что Google направляет большую часть своих ресурсов на разработку Compose. Большинство либ XML находятся только в режиме обслуживания, если вообще находятся (что касается упомянутого вами datepicker для Compose — в варианте XML есть ошибки, которые не исправляются уже более 1 года, и нет никаких признаков того, что кто-то их исправит. Например, если у вас телефон Samsung и вы пытаетесь ввести дату текстом, он будет постоянно заполнять поле заполнителем, не позволяя вам ввести ее).
Вы не упомянули о том, что система на основе XML существует уже более 10 лет. Это довольно много времени, чтобы довести ее до состояния, когда она работает так же легко, как сейчас. В Compose люди обсирали ее еще в бета-версии. Такое ощущение, что есть две школы мысли — либо вы должны быть в группе XML, либо в группе Compose, и обязательно должны обсирать «другую команду». Я с этим не согласен — я считаю, что Compose — это отличный способ улучшить и модернизировать разработку под Android, но людям действительно нужно дать ему немного послабления. Он все еще относительно молод. Я имею в виду, что мы прошли через эпоху гребаных butterknife и findViewById, и вдруг все забыли, что это тоже было дерьмом.
Библиотека навигации — тут я должен согласиться. Я наконец-то перевел наше приложение на композитную навигацию и хотел обойтись без лишних библиотек (потому что они наконец-то реализовали safeargs) — и я совсем не получаю удовольствия. Все это очень тупо и требует много ручного труда для довольно простых вещей, но это все еще бета-версия (по крайней мере, версия с safeargs), так что я надеюсь, что API будет сильно улучшен.
Импорт для меня не так уж и важен — в смысле, нажатие alt+enter два лишних раза не причиняет мне особого вреда. Я был рядом с Kotlin Synthetics, и после этого — я не суечусь по поводу импорта.
Snackbar — это все еще две строки, просто нужно лучше планировать архитектуру приложения. Мне не нравится направление, которое они выбрали, я хотел бы просто запускать событие из любого места, но это не такая уж большая проблема, на самом деле.
Не знаю, чего вам не хватает в диалогах и bottomomsheetdialogs — я обнаружил, что они отлично работают, и их легче модифицировать и настраивать, чем их XML-аналоги.
Самый большой плюс в пользу использования Compose и начала работы сейчас для меня заключается в том, что он становится лучше. Он удобен для использования (и был удобен последние пару лет, если вы знали, что делаете), но каждая новая версия приносит значительные изменения в производительности и QoL. Если вы использовали его в своем приложении и он работает, дальше будет только лучше.
Я думаю, что время разработки сократилось вдвое, когда я перешел на Compose, и мне просто нравится тот факт, что он, сука, бьет тебя по лицу, если ты хочешь срезать углы (например, сделать бизнес-логику в Composable). Архитектура наших приложений стала намного чище и лучше разделена на части — и с ней легче работать, потому что нужно переносить все на state pattern.
Я бы не советовал использовать внешние библиотеки UI, так как новые релизы Compose могут сломать их и заставить вас остаться на пониженной версии, потеряв при этом новые возможности и улучшения производительности (которые, как я уже говорил, обычно огромны).
Документация есть тут и там, в зависимости от того, что вам нужно и используете ли вы бета-версию функции, но мой лучший совет, если документации не хватает, — пробовать, пока не заработает. Ctrl + клик приведет вас к реализации композабл, и оттуда вы можете попытаться добраться до того, что вам нужно изменить, и посмотреть, как это сделать. Это не самый простой путь, но он работает, когда у вас нет альтернативы.
В индустрии разработки в целом произошел масштабный сдвиг в том, как рассматривается стабильность программного обеспечения.
Бета-версия теперь готова к производству.
Я по-прежнему использую XML для своих личных приложений. Для меня важны стабильность, скорость и эффективность, как при разработке, так и в процессе работы.
Я изучил Compose, чтобы использовать его для работы, но я согласен со всеми вашими болевыми точками, не говоря уже о примерно 3 различных «вкусах», все из которых имеют конкурирующие компоненты и различные уровни поддержки, возможностей и ошибок.
Моя самая большая проблема, связанная с Compose, заключается в том, как Google распространял информацию о нем.
Они анонсировали бета-версию Compose в феврале 2021 года, а «стабильную» версию — в 2022 году .
Мне жаль, но сейчас, и тем более 2 года назад, Compose не готов. Я помню, что Preview был настолько плохим и медленным, что перекомпиляция и проверка на эмуляторе была быстрее, чем ожидание Preview в Android Studio.
Когда я проверяю новую библиотеку, я проверяю, насколько она «регрессирует» по сравнению с другими (более старыми) способами. И Compose сильно регрессирует от XML с viewbinding (не ты, databinding!) на MVVM. XML, конечно, немного раздутый, но он прост, хорошо документирован и имеет 10+ лет решения проблем на StackOverflow в помощь. Да, я помню findViewById, Butterknife, датабиндинг, синтетику Kotlin, миграции viewbinding. Но, за исключением чертового датабиндинга, это были простые и хорошо сдерживаемые миграции.
С другой стороны, Compose :
- требует огромного количества знаний, совершенно не связанных с «построением представлений», чтобы даже начать (нужно собрать релиз с базовыми профилями, чтобы хоть как-то приблизиться к быстродействию XML, он использует продвинутые возможности Kotlin, файлы Gradle очень быстро становятся сложными)
- очень крутая кривая обучения
- как заявил автор поста, Compose ужасно документирован для чего-то еще, кроме «Hello World»
- посты StackOverflow бесполезны, потому что API изменился с тех пор. Некоторые ответы StackOverflow в некоторых случаях даже вводят в заблуждение
- «Правильный способ работы с Compose» меняется каждые 6 месяцев и требует значительных изменений для перехода на него.
За последние 8+ лет наши ViewModels (Presenters ? Anyone ? 😁) всегда были единственным источником истины. Это никогда не менялось. Теперь, с Compose, где вы размещаете свое состояние? Существует так много способов сделать это, что это сбивает с толку. Должна ли ViewModel по-прежнему размещать состояние в одном LiveData/Flow, как это было раньше? Если да, то с Compose возникает много проблем с производительностью, потому что вам придется перекомпоновывать «все дерево» каждый раз, когда VM открывает новое состояние.
В любом случае, как по мне, Google слишком поторопился со своей «стабилизацией», и «знание сообщества» вокруг Compose совсем не выросло. Инструментов по-прежнему не хватает (Preview все еще глючит и не интуитивно понятен, например, в отношении темного режима и других вещей), старые посты на StackOverflow бесполезны, если не сказать ошибочны, и нет четкого и простого способа сделать «качественный Compose». Мы даже не знаем, будет ли Compose, который мы делаем сегодня, работать через несколько месяцев/лет. Я до сих пор иногда сталкиваюсь с `findViewById`, и меня это устраивает, потому что это не мешает приложению быть отзывчивым и производительным.
Не поймите меня неправильно, я люблю декларативные UI-фреймворки, в них так много смысла для меня, но Compose в 2024 году, после 4 лет работы с ним, все еще не нравится. Я надеюсь, что все будет хорошо, правда, надеюсь, но переход будет болезненным.
Знаете, как говорится, альфа/бета относится к стабильности API, а не к завершению работы над функциями; и все, что помечено @Experimental_, технически не является стабильным API, а представляет собой эксперимент.
Первое, что вы делаете, это подключаетесь примерно к 7 различным экспериментальным аннотациям, и это длится уже несколько лет.
Я знаю, что некоторые люди с чрезвычайно глубокими знаниями Compose могут создавать безумно крутые вещи, которые на самом деле невозможны с View (определенно невозможны с Фрагментами), но результирующий код и требуемые глубокие знания зашкаливают.
А еще есть пользовательские модификаторы. Я помню статью о том, как кто-то реализовал всплывающие подсказки с помощью пользовательских LayoutModifiers, комментарии были полны «но это очень сложно, вы не должны делать это таким образом» без каких-либо других фактических рекомендаций о том, как это было бы правильно.
Честно говоря, я думаю, что использование Compose настолько сложно, что на данный момент невозможно отличить правильное от неправильного. Это просто вечные жалобы. Но, по крайней мере, большинство из нас могут определить, что что-то не подходит для использования, по ограничениям дизайна .
Я вроде как хочу вернуться к Фрагментам, по крайней мере там вложенность работала надежно.
Все так. Я не понимаю, почему у сообщества такой менталитет «новое — лучшее». Как руководитель команды, я всегда говорю «нет», пока не увижу доказательств того, что новый вариант намного лучше старого стабильного.
Я использую Compose уже некоторое время, и мои впечатления в целом положительные. В нем решены многие проблемы, связанные с пользовательским интерфейсом на основе представлений. Больше всего меня беспокоит то, что есть ошибки, особенно когда речь идет о работе с системной строкой состояния и навигационной строкой. А также то, что многие компоненты в Material3 не реализованы или помечены как экспериментальные. Я полностью ожидаю, что они продолжат улучшать библиотеку, если хотят, чтобы я продолжал ее использовать.
С чем вы чаще всего сталкиваетесь?
Как и большинство вещей в Android, здесь есть высокая кривая обучения. Но я думаю, что это связано со сложной природой мобильной разработки и попыткой Google решить эту проблему с помощью API, который может явно справиться со сложностями и при этом оставаться гибким.
Есть ли лучшие примеры для изучения?
Я бы воспользовался некоторыми примерами приложений. В них есть лучшие практики, которые вы не найдете больше нигде.
Есть ли рекомендуемые библиотеки компонентов, которые вы используете, чтобы облегчить себе жизнь?
Не особо. Библиотеки Jetpack (hilt, navigation, compose, viewmodel и т.д.) хороши тем, что все они интегрируются друг с другом. Material3 — хорошая библиотека UI-компонентов, потому что она следует системе материального дизайна.
Тебе лучше не пробовать KMP, иначе пост будет намного длиннее.
