Jetpack Compose - будущее Android UI и убийца Fragment 

0ке

Часть анимаций была значительно упрощена, но вот жду появления MotionLayout для Compose.

@@AndroidBroadcast во во) это была моя первая мысль, что будет с моушн лейаут, ведь штука годная!

@@maksonic_official Основная ее ценность - визуальный редактор анимаций. Без него библиотека просто еще один способ работы с анимацией в Android

@@AndroidBroadcast я всегда моушн сцену создавал через xml, точнее описывал поведение анимации, через дизайн только смотрел как анимация работает) не знал что и через дизайн можно создавать анимации) в любом случае motion layout очень полезная вещь!

Потом и уходить не захочется!

Будет, только надо самому начать туда погружаться

И вам спасибо, что не прошли мимо и оставили комментарий

Его раздавала JB как мерч свои Kotlin User Groupd и на конференциях давали

Костяк инструментов работает без проблем, но есть то что может отставать по продвинутым возможностя. Если вы только начинаете, я рекомендую вам разобраться в старой системе и потом уже браться за новую, но просто потрогать точно стоит чтобы увидеть как поменялась система. P.S. надеюсь вы рады своему выбору Android

Кирилл, спасибо большое за ответ

Да, android класс, хорошо, что увидел ваш канал, приложение под andoid я писал быстрее, чем для ios. Экосистема android мне показалось более понятной и понравилась больше. Еще больше мне нравится идея фулстека, но пока делать решил упор больше на какую-то одну платформу)

Верно. На старте надо окрепнуть в одной технологии и уже затем смотреть по сторонам. Так и проще будет разбираться, особенно если первой технологией получится зарабатывать на жизнь

Стандартные примеры Compose. Ещё посмотри TiVi

Спасибо! просмотрю@@AndroidBroadcast

Малая ниша, поэтому всегда будет так. Со временем придут новые и просмотры вырастут. Спасибо за поддержку

BottomSheet уже поддерживает из коробки, как и диалоги

Можно уже смело тянуть в прод

