Комментарии 15
Так а при чем тут адаптация? Может, все-таки интеграция?
Они в прошлой статье никому не ответили и тут будут игнорить ....
Если насчёт статьи про отправку уведомлений, то автора статьи уже пинганули, ответит в ближайшее время.
Когда заметите где-нибудь ещё, пишите — можете либо мне в личку, либо автору в личку, либо в наш телеграм-канал «HH Tech Talks», там сидят практически все авторы нашего блога, они ответят на любые вопросы.
Я имел в виду адаптирование большого монстра hh к новому фреймворку) ну или наоборот, приспособление Compose-а внутри нашего приложения)
Слово «Адаптация» сильно повлияло на ваше восприятие статьи? Чего не хватило?
Я имел в виду адаптирование большого монстра hh к новому фреймворку
Ну тогда это "адаптация hh под jetpack compose". Но звучит все равно так себе.
приспособление Compose-а внутри нашего приложения
Ну вот после такого заголовка я и ожидал, что вы сам Compose будете как-то "адаптировать". Вы же его совершенно не изменяли, о какой адаптации может идти речь? В общем, выбор слова выглядит неудачным и неподходящим.
Стали ли вы бы это делать на своём проекте, а не за счёт работодателя (ради чего вы это делали)? Стал ли код проще/читабельнее по сравнению с подходом на xml или старым программным? Стал ли размер приложения меньше, работа быстрее, как изменилось время сборки проекта? Если бы использовался старый программный подход, результат был бы хуже/лучше?
Давайте по порядку отвечу на каждый вопрос.
1. Стал бы делать это на своём проекте
Зависит от проекта. Если это проект не горящий, который можно разрабатывать не торопясь, то да, однозначно стал бы. Мне нравится Compose, нравится декларативный подход, нравится писать маленькие и переиспользуемые кусочки интерфейса.
Если же проект был бы срочным, я бы задумался. Но, пожалуй, всё равно стал бы затаскивать, тем более что интероп работает, и к фрагментам и XML-вьюхам можно всегда перейти.
2. Ради чего вы это делали
Пара причин:
— интересно пробовать новую технологию, чтобы не отставать от трендов и не чувствовать себя мамонтом
— за Compose-ом будущее Android-разработки (а то и мультиплатформенной), уже сейчас хочется понимать, насколько больно будет на него мигрировать.
3. Стал ли код проще
В каких-то кейсах — стало проще в разы. Я привёл в статье пример с ячейками — на XML-е у нас получилось довольно громоздкое решение со множеством подводных камней.
В некоторых кейсах — наоборот, стало сложнее, за счёт того, что Jetpack Compose всё ещё молодая технология и нет каких-то готовых решений для привычных в XML-е вещей: тот же CollapsingToolbar в нашем примере (да, есть уже Material-вариант с Top App Bar, но у нас сходу это не завелось), или отсутствие minLines в TextView.
В остальных кейсах — получается примерно 50 на 50 — где-то проще, где-то посложнее.
4. Стал ли код читабельнее
В Compose-коде приходится делать множество переносов строк, куча вложенных конструкций, куча фигурных скобок, порой немного теряешься. Но в какой-то момент привыкаешь и начинаешь читать так же, как в XML. Субъективно, стало чуть тяжелее.
5. Стал ли размер приложения меньше
Нет, стал даже больше =) Мы не сразу выпилить весь XML-код, который мы писали последние 8 лет, поэтому мы подключили ещё библиотек к приложению, не выпиливая другие.
6. Стала ли работа быстрее
Пока что разрабатывать стало сильно-то и быстрее. Потому что, как я уже говорил, технология молодая, далеко не на каждый вопрос есть ответ на StackOverflow, далеко не всё получается быстро нагуглить. Иногда после походов в google ты находишь только открытое issue в Issue Tracker-е с той же проблемой, что и у тебя.
А вопросов пока что возникает много и часто, особенно у коллег, которые только-только начинают пробовать работать с Compose-ом. Иногда мы сталкиваемся с тем, что реализованный по-быстрому компонент работает плохо, его неудобно использовать, и нам приходится тратить дополнительное время на дотюнивание написанного кода.
Но зато когда все компоненты для экрана готовы, UI накидывается довольно быстро и весело.
7. Если бы использовался старый программный подход, результат был бы хуже / лучше?
Результат точно не был бы хуже, хотя бы за счёт уже полностью готовой дизайн-системы на XML и множества отлаженных решений в нашей кодовой базе.
Был бы результат лучше — в смысле, с точки зрения удобства / скорости разработки? Тут скажу, что на XML просто привычнее разрабатывать, особенно если вы программируете под Android давно. Каждый вопрос легко гуглится, у всех коллег есть опыт решения тех или иных проблем, костыли известны. Поэтому разработка с использованием XML пока что более предсказуема по времени, чем разработка с Compose-ом.
Спасибо за ответы!
Но под "программным подходом" имелось в виду создание GUI программно, а не с XML. Можно же написать функции создания визуальных блоков и из них собирать интерфейс.
По сравнению с самописными декларативными фреймворками, Compose, конечно, впереди планеты всей — хотя бы за счёт официальной поддержки от Google и уже встроенными перерисовками нужных кусочков, рекомпозициями, мемоизациями. Самому такую махину функциональности поддерживать, мягко говоря, непросто =) А накидывать UI в стиле Telegram-а — трудно потом код будет читать.
До Compose-а уже были попытки занять нишу декларативных фреймворков:
— Был Litho от Meta-а. У Сергея Рябова был прекрасный доклад на Mobius-е про этот фреймворк. Там тоже были переиспользуемые кусочки UI, автоматическое построение UI на основе «спек». Плюс Meta очень заморачивался над тулингом (делали специальный плагин для preview, свой layout inspector, etc) и оптимизациями (рассчитывали самое оптимальное количество View на экране, без ViewGroup, старались не использовать тяжёлые Android View, заменяли их на TextDrawable / ImageDrawable / etc). При этом был annotation processor, когда смотрел — была только экспериментальная поддержка Kotlin-а. На мой вкус, код на Compose выглядит попроще, нет java builder-ов, удобный Kotlin DSL.
— Ещё был Inkremental. На канале Android Broadcast у Кирилла было когда-то интересное интервью с ребятами, разрабатывающими этот фреймворк. У ребят был похожий на Jetpack Compose синтаксис, тоже Kotlin DSL, они тоже смогли сделать изменение UI на основе state-а. Мы в hh даже хотели одно время его попробовать, но пока собирались, уже вышел Compose =))) Чем нас тогда привлёк этот фреймворк, миграция на него выглядела даже проще, чем миграция на Compose, потому что создали Inkremental смапили уже имеющиеся вьюшки из Android SDK максимально похожим образом.
В общем, решений раньше было много, но я не уверен, что нужно ли что-то сейчас кроме Compose-а, если вы до этого не использовали других фреймворков.
Подход с XML выглядел как попытка разгрузить код вьюхи и сделать возможным вёрстку другими людьми. Тут же получается лапша кода снова в вьюхе.
И логика работы уже теряется или нужно заводить еще один слой астракции, так ведь получается?
Мы в hh экраны делаем с помощью UDF-подхода, фрагмент — это только про UI, логика контролируется из ViewModel. Поэтому для нас просто поменялся код UI-слоя.
Про лапшу в коде View — могу согласится лишь отчасти: да, в Jetpack Compose-е получается больше переносов строк, больше скобочек, но так как сами функции не очень большие, читать-то по-прежнему удобно. В XML-е не всегда так легко получалось выносить общий код, как с Compose.
А ещё — «другими людьми» — это кем? Мы просто не делим разработчиков на «UI-верстальщиков» и хардкорных «логиков», которые не имеют к UI отношения =) Все пишут всё =)
Автор, а разве NavBar все еще работает?
Привет!
Что имеете в виду?
Если "работает ли NavBar внутри вашего приложения" — то, что мы в hh называем NavBar-ом — работает и используется на множестве экранов.
Если "работают ли ссылки на реализацию NavBar-а" — да, ссылки, которые я прикрепил открываются корректно, ведут на правильные куски кода.
Если имеете в виду что-то другое, уточните, пожалуйста.
Спасибо за интересный пост! Узнал много интересного
Адаптация Jetpack Compose в hh.ru