Миграция с LiveData на Coroutines Flow

[@AndroidBroadcast]

🔗 Avito.Tech avito.tech/ 💰 Поддержать проект bit.ly/3sratqQ 🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast 🔗 Блог о жизни канала boosty.to/androidbroadcast 🔗 Telegram канал "Kotlin Broadcast" ttttt.me/kotlin_broadcast

[@Nidvoraich]

Сижу я такой, ищу видосы, чтоб вкурить работу с лайвдатой... Очень надеюсь, что Флоу не станет депрекейтет ещё до того, как я посмотрю это видео :)

[@AndroidBroadcast]

LiveData вполне подходящая вещь. Видео - не призыв к миграции, а лишь руководство как это сделать, если вы хотите. В будущем буду делать такое вступление в начале ролика

[@mukhtarbimurat5106]

Спасибо, очень полезно, ждем выпуск про MVI с функциональным программированием используя Flow

[@AndroidBroadcast]

Такого пока в планах нет, но вот Compose будет однозначно раскрываться

[@arturmavlyuchenko7647]

Долгожданный выпуск!

[@AndroidBroadcast]

Даже слишком. Мне стыдно, что моё обещание и реализация так растянулись по времени

[@swamp2113]

Спасибо за выпуск! Я для себя сделал экстеншен в стиле LiveData, так красивее выглядит: inline fun Flow.collectWhenStarted(lifecycleOwner: LifecycleOwner, crossinline action: suspend (value: T) -> Unit)

[@AndroidBroadcast]

Тоже хороший вариант

[@kafychannel]

спасибо за видео, Кирилл!

[@syoritohatsuki]

Наконец-то пример миграции на простом приложении, а не на какой-то модели из жопиней с говно апи и предварительно закостыленым Retrofit и отголосками на DI

[@MrMonyag]

Вот еще бы я лайвкодинг на ютубе смотрел, это же для тех, кто не может в документацию! (сидит и смотрит, ставит лайк, оч хорошо, оч одобряет)

[@AndroidBroadcast]

Лайвкодинг должен быть как отрепетированное шоу быть, иначе это будет нудно (

[@Chernov1984]

почитай документацию после ... часов работы,,, включил видос между делом, 15 мин и есть некое представление о теме

[@tyt66612]

Весь день ломал голову как Flow закинуть в переменную и прослушивать значения этой переменной и наконец увидел, что есть функция emitAll() 👍

[@GriNAME]

Спасибо за видео!

[@heroachilles]

Благодарю, очень интересно!

[@sanek1985t]

Какой-то оверинжениринг. Вроде простые вещи надо сделать, взять данные по сети или из бд или из нотифа и отобразить во вью . Теперь предлагается выкинуть лайвдата и использовать флоу с какими-то буферами итд. Хорошо бы объяснить на реальном примере какие проблемы решает флоу и почему это проще чем другие подходы и лучше. Спасибо

[@AndroidBroadcast]

Преимущества Flow - Возможность работать на любом поток - Единый подход на всех слоях - Большое количество операторов Flow - Больше гибкости чем в LiveData - Возможность работать в Multiplatform - Лучшая cвязка с Compose

[@sanek1985t]

@@AndroidBroadcast хорошо бы детальныц пример причин такого перехода. Где люди взяли подходы livedata, eventbus, rx, flows, оценили, все выкинули и оставили flows. И объяснили почему они к этому пришли. Было бы клёво)

[@zheil2977]

Приветствую! Прошел год. Ну как сейчас успехи? Разобрались в преимуществах Flow?

[@sladkiymems]

Приветствую! Прошел год. Ну как сейчас успехи? Разобрались в преимуществах Flow?

[@РоманСкляренко-у1д]

Приветствую! Прошел год. Ну как сейчас успехи? Разобрались в преимуществах Flow?

[@sanek1985t]

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

[@AndroidBroadcast]

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

[@monkas2738]

Спасибо, отличное видео! Хотелось бы как нибудь увидеть видео про MVI, с выходом беты Compose это можно вместе связать.

[@AndroidBroadcast]

Я думал над рассказом про Unidirectional Data Flow и о том какие именно архитектуры этому соответствуют. Сейчас в свободное время занимаюсь изучение Jetpack Compose

[@ivanvlasov8308]

Спасибо, Кирилл, очень полезно!

[@codemachine19]