Я не могу включить монетизацию, так как Google не присылает мне письмо с проверкой физического адреса. Так что грустно ( Да и комиссия там конская - 30% + за вывод. Хочешь поддержать - воспользуйся donate.stream/android_broadcast

100 строк я считаю много. Хочется компактнее, хотя зависит от сложности хореографии элементов

@@AndroidBroadcast возможно можно будет оптимизировать, но все равно гораздо проще чем по старинке ☺️

Как нашел? Знакомые, реклама или поиск ?

Просто рекомендации. Как раз учил фрагменты (я новачок) и тут "Убийца Fragment" 👍

Там не всё так радужно, но самая обычная реализация делается в разы быстрее

1. Ежик с IDшками ушел в туман с распостранением ViewBinding. 2. От чего помимо Presenter, или VM еще должен быть зависим ежик с ID-шками? Если на практике у вас имплементация БЭ влияет на View - возможно, вам стоит освежить в памяти SOLID.

@@backoff6776 Вы абсолютно ничего не поняли. Давайте на примере. Вам нужно показать список фирм-клиентов. Для каждой фирмы дополнительно нужно отображать менеджера со стороны компании и менеджера компании помимо других полей. Так же для каждого из менеджеров нужно получить его состояние на SIP сервере и аватар. Т.е. у клиента есть managerId, а у менеджера есть avatarId. Пользователь приложения в настройках указывает какие поля нужно отображать и в каком порядке для каждого из типов фирм-клиентов. И теперь самое вкусное. Фирм-клиентов десятки тысяч. Как несложно понять загрузить все на телефон это отельная непростая задача. Поэтому это сразу отпадает. Только тотальная динамическая подгрузка маленькими порциями в зависимости от того, что отображается в конкретный момент времени. Любое изменение тут-же приводит к перестроению списка. И если все сделать по-простому, то анимация хорошо если вообще когда-то закончится. А ведь есть еще поиск и фильтрация. Как без них если элементов много? И по хорошему нужно не просто показать то, что нашел, а как-то выделить текст из-за которого сейчас каждый из элементов отображается.

​@@illyaevseev312 , окей, допустим. Не понял, как это: "отображать менеджера со стороны компании и менеджера компании". Я не большой спец в классификации менеджеров. Это очепятка, или два разных человека?) Исходя из задачи, у меня будет несколько задействованных Getaway: - REST сервер - SIP сервер - SPrefs 1. Fragment подписывается на VM. Вот здесь момент: мой это проект, или коммерческий? Если коммерческий - ViewModel будет содержать LiveData, который будет излучать полный(на текущий момент) список клиентов, который с помощью DiffUtils будет скармливаться адаптеру. Так бысттрее. Если это мой проект - я буду играться с обновлением списка сам, т.к. мне не нравится идея сравнивать изменения внутри вью. Во фрагменте к списку прикручена прослушка scrollLIstener. Когда позиция N становится видимой - Fragment дергает вью-модель: loadNext(). Упустим обработку ошибки, лоадера. В VM есть соответствующие LiveData и фрагмент на них подписан. Все. Помимо VM никаких других зависимостей у фрагмента нет. Ну может быть еще фрагмент контейнера, если мы используем SharedLiveData для передачи внешнего VM вложенным вьюшкам. 2. VM имеет зависимость от UseCase(или Repository, или где мы там Bussines Logic обрабатываем), возможно каких-нибудь мапперов и прочей вспомагательной мишуры. В loadClients VM запускает соответстующий UseCase(допустим, у нас UseCase-ы), меняет свое состояние и подписывается на результат. 3. Use case идет на SIPGateway, потом параллельно на REST и в SPrefs. Полученные результаты агрегируются в соответствующий DTO и отправляются, как результат, в обсервер, переданный View-моделью. 4. Вью модель получает опповещение о новой порции данных и обновляет LiveData. Fragment получает новый список и отдает его в адаптер через DiffUtil. Список обновляется. По тому же принципу через соответствующие UseCase ViewModel подписывается на изменения на стороне SIP сервера и изменения настроек в SPrefs. При получении оповещения от них, LiveData так же обновляется, adapter рендерит соответствующий ViewHolder в зависимости от настроек и усттанавливает состояние клиента на SIP сервере. Вроде все. Тут задача скорее объемная, чем сложная. Ах да и аватарка грузиться каким-нибудь Glide, или Picasso. Вот тут возникает та же архитектурная лажа, что c DiffUtil(а именно запрос изображения самой на стороне View, ее кеширование, обработка результата и т.д. в обход бизнесс логики приложения), но опять же.. это реалии дроид разработки. В пет-проекте, я бы отказался от Glide, или пробовал бы использовать его в Geteway, но в коммерческой разработке поступил бы стандартно. Вроде все. Fragment не зависит не от чего кроме VM и утилит типа Glide, DiffUtil, данные во вью обновляются ViewBinding.. Никаких ежиков. Никакихлишних зависимостей кроме вышеупомянутых библиотек. Вроде все. Где я неправ?

@@backoff6776 Ну не поняли о чем я хотел сказать так не поняли.

@@illyaevseev312 , ну да. Видимо я что-то не понял в указанном примере. Потому собсно я и спросил: "где я неправ?". Не вижу связи между описанной задачей и необходимостью клепать елки из ID-шек, или скармливать множество зависимостей фрагменту(активности). ID-шки останутся под капотом ViewBinder, а вью будет зависима только от ViewModel, утилит и, возможно внешней вью-модели контейнера. Какая бы крививая не была реализация БЭ, все необходимые костыли будут спрятаны в реализации Gateway, за фасадом и вью слою будет вообще на них плевать. Сложность агрегирования ответтов от разных серверов и синхронизации запросов будет инкапсулирована в UseCase и тоже закрыта за фасадом: OutPort. В чем собсно беда, которую я не учел?

Это общее движение разработки UI в приложениях, поэтому и языки адаптируются. Как и фреймворки. Задача языка - позволять эффективно решать задачи разработчиков на нем

Думаю достаточно пока актуальна View, а это ещё долгие годы

Если модульность занесена, можно новые фичи на композе пробовать писать

Не так.Java и Kotlin компилируются в байт-код, только kapt генериь Java классы для совместимости с Java Annotation Processing

Jetpck Compose - решение чисто для Android. Compose Multiplatform делает JetBrains и вот это уже угроза Flutter

Мне кажется, что Flutter в ближайшем времени закрывать не собираются, почитайте про фуксию (если фуксия, как система будет жива) . Также у Flutter быстрорастущая комьюнити, так как Dart имеет низкий порог входа, в принципе как и у Flutter. Кроме того, Flutter активно развивается, да достаточно полазить на их канале.

Flutter уже занял свои нишу и растет. Будущее точно есть, но какой объем узнаем только ты будущем

Жду не дождусь уже дать вам возможность заполучить его себе

В первых Beta было ещё не очень, но стал лучше к релизу

