Уважаeмый, Вы путаете side effects и effect handlers. LaunchedEffect - это функция effect handler, которая работает с сайд эфектами которые возникают на запуске композэбл.
@holoceo
2 жыл бұрын
Вот вам derivedStateOf, но хз что он делает и зачем нужен. Лол) А так хорошее видео, спасибо.
@АлександрЯцук-ч8ы
2 жыл бұрын
Спасибо за видео. Чем больше будет таких видео, тем быстрее будет продвигаться композ в командах) Не согласен с тем что просто можно просто взять и как в первой части видео использовать rememberCoroutineScope и остальные сайд эффекты, и этим избавится от вью модели. Вью модель в первую очередь была создана гуглом для пережития изменения конфигураций. При пересоздании активити ввиду изменения конфигурации текущий композишн диспозится и например при повороте экрана все эти эффекты вызовутся заново. Тот же LaunchedEffect вне зависимости от ключа при изменении конфигурации просто вызовет лямбду внутри. При уходе с экрана и попадании его в бекстек только saveable состояние сохранится, кроме того все корутины запущенные с помощью coroutine scope созданного с помощью rememberCoroutineScope будут отменены. Написание бизнес логики в композабл функции в целом только добавляет сложности, слишком много граблей на которые можно наступить не учитывая работу композа. При этом тестировать эту бизнес логику сложнее. Мое личное мнение: Все сайд эффекты и корутин скоупы нужно использовать только для поддержки ui дерева, анимаций и отправки в бизнес логику событий при наступлении какого-то состояния ui или создания простеньких ui элементов, которые могут изменять свое состояние только пока они находятся на экране. Для экранов же необходим объект бизнес логики, который может жить вне рамок композиции, а в рамках нахождения экрана в бекстеке.
@MobileDeveloper
2 жыл бұрын
Я еще сам не тестил, но есть гипотеза, что если запровайдить configurationChange в манифесте, то активити пересоздаваться не будет, при этом перерисовка все равно будет происходить, потому что компоуз. Но надо проверить
@АлександрЯцук-ч8ы
2 жыл бұрын
@@MobileDeveloper Дело даже не в повороте экрана.Это был пример изменения конфигурации, которых больше чем одна. Если бы изменения в манифесте был тру вей хендлинга смены конфигураций никто бы сейчас не использовал вью модели, можно было бы просто создавать любой класс внутри фрагмента/активити и не парится со всеми этими созданиями фабрик для вью моделей. Кроме этого все равно остаётся сброс состояния при замещении экрана и попадании в бекстек, который конечно фиксится сохранением всего состояния через saveable механизм, но не очень удобно. Однако отмена всех корутин в скоупе композабла экрана после попадания в бекстек экрана и привязка времени жизни бизнес логики к ui композа уже проблема для некоторых кейсов, с этим можно жить, но не очень хочется.
@mikeshilovski1512
2 жыл бұрын
мне кажется наоборот джунам все проще и проще входить теперь будет, когда все переходит на более декларативный подход. А математика это круто, но далеко не основное сейчас
@NickTitovDev
Жыл бұрын
Спасибо за видео. Интересна задумка отказа от view model
@АнгелДемон-г2ю
Жыл бұрын
Мне кажется это противоречит самому подходу композа, идея в том что за логику отвечают модели, они ходят в сеть, пишут в базу и прочее и меняют Стейт,а композ просто подписывается на изменения , а смешивать их в одно месево то получится куча не читаемого и не поддерживаемого кода.
@СергейБезногов-т6у
29 күн бұрын
Я много чего написал используя Jetpack Compose. И всегда я использовал ViewModel для бизнеc логики. Все эти effect handlers нужны только для выполнения тупорылых заданий от тупорылых преподавателей на этапе обучения, и никогда в реальной работе. Реальный программист никогда не делает все эти соunters++. Очень редко может пригодиться coroutineScopeEffect для запуска корутин из компоуза. Но и без неё можно жить если переписать плохо написанный код
@СергейБезногов-т6у
29 күн бұрын
Не модели, сударь!!! А ViewModel и соответствующий DataState class, хотя можно и обойтись без него, можно просто все переменные запихнуть по отдельности во ViewModel. Только так неудобно, это плохая практика. А хорошая практика - сделать дата класс для всех state переменных, а уже потом во ViewModel инициализировать во mutableStateOf только одну переменную, и из неё доставать все переменные в Compose
@karamba6936
Жыл бұрын
небольшая поправка - сайд эффекты это проблемы, возникающие в компоуз среде при использовании обычного кода(объявлении переменных, корутин скоупа и прочего). А вот эффект хэндлеры призваны решить эти проблемы
@СергейБезногов-т6у
29 күн бұрын
Человек не знает разницу между сайд эффектами и эффект хэндлерами и взялся нас образовывать
@nefedov-dima
2 жыл бұрын
Кстати, не очень согласен, что сайд эффекты делают из компоуза не UI. Это скорее просто способ как из UI выбраться наружу. Просто можно посмотреть на ReactJs. По факту эти библиотеки очень похожи. Реакт позиционирует себя, как чисто UI библиотека.
@antaki93
11 ай бұрын
К 17-ой минуте полностью потерял нить повествования. Я всё понимаю, мысли разные могут приходить, когда всё с одного дубля записывается. Но какая-то последовательность изложения материала должна быть?
@deadchannal
2 жыл бұрын
Ого! Очень актуально! Спасибо
@MobileDeveloper
2 жыл бұрын
👍👍
@sovrinfo
2 жыл бұрын
Спасибо за видео.Коммент в поддержку!
@MobileDeveloper
2 жыл бұрын
Спасибо )
@paulsoja2732
2 жыл бұрын
Спасибо за видео. Не в качестве критики, но всё же - очень отвлекает когда махаешь руками на видео.
@MobileDeveloper
2 жыл бұрын
Попробую не махать 😂
@aliaksandrbohush5257
11 ай бұрын
C [8:29] Алексей начинает проходить собес по алгоритмам.
@АлександрУколов-л6н
Жыл бұрын
блин, ну revert же есть :) много написал, просто ревертни, проект-то под VCS у тебя :)
@Michael100788
2 жыл бұрын
Привет! предлагаю осветить такие темы как использование Баз Данных в мобильной разработке, тот же SQlite, Room, Realm;. Также обсудить практическое использование в условиях командное разработки систем контроля версий Git/GitHub
@MobileDeveloper
2 жыл бұрын
Есть видео про Room на канале
2 жыл бұрын
Молекула, судя по всему, это чисто функциональный MVI. Интересный подход. Все больше замечаю ситуации в Kotlin, когда какая-то логика, состояние умещается в объекте, и класс с внутренними свойствами вообще не нужен. Как раз тот самый случай, когда все можно вынести в простые функции модуля, без лишних оборачиваний в объекты, и все зависимости передавать как аргументы. Для Ktor, к примеру, уже есть функциональная надстройка над Koin, где граф зависимостей тоже строится на функциях, т.к. сам Ktor тоже в этой стилистике.
@MobileDeveloper
2 жыл бұрын
Да, интересно будет посмотреть куда все придет. Планирую записать тренды на следующий год, думаю будет крайне интересно
@homie2417
2 жыл бұрын
Теперь ооп гавно, а функции круто. Когда вы уже определитесь...)
@MobileDeveloper
2 жыл бұрын
А я где-то там сказал что ооп гавно, а функции круто?
@veygard
2 жыл бұрын
Спасибо за видео!
@YanchenkOFF
2 жыл бұрын
Круто!
@СергейПанов-з3ц
2 жыл бұрын
Поставил на этом и предыдущем видео "Спасибо" комментарий. Но они не видны. Деньги хоть дошли? Я пойду писать в гугл, чтобы они починили эти комментарии.
@MobileDeveloper
2 жыл бұрын
Сейчас посмотрю, я видел на почту пришло два письма. Гугл иногда удаляет комменты.. я хз почему
@MobileDeveloper
2 жыл бұрын
Судя по тому что я вижу они не дошли, ну по крайне мере в статистике их нет. В любом случае спасибо вам огромное за поддержку канала!)
@procolharum1960
2 жыл бұрын
У тебя этот видос выпал из плейлиста по композу
@MobileDeveloper
2 жыл бұрын
О, спасибо большое, сейчас добавлю )
@pavelaleksandrov441
2 жыл бұрын
derivedStateOf может быть полезен для маппинга одной модели данных в другую. Или, например, можно сделать отдельное состояние, которое будет вычисляться от нескольких других состояний.
@pavelaleksandrov441
2 жыл бұрын
Например, если на экране есть какие-то данные, которые динамично изменяются, и на основе них нужно иметь другие состояния экрана
Пікірлер: 46