Комментарии 28
Как минимум сейчас есть аннотация @Model, которая превращает класс в observable источник данных для Compose. Похоже на scoped model в Flutter. Посмотреть пример использования можно в исходниках
"10.dp" — это влияние php?:-)
Просто extension-функция над Int, которая преобразовывает его в инстанс дата класса Dp. Исходники Dp.kt
Лично я не вижу ничего страшного в том, что-бы что-то бросить в редакторе, а потом подправить руками. Я не все наизусть помню. Но по большому счеты вы правы. Чем сложнее UI, тем проще сделать руками.
Но вот чем плохо все делать внутри одного констрейна я не очень понимаю. Не могли бы вы развить эту мысль?
Если есть возможность написать все приложение в одном классе — почему так не делают? Юзают же зачем-то разбивку на классы и компоненты.
Contstraint как раз и разбивает на экраны. Дробление ведь то же имеет свой разумный предел. Скажем мы ведь можем для каждой переменной создавать свой класс. Но не думаю, что кто-то так делает.
1. Намного больше это 2-3 лишних параметра? Как по мне не сильно большая плата за стабильность и управляемость.
2. Даже не знаю что сказать. Полно статей с анимацией как это все работает. Как это можно не понять? Вы точно доки читали? Или каждый раз угадывали?
3. Так сложилось исторически, что в нашей команде сложной разметкой занимаюсь именно я. И у меня еще ни разу не было такого, что бы при добавлении в любое место элемента все-все сломалось. Конечно правки для соседних или связанных элементов делать приходится. Но ради предсказуемости результата я на это готов.
4. Вполне логично, что разные элементы это разные элементы. Но сказать, что «невозможно работать нормально как с однми целым» это вы сильно перегибаете. Конечно когда в нашем распоряжении не было MVVM, LiveData, DataBinding это было несколько муторно. И то не было ничего невозможного. Но сейчас просто привязав видимость элементов к LiveData мы может управлять ими как группой. Мы можем даже пойти дальше. Мы можем создать любые кастомные параметры, которые на основе той-же LiveData могут реализовывать любую сколь угодно сложную логику. Например пропадать по очереди и перекрашиваться при этом в розовый. И все это будет делаться присвоением всего-лишь одного значения.
Простите если это прозвучит грубо, но, честно говоря, я ожидал чего угодно, но только не ответ в стиле «я его не понимаю». Мы уже давным-давно перешли на ConstraintLayout и для сложных интерфейсов это спасение. И я даже не сомневаюсь, если бы я внутри констрейна начал городить кучу вложенных лайаутов, то коллеги подошли бы ко мне и начали очень осторожно выспрашивать кто меня так сильно обидел и почему я просто не избил его, а решил прибегнуть к такому изощренному издевательству.
Видимо, мы с вами думаем по разному. Все что угодно можно сделать в констрейнте, но в 80% случаев он не нужен и все проще сделать без него.
Опять вы про сложность. Объясните мне что сложного в том, что бы сцепить начало-конец элемента или верх-низ? Причем можно это делать абсолютно произвольно. Чем это сложнее, чем выстраивать иерархию вложенных друг в друга контейнеров?
Конечно имеет. Но с ConstraintLayout нам объявили, что теперь дробления в пределах экрана нет вообще.
Нет. Нам сказали, что теперь его можно не делать. Но никто ведь не запрещает это делать. Если в этом есть необходимость. Просто зачастую этой необходимости нет.
2-3 лишних парамента в каждом элементе. А стабильность и управляемость не добавляется, а убавляется из-за чрезмерной сложности.
Опять сложность. Вы бусики видели? Тут ведь то же самое. Дикари справляются с этой сложностью, а вам тяжело? Серьезно?
Читал доки. Читал статьи. Так и не понял в чем смысл этим всем мучаться если есть LinearLayout.
Да что уж там. Зачем вообще это все если есть ASM.
При добавлении элемента ничего не ломается, а вот когда вы начинаете менять constraints чтобы вписать этот элемент где-то посередине — все летит в трубу. Да, оно потом чинится, но зачем мучаться, если есть LinearLayout?
Нет. Ничего не ломается. Именно потому LL и не нужен.
Конечно, биднить видимость к 10 вьюхам намного лучше чем к одному лейауту, который хранит все связанные элементы.
Хм. А почему вы выкинули из обсуждения фразу :«пропадать по очереди и перекрашиваться при этом в розовый»? Или это то же слишком сложно? Не знаю как у вас, а у нас обычно реализуют то, что придумал дизайнер и согласовали с заказчиком. И если гибкость уже заложена, то поддерживать проект будет значительно проще. Допустим вы решили все положить в LL. На начальном этапе все работает. А потом вдруг кому-то пришло в светлую голову, что нужно что бы пропадали не все элементы, а 1,2,4 и 7. А во втором ряду при этом сонхронно со 2 пропадал и его второй. И это только в первом случае. Во втором, третьем и четвертом все должно быть совсем по-другому. Вот теперь вам нужно будет все переделать. И если вдруг решат, что все не так, то нужно будет опять все переделать. Вот тогда все и поплывет. Да еще и все попробуй отладить.
А потом, когда вы добавите в группу внутри ConstraintLayout еще 1 элемент и забудете прибиндить видимость — вам тестеры зыведут баг.
А почему только это забуду? Давайте я еще и забуду LiveData проинициализировать. Ну что бы оно еще и рухнуло. Ну и в базу данных данные забуду положить. А еще когда параметр прописывал вписал не от видимости, а от чего-то другого. Да, когда констрейн подключал я еще библиотеку перепутал и старючую альфу вкатил. Я понимаю, что программисты почти всегда идут по положительному сценарию. Но если ты дописал сокрытие элементов, то ведь жмакнешь кнопочку что бы хоть одним глазиком посмотреть как работает. Ну вот не верю, что кто-то вот так неглядя свою работу тестерам передает. И ладно-бы LL был непогрешимым. А так добавили вы элемент и проверили на устройстве с высокой плотностью пикселей. А тестер взял да и проверил на каком-то стареньком или крайне дешевом телефоне. А влазит-то не все. И ведь то же баг заведет.
так как уместно применять каждый из имеющихся инструментов для той цели, с которой он справляется лучше всех. ConstraintLayout справляется почти со всем, но при этом требует намного больше времени для этого и легче ломается при изменениях
Судя по всему ConstraintLayout применять для разметки уместнее всего. Он сочетает в себе гибкость и быстроту. Осталось дело за малым. Вдумчиво прочитать документацию и понять, что проще уже некуда. И во время создания интерфейса немного подумать и не метаться с привязками. И тогда все изменения будут вносится быстро и просто. Ну или продолжать ворчать и обливаться холодным потом когда возникает надобность подправить что-то с существующем констрейне.
Мне кажется, что тут нужно искать золотую середину между вёрсткой в редакторе и в коде.
Олды не используют редактор, потому что раньше он был очень не очень.
Сейчас, как мне кажется, ситуация улучшилась. Его можно использовать для :
- накидывания элементов с обязательными атрибутами,
- выравнивания в Constraint (хотя для меня это было не очевидно до просмотра курса от Google),
- просмотра того, что получилось (не работает со сложными экранами и кастомными view).
При этом, безусловно, нужно всегда проверять, что получилось в xml (это кстати так же рекомендуют в курсе выше). Да и сложные моменты иногда проще сделать в xml.
А еще терпеть не могу, когда сложный UI целиком делают в одном ConstraintLayout.
Если есть такая возможность, почему бы нет? Constraint Layout как раз и придумали для уменьшения вложенности элементов и повышения скорости их обсчёта.
Скорее всего примерно так, как сейчас это происходи в плагине для Android Studio для Flutter.
Можно в коде выделить элемент и нажать кнопочку Обернуть в Padding или Обернуть в Column, и так далее.
Вопрос с визульным редактором для просмотра (хотя бы приблизительно) того, что получилось, довольно интересный. В Flutter говорят — ребята, вам он не нужен, потому что у нас изменения в экране пересобираются за пару секунд, при этом вы остаетесь на том же экране, не нужно каждый раз доходить до него вглубь.
В нативном Android с этим сложнее, потому что и Instant Run намного дольше, и не всегда он работает правильно.
В то же время визуальный просмотр в Android уже достаточно близок к реальности (вкладка Preview). Использовал несколько раз для показа граф.дизайнеру и быстрых правок, прежде чем собрать сборку и показать финальный скриншот.
Wrap {
Padding(30.dp) {
DrawRectangle(color = Color.Cyan)
Text("Drag or tap on the seek bar")
}
}
Возможно. Нужно перепроверить
Если посмотреть на Padding во втором примере, то Padding в Compose то же самое, что Margin в XML, а Padding в XML реализован в Compose через HeightSpacer и WidthSpacer.
Так что, скорее всего, нам нужно обернуть в Padding только Text, чтобы между ним и Rectangle было пространство. Но нужно проверить.
С одной стороны давно понятно, что что-то нужно менять и XML сам по себе не так уж хорош. Но вот что лично мне не нравится, так это разметка UI в коде. Хотя может быть я сам себя накручиваю. В конце-концов сейчас многие раскладывают по папочкам фрагмент, вьюмодел. Ну будет еще один файл там-же лежать с разметкой. Сейчас мы указываем XML, а будем указывать вершину описанной иерархии. В общем нужно сначала дождаться, а потом уже паниковать.
Если взять классический MVP, MVVM, или что-то другое с буквой V внутри, то в качестве этого View мы обычно считаем XML (возможно, с Databinding внутри) + "глупый" фрагмент/активити, которые служат как прослойка между Android OS, XML и платформонезависимым кодом на Java/Kotlin (Presenter, ViewModel, ...).
С декларативным UI у нас будет в слое View тот же фрагмент/активити + классы с @Composableкомпонентами, которые мы кладем внутрь. Кажется, что так даже удобнее.
Ну и положить этот View слой в отдельную папочку (если еще не) для структурированности.
Второе: Когда вы используйте xml для рисовалова экранов, то Android Studio показывает как выглядить конечный экран. И это очень удобно.
А в случае Compose подхода, такое возможно будет гляда просто на Kotlin код?
Нужно что будет, себе представлять как выглядит результат?
Или я ошибаюсь?
Про сложные экраны и замену для Constraint самому очень интересно, как реализуют. Пока её нет, предсказать сложно. Возможно, что-то похожее на Flutter подход. Может, разрешат использовать @Composable внутри Constraint.
Если как в Flutter, то он предоставляет некий конструктор из Material-элементов. И для типичного приложения по Material-гайдлайнам вроде бы достаточно.
Но вот если хочется уникальный дизайн, тут согласен, что как-то сложнее, чем с XML.
Первое впечатление от Android Jetpack Compose