Jetpack Compose: отличная идея, но плохая реализация? — обсуждение на Reddit

Я работаю с 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, иначе пост будет намного длиннее.