очень полезное видео было, спасибоо) хотелось поставить больше, чем один лайк. Хоть я и считаю себя относительно опытным разработчиком, но узнал для себя море нового
Очень информативный выпуск, узнал много нового, спасибо. На ролике с собесом ты сказал что-то вроде по поводу ui, что неопытный накидает несколько лэйаутов, а не сделает всё в один уровень, что-то подобноее, могу ошибаться, было бы вообще классно узнать побольше о том как правильно верстать и хорошие практики
Спасибо за видео! Хорошая подача, кратко и по делу по основному функционалу. В будущем хотелось бы увидеть уроки по оптимизации «тяжелых» списков, например, ленты социальной сети. И отдельно пожелание на урок по анимациям. Сейчас разбираться с ними очень неудобно, много частностей и классов для этого
@@AndroidBroadcast бейз лайны знал, но как-то активно не юзал (забываю постоянно), а вот всё что связано с динамикой вьюшек (constraint gone параметры) было прям открытием)
Как мне кажется, то на просторах рунета не хватает такого качественного и понятного контента про андроид разработку. Если бы ты какие-то курсы выпустил, я даже подумал бы о покупке такого курса.
Спасибо. Я буду выпускать серию видео на канале, к которым можно будет получать доступ значительно раньше других. Все это происходит через донаты на Boosty (ссылочка в описании)
Нереальное видео! Так сжато, по делу и без воды я еще не видел!) все супер, а как быть с ID актерами 19:28 ведь по идеи они должны прилетать динамически? задавать их программно?
Ля ты пухляш был два года назад. Молодец, что работаешь над собой! Я посмотрев видео, пришёл к выводу, что к пониманию того, о чём ты говоришь сегодня, я приду спустя то время, что ты шёл по своему пути в истории видеороликов ;) Короче еще не скоро :D
Всю круто, хорошо прошёлся по основным фичам. Единственное хотел бы отметить про Group, из опыта для видимости его лучше не применять, по сколько человек, который смотрит первый раз этот экран и не знает что есть группа, может пытаться изменить видимость одной View, которая в группе и у него это не получится. Так же не плохо было бы отменить про список актёров, что правильно это делать через Recycler, по сколько явно при разных данных будет разное количество актёров.
Знал и использовал все фишки из видео. Не упомянули в видео про возможность задавать соотношение сторон у view в constraint layout'e и возможность располагать view под углом относительно друг друга.
goneMargin и Flow было новым. А про group могу сказать, что если нужно будет работать в невидимостью с отдельными вьюхами внутри группы, то не получится. видизибили группы имеет приоритет.
Отличное видео с хорошими примерами. Единственное хотелось бы поправить, что baseline не только у TextView, а у View класса. То есть любое View можно выравнивать по baseline. У View есть метод на строке c небольшим номером №25341 - getBaseline().
О хотел как раз узнать подробнее про констрейнт и тут коротко о главном))) Некоторые вещи для себя подчеркнул. Но с отступами, я бы не создавал группу для отступов, что то подсказывает, что обычный marginStart отработает быстрее Guideline если я ошибаюсь, то был бы рад узнать об этом, гуглить влом xD Но по логике это привязка + все равно остается Margin 0, - привязка и все. А для этих целей завожу base_margin = 16dp
лучше бы показывал новичкам, что отступы хорошо бы не не хардкодить , а через ресурсы юзать, захочешь ты их на 3 дюймовых экранах поменьше сделать, что бы площадь полезная чуть больше была. и вместо 3х минут, в сложных вьюхах час будет переделывать
Слушай, по поводу актёров. Очевидно же, что они берутся из какой-то DB (раз андроид, значит SQLite в стандартной обёртке Room), и для каждого нового фильма будут обновляться, т.к. из будет больше/меньше. Ты же указал их статикой. И я понимаю, что мы можем в коде переписать .flow_referenced_id на интересующее, но... если задача включает постановку элементов больших, чем просто текст, разве для этого не нужен recycleView?
Это поддержка Right to Left - языков где написание происходит ни как в русском слева направо, а наоборот. Left, right будут всегда размещаться слева и справа соответственно, независимо от правил написания в локале. А вот start, end будут реагировать и менять расположение элементов UI Рекомендуется использовать именно start, end везде: отступы, паддинги, размещение, картинки и прочее
отличное видео, только заставка громкая на 3:37 ты говоришь что нужно обязательно указать горизонтальный констрейнт, но разве есть в этом смысл если ширина view на весь parent? имеет ли это какое то значение сейчас, или это просто на случай если нужно будет что доделывать? чем match_constraint 0dp лучше match_parent в случае если мне надо вью растянуть с начала до конца parent?
Указание constraint не является жестким требованием, но не использовать match_parent и указывать горизонтальный и вертикальный constraint избавит вас от ошибок, на которые я и другие разработчики успели убить в свое время по несколько часов своей работы.
Вопрос (в начале 7-й минуты примерно): почему, когда указываешь относительно какого объекта размещаться (типа app:layout_constraintEnd_toEndOf="@id/banner"), Студия по умолчанию предлагает влепить плюс между @ и id и почему его оставлять там опасно? Чем именно опасно, ведь с плюсом тоже работает?
Хороший разбор, спасибо. Интересно как это будет выглядеть при повороте экрана и как это все подгоняется после вертикальной верстки? Или такие дизайны обычно подразумевают отсутствие альбомной ориентации?
Правильно ли говорят, если в Constraint Layout использовать другие вью группы (к примеру Linear Layout и т.д.), то это отрицательно влияет на производительность прилы?
если вьюха не слишком сложная, то одна вложенность ничего визуально не изменит. и сильно завист от задач, например всякие include , которые используются в разных экранах итд.
Не думаю что такое в обозримом будущем появится на канале. На эту тему рекомендую посмотреть доклад от Chet Haase ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-pMZmDBwjQvQ.html
Классное видео, спасибо. Можно ещё добавить, что эти операции можно выполнять во вкладке Design, не всегда это удобно и понятно, но например перетащить constraint к границе экрана можно. Также ещё по своему опыту знаю, что не все знают основные хоткеи в студии, а в видео часто они используются. В свое время на столе лежала распечатанная таблица от Jetbrains. Вот тут можно скачать pdf под все OS resources.jetbrains.com/storage/products/intellij-idea/docs/IntelliJIDEA_ReferenceCard.pdf
ну количество актеров может динамически меняться в зависимости от фильма для такого экрана, может там юзать что то типа recycler view или тут был использован flow чисто для примера что есть такой хелпер, из кода есть в него возможность динамически сетить актеров? как в таких случаях лучше делать?
Я говорил что это пример для демонстрации возможности. В реальной задаче лучше использовать RecyclerView, но если количество актеров на экране фиксированное то вполне можно и добавить все эти View динамически. RecyclerView лучше использовать при очень большом количестве элементов либо когда они тяжелые и нужно их переиспользовать.
@@AndroidBroadcast аа ну сорри, не услышал, я просто ни разу им не пользовался, а после просмотра решил поиграть с ним иии так и не придумал, где бы я его смог использовать))) Кстати FlexboxLayout делает то же самое и даже с теми же самыми параметрами, только он при этом полноценный Layout.. ```implementation 'com.google.android:flexbox:2.0.1'```
Я выбрал такой макет, чтобы продемонстрировать на нём все возможности и сделать это компактно по времени. Боюсь с более сложным layout мог убить много времени и все бы превратилось в кашу.
Интересный подход с Flow, странно что он не работает как ViewGroup, т.е. вьюшки находятся рядом, а не в нём. Не сбивает ли это с толку? Видим вьюшку в xml, а правил размещения у нее нет, т.к. за это отвечает Flow. Что насчёт best практик в этом случае? Сначала flow, а следом вьюхи которые он содержит или наоборот? Ещё не нравится ConstraintLayout из-за необходимости иметь id, которые нужны только для позиционирования других вьюх, в итоге если на экране много TextView, которые не нужны в коде, получаем textView1, textView2, textViewN. Тут ещё стоит вспомнить про особенность студии, когда при попытке рефакторинга id вьюхи в одном xml, он меняется во всех. ИМХО стоит добавить псевдо id, который виден в разметке, но недоступен в коде, в т.ч. в ViewBinding.
@@AndroidBroadcast Добавление Актёров наверно лучше сделать через какой-нибудь лист с адаптером, т.к. в коде будет некрасиво: создай view, вставь LayoutParams, сделай generateId(), добавь view сначала в layout, а уже потом во Flow. Это в целом и так понятно, ведь основная цель видео показать возможности contraintLayout, но стало интересно, как решить эту задачу правильно? Я джун и мне в голову ничего кроме RecycleView со своим layoutManager'ом не пришло. Но сам recycling нам вроде бы не нужен...
Не совсем понял в чём прикол Guidelines, ведь кода стало только больше, но ничего не поменялось (если правильно понял). Ещё не понял что имелось в виду под "реализацией сложных UI через собственный View", что может быть эффективней ConstraintLayout.
Guidelines позволяют выравнивать несколько элементов сразу, причем делать это можно не только как padding контейнера, а в процентах. Удобство и не больше
Раньше чтобы делать сложные UI без вложений могли прибегать к созданию собственной, View. ConstraintLayout дал возможность создавать сложные экраны без вложенности, но по производительности он не лучший
