Channel или mutablesharedflow , какой из них является лучшей заменой устаревшему localbroadcastmanager
Раньше я использовал LocalBroadcastManager and EventBus в своих приложениях для чата и такси, которые сейчас либо устарели, либо не рекомендуются к их использованию.
Я намерен заменить их новыми структурами данных, такими как mutablesharedflow or channel,
Я хочу знать, какой из них лучше подходит для моего случая? или, может быть, другая структура данных?
Ответы 2
От Романа Елизарова Каналы добавлены как примитив межкорутинной связи.
Вы не можете использовать каналы для распространения событий или обновлений состояния таким образом, чтобы несколько подписчиков могли независимо получать их и реагировать на них.
Так они представили Flow. Но Flow — это холодная наблюдаемая, где каждый подписчик получает свои данные (независимые от других подписчиков). С SharedFlow вы получаете горячее наблюдаемое, которое генерируется независимо от наличия подписчиков.
Вы можете сделать то же самое с ConflatedBroadcastChannel. Но JetBrains рекомендует использовать Flow вместо Channels из-за их более простого API.
Так что, если вы хотите перейти на Coroutines и вам нужно горячее наблюдаемое, которое могут слушать несколько подписчиков, вам следует использовать SharedFlow.
Пожалуйста. StateFlow расширяет SharedFlow. Это то же самое, но с кешированным свойством value. Таким образом, вы можете получить его последнее состояние в любое время, даже вне наблюдения за потоком, такого как yourStateFlow.value. Поэтому, если вы хотите не только уведомить, но и разрешить другим запрашивать текущее состояние/значение потока, вы должны использовать StateFlow.
Примечание: ConflatedBroadcastChannel устарел с версии 1.5.0. Он будет объявлен устаревшим с предупреждением в 1.6.0 и с ошибкой в 1.7.0. Он заменен на StateFlow. Так что с этого момента следует избегать его использования. Если вы хотите, чтобы несколько подписчиков подписывались на одно и то же событие, используйте SharedFlow.
Оба хороши для прослушивания одноразовых событий. Все зависит от ваших вариантов использования.
SharedFlow, известный как hot flow ->
- Выдавать события, даже если их не слушает ни один наблюдатель
- Если ни один наблюдатель не слушает его, вы теряете эти события.
Каналы, известные как cold flow
- Не генерирует события, когда его не слушает ни один наблюдатель. Он работает как BlockingQueue.
- Когда вы начинаете собирать, он собирает все данные, которые были отправлены.
Это неправильно. Каналы горячие, а не холодные. Канал потребляет ресурсы, пока не будет закрыт.
Канал горячий, а SharedFlow холодный.
@TarifChakder Оба горячие, с официального сайта: «Общий поток называется горячим, потому что его активный экземпляр существует независимо от наличия сборщиков».
Я очень ценю ваш комментарий, он очень полезен. я на самом деле забыл принять во внимание MutableStateFlow, я хотел бы знать ваше мнение о StateFlow и SharedFlow в этом сценарии?