🔗 Avito.Tech avito.tech/ 💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast 🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
@@AndroidBroadcast я всегда моушн сцену создавал через xml, точнее описывал поведение анимации, через дизайн только смотрел как анимация работает) не знал что и через дизайн можно создавать анимации) в любом случае motion layout очень полезная вещь!
Комментарий в поддержку канала Поставил в своём проетке api 21 (повысил с 16 версии) и теперь пробую Compose для простых экранов, пока что очень нравится.
Видео зацепило названием. Хоть сразу и было понятно, что у этого убийцы пока силенок маловато что бы просто заменить все, что уже есть, но все-же любопытство взяло верх. Лично мне Compose импонирует. Даже несмотря на все имеющиеся косяки на сегодняшний день. Да и простота того же lazyColumn подкупает. И на простых примерах все работает отлично. Но как часто мы сталкивается с простыми случаями? Обычно это ежик с id-шниками, в который входят другие ежики со своими зависимостями и все это нужно динамически подгружать. И хорошо если с бэкэндом все замечательно. А если нет? И вот тут уже простой пример вдруг превращается в не очень-то и понятного монстра. И, заметьте, это не самый сложный случай.
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.. Никаких ежиков. Никакихлишних зависимостей кроме вышеупомянутых библиотек. Вроде все. Где я неправ?
@@illyaevseev312 , ну да. Видимо я что-то не понял в указанном примере. Потому собсно я и спросил: "где я неправ?". Не вижу связи между описанной задачей и необходимостью клепать елки из ID-шек, или скармливать множество зависимостей фрагменту(активности). ID-шки останутся под капотом ViewBinder, а вью будет зависима только от ViewModel, утилит и, возможно внешней вью-модели контейнера. Какая бы крививая не была реализация БЭ, все необходимые костыли будут спрятаны в реализации Gateway, за фасадом и вью слою будет вообще на них плевать. Сложность агрегирования ответтов от разных серверов и синхронизации запросов будет инкапсулирована в UseCase и тоже закрыта за фасадом: OutPort. В чем собсно беда, которую я не учел?
А что с Flutter? Пишу на нем больше года, все устраивает кроме запоздалых обновлений UI виджетов. С выходом Compose задумался, стоит ли полностью перейти с Flutter на него. Flutter - тоже проект Гугла, получается некая конкуренция внутри компании. Есть страх, что Flutter закроют и сосредоточатся на Compose. Есть мысли на этот счёт?
Мне кажется, что Flutter в ближайшем времени закрывать не собираются, почитайте про фуксию (если фуксия, как система будет жива) . Также у Flutter быстрорастущая комьюнити, так как Dart имеет низкий порог входа, в принципе как и у Flutter. Кроме того, Flutter активно развивается, да достаточно полазить на их канале.
Что по кнопке платного комментария? Почему на твоём канале её нет? Хочется протестировать её на твоём канале. Про бусти, патреоны знаю, но я хочу кнопку.
Я не могу включить монетизацию, так как Google не присылает мне письмо с проверкой физического адреса. Так что грустно ( Да и комиссия там конская - 30% + за вывод. Хочешь поддержать - воспользуйся donate.stream/android_broadcast
Спасибо большое за работу, благодаря Вам в первую очередь обратил внимание на android. Написал первое приложения на классическом view, если так можно выразиться. Подскажите, если не затруднит, извините заранее за возможно нубский вопрос. На compose уже можно смело писать приложения для android ? Я имею ввиду нет ли проблем корректной работой compose с другими инструментами экосистемы Аndroid, или может есть подводные камни ? Из видео мне лично показалось, что это уже по настоящему production решение.
Костяк инструментов работает без проблем, но есть то что может отставать по продвинутым возможностя. Если вы только начинаете, я рекомендую вам разобраться в старой системе и потом уже браться за новую, но просто потрогать точно стоит чтобы увидеть как поменялась система. P.S. надеюсь вы рады своему выбору Android
Да, android класс, хорошо, что увидел ваш канал, приложение под andoid я писал быстрее, чем для ios. Экосистема android мне показалось более понятной и понравилась больше. Еще больше мне нравится идея фулстека, но пока делать решил упор больше на какую-то одну платформу)
Верно. На старте надо окрепнуть в одной технологии и уже затем смотреть по сторонам. Так и проще будет разбираться, особенно если первой технологией получится зарабатывать на жизнь
Так то xml это максимальная декларативность - там надо потрудится чтобы всунуть императив. Пример с каунтером как я понял так же "устанавливает атрибуту text тек значение каунтера" или это не изменение стейта, а своего рода связывание? То что из коробки можно прям в ide "тестить" представление в связке с логикой(обработки событий) скорее всего останется невостребованной так как это тестирование сломается на первом же обращении к серверу или каком то композите который включает в себя чуть больше чем 1 текстовое поле и 2 кнопки. разрабы чаще всего будут продолжать "экономить" на создании инструментов тестирования разрабатываемого функционала чтобы при разработке можно было в несколько инструкций создавать фейковые состояния для проверки своего представления(под разные разрешения, с в разных позициях и прочее)... Кто вот прям сейчас работая в "паттерне" mvvm мешает создать тестовый билдер для подделки контракта viewmodel и проверить в досконально все интересующие вариации рендеринга разрабатываемой view? При этом технической проблемы в этом нет - сама студия как раз отлично этим пользуется для первичного превью при создании так надоевшего xml. Так же никто не мешает прям сейчас сделать фейковые реализации всяких репозиториев и прочего DAL, с удобным API первичной инициализации оптимизированного под удобную инициализацию тестовыми данными. Это даст возможность не переходя на специальные технологии оттестить в изолированном окружении вьюху вместе с состоянием презентационного слоя(view + viewmodel). те самые щелчки на + и -, только не прям из idea, а запустив разрабатываемое activity в фейковыми зависимостями. Но полагаю что все эти возможности остаются только в виде потенциальных из-за "экономии". ведь зачем писать лишний код, его же надо поддерживать, а у нас не такое сложное приложение, и времени на это нет - нам бы очередную фичу запилить нащелкивая в ui и в лучшем случае постоянно подкручивая заглушки в какой нить WireMock, SoapUI или своего очень обобщённого велосипеда
Спасибо за ваши видео Кирилл - интересно\полезно! Может подскажете - какой ни будь (лучше какие то) хороший средне\большой проект с открытым исходным кодом где вью на Compose. Очень интересно как влияет на архитектуру, какую делают структуру каталогов… Также если бы было с удовольствием посмотрел бы видео с разбором
На мой взгляд слишком похожий на react Composable - это компонент который рисует ui Можно пасавать пропсы между компонентами У каждого компонента свой стейт или общий у родителя Ну блин язык Kotlin а дальше react =) Круто, и автору огромное спасибо!
Это общее движение разработки UI в приложениях, поэтому и языки адаптируются. Как и фреймворки. Задача языка - позволять эффективно решать задачи разработчиков на нем
Как по мне, компоуз ещё сыроват, хотя на реддите говорят что уже используют в продакшене. Список строится круто (Про repeat, кстати, не знал, делал через for), но когда я его трогал мне показалось, что он подлагивал. Из плюшек - стики хидер из коробки. Ну и теперь нам нужна новая архитектура, новые подходы, новый способ взаимодействия с DI фреймворками, нужен ли нам теперь ViewModel в принципе и т.д.
если я правильно понял то котлин это просто "обёртка" для явы? код на котлине преобразуется в код на яве и выполняется? нафига оно надо, не проще ли без посредников обойтись..
меня очень сильно смущает все эти магические аннотации в котлине... да сам по себе view очень жирный класс, но зато я в любой момент могу открыть исходники и понять , что там и как работает. это касается и короутин. не нравится мне эта тенденция... в любом случае кастомные вью писать надо будет всегда, и насколько легко (и вообще возможно ли??) это сделать на компоуз? очень много вопросов.
в любой момент открыть исходники и изучить 30000 строк вью и наследников с делегатами по цепочке?)) а насчёт кастом вью Кирилл упомянул - все стало только проще
@@dmitriismirnov6769 да, приходилось не раз ковырять исходники когда кастомные вью писал. конечно прям изучить в любой момент не получится, но в иде найти методы, которые тебе нужны и посмотреть логику достаточно легко. чего не скажешь о компиляторе и куче вспомогательных костылей вокруг него.
У меня вопрос насчет существующего приложения, хотелось бы новые экраны уже описывать компосом, прочитал что есть MdcTheme, вопрос как долго он будет существовать и поддерживаться? У нас проект крупный, и быстро перевести все невозможно
Как я понял compose актуален для тех, кто массово разрабатывает прилы на аутсорсе (скорость разработки). А если я работаю над одним проектом, какой в нем смысл?
С момента выхода видео прошло немало времени, что думаешь о компоуз сейчас? На сколько он стал востребован, на сколько стал стабильнее и много ли проблем еще нужно решить? По моим личным опросам, кто-то пробует переписывать отдельные экраны на него, но никто не стартует с ним с нуля. Создается ощущения что сейчас в 2023 он еще сыроват, а все хотят стабильности, и судя по вакансиям спроса на эту технологию на рынке практически нет, но всем интересно.
@@AndroidBroadcast Думаю да, многие не хотят перестраиваться и много староверов с джавой, которых не загонишь на компоуз. И конечно тонны приложений уже готовых нужно поддерживать.
@@Polite_person_ а зачем переписывать с Java если все работает, DI настроен, чистая архитектура грамотно спроектирована? Все приложение оттестировано вдоль и поперек, таски выполняются.... Никакое руководство не даст времени и старт на переписывание. Я в продуктовой компании, вот какие аргументы для менеджера и тех директора предоставить?)
Я не планировал возвращаться работать в программирование. В Surf я занимаюсь тех. пиаром и это вынужденный компромисс из-за интересной задачи в компании для меня как специалиста по личному бренду, так и финансова сторона вопроса играет важную роль.
Для меня кастом вью, о котором говорит Кирилл в этом видео - это что-то свое полностью нарисованное на канвасе. Таких вьюшек я очень много написал, довольно сложных (можно сказать, хобби у меня такое). Но я-то думал, что люди это и имеют в виду, и тоже удивился, что так много народу этим занимается. А когда узнал, что под кастомом больше понимается просто какие-то стандартные вью, сгруппированные под свои какие-то правила - ну это детский сад, а не кастом вью)
теоретически конечно эти сгруппированные вью тоже являются подвидом кастом вью, и у них есть название - Compound Controls, но если сравнивать по сложности разработки, да, компаунды на уровне детсада ;)
Да и вообще что такое нативное? Для меня нативное - это то, что оптимизируется и затачивается под определенную платформу для большего быстродействия и стабильности. Т.е. флаттер не нативный, т.к. он про многоплатформенность и разработчикам приходится искать компромиссы. А вот компоуз вроде пока не лезет в другие платформы, значит затачивается чисто под андроид и является нативным. Или я не прав?
Не знаю как будет с гуглом, но с эплом я попал в задницу с их свифтюай. Много багов, которые появлялись когда юзер обновлял айос. С каждым выходом новой версии айос мне приходилось в горячке быстро создавать кучу костылей. После этого вернулся к сторибордам и пока не желею. Сырой еще свифтюай. Теперь боюсь использовать компоуз. Подожду еще годика 3...
@@AndroidBroadcast понял, спасибо) кстати, то ли это ютуб баганул, то ли у меня что-то случилось, но коммент должен был быть в видео про DI(почему вы с Koina перешел на другую библиотеку).. странненько) а видос про компоуз в планах на сегодня был ахах. Но еще раз спасибо за ответ :))
как по мне, то еще рано в прод заводить компоуз. Может разве что какие-то отдельные скрины, но полностью пилить апку на компоузе я бы не рисковал прямо сейчас. Периодически мониторю примеры приложений на компоузе и очень всё неаккуратно написано. Нету каких-то красивых подходов. Потому подожду еще наверное годик, пока всё устаканится. А если в нынешнем виде так и останется, то уж лучше компоуз вообще не взлетел.
@@AndroidBroadcast как минимум сейчас не найдешь специалистов на рынке, которые уже умеют в компоуз. То есть уже надо людям дать время на изучение. Дальше - это всякие тулзы и апдейты. Я уверен, что хоть глобальных изменений в компоузе уже не будет, но всё же куча мелочей еще изменится. Ну и компоух хоть и релизнулся, но тот же констрейнт с ним еще не в релизе. Так что по моим планам - до следующего лета я на компоуз не перейду. PS. Попробовал немного компоуз в пет проекте - много вопросов по читабильности кода. В гитхабе смотришь примеры проектов и вообще не понимаешь что сверстано на экране. Приходится грузить проект и в студии в превью уже смотреть.
Кирилл, большое спасибо! К Compose присматривался давно, после просмотра этого видео сразу, вот прямо сейчас, опробую его в пет проекте. Есть, конечно, вопросы/сомнения, как это взлетит на сложных списках со множественными типами айтемов, а также придется еще перенастроить мозги в плане отказа от фрагментов (SingleActivity, Navigation), может ты уже опробовал на практике подобное решение?
Очень плачевно что нет и не будет, скорей всего, поддержки для явы. Можешь сказать, что и "слава богу" =) но есть много людей, которые недолюбливают котлин, в их числе я. Поигрались с другом с компоусом - пока что сыровато, в большие проекты внедрять рановато, читается код, как по мне, непривычно. Время покажет. Огромное спасибо за контент! Много чего нового подчерпываю от тебя
Это эволюция. Одни технологии уходят, другие приходят им на замену. Вы можете придерживаться старых принципов, но рынок и выгода бизнеса помешают за вас. Вполне возможно, на работе вы пишите на Kotlin, потому что за Android разработку на Java уже не готовы платить, или не меняете работу, просто потому что "хочу быть на Java"
Все также есть различные Layout, можно реализовать собственный виджет через Compose, где будет своя отрисовка, обработка событий и прочее. Также можно сделать свой Layout
@@AndroidBroadcast спасибо, а как на счет паттренов проектирования? mvp mvvm с композом как работает? как вьюшки подписываются на viewModel? Я начал писать HelloWorld на компосе и уже ощутил всю силу и превосходства, но я себя чувствую утенком среди акул
@@AndroidBroadcast В этом то и дело что не успеваешь применять одного, появляется другой, получается тратишь время на так называемые deprecated features начать с новыми сложно, так как не хватает материала или они находятся в бета версия
Меняется все не так быстро, новые подходы внедряются постепенно, а такие технологии как Compose выходят редко, интегрируются неспешно и живут очень долго
Очень сомнительная технология этот Compose. За его интеграцию в КММ однозначно лайк. Но есть много непонятного лично для меня. Хоть убей но ничего принципиально нового, кроме как асинхронщины в построении UI и новых не нативных + сырых View элементов я там не вижу. Точно так же как в Compose только без него и без HotReload можно было всегда строить экраны в коде. Разница лишь в кол-ве кода. Compose даёт удобные обёртки для этого. Убийца фрагментов ? Я наверно что-то не понимаю но фрагмент это не только кучка группированных вьюшек но ещё и масса логики в рамках конкретной задачи, которая задаёт алгоритм поведения для их всех. Поведение ведь так же нуждается в декомпозиции, разбиении на микрозадачи. Этот код нужно где-то прописывать. Как в Compose правильно прописать всю UI логику для "фрагмента" ? Я не пробовал Compose ещё но базируясь на первом впечатлении с обзоров - используя Compose мы просто начнём засирать код. Раньше у нас была отдельно вёрстка UI и отдельно UI логика (DataBinding не рассматриваем). А в Compose всё будет слито в один файл. Да, мы можем выносить общую логику в отдельные файлы но это не избавляет от увеличения кол-ва кода в файле Activity/Fragment. Про композитные View так же довольно сомнительно. ничто нам раньше не мешало сделать код аля viewBinding.root.addView( TextView(context).apply{ text = getString(R.id.some_text) //Other attrs... } ) Я в этом деле ещё не разбираюсь. Если написал что-то глупое - прошу меня простить. Просто есть масса вопросов ответы на которые нагуглить мешает моя лень программиста. А тут прям идеальное место, что бы найти их все разом в качестве ответа на мой комментарий.
Compose не имеет отношение к View и по другому всё отрисовывает. Никто не мешает вам также организовать отдельные Kotlin файлы и там делать только UI. Рекомендую попробовать и тогда поймёте в чём разница, если весь доклад воспринялся скепсисом
Нет, они точно еще будут в разработке долго, так как они плотно осели в кодовой базе за 10 лет ) Больше чем RxJava даже, так что не переживайте. В новых приложениях подход начнет отмирать, но пока он живее всех живых!
Раньше хватались декларативным UI и hot reload. Первое пропало. Что будете делать когда и второго не станет? Если разработка хватает тем что их приложение можно быстрее пересобрать, то что-то вы не то делаете
java проекты это вымирающие динозавры, которые застряли в прошлом из-за чего упорства или упрямства не хотят идти вперёд. Проекты на основе AOSP не считаются
@@AndroidBroadcast попробуй найти Григория клюшникова, он разработчик ВК бывший и телеги. Я с ним общался. Может прольет свет. Но как мне показалось он сам по хардкору - бизнес логика во фрагментах итд. А ответ Я думаю простой - просто так быстрее разработать приложение. Если над ним работает 2-5 человек, то легко будет разобраться что к чему и не нужны все эти дополнительные слои абстракции, обертки, инфекции зависимостей итд - это по сути инфраструктура и она не имеет отношения к фичам. Иногда код в виде простыни реально легче и быстрее понять когда он в одном файле)
Гришу знаю по чатам. Он ярый писец только на Android SDK и никаких Jetpack. Тоже отказывается давать интервью. Но тут возможно я такой ещё человек что со мной говорить не хотят
Раздражает бешеный фанатизм. Раньше у нас был xml в котором мы декларировали , теперь делаем тоже в compose но чтобы увидеть изменения нужно билдить , просерать время ....
Даже с XML нужно было делатт, чтобы увидеть виджеты не из Android SDK. Compose - это не альтернатива XML. ,Это совсем другой принцип показа UI, но никто не мешает остаться на XML
🔗 Avito.Tech avito.tech/
💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
0ке
Дождался) Жду гайдов. Особенно интересно как анимировать все. Спасибо!
Часть анимаций была значительно упрощена, но вот жду появления MotionLayout для Compose.
@@AndroidBroadcast во во) это была моя первая мысль, что будет с моушн лейаут, ведь штука годная!
@@maksonic_official Основная ее ценность - визуальный редактор анимаций. Без него библиотека просто еще один способ работы с анимацией в Android
@@AndroidBroadcast я всегда моушн сцену создавал через xml, точнее описывал поведение анимации, через дизайн только смотрел как анимация работает) не знал что и через дизайн можно создавать анимации) в любом случае motion layout очень полезная вещь!
Комментарий в поддержку канала
Поставил в своём проетке api 21 (повысил с 16 версии) и теперь пробую Compose для простых экранов, пока что очень нравится.
Потом и уходить не захочется!
Видео зацепило названием. Хоть сразу и было понятно, что у этого убийцы пока силенок маловато что бы просто заменить все, что уже есть, но все-же любопытство взяло верх. Лично мне Compose импонирует. Даже несмотря на все имеющиеся косяки на сегодняшний день. Да и простота того же lazyColumn подкупает. И на простых примерах все работает отлично. Но как часто мы сталкивается с простыми случаями? Обычно это ежик с id-шниками, в который входят другие ежики со своими зависимостями и все это нужно динамически подгружать. И хорошо если с бэкэндом все замечательно. А если нет? И вот тут уже простой пример вдруг превращается в не очень-то и понятного монстра. И, заметьте, это не самый сложный случай.
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. В чем собсно беда, которую я не учел?
Про Recycler мега круто
Там не всё так радужно, но самая обычная реализация делается в разы быстрее
На новом проекте начали использовать Compose. Это можно сравнить как пересесть с Java на Kotlin. Прикольные анимации можно делать в 100 строк кода )
100 строк я считаю много. Хочется компактнее, хотя зависит от сложности хореографии элементов
@@AndroidBroadcast возможно можно будет оптимизировать, но все равно гораздо проще чем по старинке ☺️
Как всегда круто и максимально информативно! Спасибо!
Через годик можно будет пробовать:)
Можно уже смело тянуть в прод
А что с Flutter? Пишу на нем больше года, все устраивает кроме запоздалых обновлений UI виджетов. С выходом Compose задумался, стоит ли полностью перейти с Flutter на него. Flutter - тоже проект Гугла, получается некая конкуренция внутри компании. Есть страх, что Flutter закроют и сосредоточатся на Compose. Есть мысли на этот счёт?
Jetpck Compose - решение чисто для Android. Compose Multiplatform делает JetBrains и вот это уже угроза Flutter
Мне кажется, что Flutter в ближайшем времени закрывать не собираются, почитайте про фуксию (если фуксия, как система будет жива) . Также у Flutter быстрорастущая комьюнити, так как Dart имеет низкий порог входа, в принципе как и у Flutter. Кроме того, Flutter активно развивается, да достаточно полазить на их канале.
Flutter уже занял свои нишу и растет. Будущее точно есть, но какой объем узнаем только ты будущем
как всегда отличная подача информации, ждём больше видео по композ🔥👍
Будет, только надо самому начать туда погружаться
Здравствуйте! Очень странный вопрос, а где Вы нашли этот флажок Котлин, который на заднем плане?))
Его раздавала JB как мерч свои Kotlin User Groupd и на конференциях давали
очень интересно, спасибо 🙏💕
28 июля произошло 2 великих события - я родился и вышел stable jetpack compose
Кирилл, благодарю за качественный контент! Не могу понять почему у Вас так мало просмотров. У Вас отличные видео. Продолжайте в том же духе)
Малая ниша, поэтому всегда будет так. Со временем придут новые и просмотры вырастут. Спасибо за поддержку
Открыл для себя ваш канал, всё круто!
Как нашел? Знакомые, реклама или поиск ?
Просто рекомендации. Как раз учил фрагменты (я новачок) и тут "Убийца Fragment" 👍
Что по кнопке платного комментария? Почему на твоём канале её нет? Хочется протестировать её на твоём канале.
Про бусти, патреоны знаю, но я хочу кнопку.
Я не могу включить монетизацию, так как Google не присылает мне письмо с проверкой физического адреса. Так что грустно ( Да и комиссия там конская - 30% + за вывод. Хочешь поддержать - воспользуйся donate.stream/android_broadcast
Спасибо за выпуск . Очень жду видео про него
Благодарю за отличный, современный контент !)
Спасибо большое за работу, благодаря Вам в первую очередь обратил внимание на android. Написал первое приложения на классическом view, если так можно выразиться. Подскажите, если не затруднит, извините заранее за возможно нубский вопрос. На compose уже можно смело писать приложения для android ? Я имею ввиду нет ли проблем корректной работой compose с другими инструментами экосистемы Аndroid, или может есть подводные камни ? Из видео мне лично показалось, что это уже по настоящему production решение.
Костяк инструментов работает без проблем, но есть то что может отставать по продвинутым возможностя. Если вы только начинаете, я рекомендую вам разобраться в старой системе и потом уже браться за новую, но просто потрогать точно стоит чтобы увидеть как поменялась система.
P.S. надеюсь вы рады своему выбору Android
Кирилл, спасибо большое за ответ
Да, android класс, хорошо, что увидел ваш канал, приложение под andoid я писал быстрее, чем для ios. Экосистема android мне показалось более понятной и понравилась больше. Еще больше мне нравится идея фулстека, но пока делать решил упор больше на какую-то одну платформу)
Верно. На старте надо окрепнуть в одной технологии и уже затем смотреть по сторонам. Так и проще будет разбираться, особенно если первой технологией получится зарабатывать на жизнь
Отличнейшее видео. Кратко, по сути. Идеально. Спасибо!
так что, компоуз функции таки с большой буквы писать?
Да
спасибо, лайк!
Так то xml это максимальная декларативность - там надо потрудится чтобы всунуть императив.
Пример с каунтером как я понял так же "устанавливает атрибуту text тек значение каунтера" или это не изменение стейта, а своего рода связывание?
То что из коробки можно прям в ide "тестить" представление в связке с логикой(обработки событий) скорее всего останется невостребованной так как это тестирование сломается на первом же обращении к серверу или каком то композите который включает в себя чуть больше чем 1 текстовое поле и 2 кнопки. разрабы чаще всего будут продолжать "экономить" на создании инструментов тестирования разрабатываемого функционала чтобы при разработке можно было в несколько инструкций создавать фейковые состояния для проверки своего представления(под разные разрешения, с в разных позициях и прочее)... Кто вот прям сейчас работая в "паттерне" mvvm мешает создать тестовый билдер для подделки контракта viewmodel и проверить в досконально все интересующие вариации рендеринга разрабатываемой view? При этом технической проблемы в этом нет - сама студия как раз отлично этим пользуется для первичного превью при создании так надоевшего xml. Так же никто не мешает прям сейчас сделать фейковые реализации всяких репозиториев и прочего DAL, с удобным API первичной инициализации оптимизированного под удобную инициализацию тестовыми данными. Это даст возможность не переходя на специальные технологии оттестить в изолированном окружении вьюху вместе с состоянием презентационного слоя(view + viewmodel). те самые щелчки на + и -, только не прям из idea, а запустив разрабатываемое activity в фейковыми зависимостями. Но полагаю что все эти возможности остаются только в виде потенциальных из-за "экономии". ведь зачем писать лишний код, его же надо поддерживать, а у нас не такое сложное приложение, и времени на это нет - нам бы очередную фичу запилить нащелкивая в ui и в лучшем случае постоянно подкручивая заглушки в какой нить WireMock, SoapUI или своего очень обобщённого велосипеда
Спасибо за ваши видео Кирилл - интересно\полезно! Может подскажете - какой ни будь (лучше какие то) хороший средне\большой проект с открытым исходным кодом где вью на Compose. Очень интересно как влияет на архитектуру, какую делают структуру каталогов… Также если бы было с удовольствием посмотрел бы видео с разбором
Стандартные примеры Compose. Ещё посмотри TiVi
Спасибо! просмотрю@@AndroidBroadcast
Очень интересный контент! Спасибо.
На мой взгляд слишком похожий на react
Composable - это компонент который рисует ui
Можно пасавать пропсы между компонентами
У каждого компонента свой стейт или общий у родителя
Ну блин язык Kotlin а дальше react =)
Круто, и автору огромное спасибо!
Это общее движение разработки UI в приложениях, поэтому и языки адаптируются. Как и фреймворки. Задача языка - позволять эффективно решать задачи разработчиков на нем
Спасибо большое.
Интересно, что там с диалогами и ботомшитами.
BottomSheet уже поддерживает из коробки, как и диалоги
Отличный выпуск! Спасибо :)
И вам спасибо, что не прошли мимо и оставили комментарий
Как по мне, компоуз ещё сыроват, хотя на реддите говорят что уже используют в продакшене. Список строится круто (Про repeat, кстати, не знал, делал через for), но когда я его трогал мне показалось, что он подлагивал. Из плюшек - стики хидер из коробки.
Ну и теперь нам нужна новая архитектура, новые подходы, новый способ взаимодействия с DI фреймворками, нужен ли нам теперь ViewModel в принципе и т.д.
В первых Beta было ещё не очень, но стал лучше к релизу
MVVM вполне жизнеспособен
если я правильно понял то котлин это просто "обёртка" для явы?
код на котлине преобразуется в код на яве и выполняется?
нафига оно надо, не проще ли без посредников обойтись..
Не так.Java и Kotlin компилируются в байт-код, только kapt генериь Java классы для совместимости с Java Annotation Processing
Супер. Спасибо!
Круто!
Спасибо! 🔥
меня очень сильно смущает все эти магические аннотации в котлине... да сам по себе view очень жирный класс, но зато я в любой момент могу открыть исходники и понять , что там и как работает. это касается и короутин. не нравится мне эта тенденция... в любом случае кастомные вью писать надо будет всегда, и насколько легко (и вообще возможно ли??) это сделать на компоуз? очень много вопросов.
в любой момент открыть исходники и изучить 30000 строк вью и наследников с делегатами по цепочке?))
а насчёт кастом вью Кирилл упомянул - все стало только проще
@@dmitriismirnov6769 да, приходилось не раз ковырять исходники когда кастомные вью писал. конечно прям изучить в любой момент не получится, но в иде найти методы, которые тебе нужны и посмотреть логику достаточно легко. чего не скажешь о компиляторе и куче вспомогательных костылей вокруг него.
Даже сейчас можно посмотреть и увидеть как рисуются компоненты, фактически от нас спрятали механизм обновления UI в зависимости от состояния
Спасибо!
У меня вопрос насчет существующего приложения, хотелось бы новые экраны уже описывать компосом, прочитал что есть MdcTheme, вопрос как долго он будет существовать и поддерживаться? У нас проект крупный, и быстро перевести все невозможно
Думаю достаточно пока актуальна View, а это ещё долгие годы
Спасибо за видео :)
Compose лучше использовать в новых проектах, а старые делать по старинке, иначе со временем будет каша
Если модульность занесена, можно новые фичи на композе пробовать писать
Как я понял compose актуален для тех, кто массово разрабатывает прилы на аутсорсе (скорость разработки). А если я работаю над одним проектом, какой в нем смысл?
Вам не важна скорость разработки даже для одного проекта? Вопрос в том что за единицу времени вы доставите больше фичей пользователю
Большое спасибо за овервью
Классный мерч!)
Жду не дождусь уже дать вам возможность заполучить его себе
мы уже используем
Кто мы? Что за продукт и приложение?
познавательно)
Спасибо
С момента выхода видео прошло немало времени, что думаешь о компоуз сейчас? На сколько он стал востребован, на сколько стал стабильнее и много ли проблем еще нужно решить? По моим личным опросам, кто-то пробует переписывать отдельные экраны на него, но никто не стартует с ним с нуля. Создается ощущения что сейчас в 2023 он еще сыроват, а все хотят стабильности, и судя по вакансиям спроса на эту технологию на рынке практически нет, но всем интересно.
Все стало лучше, много приложений написали с нуля, а другие перешли. Программисты с кривыми руками всегда жалуются и не хотят ничего не учить
@@AndroidBroadcast Думаю да, многие не хотят перестраиваться и много староверов с джавой, которых не загонишь на компоуз. И конечно тонны приложений уже готовых нужно поддерживать.
@@Polite_person_ а зачем переписывать с Java если все работает, DI настроен, чистая архитектура грамотно спроектирована? Все приложение оттестировано вдоль и поперек, таски выполняются.... Никакое руководство не даст времени и старт на переписывание. Я в продуктовой компании, вот какие аргументы для менеджера и тех директора предоставить?)
@@zaur4094 Я имел ввиду, что есть кто до сих пор стартует на Java.
молодец обзорчик зачетный
А чего так редко зум меняется?
Сделал бы изменение зума каждую секунду.
Я был молод и неопытен, не судите строго ведь я не профессионал съемки и монтажа
Вот будет реализация под ios, тогда и поговорим про кроссплатформенность.
Зачем думать о Compose только как мультиплатформенном решение для iOS и Android? К SwiftUI те же требования?
А нормальное кастом вью на нем реально сделать или нет?
Да, есть доступ к Canvas и обработки разных событий. Всё компоненты сейчас так сделаны
С realtime preview все очень плохо?
Что именно вы подразумеваете под этим? Интерактивные режим (можно нажимать на кнопки) или статический предпросмотр Compostable функций?
Я не поучаствовал проблем со статикой в превью, а вот интерактивный режим ещё требует доработки
до начала 2021 года поддерживал минимальное апи 15, но позже понял, что смысла уже особого нету, надеюсь compose решит многие проблемы)
По статистике GP уже мало смысла имеет поддерживать что-то ниже 6.0
@@AndroidBroadcast Согласен, не думаю что остались люди использующие андроид
Кирилл, ты же говорил, что больше не планируешь работать на дядю? А в этом видео сказал, что работаешь в Surf 🤨🤔
Я не планировал возвращаться работать в программирование. В Surf я занимаюсь тех. пиаром и это вынужденный компромисс из-за интересной задачи в компании для меня как специалиста по личному бренду, так и финансова сторона вопроса играет важную роль.
Для меня кастом вью, о котором говорит Кирилл в этом видео - это что-то свое полностью нарисованное на канвасе. Таких вьюшек я очень много написал, довольно сложных (можно сказать, хобби у меня такое). Но я-то думал, что люди это и имеют в виду, и тоже удивился, что так много народу этим занимается. А когда узнал, что под кастомом больше понимается просто какие-то стандартные вью, сгруппированные под свои какие-то правила - ну это детский сад, а не кастом вью)
теоретически конечно эти сгруппированные вью тоже являются подвидом кастом вью, и у них есть название - Compound Controls, но если сравнивать по сложности разработки, да, компаунды на уровне детсада ;)
Мир Custom View огромен )
надеюсь виджеты будут добавлять так же как команда флаттера
В Roadmap поддержка Material You и виджетов один из основных пунктов
Почему же compose не нативный?
На главной странице написано "Jetpack Compose is Android’s modern toolkit for building native UI."
Да и вообще что такое нативное? Для меня нативное - это то, что оптимизируется и затачивается под определенную платформу для большего быстродействия и стабильности.
Т.е. флаттер не нативный, т.к. он про многоплатформенность и разработчикам приходится искать компромиссы. А вот компоуз вроде пока не лезет в другие платформы, значит затачивается чисто под андроид и является нативным. Или я не прав?
По мне нативный - это Android View, которые часть системы. Вот Compose повторяет их внешний вид и где-то расходится
Compose - официально мультиплатформенное решение, поддерживающее Desktop, Android, Web
Кажется что лучшим решением был бы flutter на kotlin , остальное в топку )
круть
Не знаю как будет с гуглом, но с эплом я попал в задницу с их свифтюай. Много багов, которые появлялись когда юзер обновлял айос. С каждым выходом новой версии айос мне приходилось в горячке быстро создавать кучу костылей. После этого вернулся к сторибордам и пока не желею. Сырой еще свифтюай.
Теперь боюсь использовать компоуз. Подожду еще годика 3...
Плюс Compose - это отдельная библиотека и не привязки к релизу платформы. Исправление багов и улучшений доставляются всем
@@AndroidBroadcast Спасибо за информацию
Все еще нужно достаточно много RAM для нормальной работы превью (на моем стареньком маке так и не запустилось)
Да, жду Mac на ARM и вкачать туда 32 гига оперативывы
короче, коин юзаем для мелких проектов, хилт для среднего уровня сложности и даггер для огромных проектиков с сложной логикой и архитектурой
Для огромных Dagger - проблема из-за кодогенрации. Там ручной DI
@@AndroidBroadcast понял, спасибо) кстати, то ли это ютуб баганул, то ли у меня что-то случилось, но коммент должен был быть в видео про DI(почему вы с Koina перешел на другую библиотеку).. странненько) а видос про компоуз в планах на сегодня был ахах. Но еще раз спасибо за ответ :))
как по мне, то еще рано в прод заводить компоуз. Может разве что какие-то отдельные скрины, но полностью пилить апку на компоузе я бы не рисковал прямо сейчас. Периодически мониторю примеры приложений на компоузе и очень всё неаккуратно написано. Нету каких-то красивых подходов. Потому подожду еще наверное годик, пока всё устаканится. А если в нынешнем виде так и останется, то уж лучше компоуз вообще не взлетел.
Какие критерии принятия решения в прод?
@@AndroidBroadcast как минимум сейчас не найдешь специалистов на рынке, которые уже умеют в компоуз. То есть уже надо людям дать время на изучение. Дальше - это всякие тулзы и апдейты. Я уверен, что хоть глобальных изменений в компоузе уже не будет, но всё же куча мелочей еще изменится. Ну и компоух хоть и релизнулся, но тот же констрейнт с ним еще не в релизе. Так что по моим планам - до следующего лета я на компоуз не перейду.
PS. Попробовал немного компоуз в пет проекте - много вопросов по читабильности кода. В гитхабе смотришь примеры проектов и вообще не понимаешь что сверстано на экране. Приходится грузить проект и в студии в превью уже смотреть.
Кирилл, большое спасибо! К Compose присматривался давно, после просмотра этого видео сразу, вот прямо сейчас, опробую его в пет проекте. Есть, конечно, вопросы/сомнения, как это взлетит на сложных списках со множественными типами айтемов, а также придется еще перенастроить мозги в плане отказа от фрагментов (SingleActivity, Navigation), может ты уже опробовал на практике подобное решение?
Взлетит отлично - код станет проще и понятнее.
Я попробовал его немного, но планирую писать на нём полностью проект и показывать вам результаты
Очень плачевно что нет и не будет, скорей всего, поддержки для явы. Можешь сказать, что и "слава богу" =) но есть много людей, которые недолюбливают котлин, в их числе я. Поигрались с другом с компоусом - пока что сыровато, в большие проекты внедрять рановато, читается код, как по мне, непривычно. Время покажет.
Огромное спасибо за контент! Много чего нового подчерпываю от тебя
Это эволюция. Одни технологии уходят, другие приходят им на замену. Вы можете придерживаться старых принципов, но рынок и выгода бизнеса помешают за вас. Вполне возможно, на работе вы пишите на Kotlin, потому что за Android разработку на Java уже не готовы платить, или не меняете работу, просто потому что "хочу быть на Java"
Но как нам теперь верстать сложные экраны? Закругленые вьюшки, зависимости вьюшек друг от друга,...
Все также есть различные Layout, можно реализовать собственный виджет через Compose, где будет своя отрисовка, обработка событий и прочее.
Также можно сделать свой Layout
@@AndroidBroadcast ого супер, честно сказать я не нашёл расширенных туториалов, везде только и показывают как helloworld вбить, спасибо за ответ
На сайте Google много документации, примеры в GitHub, видео и Codelab
@@AndroidBroadcast спасибо, а как на счет паттренов проектирования? mvp mvvm с композом как работает? как вьюшки подписываются на viewModel? Я начал писать HelloWorld на компосе и уже ощутил всю силу и превосходства, но я себя чувствую утенком среди акул
@@putinstop5940 Надо просто освоиться с новой идеологией вокруг состояния и всё сойдется
Обидно конечно,😌 не успеваешь выучить существующие подходы и технологии и БАТС новая технология, новые прицепы, другая архитектура и другие паттерны 😏
Программирование всегда было про то что постоянно надо учиться, расширять взгляды и применять новые популярные подходы
@@AndroidBroadcast В этом то и дело что не успеваешь применять одного, появляется другой, получается тратишь время на так называемые deprecated features начать с новыми сложно, так как не хватает материала или они находятся в бета версия
Меняется все не так быстро, новые подходы внедряются постепенно, а такие технологии как Compose выходят редко, интегрируются неспешно и живут очень долго
Очень сомнительная технология этот Compose.
За его интеграцию в КММ однозначно лайк. Но есть много непонятного лично для меня.
Хоть убей но ничего принципиально нового, кроме как асинхронщины в построении UI и новых не нативных + сырых View элементов я там не вижу.
Точно так же как в Compose только без него и без HotReload можно было всегда строить экраны в коде. Разница лишь в кол-ве кода. Compose даёт удобные обёртки для этого.
Убийца фрагментов ? Я наверно что-то не понимаю но фрагмент это не только кучка группированных вьюшек но ещё и масса логики в рамках конкретной задачи, которая задаёт алгоритм поведения для их всех. Поведение ведь так же нуждается в декомпозиции, разбиении на микрозадачи. Этот код нужно где-то прописывать.
Как в Compose правильно прописать всю UI логику для "фрагмента" ?
Я не пробовал Compose ещё но базируясь на первом впечатлении с обзоров - используя Compose мы просто начнём засирать код.
Раньше у нас была отдельно вёрстка UI и отдельно UI логика (DataBinding не рассматриваем).
А в Compose всё будет слито в один файл. Да, мы можем выносить общую логику в отдельные файлы но это не избавляет от увеличения кол-ва кода в файле Activity/Fragment.
Про композитные View так же довольно сомнительно. ничто нам раньше не мешало сделать код аля
viewBinding.root.addView(
TextView(context).apply{
text = getString(R.id.some_text)
//Other attrs...
}
)
Я в этом деле ещё не разбираюсь. Если написал что-то глупое - прошу меня простить. Просто есть масса вопросов ответы на которые нагуглить мешает моя лень программиста. А тут прям идеальное место, что бы найти их все разом в качестве ответа на мой комментарий.
Compose не имеет отношение к View и по другому всё отрисовывает. Никто не мешает вам также организовать отдельные Kotlin файлы и там делать только UI. Рекомендую попробовать и тогда поймёте в чём разница, если весь доклад воспринялся скепсисом
Я Fragments только пытаюсь осилить, а они уже устарели )))
Нет, они точно еще будут в разработке долго, так как они плотно осели в кодовой базе за 10 лет ) Больше чем RxJava даже, так что не переживайте. В новых приложениях подход начнет отмирать, но пока он живее всех живых!
Зачем ты ведёшь этот канал когда есть flutter...
Потому что Flutter мне не нравится и как видишь практически 8000 тыс людей тоже смотрят что я делаю
@@AndroidBroadcast сделай видео почему не нравится флаттер и почему тебе нравится ждать компиляцию 2мин и не нравится хотрелоад))
Раньше хватались декларативным UI и hot reload. Первое пропало. Что будете делать когда и второго не станет? Если разработка хватает тем что их приложение можно быстрее пересобрать, то что-то вы не то делаете
+
Вы как-то не учли большие легаси проэкты где Java это за 60-80% кода и таких проектов очень много. Так что это совсем не "узкая категория"...
java проекты это вымирающие динозавры, которые застряли в прошлом из-за чего упорства или упрямства не хотят идти вперёд. Проекты на основе AOSP не считаются
@@AndroidBroadcast а как же телеграм? Отлично работает, руки растут у людей из правильного места
Это тоже исключение из правил. Самое обидное что разработчики Telegram отказываются пообщаться про свои технологии и рассказать почему так.
@@AndroidBroadcast попробуй найти Григория клюшникова, он разработчик ВК бывший и телеги. Я с ним общался. Может прольет свет. Но как мне показалось он сам по хардкору - бизнес логика во фрагментах итд. А ответ Я думаю простой - просто так быстрее разработать приложение. Если над ним работает 2-5 человек, то легко будет разобраться что к чему и не нужны все эти дополнительные слои абстракции, обертки, инфекции зависимостей итд - это по сути инфраструктура и она не имеет отношения к фичам. Иногда код в виде простыни реально легче и быстрее понять когда он в одном файле)
Гришу знаю по чатам. Он ярый писец только на Android SDK и никаких Jetpack. Тоже отказывается давать интервью. Но тут возможно я такой ещё человек что со мной говорить не хотят
Compose выглядит уродливо, старый вариант по ощущениям лучше
Раздражает бешеный фанатизм. Раньше у нас был xml в котором мы декларировали , теперь делаем тоже в compose но чтобы увидеть изменения нужно билдить , просерать время ....
Даже с XML нужно было делатт, чтобы увидеть виджеты не из Android SDK. Compose - это не альтернатива XML. ,Это совсем другой принцип показа UI, но никто не мешает остаться на XML
А мы за Java))
flutter всех убьет
Спасибо за выпуск . Очень жду видео про него
Обязательно будут, а пока кинул все силы на восстановление моего голоса. Пока не могу записывать ролики вовсе
Спасибо!
Спасибо!