# kotlin-flow Kotlin Flow is an asynchronous data-stream abstraction that sequentially emits values and completes normally or with an exception. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How Kotlin Flow Operator Fusion Works and When Ordinary Operators Break It DevFeed: [How Kotlin Flow Operator Fusion Works and When Ordinary Operators Break It]() Original publisher: [Read original article]() Author: Majidshahbaz Published: 2026-09-13T05:43:21Z Content type: article Language: en Sources: [ProAndroidDev - Medium]() Topics: [kotlin-flow](), [Coroutines](), [Code]() Tags: [android](), [code](), [coroutines](), [jetpack-compose](), [kotlin](), [kotlin-coroutines](), [kotlin-flow]() ### AI overview This article investigates Kotlin Flow operator fusion by instrumenting the runtime and comparing pipelines with adjacent fusible operators against pipelines interrupted by an ordinary map() call. It explains that adjacent channelFlow, flowOn, buffer, and produceIn calls can share one underlying channel through FusibleFlow, while an intervening non-fusible operator causes additional wrapper structure. ### Source excerpt Image Generated for the ArticleI Counted Every Hidden Channel Kotlin Flow Creates -- Most Devs Are Wrong About Which Operators Are Freebuffer() and flowOn() are supposed to fuse into one channel when chained. I wrote code to prove it -- and then found four "harmless" operators that quietly break it. Ask any experienced Kotlin developer what happens when you chain .buffer().flowOn(Dispatchers.IO).buffer(), and you'll usually get a confident answer: "it fuses into one channel." That's the folklore, repeated in talks, docs, and Stack Overflow answers. It's also only half true, and nobody seems to have actually checked the other half: which everyday operators quietly stop that fusion from happening. I decided to stop trusting folklore and instrument the actual runtime. Five separate experiments later, I had a very clear, very measurable answer -- and one of the results genuinely surprised me. The Myth, and the Mechanism Behind It Kotlin's coroutines library really does fuse adjacent channelFlow, flowOn, buffer, and produceIn calls into a single underlying channel instead of creating one per operator. This isn't a rumor -- it's real, deliberate behavior, implemented through an interface called FusibleFlow. Here's the actual check, straight from the source: https://medium.com/media/1cd3b407c1f2b2955b3df4be68ca18b5/href When flowOn() or buffer() is called, it checks whether the flow it's being called on already implements FusibleFlow. If it does, instead of wrapping it in a new object, it calls .fuse() -- which updates the existing object's settings (buffer size, dispatcher) in place. No new object. No new coroutine. No new channel. But that check only succeeds if the upstream is already a ChannelFlow. And that's where the folklore quietly stops being true. Building Something to Actually Measure This I wrote two nearly identical pipelines -- one where the fusible operators sit directly next to each other, and one where a completely ordinary map() sits in the middle: https://medi ## A Kotlin Flow Guessing Game DevFeed: [A Kotlin Flow Guessing Game]() Original publisher: [Read original article]() Published: 2026-03-23T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [kotlin-flow](), [Kotlin]() Tags: [fun](), [kotlin](), [kotlin-flow](), [workshop-learning-programming]() ### AI overview A game designed to test and strengthen understanding of Kotlin Flow. ### Source excerpt A fun game that pushes your understanding of Kotlin Flow. ## Kotlin Flow to RxJava or Reactor and vice versa DevFeed: [Kotlin Flow to RxJava or Reactor and vice versa]() Original publisher: [Read original article]() Published: 2025-09-22T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [kotlin-flow](), [RxJava](), [Reactive Streams](), [interoperability](), [kotlin-coroutines]() Tags: [how-to](), [interoperability](), [kotlin](), [kotlin-flow](), [reactive-streams](), [rxjava](), [workshop-learning-programming]() ### AI overview A guide to converting Kotlin Flow to RxJava or Reactor streams and converting those streams back to Kotlin Flow. It covers interoperability libraries, extensions, coroutine-based stream creation, and handling single-value or no-value operations. ### Source excerpt A guide on how to convert Kotlin Flow to RxJava or Reactor streams and vice versa. ## Kotlin Coroutines and Swift DevFeed: [Kotlin Coroutines and Swift]() Original publisher: [Read original article]() Published: 2025-09-15T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [kotlin-coroutines](), [Swift](), [Kotlin Multiplatform](), [Structured concurrency](), [async/await](), [kotlin-flow](), [kotlin-native](), [iOS]() Tags: [async](), [cancellation](), [coroutines](), [how-to](), [kotlin](), [kotlin-flow](), [kotlin-multiplatform](), [kotlin-native](), [structured-concurrency](), [swift](), [workshop-learning-programming]() ### AI overview This tutorial explains how to bridge Kotlin Coroutines and Swift's async/await and structured concurrency in Kotlin Multiplatform iOS projects. It covers suspending functions, exception conversion, Kotlin Flow to AsyncSequence, and calling Swift async functions from Kotlin. ### Source excerpt How to use Kotlin Coroutines in Swift projects, or Swift libraries from Kotlin Coroutines. ## Understanding Kotlin Flow flatMapMerge behavior DevFeed: [Understanding Kotlin Flow flatMapMerge behavior]() Original publisher: [Read original article]() Published: 2024-03-06T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [kotlin-flow](), [kotlin-coroutines](), [Concurrency]() Tags: [concurrency](), [fetch](), [how-to](), [kotlin](), [kotlin-coroutines](), [kotlin-flow](), [workshop-learning-programming]() ### AI overview This article explains surprising aspects of Kotlin Flow's flatMapMerge, including its synchronous transformation step, default concurrency limit of 16, and inconsistent behavior when the concurrency is set to 1. It examines the implementation and presents patterns for handling asynchronous transformations. ### Source excerpt How not to get surprised by flatMapMerge behavior. ## Collecting items from the Flow in chunks💦 DevFeed: [Collecting items from the Flow in chunks💦]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2023-10-23T04:46:23Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [kotlin-flow](), [Kotlin](), [kotlin-coroutines](), [Programming](), [reactive](), [SQLite]() Tags: [collect](), [coroutines](), [flow](), [guide](), [how-to](), [kotlin](), [kotlin-coroutines](), [kotlin-flow](), [multithreading](), [reactive-programming]() ### AI overview A practical guide to collecting Kotlin Flow items in time-based chunks without losing produced data. It explains why batching high-frequency analytics events can reduce the cost of repeated database or network operations and outlines an operator implementation. ### Source excerpt Learn how to collect Kotlin Flow items in chunks or intervals without losing data. A practical guide to handling high-frequency data streams efficiently. ## Strategies for automatically refreshing data on Android using Kotlin Flow DevFeed: [Strategies for automatically refreshing data on Android using Kotlin Flow]() Original publisher: [Read original article]() Author: Christophe Beyls Published: 2023-10-06T17:27:03Z Content type: tutorial Language: en Sources: [Stories by Christophe Beyls on Medium]() Topics: [kotlin-flow](), [Kotlin](), [Android](), [RxJava](), [ui]() Tags: [android](), [android-app-development](), [androiddev](), [api](), [coroutine](), [flow](), [kotlin](), [kotlin-flow](), [rxjava](), [sharedflow](), [ui]() ### AI overview This tutorial explains how to periodically refresh data in Android user interfaces with Kotlin Flow. It compares sequential map() processing with concurrent, cancellation-aware mapLatest() processing and discusses lifecycle-aware refreshing and caching considerations. ### Source excerpt Making timers lifecycle-aware This is the third part of a series of articles discussing the usage of Kotlin Flow to efficiently load data in Android applications. It's a direct follow-up to part 2: "Smarter Shared Kotlin Flows", as it reuses the same concepts to cover another use case: automatic periodic refresh of the user interface. Simple periodic refresh When it's not possible to determine precisely when a data set displayed by the UI has changed, or when it changes too frequently, a common strategy is to reload the data periodically at a fixed interval while the screen is visible. One of the simplest ways to achieve this is to create a Flow from an infinite loop calling delay() between emissions: fun tickerFlow(period: Duration): Flow = flow { while (true) { emit(Unit) // Tick delay(period) } } This is equivalent to the Observable.interval() operator in RxJava with a fixed emitted value (Unit) and an initial delay of 0. Then, transform this Flow using the map() or mapLatest() operator to perform the loading action on each "tick" of the timer and return the result: tickerFlow(REFRESH_INTERVAL) .map { repository.loadSomeData() } Note the subtle difference in behavior between the two operators: With map() the entire Flow will be executed in sequence within a single coroutine, meaning delay() will only start running after the loading operation completes. As a result, each loading operation will be delayed by the amount of time it took to perform the previous loading operation, plus the fixed interval. With mapLatest() the main coroutine will collect the upstream values of tickerFlow() while a child coroutine will be created to perform the loading operation concurrently and collect the result without suspending the main coroutine. This means that delay() will start running immediately after the previous tick and each loading operation will start precisely according to schedule. This also means that the interval must be longer than the typical loading time beca ## PermissionFlow: A Reactive API for knowing the status of Android app permissions DevFeed: [PermissionFlow: A Reactive API for knowing the status of Android app permissions]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2023-05-22T05:19:08Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Android](), [Library](), [reactive](), [Kotlin](), [kotlin-flow](), [Authorization](), [Coroutines]() Tags: [android](), [android-app-development](), [android-development](), [coroutines](), [jetpack-compose](), [kotlin](), [kotlin-flow](), [permission](), [reactive]() ### AI overview PermissionFlow is an open-source Android library that provides a reactive API for tracking permission states across app modules. The article explains how it can notify subscribers of permission changes, including changes made in app settings, and describes Kotlin Flow, testing, and Jetpack Compose support. ### Source excerpt Introduction to PermissionFlow: A reactive API for Android that simplifies tracking permission status changes using Kotlin Coroutines and Flow. ## Reactive streams testing DevFeed: [Reactive streams testing]() Original publisher: [Read original article]() Published: 2023-01-08T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [Reactive Streams](), [Testing](), [API](), [Documentation](), [kotlin-flow](), [RxJava](), [Refactoring](), [callback]() Tags: [api](), [code](), [documentation](), [kotlin](), [kotlin-flow](), [reactive-streams](), [refactoring](), [rxjava](), [testing]() ### AI overview This article explains how to test reactive-stream APIs, using RxJava and Kotlin Flow as examples. It emphasizes testing emitted values and other implicit behavior so tests document public API expectations and support safer migrations and refactoring. ### Source excerpt Introduction We should test the code to guarantee that it does exactly what it is expected to do. Tests not only verify correctness of the program but also set expectations. This becomes especially useful for public API, where tests can be treated as part of documentation that describes not only results but also behavior. Such things help do less painful migrations and refactoring as it becomes clear what behaviors are changing and what we should do about that. ## Kotlin Coroutines Course Adds Kotlin Flow Modules for Android Development DevFeed: [Kotlin Coroutines Course Adds Kotlin Flow Modules for Android Development]() Original publisher: [Read original article]() Author: Lukas Lechner Published: 2022-11-21T14:57:43Z Content type: release Language: en Sources: [Lukas Lechner]() Topics: [Kotlin](), [kotlin-flow](), [Coroutines](), [kotlin-coroutines](), [android-development](), [Mobile]() Tags: [allgemein](), [android-development](), [coroutines](), [course](), [flow](), [kotlin](), [kotlin-coroutines](), [kotlin-flow]() ### AI overview The author announces an update to an existing Kotlin Coroutines course for Android, adding modules about Kotlin Flow. The update includes 6 hours of video content, bringing the course to 15 hours in total. ### Source excerpt Hi Readers 👋 There hasn't been a lot of news from my side lately, but today I can announce something big! I spent the last months extending my already existing Course about Kotlin Coroutines for Android with modules about Kotlin Flow! The result is an additional 6 hours of video content about Kotlin Flow, making Read More The post My Coroutines Course just got a BIG update: Kotlin Flow for Android Development first appeared on Lukas Lechner. ## Using Coroutines and Flows with Firebase on an Android app DevFeed: [Using Coroutines and Flows with Firebase on an Android app]() Original publisher: [Read original article]() Author: Marina Coelho Published: 2022-10-26T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Coroutines](), [Kotlin](), [Firebase](), [kotlin-coroutines](), [kotlin-flow](), [Android](), [Compose]() Tags: [android](), [compose](), [coroutine](), [coroutines](), [firebase](), [flow](), [how-to](), [jetpack-compose](), [kotlin](), [kotlin-coroutines](), [kotlin-flow]() ### AI overview A tutorial on replacing callback-based Firebase service calls with Kotlin Coroutines and Kotlin Flow in an Android application built with Jetpack Compose. It covers Firebase Authentication and Cloud Firestore examples. ### Source excerpt Learn how to use Kotlin Coroutines and Kotlin Flows with Firebase on an Android app built with Jetpack Compose. ## Smarter Shared Kotlin Flows DevFeed: [Smarter Shared Kotlin Flows]() Original publisher: [Read original article]() Author: Christophe Beyls Published: 2022-06-06T16:44:02Z Content type: tutorial Language: en Sources: [Stories by Christophe Beyls on Medium]() Topics: [kotlin-flow](), [Kotlin](), [Android]() Tags: [android](), [android-app-development](), [androiddev](), [database](), [efficiency](), [flow](), [kotlin](), [kotlin-flow](), [livedata](), [sharedflow]() ### AI overview This second article in a Kotlin Flow on Android series explains how SharedFlow and StateFlow using SharingStarted.WhileSubscribed() can restart upstream work when a lifecycle becomes active again. It compares this behavior with lifecycle-aware LiveData and proposes designing a Flow operator that propagates lifecycle state upstream to avoid unnecessary network requests or database queries. ### Source excerpt Make the lifecycle available to the upstream Flow to skip unnecessary work This is the second part of a series of articles about using Kotlin Flow on Android. In the first part, we described the main limitation of Kotlin Flow when used inside ViewModel classes: When a SharedFlow or StateFlow using the SharingStarted.WhileSubscribed() strategy is collected again after the user navigates back to an Activity or Fragment, its source upstream Flow will always restart from scratch, sometimes resulting in unnecessary work being performed when the previously cached data was still valid. val results: StateFlow = queryFlow.mapLatest { query -> repository.search(query) }.stateIn( scope = viewModelScope, started = SharingStarted.WhileSubscribed(5000L), initialValue = SearchResult.EMPTY ) In the above example, repository.search() will be executed again even if the latest value of queryFlow didn't change in the meantime. This means a potential unnecessary network request or database query. LiveData doesn't suffer from this issue because its observers don't need to unsubscribe when they become inactive: LiveData is lifecycle-aware and will postpone the delivery of new results until it becomes active, while also ensuring that the same result will never be delivered to the same observer twice (even when it becomes active again). For more details I invite you to read the full article. At the end of this first part, we concluded that there was no simple and correct way to avoid performing this unnecessary work when relying only on the standard shareIn() or stateIn() operators. In this second part, we are going to solve that efficiency problem by designing a new Flow operator that will allow SharedFlows to integrate better with the lifecycle. Synchronizing with the LifecycleLiveData The core reason why LiveData deals with lifecycles better than Flow is because the lifecycle state is automatically propagated upstream through all the LiveData instances so they can all pause ## Kotlin Flow Notes: Producers, Consumers, Operators, and Hot and Cold Flows DevFeed: [Kotlin Flow Notes: Producers, Consumers, Operators, and Hot and Cold Flows]() Original publisher: [Read original article]() Published: 2022-04-27T16:16:06Z Content type: tutorial Language: en Sources: [maiatoday]() Topics: [kotlin-flow](), [Kotlin](), [Coroutines](), [Large Screen](), [Streams]() Tags: [android](), [article](), [asynchronous](), [cheat-sheet](), [code](), [coroutine](), [coroutines](), [coroutines-flow](), [flow](), [kotlin](), [kotlin-coroutines](), [kotlin-flow](), [sharedflow](), [sketch-note](), [stateflow](), [streams]() ### AI overview A set of companion sketch notes about Kotlin Flow, covering suspend functions, streams of multiple values, producers and consumers, terminal and transform operators, execution contexts, hot and cold flows, and Android usage. ### Source excerpt This post is my companion sketch notes for all the resources I consumed on the topic of flows. It is not meant to replace the info that I found on the internet but rather supplement it. Nor is it complete or should it be a standalone guide. In fact you can find an excellent list of my favourite resources at the end of the article. It is a document that helps me make sense of the topic. With that disclaimer out of the way... Let's take a step back and look at the suspend function. If your coroutine knowledge is rusty, freshen that up first. What if we want to provide multiple values? A stream of values that can be observed? Enter flows. At their most basic, flows have a producer and a consumer. The interface looks like this (spoiler it's just suspend functions under the hood) The consumer gets the multiple values by using a terminal operator. If I need to change the produced values along the way before consuming them, there are transform operators. How do I switch from main to io context? What's with the hot and cold flows? How do I remember which is which? Some practical hot flows. Flows on Android References Kotlin Coroutines Flow in a nutshell Kotlin Flows ~ an Android cheat sheet Kotlin Flows in Android summary Android flow Asynchronous Flow | Kotlin Flow under the hood: how does it really work KotlinConf 2019: Asynchronous Data Streams with Kotlin Flow by Roman Elizarov Kotlin Flows in a Nutshell FlowMarbles Android StateFlow and SharedFlow If you are reading this far I will reward you with an Android portait. ## QueryBuilder: How I wrote a runtime SQL query generator for an Android app DevFeed: [QueryBuilder: How I wrote a runtime SQL query generator for an Android app]() Original publisher: [Read original article]() Author: Sanskar Agrawal Published: 2022-02-07T12:05:01Z Content type: tutorial Language: en Sources: [Sanskar's Stuff]() Topics: [Android](), [SQL](), [Databases](), [Kotlin](), [Object-relational mapping](), [SQLite](), [kotlin-flow](), [coding]() Tags: [android](), [app-development](), [coding](), [database](), [kotlin](), [kotlin-flow](), [orm](), [room](), [sorting](), [sql](), [sqlite]() ### AI overview A developer explains how an Android app called Transactions uses Room ORM over SQLite and Kotlin Flow, then describes the need for incremental sorting and filtering. The article compares filtering Kotlin lists with writing custom DAO methods for every query combination, motivating a runtime SQL query generator. ### Source excerpt I've been building an app called Transactions for some time. As the name suggests, Transactions offers you the capability to track your income and expenses made through cash or digital mediums. I mostly wrote it for my personal use, but it caught on ... ## Kotlin property delegates for Datastore Preferences library DevFeed: [Kotlin property delegates for Datastore Preferences library]() Original publisher: [Read original article]() Author: Yahor Urbanovich Published: 2021-08-23T15:40:08Z Content type: tutorial Language: en Sources: [Stories by Yahor Urbanovich on Medium]() Topics: [Kotlin](), [Library](), [Coroutines](), [kotlin-flow](), [migration]() Tags: [android](), [android-app-development](), [androiddev](), [coroutines](), [delegates](), [delegation](), [deprecated](), [flow](), [kotlin](), [kotlin-flow](), [library](), [migration](), [property-delegation](), [suspend-function]() ### AI overview This tutorial explains migrating preference storage from SharedPreferences to AndroidX DataStore Preferences. It shows how Kotlin property delegation can encapsulate reading and writing values, and how Flow, coroutines, first(), and runBlocking can support single-value access despite DataStore's Flow-based API. ### Source excerpt Kotlin delegated property for Datastore Preferences library Recently AndroidX Datastore 1.0 was released. The moment has come, it's time to migrate away from SharedPreferences. As for me, the key benefit is the built-in support of Kotlin Flow and Coroutines. Previously we had to write our own wrapper under SharedPreferences.OnSharedPreferenceChangeListener, emit changes into ConflatedBroadcastChannel and then convert it into Flow. https://medium.com/media/b5410ce9df08d9b73427a2138a6b0a8d/href Firstly, this approach produces a lot of intermediate variables. Secondly, ConflatedBroadcastChannel deprecated and should be replaced with StateFlow. In this case, DataStore comes out as the winner. The migrated to DataStore version looks clean and simple. https://medium.com/media/cce0d485e2af9941e677dc7973a54c6f/hrefRead/write single value using SharedPreferences Let's imagine, we need to store the current App theme as String. For this purpose, we need to initialize SharedPreferences, then make two functions to read and write these values. https://medium.com/media/3bc9760a22ebd1071e4dcb21eaf8d4ba/href Well, two functions it is not so bad, but we can try to merge this into single Property. https://medium.com/media/c3babbf2b6c55bb18172f66ddc825b06/href To make it fully clear and supportable we can use the Kotlin delegation feature. As we want to read and write simultaneously, ReadWriteProperty will suit our goal. https://medium.com/media/80f370a5a5735b911c75d3a0f1d22b21/href Please take a look at the final compact version, where all logic is encapsulated inside the delegate. https://medium.com/media/39b5311b04373b1f31d3030b8b083587/hrefDataStore Preferences and missing API During migration, it turned out that the library doesn't provide an API for reading a single property. DataStore proposes to use Flow for all cases. Developers are now required to read/write the value in the scope of a suspend function. https://medium.com/media/e7c4e45e239e11bc5082f3997e5280dd/href What was e ## Kotlin flow: Nesting vs Chaining DevFeed: [Kotlin flow: Nesting vs Chaining]() Original publisher: [Read original article]() Published: 2021-07-08T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [kotlin-flow](), [Kotlin](), [Reactive Streams](), [reactive](), [RxJava]() Tags: [kotlin](), [kotlin-flow](), [reactive](), [reactive-streams](), [rxjava]() ### AI overview A tutorial comparing nesting and chaining in Kotlin Flow reactive streams. It explains that chaining can improve readability for simple sequential streams, while nesting is useful for sharing data across streams and managing stream lifecycles, such as conditionally observing a user's location. ### Source excerpt Introduction When it comes to reactive streams it is likely everyone heard about huge 'Rx-chains'. But reactive streams are not only about chaining but also about nesting. Let's find out what are they, what are the differences, and why it matters. We'll use Kotlin Flow throughout the article, but everything can be applied to RxJava as well. First of all, we need to come up with definitions. For that, we'll take a look at some simple streams. ## Android Room Hidden Costs DevFeed: [Android Room Hidden Costs]() Original publisher: [Read original article]() Published: 2020-12-18T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [Databases](), [kotlin-flow](), [SQLite](), [Reactive Streams](), [RxJava](), [Android](), [Android Studio]() Tags: [android](), [android-studio](), [databases](), [kotlin-flow](), [reactive-streams](), [rxjava](), [sqlite]() ### AI overview This article examines the hidden costs of using Android Room to support reactive streams. It explains how Room uses SQLite triggers and an internal invalidation table to detect changes, trigger callbacks, and automatically re-query data for observers. ### Source excerpt Introduction Android Room is an awesome AndroidX library. It is great because it provides a clean way of how to deal with databases without introducing some heavy concepts. Out of the box with Room one gets: simplified code comparing with raw SQLite queries working via DAO interfaces and models instead of Cursors auto-generated "boilerplate" code for queries migration support Android Studio tooling (compile-time verification of queries and highlight) support for reactive streams (RxJava, Kotlin Flow) and more In this article, I'd like to discover some hidden costs Room applies to support reactive streams and how one can try to avoid them. ## Shared flows, broadcast channels DevFeed: [Shared flows, broadcast channels]() Original publisher: [Read original article]() Author: Roman Elizarov Published: 2020-11-16T13:16:59Z Content type: article Language: en Sources: [Stories by Roman Elizarov on Medium]() Topics: [Kotlin](), [kotlin-flow](), [Coroutines](), [Concurrent Programming](), [Streams]() Tags: [asynchronous](), [channel](), [concurrent](), [coroutine](), [flow](), [kotlin](), [kotlin-flow](), [streams](), [synchronization]() ### AI overview This article explains why Kotlin shared flows were introduced as a replacement for broadcast channels for distributing events and state updates to multiple subscribers. It contrasts channel-based transformations with Kotlin Flow, emphasizing the synchronization costs of channels and the efficiency of flow transformations. ### Source excerpt Photo by Davies Designs Studio on Unsplash Once upon a time coroutines were introduced to Kotlin and they were lightweight. We could launch a multitude of coroutines and we needed a way to communicate between those coroutines without running into a dreaded "mutable shared state" problem. Thus Channel was added as an inter-coroutine communication primitive. The channels are wonderful. Channels support one-to-one, one-to-many, many-to-one, and many-to-many communication between coroutines, and every value that is sent to the channel is received once. Diagram of many-to-many channel operation You cannot use channels to distribute events or state updates in a way that allows multiple subscribers to independently receive and react upon them. Thus the BroadcastChannel interface was introduced with buffered and ConflatedBroadcastChannel as its implementations. They served us well for a while, but they turned out to be a design dead-end. Now, since kotlinx-coroutines version 1.4 we have introduced a better solution -- shared flows. Read on for the full story. Flows are simple In the early versions of the library, we had only channels and we tried to implement various transformations of asynchronous sequences as functions that take one channel as an argument and return another channel as a result. It means that, for example, a filter operator would run in its own coroutine. Diagram of filter operator with channels The performance of such an operator was far from great, especially compared to just writing an if statement. In a hindsight, it is not surprising, because a channel is a synchronization primitive. Any channel, even an implementation that is optimized for a single producer and a single consumer, must support concurrent communicating coroutines and a data transfer between them needs synchronization, which is expensive in modern multicore systems. When you start building your application architecture on top of the asynchronous data streams, the need to have transformat ## Kotlin Flow Compared with RxJava: Benefits and Trade-offs DevFeed: [Kotlin Flow Compared with RxJava: Benefits and Trade-offs]() Original publisher: [Read original article]() Published: 2020-05-17T00:00:00Z Content type: article Language: en Sources: [Vasya Drobushkov]() Topics: [kotlin-flow](), [RxJava](), [Kotlin]() Tags: [article](), [kotlin](), [kotlin-flow](), [rxjava]() ### AI overview A follow-up analysis compares Kotlin Flow with RxJava, discussing claimed benefits, drawbacks, and trade-offs. The article examines channels, StateFlow, subjects, and experimental API compatibility. ### Source excerpt Source Introduction Recently the article about Kotlin Flow benefits over RxJava was published by Antoni Castejón García: Kotlin Flow benefits over RxJava Though Antoni made a good work and many thanks to him for providing his feedback and experience (we need to share our thoughts, this improves community acknowledgment in various areas) -- I found few places in the article with which I don't fully or partially agree. Some points, in my opinion, were missing. So, I decided to make a follow-up feedback post on what I consider the real benefits of Kotlin Flow over RxJava. Feedback is also a good thing as it helps us to drive forward and maybe look at the same things from a different angle. ## Integrating Firebase Cloud Firestore with Kotlin Coroutines and Flow in Android DevFeed: [Integrating Firebase Cloud Firestore with Kotlin Coroutines and Flow in Android]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2020-04-30T07:35:30Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Firebase](), [Firestore](), [Kotlin](), [kotlin-coroutines](), [kotlin-flow](), [Android](), [reactive]() Tags: [android](), [firebase](), [firestore](), [flow](), [how-to](), [kotlin](), [kotlin-coroutines](), [others](), [reactive]() ### AI overview This tutorial demonstrates how to use Kotlin Coroutines and Flow with Firebase Cloud Firestore in Android. It explains Flow as a cold reactive stream and shows a repository-based approach for exposing loading, success, and failure states while retrieving posts. ### Source excerpt Learn how to integrate Firebase with Kotlin Coroutines and Flow for reactive data streams in your Android applications. ## Kotlin Mumbai: Kotlin basics and Flows DevFeed: [Kotlin Mumbai: Kotlin basics and Flows]() Original publisher: [Read original article]() Author: Siddhesh Patil Published: 2020-04-27T13:26:47Z Content type: article Language: en Sources: [Sid Patil - Android Engineer and Kotlin Advocate]() Topics: [Kotlin](), [kotlin-flow](), [Coroutines](), [Development](), [Programming]() Tags: [akshay-chordiya-gde-android](), [android-developers-in-mumbai](), [async](), [community](), [development](), [filip-babic-gde-in-kotlin](), [kotlin](), [kotlin-flow](), [kotlin-mumbai](), [kotlin-user-group-in-mumbai](), [kug](), [programming](), [talks-in-mumbai]() ### AI overview A Kotlin Mumbai meetup recap covering an introductory Kotlin session by Filip Babić and a session by Akshay Chordiya on asynchronous programming with Kotlin Flows and coroutines. The online event was held on Google Meet and attracted 50-60 attendees. ### Source excerpt Filip Babic and Akshay Chordiya take us through the world of kotlin! ## From RxJava to Kotlin Flow: Testing DevFeed: [From RxJava to Kotlin Flow: Testing]() Original publisher: [Read original article]() Published: 2020-03-05T00:00:00Z Content type: comparison Language: en Sources: [Vasya Drobushkov]() Topics: [kotlin-flow](), [RxJava](), [Testing](), [Development]() Tags: [compare](), [error-handling](), [kotlin](), [kotlin-flow](), [rxjava](), [testing]() ### AI overview This article compares testing in RxJava and Kotlin Flow. It covers RxJava's TestObserver and TestScheduler, Kotlin Flow's TestCoroutineScope and TestCoroutineDispatcher, and examples of asserting stream values and completion. ### Source excerpt Source This post is part of series of comparing RxJava to Kotlin Flow. Previous articles were about Threading, Backpressure, Error Handling, Stream Types, Throttling Introduction Testing is a crucial part of whole development. Testing allows you to write programs in a reliable fashion, prevent regressions and have many other goodies. I won't go through the list of advantages of writing tests in this article though. In testing it is important to have tools which allow you to write reliable tests and also tools which allow you to test your business logic. Business logic might be inside some function which calculates data and returns result, but also it might be some loading of data from network or doing some work in reaction to UI events. In places where we might have RxJava integrated. So it is very important to be able to test our rx-chains. In this article we'll go through the most important concepts in RxJava testing and compare it with what we have in Kotlin Flow. ## From RxJava to Kotlin Flow: Stream Types DevFeed: [From RxJava to Kotlin Flow: Stream Types]() Original publisher: [Read original article]() Published: 2020-02-26T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [kotlin-flow](), [RxJava](), [Programming](), [reactive](), [backpressure]() Tags: [backpressure](), [flow](), [kotlin](), [kotlin-flow](), [reactive](), [reactive-programming](), [rxjava]() ### AI overview This article compares stream types in RxJava and Kotlin Flow as part of a migration series. It explains RxJava's Observable, Flowable, Single, Maybe, and Completable, then maps them to Kotlin Flow or suspending functions and highlights differences in backpressure and stream composition. ### Source excerpt Source This post is part of series of comparing RxJava to Kotlin Flow. Previous articles were about Threading, Backpressure, Error Handling Introduction In reactive programming we use streams. Therefore in both RxJava and Kotlin Flow we'll have to use some streams. Though we'll encounter some differences if we decide to migrate. In this article we'll try to get into the stream types which have RxJava and Kotlin Flow and some important differences. ## From RxJava to Kotlin Flow: Error Handling DevFeed: [From RxJava to Kotlin Flow: Error Handling]() Original publisher: [Read original article]() Published: 2020-02-24T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [kotlin-flow](), [RxJava](), [Error Handling](), [reactive](), [Exception](), [Coroutines](), [Programming]() Tags: [coroutine](), [crashes](), [error-handling](), [exception](), [kotlin](), [kotlin-flow](), [reactive](), [rxjava]() ### AI overview This tutorial compares error handling in RxJava and Kotlin Flow. It explains that RxJava propagates stream errors as terminal events to an Observer's onError callback, while Kotlin Flow uses coroutine exception handling, including try-catch and propagation to parent jobs or coroutine scopes. ### Source excerpt Source This post is part of series of comparing RxJava to Kotlin Flow. Previous articles were about Threading and Backpressure. Introduction Error handling is fundamental in reactive programming. Reactive streams might fail with exception and propagate it as an event downstream notifying consumers on the error that happened. As in previous articles, we'll try to compare RxJava and Kotlin Flow error handling mechanisms. This might help us to migrate existing code from RxJava to Kotlin Flow and also understand how to properly use Kotlin Flow. [Next page]()