Комментарии 9
Для отправки единичных эвентов из viewModel лучше использовать
MutableSharedFlow<T>(replay = 0, extraBufferCapacity = 1, BufferOverflow.DROP_OLDEST)
В данном случае будет сохраняться последний отправленный эвент, до первого считывания его подписчиком.
К сожалению, не будет. При отсутствии подписчиков сохраняются только значения попавшие в replay буфер. Выдержка из документации:
In the absence of subscribers only the most recent [replay] values are stored and the buffer overflow behavior is never triggered and has no effect.
Я так и не понял зачем вы сделали миграцию в сторону сложности... Гибкости я в ваших примерах не увидел. И вы правильно сказали, что flow сделан для общения между корутинами. Но у нас view <-> viewmodel.
Можно привести пример, что сделать на flow можно лучше, или удобнее в разрезе заявленной задачи. Я как flow не крутил в данном контексте им применения не смог найти. Ну т.е. можно, но зачем?
Ну и google рекомендует конвертировать flow в livedata перед передачей в view.
Ну и google рекомендует конвертировать flow в livedata
LiveData is still our solution for Java developers, beginners, and simple situations. For the rest, a good option is moving to Kotlin Flows.
Ну это статья на medium с мнением одного человека.
Ну и суть не в этом. Такая рекомендация была и вполне была обоснована. Чем обоснован переход на flow я не вижу и даже не вижу попыток это объяснить....
Этот один человек – Developer Relations Engineer @ Google, working on Android. Я крайне сомневаюсь, что у них там нет единой линии между всеми деврелами, которой они придерживаются.
Чем обоснован переход на flow
Просто попытка не плодить сущности. Вот есть обсервабл дата холдер в виде LiveData. Сторонняя зависимость по сути из одного класса. Которая еще и в тестах требует под себя целую рулу (InstantTaskExecutorRule). И тут внезапно появляется похожая штука, которая по сути часть стандартной библиотеки Kotlin, так еще и с более обширным API.
Тратить время на целенаправленную миграцию кмк смысла нет, но потихоньку выпиливать можно.
Ну если бы это была официальная политика партии, то они бы опубликовали такое заявление на android.com
Ну и я бы хотел верить, что разногласия там все же есть :) Это полезно для нас :)
Я согласен, что штука похожая, но вот была отличная штука, которая наконец смогла подружится с ЖЦ view, не сильно затратная. А потом сделали похожая, только без синхронизации ЖЦ с кучей API и вариантов использования.
И многие тут же ринулись под эти знамёна. Я не против, я просто аргументов не вижу.
А сущности тут наплодили достаточно. Можно на handler и thread это все сделать, собственно лет 10 назад так и писал. А потом asynctadk, loaders, fragment, workers и теперь корутины... С тех пор не спешу с миграциями, без хороших аргументов :)
Deleted
для одноразовых событий лучше делать Channel(Channel.BUFFERED) все же,
так как shared отправит событие каждому подписчику, причем только одно, а шаред все отправит и только один раз каждое, независимо от количества подписчиков. А если надо только последнее всегда хранить, то можно ему задать capacity = 1 и onBufferOverflow = DROP_OLDEST.
вот пример - https://pl.kotl.in/HB6oyAjkM
От LiveData к Flow…