MVVM вполне жизнеспособен

в любой момент открыть исходники и изучить 30000 строк вью и наследников с делегатами по цепочке?)) а насчёт кастом вью Кирилл упомянул - все стало только проще

@@dmitriismirnov6769 да, приходилось не раз ковырять исходники когда кастомные вью писал. конечно прям изучить в любой момент не получится, но в иде найти методы, которые тебе нужны и посмотреть логику достаточно легко. чего не скажешь о компиляторе и куче вспомогательных костылей вокруг него.

Даже сейчас можно посмотреть и увидеть как рисуются компоненты, фактически от нас спрятали механизм обновления UI в зависимости от состояния

Все стало лучше, много приложений написали с нуля, а другие перешли. Программисты с кривыми руками всегда жалуются и не хотят ничего не учить

​@@AndroidBroadcast Думаю да, многие не хотят перестраиваться и много староверов с джавой, которых не загонишь на компоуз. И конечно тонны приложений уже готовых нужно поддерживать.

@@Polite_person_ а зачем переписывать с Java если все работает, DI настроен, чистая архитектура грамотно спроектирована? Все приложение оттестировано вдоль и поперек, таски выполняются.... Никакое руководство не даст времени и старт на переписывание. Я в продуктовой компании, вот какие аргументы для менеджера и тех директора предоставить?)

@@zaur4094 Я имел ввиду, что есть кто до сих пор стартует на Java.

Вам не важна скорость разработки даже для одного проекта? Вопрос в том что за единицу времени вы доставите больше фичей пользователю

Да, есть доступ к Canvas и обработки разных событий. Всё компоненты сейчас так сделаны

Зачем думать о Compose только как мультиплатформенном решение для iOS и Android? К SwiftUI те же требования?

Да

В Roadmap поддержка Material You и виджетов один из основных пунктов

Я был молод и неопытен, не судите строго ведь я не профессионал съемки и монтажа

Кто мы? Что за продукт и приложение?

Что именно вы подразумеваете под этим? Интерактивные режим (можно нажимать на кнопки) или статический предпросмотр Compostable функций?

Я не поучаствовал проблем со статикой в превью, а вот интерактивный режим ещё требует доработки

По статистике GP уже мало смысла имеет поддерживать что-то ниже 6.0

@@AndroidBroadcast Согласен, не думаю что остались люди использующие андроид

Взлетит отлично - код станет проще и понятнее.

Я попробовал его немного, но планирую писать на нём полностью проект и показывать вам результаты

Да, жду Mac на ARM и вкачать туда 32 гига оперативывы

Какие критерии принятия решения в прод?

@@AndroidBroadcast как минимум сейчас не найдешь специалистов на рынке, которые уже умеют в компоуз. То есть уже надо людям дать время на изучение. Дальше - это всякие тулзы и апдейты. Я уверен, что хоть глобальных изменений в компоузе уже не будет, но всё же куча мелочей еще изменится. Ну и компоух хоть и релизнулся, но тот же констрейнт с ним еще не в релизе. Так что по моим планам - до следующего лета я на компоуз не перейду. PS. Попробовал немного компоуз в пет проекте - много вопросов по читабильности кода. В гитхабе смотришь примеры проектов и вообще не понимаешь что сверстано на экране. Приходится грузить проект и в студии в превью уже смотреть.

В чём именно выражает недоверие к Google?

Я не планировал возвращаться работать в программирование. В Surf я занимаюсь тех. пиаром и это вынужденный компромисс из-за интересной задачи в компании для меня как специалиста по личному бренду, так и финансова сторона вопроса играет важную роль.

Плюс Compose - это отдельная библиотека и не привязки к релизу платформы. Исправление багов и улучшений доставляются всем

@@AndroidBroadcast Спасибо за информацию

Да и вообще что такое нативное? Для меня нативное - это то, что оптимизируется и затачивается под определенную платформу для большего быстродействия и стабильности. Т.е. флаттер не нативный, т.к. он про многоплатформенность и разработчикам приходится искать компромиссы. А вот компоуз вроде пока не лезет в другие платформы, значит затачивается чисто под андроид и является нативным. Или я не прав?

По мне нативный - это Android View, которые часть системы. Вот Compose повторяет их внешний вид и где-то расходится

Compose - официально мультиплатформенное решение, поддерживающее Desktop, Android, Web

Программирование всегда было про то что постоянно надо учиться, расширять взгляды и применять новые популярные подходы