харош харош мужик давай еще еще

[@Alexandr234]

спасибо большое Кирилл!

[@АртемТерновенко-к4ж]

супер

[@Tetiana-k2w]

Крутое видео) спасибо

[@codingpas]

Не гладя лайк

[@AndroidBroadcast]

Доверяй, но смотри до конца!

[@luckystrike91]

10:17 эмм, но ведь lifecycleScope будет закрыт только при onDestroy? тоесть если активити перейдет в onStop, оно будет по прежнему получать сообщения и пытаться апдейтить ui. или я что-то не так понял или в коде ошибка...

[@Иванов.Михаил]

Думаю, что правильнее назвать функцию collectWhenStarted, что явно сообщает о запуске flow. А также не лишним будет возвращать Job, которая возвращается функцией launchWhenStarted(). В итоге получается что-то вроде этого: fun Flow.collectWhenStarted(lifecycleScope: LifecycleCoroutineScope): Job { return lifecycleScope.launchWhenStarted { [e-mail]() } }

[@AndroidBroadcast]

collect - это стандартная suspend функция и не подразумевает под собой передачу Scope

[@stanislavlatyshev2621]

Испортил красивое значение лайков 777. Спасибо за видео очень помогло. Хотелось бы больше по корутинам и flow.

[@AndroidBroadcast]

Уже в раннем доступе есть первый урок из курса по Kotlin Coroutines boosty.to/androidbroadcast/posts/48374c74-9420-4046-bebf-382ceb624e37?share=post_link

[@SpinQuarK26]

Интересные способы работы, только возникает резонный вопрос зачем переходить на Flow с LiveData? Особенно когда у тебя только одно значение приходит (обычный get запрос), а не поток

[@AndroidBroadcast]

Нет причины делать это обязательно, но мне нравится унификация работы в асинхронном стиле, множество оператор и отсутствие необходимости работы в главном потоке. Поэтому я предпочитаю унификацию на всех слоях через Flow

[@SuperMarkwel]

за 20 минут узнал больше чем в универе

[@AndroidBroadcast]

От такого грущу за универ (

[@tequilaonelove]

Подскажите что за универы такие, которые андроид разработке учат, что-то интересно стало))

[@vadimmorozov30]

было бы прикольно если бы заготовка валялась где то на гитхабе и я бы смог пройтись по шагам после сам) некий codelab'чик)

[@AndroidBroadcast]

Такой заготовки нет + нужно дополнительное время на ее подготовку, что будет затягивать работу над роликом (

[@marattlepberghenov5786]

Зачем использовать apply для mutableLiveData, если можно default значение положить в конструктор?

[@AndroidBroadcast]

Пропустил появление этого конструктора. Уже давно переехал на Flow, поэтому и не помнил. Спасибо что рассказали

[@deadchannal]

Было полезно

[@wtf_nick]

А как сделать что-то типа SingleLiveEvent для отображения диалогов и тд?

[@AndroidBroadcast]

Я способа не нашел. Фактически после доставки данных надо очищать буфер, но события о доставки нет. Также наследоваться от SharedFlow и StateFlow сейчас не рекомендуется

[@aartikov]

Использовать Channel. Например, так: github.com/aartikov/Sesame/blob/master/sesame-property/src/main/kotlin/me/aartikov/sesame/property/Command.kt

[@andreyliashuk2516]

Я использовал sharedFlow с буфером 0, это не совсем SingleLiveEvent, но для диалогов и ui событий подойдёт.

[@artjomsalijevs8356]

Не очень понимаю, в чем основной профит данной миграции?

[@AndroidBroadcast]

- Возможность работать на множестве поток - Единый подход на всех слоях - Большое количество операторов для Flow - Больше гибкости чем в LiveData

[@artjomsalijevs8356]

@@AndroidBroadcast как думаете, насколько высокая вероятность того, что LiveData будет выпелен из jetpack в пользу Flow (в будущем)

[@AndroidBroadcast]

Выпилен точно не будет, но учитывай что все идёт в Kotlin Multiplatform, то LiveData там не вписывается. Её просто перестанут пользоваться как случилось с AsyncTask

[@evgeniy9248]

@@artjomsalijevs8356 Согласен с Кириллом, народ просто по чуть чуть начнёт переходить на Flow, уходя от костылей с liveData. Удаляя всякие SingleLiveData.

[@artjomsalijevs8356]

@@AndroidBroadcast у асинтаска было много проблем, он большой, не поворотливый и ничего не знал о состоянии. По этому переход на livedata дал гиганский ппофит в этих вопросах. А тут профиты, да есть, но не настолько ярко выражены. Есть смысл миграции если бы лайв дату планировали снять с поддержки / задепрекейтить в будущем. Все таки миграция больших проэктов это дорого

[@artemchep]

Не рекомендую так подписываться на Flow, это хоть и поставит его на паузу после onStop но не сделает неактивным! Если у вас там какая-то сложная логика и буферы то вполне вероятно что вы продолжите выполнять работу в фоне, иногда ее может накопиться прилично, особенно если вы уйдете глубоко по навигации.

[@AndroidBroadcast]

Естественно все зависит от задачи и чего хочется достичь. Копи-паста до добра никогда не доводила )

