# RxJava Published articles for RxJava. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Kotlin Coroutines Compared with Reactor for Sequential and Asynchronous Operations DevFeed: [Kotlin Coroutines Compared with Reactor for Sequential and Asynchronous Operations]() Original publisher: [Read original article]() Published: 2025-10-06T00:00:00Z Content type: comparison Language: en Sources: [Kt. Academy]() Topics: [Coroutines](), [Kotlin](), [kotlin-coroutines](), [Reactive Streams](), [RxJava](), [async/await](), [Android](), [Back end]() Tags: [android](), [async](), [asynchronous](), [await](), [backend](), [compare](), [comparison](), [coroutines](), [kotlin](), [kotlin-coroutines](), [programming](), [programming-languages](), [reactive-streams](), [rxjava](), [simple](), [time](), [workshop-learning-programming]() ### AI overview This article compares Kotlin Coroutines with Reactor for backend and Android development. It argues that coroutines provide more readable and straightforward syntax for sequential and asynchronous operations, while Reactor requires additional operators, concepts, and patterns. ### Source excerpt A comparison of Kotlin Coroutines and Reactor, highlighting the elegance and simplicity of Coroutines over the complexity of Reactor. ## 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. ## Why Kotlin Coroutines simplify asynchronous, non-blocking development DevFeed: [Why Kotlin Coroutines simplify asynchronous, non-blocking development]() Original publisher: [Read original article]() Published: 2024-10-09T00:03:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Coroutines](), [Kotlin](), [kotlin-coroutines](), [multiplatform](), [Android](), [RxJava]() Tags: [asynchronous](), [blocking](), [coroutines](), [kotlin](), [kotlin-coroutines](), [multiplatform](), [reactive-streams](), [rxjava](), [workshop-learning-programming]() ### AI overview This tutorial chapter explains why Kotlin Coroutines are useful for asynchronous programming. It highlights their multiplatform support, lightweight execution, non-blocking imperative and reactive styles, reduced boilerplate, and simpler debugging and maintenance compared with callbacks and reactive streams. ### Source excerpt The explanation of why coroutines stand out and offer us what hasn't been offered by other technologies. ## Orbit Multiplatform wins Kotlin Foundation Grant: A Journey and a Look Ahead DevFeed: [Orbit Multiplatform wins Kotlin Foundation Grant: A Journey and a Look Ahead]() Original publisher: [Read original article]() Author: Matthew Dolan Published: 2024-10-02T13:30:16Z Content type: article Language: en Sources: [Stories by Matthew Dolan on Medium]() Topics: [Kotlin](), [multiplatform](), [Coroutines](), [Library](), [kotlin-coroutines](), [Open Source](), [Android](), [RxJava](), [reactive](), [Programming]() Tags: [android](), [android-app-development](), [coroutines](), [development](), [kotlin](), [kotlin-coroutines](), [kotlin-multiplatform](), [multiplatform](), [mvi](), [open-source](), [orbit](), [reactive](), [rxjava]() ### AI overview The article announces that the Kotlin Foundation awarded a grant to Orbit Multiplatform and reviews the open-source library's evolution. It describes Orbit 1's reactive, RxJava-inspired architecture and debugging and maintenance challenges, then explains the redesign leading to Orbit 2, including Kotlin coroutines, structured concurrency, composition, direct function calls, and a simplified DSL. ### Source excerpt We're thrilled to announce that the Kotlin Foundation has awarded Orbit Multiplatform a grant! This recognition is a tremendous honour and a chance to reflect on Orbit's journey and share our vision for the future. Orbit's Origins Orbit began as an open-source project over five years ago, in September 2019. It was one of the first libraries I co-created with Mikołaj Leszczyński, and its development has been a journey of constant learning and evolution. The Early Days: Orbit 1 I first encountered Orbit when I joined the Android team at Babylon Health in July 2018. Mikołaj had already developed the initial version of Orbit, heavily inspired by RxJava and talks such as Jake Wharton's Managing The Reactive World with RxJava. RxJava's influence was evident in Orbit's reactive approach, with chained operations driving the architecture. However, while this design worked well in some cases, it posed significant challenges -- especially with debugging. For instance, one event could trigger multiple others, leading to hard-to-trace bugs. Additionally, we ran into issues with type erasure due to the use of generics, which made it even harder to maintain the library. Here's an example of the syntax from Orbit 1: data class State(val total: Int = 0) data class AddAction(val number: Int) class CalculatorMiddleware: Middleware by middleware(State(), { perform("addition") .on() .withReducer { state, action -> state.copy(state.total + action.number) } }) While the initial approach was a valuable learning experience, it became clear that Orbit needed a shift. The Transition: Kotlin Coroutines and Orbit 2 In October 2018, Kotlin 1.3 introduced coroutines, offering an opportunity to rethink Orbit's architecture. Coroutines brought structured concurrency to Kotlin, making asynchronous programming more straightforward and less error-prone. However, it wasn't until May 2020 that we began redesigning Orbit's syntax to leverage coroutines. By August 2020, we released ## Kotlin Coroutines dispatchers DevFeed: [Kotlin Coroutines dispatchers]() Original publisher: [Read original article]() Published: 2024-07-01T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [kotlin-coroutines](), [Coroutines](), [Kotlin](), [Library](), [RxJava](), [Android]() Tags: [blocking](), [coroutines](), [dispatcher](), [kotlin](), [kotlin-coroutines](), [main-thread](), [rxjava](), [ui](), [workshop-learning-programming]() ### AI overview This tutorial explains Kotlin Coroutines dispatchers, which determine the thread or thread pool where coroutines start and resume. It covers the default dispatcher, limiting dispatcher parallelism, and the Main dispatcher for UI-related work, with a comparison to RxJava schedulers. ### Source excerpt Where we should use each dispatcher from the Kotlin Coroutines library. ## A Pattern for Composing Flow Operations DevFeed: [A Pattern for Composing Flow Operations]() Original publisher: [Read original article]() Published: 2024-04-15T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [kotlin-coroutines](), [Streams](), [async](), [backpressure](), [flux](), [RxJava]() Tags: [async](), [backpressure](), [flux](), [jpa](), [kotlin](), [kotlin-coroutines](), [rxjava](), [streams](), [workshop-learning-programming]() ### AI overview This tutorial explains a pattern for composing Kotlin Flow operations by collecting one cold flow within another flow definition. It discusses sequential processing, asynchronous operations, and the limitations of using internal flow types when composing streams. ### Source excerpt Extending and operating on top of your existing flows ## 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 ## Swampy Refactor: Converting Otto Bus to Flows DevFeed: [Swampy Refactor: Converting Otto Bus to Flows]() Original publisher: [Read original article]() Published: 2023-07-17T17:18:36Z Content type: tutorial Language: en Sources: [maiatoday]() Topics: [migration](), [Coroutines](), [deprecated](), [Code](), [RxJava](), [Kotlin](), [Git]() Tags: [code](), [coroutines](), [deprecated](), [flow](), [git](), [migration](), [otto-bus](), [refactor](), [rxjava](), [swampy]() ### AI overview This tutorial explains how to migrate an Android application from the deprecated Otto Bus event bus to Kotlin Flow. It presents an incremental, event-by-event process and notes that the work may require architectural refactoring, dependency-injection changes, and testing. ### Source excerpt The story starts I was wandering around my day job's code base and I happened on a time capsule - a pristine Java Activity studded with semi-colons, a snapshot of how we built things in 2014. All the member variables started with m and there was plenty of logic to update the screen and dictate actions. Despite being old, it's still used every day by users. Why would I change it? The Bus disappears Well, it got its data from a subscription to the Otto Bus. Otto Bus was deprecated in 2016. A blog post suggested migrating to RxJava, but since our code base standard now involves coroutines, Flows, and in some cases, LiveData, I decided to remove deprecated libraries and complete the partial migrations we started some time ago. This blog post summarizes how to migrate from Otto Bus to Flow. I've also created a Git repo with a simplified example that uses Otto Bus, with a conversion to Flow in the commit history. Check out the otto-bus tag for the working Otto Bus version and the flow tag for the converted Flow version. I am sparing you the Java to Kotlin conversions. This toy app lets you tap on the 8 ball for a message. It uses Otto Bus to notify the 8 Ball that a new message is needed as well as when a new message is available. How to tackle the migration - step by step Here are the basic steps for this kind of migration: Pick one event Find All the producers of this event (hopefully, there is only one but don't count on it) Replace with compatible functionality. We'll look at how to choose compatible functionality in the next section. Things will be broken. Find all subscribers of this event by looking for @Subscribe annotations. Replace with a matching access mechanism. Things should work at this point. Test that everything that used this one event still works Repeat with the next event until there are no events left to migrate Remove the Otto bus and it's dependencies Celebrate! Of course this looks deceptively simple. As simple as it is to add otto bus to a code ba ## 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. ## SharedFlow and StateFlow DevFeed: [SharedFlow and StateFlow]() Original publisher: [Read original article]() Published: 2022-02-21T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Coroutines](), [Kotlin](), [Android](), [RxJava]() Tags: [channel](), [coroutines](), [flow](), [interfaces](), [kotlin](), [livedata](), [rxjava](), [scope](), [sharedflow](), [stateflow](), [value](), [values](), [workshop-learning-programming]() ### AI overview A tutorial explaining Kotlin's SharedFlow and StateFlow for broadcasting and observing values among multiple coroutines. It covers replayed values, cancellation, interfaces for collecting and emitting, and converting a Flow with shareIn. ### Source excerpt Known as a replacement for Subject, LiveData, and many more. SharedFlow and StateFlow are powerful coroutines classes, every Kotlin developer should know. ## The state of managing state (with Compose) DevFeed: [The state of managing state (with Compose)]() Original publisher: [Read original article]() Author: Jake Wharton Published: 2021-11-11T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Compose](), [Coroutines](), [multiplatform]() Tags: [compose](), [coroutines](), [multiplatform](), [rxjava]() ### AI overview This article describes the evolution of Cash App's Android UI architecture from RxJava-based state management toward Compose. It introduces Molecule as a way to use Compose to produce state values without performing rendering, allowing the resulting state stream to be consumed outside Compose UI. ### Source excerpt This post was published externally on Cash App Code Blog. Read it at https://code.cash.app/the-state-of-managing-state-with-compose. ## Going Fully Multiplatform #1: Migrating your Android Project to Kotlin Multiplatform DevFeed: [Going Fully Multiplatform #1: Migrating your Android Project to Kotlin Multiplatform]() Original publisher: [Read original article]() Author: Isuru Rajapakse Published: 2021-10-21T13:24:07Z Content type: tutorial Language: en Sources: [Stories by Isuru Rajapakse on Medium]() Topics: [Kotlin Multiplatform](), [multiplatform](), [Kotlin](), [Android](), [iOS](), [Ktor](), [Web](), [Jetpack Compose](), [koin](), [RxJava](), [navigation]() Tags: [android](), [caching](), [dependency-injection](), [kotlin](), [kotlin-multiplatform](), [ktor](), [libraries](), [moshi](), [multiplatform](), [navigation](), [okhttp](), [retrofit](), [rxjava]() ### AI overview The article describes migrating an Android-only application to Kotlin Multiplatform. It compares the existing Android stack with a planned multiplatform stack targeting Android, JVM, iOS, and Web, including changes to networking, serialization, caching, dependency injection, asynchronous plumbing, navigation, and UI. ### Source excerpt Earlier this year I started a mission to start migrating one of our long-lasting Android-only apps to Kotlin Multiplatform to go beyond just Android. This is the story of how that went. Migration from Only-Android to Kotlin Multiplatform!The Android stack This is our current "stack" our android app was set up as follows Targeting Android SDK API 23 or above, we had a few libraries to help us out. The Android-only stack OkHttp for Networking Retrofit for.. also Networking Moshi for serialisation Okio for caching Koin for Dependency Injection/ Service Locator Plumbing with RxJava Navigation with Conductor Imperative UI with Android Views written in XML The Multiplatform stack To go beyond just Android, I had to make some hard decisions to step outside of the comfort zone that we've been so fond of To target Android, JVM, iOS and Web -- we will be making use of The Multiplatform stack Ktor for Networking Kotlin Serialisation for.. serialisation Caching with SQLDelight Koin for Dependency Injection (that one can stay) Plumbing with Coroutine Flows Navigation with Decompose Declarative UI powered with Jetpack/Jetbrains Compose That's the plan! In the next few articles, we'll take a look at each step in more detail. Before jumping on to that -- I want to take a close look at how we can fully modularise a Kotlin Multiplatform project with Going Fully Multiplatform #2 Modularising your Kotlin Multiplatform Project! ## 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. ## Great teams merge fast DevFeed: [Great teams merge fast]() Original publisher: [Read original article]() Author: Saket Narayan Published: 2021-02-23T23:15:21Z Content type: opinion Language: en Sources: [Saket Narayan]() Topics: [Android](), [Pull Request](), [Git](), [GitHub](), [Kotlin](), [RxJava]() Tags: [android](), [git](), [github](), [kotlin](), [pr-reviews](), [rxjava](), [square](), [uncategorized]() ### AI overview An opinion article describes how the Square/Cash App Android team merged code multiple times a day. It attributes the faster workflow to trust-based pull-request reviews, automated linting, small stacked pull requests, and GitHub support for retargeting stacked changes. ### Source excerpt One of the many things I was constantly amazed about during my first few weeks at Square/Cash App was seeing how fast this team shipped code. All members of the Android team (and likely other platforms as well) were merging to the main git branch multiple times every day. This was in stark contrast to [...] The post Great teams merge fast appeared first on Saket Narayan. ## Modelling UI State on Android DevFeed: [Modelling UI State on Android]() Original publisher: [Read original article]() Author: Stojan Anastasov Published: 2021-01-29T00:00:00Z Content type: tutorial Language: en Sources: [Stojan Anastasov's blog]() Topics: [Android](), [android-development](), [Kotlin](), [Data structures](), [Development]() Tags: [android](), [android-development](), [cardinality](), [data-class](), [data-structure](), [fp](), [functional](), [kotlin](), [livedata](), [rxjava](), [sealed-class](), [stateflow](), [types](), [ui](), [viewmodel]() ### AI overview This article explains how to model Android UI state in Kotlin using data classes and sealed classes. It connects types with sets and cardinality, then describes product types and sum types as tools for representing valid application states. ### Source excerpt The recommended approach from Google for Android development is holding the UI state in a ViewModel and having the View observe it. To achieve that one can use LiveData, StateFlow, RxJava or a similar tool. But how to model the UI state? Use a data class or a sealed class? Use one observable property or many? I will describe the tradeoffs between the approaches and present a tool to help you decide which one to use. This article is heavily inspired by Types as Sets from the Elm guide, a large part is a translation from Elm to Kotlin. Photo by Marc-Olivier Jodoin on Unsplash Types as sets By Making Data Structure we can make sure the possible values in code exactly match the valid values in real life. Doing that helps to avoid a whole class of bugs related to invalid data. To achieve that, first we need to understand the relationship between Types and Sets. We can think of Types as sets of values, they contain unique elements and there is no ordering between them. For example: Nothing - the empty set, it contains no elements Unit - the singleton set, it contains one element - Unit Boolean - contains the elements true and false Int - contains the elements: ... -2, -1, 0, 1, 2 ... Float - contains the elements: 0.1, 0.01, 1.0 .... String - contains the elements: "", "a", "b", "Kotlin", "Android", "Hello world!"... So when you write: val x: Boolean it means x belongs to the set of Boolean values and can be either true or false. Cardinality In Mathematics, Cardinality is the measure of "number of elements" of a Set. For example the set of Boolean contains the elements [true, false] so it has a cardinality = 2. Let's take a look at the cardinality of the sets mentioned above: Nothing - 0 Unit - 1 Boolean - 2 Short - 65535 Int - ∞ Float - ∞ String- ∞ Note: The cardinality of Int and Float is not exactly infinity, it's 2^32 however that is a huge number. When building apps, we use built-in types and create custom types using constructs like data classes and sealed classes. Product ## Unit Tests and Concurrency DevFeed: [Unit Tests and Concurrency]() Original publisher: [Read original article]() Author: Stojan Anastasov Published: 2021-01-06T00:00:00Z Content type: tutorial Language: en Sources: [Stojan Anastasov's blog]() Topics: [RxJava](), [Concurrency](), [Android](), [Testing]() Tags: [android](), [api](), [concurrency](), [junit](), [observeon](), [recyclerview](), [rxjava](), [scheduler](), [testing](), [tests](), [trampoline]() ### AI overview This tutorial explains how replacing RxJava schedulers with a single test scheduler can hide concurrency problems. It presents an Android example involving concurrent API calls and discusses refactoring the RxJava chain to update the UI as results become available. ### Source excerpt Once Retrofit added RxJava support, RxJava became my go-to concurrency framework for writing Android apps. One of the great things about RxJava is the excellent testing support. It includes TestObserver, TestScheduler, RxJavaPlugins so you can switch your schedulers in tests. A common approach in testing RxJava code is using a JUnit rule that replaces the Scheduler pools with Schedulers.trampoline() before tests are run and resets them to the original thread pools after the tests. This makes the whole Observable chain runs on a single thread, the same thread the test runs on, which means we can write assertions without worrying about concurrency. However the production code usually is not single threaded. IO operations are done on the IO thread pool, views are updated on the main thread and everything else happens on the computation pool. By using different schedulers in the tests and using a different strategy (single threaded) we make those unit tests useless in catching concurrency issues. A real world scenario I was working on a side project. The screen consists of a RecyclerView displaying a list of elements. To get the elements I need to perform two different API calls. The first API call returns a list with N elements, then for each item in the list I need to perform the second call. After combining the data I send it to the UI for displaying. Using RxJava this looks like: // Emits Loading then Content or Problem private fun requestData(): Observable = service.firstApiCall() .observeOn(Schedulers.computation()) .map { it.message } .flatMap(this::secondApiCall) .map { ViewState.Content(it) } .startWith(Single.just(ViewState.Loading)) .onErrorReturn { ViewState.Problem } .toObservable() // Concurrently executes secondApiCall for each element in list. // Transforms the result to ViewEntity, combines everything in a list private fun secondApiCall(list: List): Single> = Observable.fromIterable(list) .concatMapEager { ## Structural and navigation anti-patterns in modularized Android applications DevFeed: [Structural and navigation anti-patterns in modularized Android applications]() Original publisher: [Read original article]() Author: Gabor Varadi Published: 2020-12-25T11:38:05Z Content type: article Language: en Sources: [Stories by Gabor Varadi on Medium]() Topics: [Android](), [Gradle](), [modules](), [navigation](), [Code](), [Dagger](), [Dependency injection](), [RxJava]() Tags: [android](), [android-app-development](), [antipattern](), [architecture](), [clean-architecture](), [code](), [dagger](), [dagger-2](), [dependency-injection](), [domain-driven-design](), [gradle](), [modularization](), [modules](), [navigation](), [navigation-architecture](), [rxjava]() ### AI overview This article examines structural and navigation anti-patterns in modularized Android applications. It traces the history of Android Clean Architecture and argues that organizing an application around top-level data, domain, and presentation modules can be problematic, particularly when the structure is adopted from educational examples rather than feature-based organization. ### Source excerpt Structural and navigation anti-patterns in multi-module and modularized applications: The case against "Android Clean Architecture" and the "domain" moduleTop-level "domain" module is a code smell. Merry Christmas to all! The subject of this article is one that has been on my mind for a very long time. After all, "Clean Architecture" is often seen as the end goal, the hallmark of the finest of Android application code structure -- it is the best of the very best. The name itself, "Clean Architecture", signals that it's a good thing ~ after all, who wants to work with "messy" code in comparison? Of course, the title of this article shows that this isn't the conclusion we'll come to. The following tweet is closer to our final evaluation -- let us analyze why it might be accurate. Clean architecture + Android for us was like building a beautiful sailing boat in your backyard because someone on TV convinced you it's better for crossing the sea than an inflatable, while you live in the mountains and also your house is on fire. https://t.co/iGqy25wk7m The history of "Android Clean Architecture"The origins To understand "Clean Architecture" as done on Android, we must trace it back to its roots, and where/when it was made popular in the first place. As far as I'm aware, it dates back to 2014, the original proposition in "Fernando Cejas: Architecting Android... the clean way?". It was a highly influential article, as it revolutionized the structure of Android apps. Code that is actually separated across layers (back when Fragments were untrustworthy, and all code was in OS-level components), rather than just throwing everything into 2000+ line Activities? A pioneer of its time. One interesting decision however in the representative sample code was that in order to signify the strict separation of layers, these layers were each separated from one another using top-level Gradle modules, each labeled data, domain, and presentation. As we will see, this is the downfall of the sampl ## 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. ## When LiveData and Kotlin don't play well together DevFeed: [When LiveData and Kotlin don't play well together]() Original publisher: [Read original article]() Author: Danny Preussler Published: 2020-12-15T13:38:10Z Content type: tutorial Language: en Sources: [Stories by Danny Preussler on Medium]() Topics: [Android](), [Kotlin](), [reactive](), [bug](), [RxJava](), [Code](), [implementation]() Tags: [android](), [android-app-development](), [androiddev](), [bug](), [code](), [explore](), [implementation](), [jetpack](), [kotlin](), [lifecycle](), [livedata](), [reactive](), [rotation](), [rxjava](), [viewmodel]() ### AI overview This tutorial explains how LiveData's sticky last-value behavior interacts with Kotlin nullability on Android. It examines attempts to consume values by resetting LiveData to null and explains how that can cause a runtime crash when the value is treated as non-nullable. ### Source excerpt When LiveData and Kotlin don't play well togetherPlaying well together The idea of LiveData was an interesting one. Based on the idea of reactive streams, that was on the peak at that time with RxJava plus adding automatic lifecycle handling -- a problem on Android. LiveData had bad timing though. It arrived just before Kotlin made its impact in the Android community and sometimes both don't play that nice together. Let's explore why and what can happen! The good and the bad The idea of LiveData was pretty simple: a lifecycle-aware implementation of the Observable pattern. In addition, if you resubscribe, you will get the last emitted value again. It could be compared to a typed version of an EventBus with sticky messages. This is one of the core features of LiveData. But very soon after developers, including the authors, figured, you don't always want that behavior. Let's say you have an error value. Then you probably don't want to show that error value again after resubscribing, like after rotation of a device -- for instance. One way to solve this is SingleLiveEvent and it's a good choice for one-off events like errors. Both worlds But what if you want a bit of both? You want to have the last value "sticky" plus not showing potential errors multiple times! In that case, it would be good to remove our error value from LiveData after they have been consumed, right? Let's look at the implementation ofLiveData: The current value is saved on a field: private volatile Object mData; Initially, it is set to NOT_SET which. static final Object NOT_SET = new Object(); Unfortunately, is not public otherwise, we could use it to reset the value. What now? If you search for this problem, one of the most suggested solutions is simply setting it to null. Let's explore this: viewModel.results.observe(lifecycleOwner) { result -> when (result) { SomeResult.Error -> { handleError() viewModel.results.reset() } SomeResult.Result -> { handleResult(result) } } } where the ViewModel's imple ## Building Reactive UIs with LiveData and SavedStateHandle (or equivalent approaches) DevFeed: [Building Reactive UIs with LiveData and SavedStateHandle (or equivalent approaches)]() Original publisher: [Read original article]() Author: Gabor Varadi Published: 2020-10-04T19:53:05Z Content type: tutorial Language: en Sources: [Stories by Gabor Varadi on Medium]() Topics: [reactive](), [Android](), [Jetpack](), [RxJava]() Tags: [android](), [android-app-development](), [coroutine](), [jetpack](), [lifecycle](), [livedata](), [observable](), [reactive](), [reactive-programming](), [room](), [rxjava](), [savedstatehandle]() ### AI overview This article explains LiveData as a reactive, observable, lifecycle-aware data holder for Android applications. It argues that LiveData remains useful alongside RxJava and Kotlin coroutines because its lifecycle activation states allow it to represent reactive data sources, including Room-backed data that refreshes after invalidation. ### Source excerpt Building Reactive UIs with LiveData and SavedStateHandle (or equivalent approaches like Rx) You can also follow the related discussion thread on /r/android_devs. LiveData is a misunderstood beast. Every so often, you see comments like "LiveData does not belong in Repositories", or that with the existence of RxJava, Coroutine Channels, or Coroutine Flows -- there's "no reason to use LiveData at all". While there are components in these libraries that have overlapping responsibilities (BehaviorRelay, ConflatedBroadcastChannel, MutableStateFlow), that doesn't mean LiveData is useless. With the relatively new additions to Jetpack, such as the liveData { coroutine builder, LiveData is actually quite interesting. What is LiveData? If you try to find a definition for LiveData, you'll find that it's a "reactive, observable, lifecycle-aware data holder". We know it can be observed, and we know it holds 1 data value that is re-emitted for any new observer (and any changes made to it are also emitted), just like any BehaviorRelay. But what makes it special? Due to LiveData's lifecycle-awareness, it comes with its own "activation state" ( onActive and onInactive). It lets you know when there is an active observer, and when there are no longer any active observers. The trick is that this makes it far more than "just an every-day data holder". This allows LiveData to represent reactive datasources. I'd even wager that this is the original purpose for which LiveData was created, if Room's ComputableLiveData is any indication (as that also relies on onActive to trigger the refresh of the query results, if the table had been invalidated by a write to it). Why do I want reactive datasources? If you have data or state that can change over time, it's significantly easier to be notified of changes, than it is to poll for possible changes (and potentially miss out on changes if we tried to fetch data at the wrong time). This means that by using an "observer" (or change listener), we can r ## Communicating with your Lifecycle Owner using RxJava DevFeed: [Communicating with your Lifecycle Owner using RxJava]() Original publisher: [Read original article]() Author: Stojan Anastasov Published: 2020-09-08T00:00:00Z Content type: tutorial Language: en Sources: [Stojan Anastasov's blog]() Topics: [Android](), [Jetpack](), [RxJava](), [Coroutines](), [Development]() Tags: [android](), [android-architecture](), [android-development](), [architecture](), [coroutines](), [development](), [google](), [jetpack](), [kotlin](), [libraries](), [livedata](), [main-thread](), [reactive](), [rxjava](), [subscription](), [viewmodel]() ### AI overview This tutorial explains LiveData in Android Jetpack, including lifecycle-aware observation, event handling, and use in the data layer. It compares LiveData with RxJava and Kotlin Flow, then describes a reactive RxJava approach for state observation and lifecycle-managed subscriptions. ### Source excerpt Google introduced Jetpack, a family of opinionated libraries to make Android development easier a few years ago. One of the core classes in Jetpack is LiveData - an observable, lifecycle aware data holder. The typical use case is having a ViewModel that exposes LiveData as a property, and observing it from your lifecycle owner, a Fragment or an Activity. A typical usage would look like this: data class MyState(val value: String) class MyViewModel : ViewModel { private val _state = MutableLiveData() val state: LiveData get() = _state } class MyFragment : Fragment { val viewModel by viewModels() override fun onViewCreated() { viewModel.state.observe(this, Observer(::handleState)) } private fun handleState(state: MySate): Unit = TODO() } There are multiple benefits of using LiveData: Your observer is notified when the data changes The observer is only notified of changes when it's active Observers are notified when they become active again, like entering into foreground etc Check the LiveData docs for all benefits. LiveData and Events In situations like showing a Snackbar/dialog or navigating to a different Activity/Fragment the ViewModel also needs to notify the LifecycleOwner. A plain old LiveData doesn't work well here because it caches the last item. As a workaround, in the official Android architecture samples there is a SingleLiveEvent implementation of LiveData. Data Layer But what about the rest of the app? You can use LiveData in your data layer, in fact Room, the persistence library from Jetpack, support LiveData as the return type natively. However while using LiveData across all the layer in the app is possible, it is less than ideal. The operations are always executed on the Main Thread and it comes with limited number of transformation functions compared to RxJava or Flow. To fix this problem LiveData comes with adapters for both RxJava and Flow from KotlinX Coroutines. This means developers can use RxJava or Flow in their d ## Refactoring from LiveData to Coroutines & Flow DevFeed: [Refactoring from LiveData to Coroutines & Flow]() Original publisher: [Read original article]() Author: Jossi Wolf Published: 2020-08-24T16:29:47Z Content type: tutorial Language: en Sources: [Stories by Jossi Wolf on Medium]() Topics: [Refactoring](), [Coroutines](), [Android]() Tags: [android](), [coroutines](), [coroutines-flow](), [flow](), [kotlin-coroutines](), [livedata](), [main-thread](), [migration](), [network](), [refactoring](), [rxjava](), [threading](), [ui]() ### AI overview This tutorial describes migrating Android repositories from LiveData to Kotlin Coroutines and Flow. It distinguishes one-shot operations from data streams and introduces migration helpers to preserve compatibility during a gradual refactor. ### Source excerpt If you haven't, I recommend reading my other post about LiveData in Repositories. We recently joined a new project with heavy LiveData usage, everywhere. The search for main thread blockages led us down a rabbit hole of removing a significant portion of our LiveData usages. Here's how we migrated our Repositories from LiveData. We were faced with a tough challenge: We had to migrate as quickly and smoothly as possible -- there was no time for huge interruptions. Having all our repositories and lots of helper classes use LiveData, this left us with two options: Make sure we get threading right in all places that use LiveData Replace LiveData in our Repositories Making sure we're on the right thread everywhere and continuing to use LiveData would be the solution requiring fewer changes, but we would still be using LiveData for a use case it isn't really designed for. It can not be said often enough: LiveData has nothing to do in layers not related to UI! Keep it out of Repositories, DataSources! There use Flow or RxJava and only put LiveData in your ViewModels!It was very unfortunate that this was shown by Google as best practice. 😪 https://t.co/zOnbmyJYDP Agreed, 💯! We're actually working on revamping this guide which hasn't been updated with the latest recommendations for a looong time 🙈 Our code was also quite convoluted and hard to fix, so we decided to look for another option to handle asynchronicity. In an ideal world, refactoring it would have been easier, and we probably would have stuck with LiveData had our code been less convoluted. Our main requirement was for our replacement to fit with our existing mental model -- ViewModels being able to observe data from repositories where needed. Looking at our code, we were able to categorise our LiveData use cases into two categories: One-shot LiveData, for example, network calls Streams of data (e.g. for retrieving cached data before emitting fresh data) Our Replacement We looked around for a bit and decided to go wi ## Working with Kotlin Coroutines and RxSwift - Russell Wolf DevFeed: [Working with Kotlin Coroutines and RxSwift - Russell Wolf]() Original publisher: [Read original article]() Published: 2020-06-15T22:52:17Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Coroutines](), [Kotlin](), [kotlin-coroutines](), [Reactive Streams](), [iOS](), [Swift](), [RxJava]() Tags: [asynchronous](), [coroutines](), [interop](), [ios](), [kotlin](), [kotlin-coroutines](), [kotlin-multiplatform](), [platforms](), [reactive-streams](), [rxjava](), [swift](), [thread]() ### AI overview A tutorial on type-safe and thread-safe interoperation between Kotlin coroutines in shared code and RxSwift on iOS. It discusses platform limitations, Swift visibility issues, asynchronous event streams, and patterns for handling single- and multiple-event functions, errors, and cancellation. ### Source excerpt We discuss type-safe and thread-safe interop between Kotlin coroutines in shared code, and RxSwift on the iOS side. Useful RxSwift patterns for interop code ## 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. [Next page]()