@@AndroidBroadcast В этом то и дело что не успеваешь применять одного, появляется другой, получается тратишь время на так называемые deprecated features начать с новыми сложно, так как не хватает материала или они находятся в бета версия

Меняется все не так быстро, новые подходы внедряются постепенно, а такие технологии как Compose выходят редко, интегрируются неспешно и живут очень долго

Для огромных Dagger - проблема из-за кодогенрации. Там ручной DI

@@AndroidBroadcast понял, спасибо) кстати, то ли это ютуб баганул, то ли у меня что-то случилось, но коммент должен был быть в видео про DI(почему вы с Koina перешел на другую библиотеку).. странненько) а видос про компоуз в планах на сегодня был ахах. Но еще раз спасибо за ответ :))

Все также есть различные Layout, можно реализовать собственный виджет через Compose, где будет своя отрисовка, обработка событий и прочее. Также можно сделать свой Layout

@@AndroidBroadcast ого супер, честно сказать я не нашёл расширенных туториалов, везде только и показывают как helloworld вбить, спасибо за ответ

На сайте Google много документации, примеры в GitHub, видео и Codelab

@@AndroidBroadcast спасибо, а как на счет паттренов проектирования? mvp mvvm с композом как работает? как вьюшки подписываются на viewModel? Я начал писать HelloWorld на компосе и уже ощутил всю силу и превосходства, но я себя чувствую утенком среди акул

@@putinstop5940 Надо просто освоиться с новой идеологией вокруг состояния и всё сойдется

Это эволюция. Одни технологии уходят, другие приходят им на замену. Вы можете придерживаться старых принципов, но рынок и выгода бизнеса помешают за вас. Вполне возможно, на работе вы пишите на Kotlin, потому что за Android разработку на Java уже не готовы платить, или не меняете работу, просто потому что "хочу быть на Java"

Нет, они точно еще будут в разработке долго, так как они плотно осели в кодовой базе за 10 лет ) Больше чем RxJava даже, так что не переживайте. В новых приложениях подход начнет отмирать, но пока он живее всех живых!

Compose не имеет отношение к View и по другому всё отрисовывает. Никто не мешает вам также организовать отдельные Kotlin файлы и там делать только UI. Рекомендую попробовать и тогда поймёте в чём разница, если весь доклад воспринялся скепсисом

теоретически конечно эти сгруппированные вью тоже являются подвидом кастом вью, и у них есть название - Compound Controls, но если сравнивать по сложности разработки, да, компаунды на уровне детсада ;)

Мир Custom View огромен )

Потому что Flutter мне не нравится и как видишь практически 8000 тыс людей тоже смотрят что я делаю

@@AndroidBroadcast сделай видео почему не нравится флаттер и почему тебе нравится ждать компиляцию 2мин и не нравится хотрелоад))

Раньше хватались декларативным UI и hot reload. Первое пропало. Что будете делать когда и второго не станет? Если разработка хватает тем что их приложение можно быстрее пересобрать, то что-то вы не то делаете

java проекты это вымирающие динозавры, которые застряли в прошлом из-за чего упорства или упрямства не хотят идти вперёд. Проекты на основе AOSP не считаются

@@AndroidBroadcast а как же телеграм? Отлично работает, руки растут у людей из правильного места

Это тоже исключение из правил. Самое обидное что разработчики Telegram отказываются пообщаться про свои технологии и рассказать почему так.

@@AndroidBroadcast попробуй найти Григория клюшникова, он разработчик ВК бывший и телеги. Я с ним общался. Может прольет свет. Но как мне показалось он сам по хардкору - бизнес логика во фрагментах итд. А ответ Я думаю простой - просто так быстрее разработать приложение. Если над ним работает 2-5 человек, то легко будет разобраться что к чему и не нужны все эти дополнительные слои абстракции, обертки, инфекции зависимостей итд - это по сути инфраструктура и она не имеет отношения к фичам. Иногда код в виде простыни реально легче и быстрее понять когда он в одном файле)

Гришу знаю по чатам. Он ярый писец только на Android SDK и никаких Jetpack. Тоже отказывается давать интервью. Но тут возможно я такой ещё человек что со мной говорить не хотят

Даже с XML нужно было делатт, чтобы увидеть виджеты не из Android SDK. Compose - это не альтернатива XML. ,Это совсем другой принцип показа UI, но никто не мешает остаться на XML

Обязательно будут, а пока кинул все силы на восстановление моего голоса. Пока не могу записывать ролики вовсе