[@artemchep]

@@AndroidBroadcast просто добрая половина сюда пришла именно за ней =)

[@НадеждаКрупская-ш9г]

Поясните пожалуйста, зачем промежуточная обёртка Flow из юзкейса в другой Flow во вьюмодели? Почему нельзя напрямую вызвать stateIn или sharedIn на возвращаемом Flow (usecase)?

[@AndroidBroadcast]

Можно тайминг, где встречается это код, Так будет проще дать пояснение

[@alekseyorekhov9095]

А есть ли какие-то приемущества flow над livedata кроме нижеприведённых Из аргументов пока вижу, только: 1. Используется не в главном потоке 2. стандартизировать потоки в data и presentation, использовать 1 технологию лучше чем 2 3. можно не сильно запариваться со стандартизацией в случае сложных кейсов где нужно знать предыдущий стейт (и там и там будет flow использования). Аргумент про то, что пакет не androidx, считаю не сильно зачётным ибо сама вьюмодель с пакетом androidx. Интересуюсь вдруг что-то не учёл, может ещё какие-то полезные фичи есть.

[@AndroidBroadcast]

Ещё можно добавить что Flow имеет множество операторов, а также является мультиплатформенным подходом.

[@alekseyorekhov9095]

Упс, загуглил, уже есть вьюмодель на iOS/Android, тогда точно мигрировать имеет смысл, тем более не очень долго👍

[@АнтонЩербаков-в9ч]

А chanells сейчас в coroutine используется? или они все, ушли под капот?

[@IgorLevkivskiy]

Ну например если надо, чтобы событие(между корутинами) отработало только один раз только для одного консюмера

[@AndroidBroadcast]

Channels сейчас используются по их основному применению - общение между несколькими Coroutinе. Они будут использовать под капотом Flow в тех операторах где такое нужно. BroadcastChannle уже заменён SharedFlow, все операторы Channel тоже deprecated. Думаю что скоро уже все расчистят по основным API и будет видно конечный результат

[@audiserg]

А можно поподробней про usecase, может ссылочка найдется. Как то необычно, обычно даже в гуглопримерах, в зависимостях модели только репозитории. Я так понял это способ вынести логику из вьюмодели?

[@AndroidBroadcast]

UseCase - это из Clean Arhitecture и в множестве статей по ней это будет упоминаться. Вот например proandroiddev.com/why-you-need-use-cases-interactors-142e8a6fe576

[@sanek1985t]

Ребята, без стеба спрашиваю. Что будет с разработкой под андройд ? Все меняется чё то слишком быстро с неочевидными профитами. До коле ?! Это издевательство реально - апи устаревает с какой то нереальной скоростью, а значит и ваши знания и ваши инвестиции в изучение андройд. Когда делать приложения, если надо все время что то изучать ?! Прямо какой то JavaScript андройда. Как будто все разработчики сумасшедших либ с js ломанадись в андройд разработку и будут тут делать также. Я пообщался с ребятами из vk, которые разрабатывают приложение на андройд. Блин , да там нету никакого навигатор компонента. Там даже фрагменты не реплейсятся, а делается add + show/hide, то есть все экраны все время в памяти. Подозреваю там и rx то нету , не говоря уже о лайвдата и тем более флоу. Как так то . Крупные игроки не используют все эти новые фишки. Тогда резонный вопрос - зачем это?! Назовите мне популярные топ 20 приложении, которые юзают эти технологии , плиз

[@wtf_nick]

По мне так нужно на старте проекта решать стек, и дальше не двигать его особо, если нет с ним проблем, и не переживать по этому поводу. Мы так-то инженеры, и переходя на другой проект просто должны за пару вечеров раскурить его стек и пойти дальше пилить фичи, параллельно разбираясь в тонкостях, большие проекты так просто не перепишешь, да и реально смысла нет менять технологию просто на чуть более удобный апи (не всегда кстати выходит удобнее), если реально есть профит, то да. Другое дело, что тогда не на всех собесах в тебе заинтересуются, ибо часто гоняют по конкретным либам, ну это уже специфика СНГ и то можно обновить немного свои знания перед сменой работы, в FAANG особо за молодежные либы не спрашивают насколько я понял. Короче говоря я бы не переживал так за все эти новшества, хотя бы знать альтернативу чему выкатили и какой профит можно получить, чтобы например не пилить новые фичи на асинтасках в 21 году

[@wtf_nick]

А RX у вк есть, а вот DI нету) Большие проекты вообще вертели Jetpack, пишут много самописных решений под свои нужды типа Ribs, MVICore, Bazel

[@AndroidBroadcast]

Jetpack не является единственным путём. Его задача решить основные задачи которые возникают у разработчиков и предложить им стандартное решение. Только большие компании могут позволить себе писать всё своё. Компании помельче используют рекомендуемый стек для которых всё это и делается. Развитие технологий будет всегда. Угнаться за ним проблематично, но понимать что происходит быть полезно, но гнаться на внедрение не стоит, если для вас это не решает задач Бурное развитие Kotlin связано с его движение в Multiplatform, как и всей мобильной разработки и клиентской

[@sergey30027]

Делайте как чуваки, которые пилят телеграм, у них все самописное.

[@deviantstudio]

топ20 аппов - это такое говнолегаси, что переписать его будет стоить охулиарды

[@ИванКитаев-ш7с]

Звук Топ

[@AndroidBroadcast]

Видна разница где писал на петличку и обычный микрофон (

[@__Minecraft_Poseidon__]

Как с помощью Flow можно реализовать long polling?

[@AndroidBroadcast]

Если хочется иметь единое глобальное место в приложение для этого, то можно все события приходящие класть в SharedFlow и на него уже будут подписываться в разных местах приложения. flow { ... } позволит добиться того же, только каждый подписчик станет слушать события от сервера независимо и создавать отдельное подключение

[@solo4_4]

Очень полезно и интересно. У меня одна не большая оговорка. Не скажу за всех, скажу за себя. Я недавно только начал заниматься андроидом, знания на уровне начала пути Джуна. Знаю что такое лайв дата и использовал ее, и в этом плане, первая часть видео с примерами на основе лайв даты была понятна, но вторая часть уже вызвала бОльшие затруднения в понимании. Было бы очень круто, если бы контент объяснялся немного проще, а в остальном - все очень круто.

[@AndroidBroadcast]

Это была практическая демонстрация с минимум теории. Теория по этому вопросу заняла бы отдельное видео. Курс по Coroutine я думаю делать и там все будет рассказывать подробно

[@EpicRackBattle]

Спасибо за выпуск ! Кирилл pagining 3 (RemoteMediator) есть в планах сделать гаид?

[@AndroidBroadcast]

Да Paging 3 обязательно буду обозревать после стабильного релиза

[@РожковАндрей-х8ш]

Крутое видео, спасибо) Кирилл, а можно в двух словах чем отличается flow от StateFlow&SharedFlow?

[@AndroidBroadcast]

- Flow холодный, SharedFlow - горячий - Flow имеет только одного подписчика, SharedFlow - нескольких - SharedFlow может хранить цепочку событий - SharedFlow является более эффективной заменой BroadcastChannel

[@kimdoc6351]

3 года изучаю Android разработку, не могу найти работу на позицию Junior, так же о себе, есть погашенная судимость, 26 лет, нет военного билета, как думаешь или думаете могу ли найти работу в ближайшее время ?

[@AndroidBroadcast]

Мне трудно что-то сказать без оценки уровня твоих знаний, ожиданий. Возможно, живёте в маленьком городе. Ближе к концу лета в сентябре начнутся стажировки в компаниях - это ваш шанс.

[@AndroidBroadcast]

Напиши мне в личку (почта есть в описании). Созвонимся и я попробую тебе подсказать как действовать

[@Артем-ш8и5ц]

Люди добрые помогите! В переменную типа Flow присваиваю значение Flow из Room Далее выполняем collect по это переменной (теперь когда что-то измениться в БД сработает блок кода в collect) Теперь проблема, я меняю в переменной о которой шла речь выше, ее значение, и присваиваю новое значение Flow Далее выполняю collect Теперь у меня работают два collect, как отменить первый сбор?

[@AndroidBroadcast]

Пишите в t.me/android_broadcast_talks

[@gorshkoov]

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

[@AndroidBroadcast]

Не думал что так в цикле делают. Пропущены события по какой причине? Очень интерсно узнать

[@gorshkoov]

Я не нашёл явной причины. Но внутри есть метод distinctUntilChanges, который, вероятно и управляет этим поведением. Да и в целом, если говорить о состоянии, и если оно возникает очень часто, то имеет смысл заигнорировать его и показать только актуальное. Для потока данных как раз и надо SharedFlow брать

[@divanlobkowski3473]

@@gorshkoov попробовал в цикле получить значения от 0 до 100, все приходят. Но, если эмитить в корутине, то придет только 0 и 100.

[@bigsarg1813]

Я просто не доумеваю! кто ставит этим видео дизлайки?

[@AndroidBroadcast]

Не всем заходит формат или я что-то сказал не так. Всегда открыт для критики, только конструктивной и аргементированной

[@itgik]

LiveData умеет работать с dataBinding, ее можно использовать напрямую в xml layouat'ах. Есть ли такая поддержка у Flow? Это было бы очень здорово, чтобы полностью перейти на Flow

[@AndroidBroadcast]

Да, помойму в AS 4.2 такая возможность появилась

[@Chernov1984]

+

[@СергейПанов-з3ц]

Чем плоха LiveData? По мне у неё только один минус - она может обсервить только в главном потоке.

[@AndroidBroadcast]

Я не говорю что она плоха, но у Flow есть преимущества: - Возможность работать на множестве поток - Единый подход на всех слоях - Большое количество операторов для Flow - Больше гибкости чем в LiveData

[@СергейПанов-з3ц]

@@AndroidBroadcast я к тому что не нужно бежать переписывать существующий код на LiveData на Flow.

[@AndroidBroadcast]

Это с любой новомодной технологий и трендами. Всегда нужно иметь свою голову.

[@ViperCinema4D]

Минусы LiveData по сравнению с Shared/StateFlow: - В LiveData по дефолту не требует указывать начальное значение - LiveData не поддерживает нуллабельный дженерик - например если завести поле LiveData, то его 'value' всё равно будет иметь тип 'String?' - У LiveData нет возможности делать поток событий без костылей типа SingleLiveEvent

[@AlexKhomenock]

@@ViperCinema4D насчёт последнего, у flow тоже нет нормального способа реализовать такое поведение

[@Nidvoraich]

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

[@AndroidBroadcast]

Множество оптимизаций выполняет компиллятор Kolin, а также R8/ProGuard в релизных сборках. Заниматься написанием кода, который должен поддерживать старые слабые устройства непростая задача и мало у кого есть на нее ресурсы, так как это накладывает дополнительное время разработки и тестирования

[@Nidvoraich]

@@AndroidBroadcast я в Андроид пришёл после программирования микроконтроллеров, где каждый бит на счету :) Для меня создать анонимный КЛАСС для выполнения одного действия - это как из пушки по воробьям :)

[@AndroidBroadcast]

Все мы формируемся своим опытом и взглядами

[@bolnoi8]

Старая противная LiveData, новая крутая flow, а я всё ещё на Rx сижу...

[@AndroidBroadcast]

Rx рабочая штука, только по мне всегда была слишком сложной и некоторые операторы неочевидны

[@krokenstiv8777]

вечно какую то херню придумывают и через полгода от нее отказываются.

[@AndroidBroadcast]

LiveData никто не предлагает заменить и она прекрасно может выполнять свою функцию дальше, но есть те кто хочет проводить через Coroutine всё. Вот этот ролик для таких людей

[@МихаилДорохин-у6э]

В lifecycleScope.launchWhenStarted нужно вызывать launchIn(this) вместо launchIn(lyfecycleScope), а не collect(), тогда он не будет блокировать поток выполнения и можно подписаться на несколько Flow в одном скоупе.