# RxJava RxJava is a Java VM library for composing asynchronous and event-based programs using observable sequences. 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 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. ## 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 ## 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 ## 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. ## Leak investigation: Rx disposal race in SQLDelight DevFeed: [Leak investigation: Rx disposal race in SQLDelight]() Original publisher: [Read original article]() Author: Py ⚔ Published: 2021-05-17T22:10:41Z Content type: tutorial Language: en Sources: [Py ⚔]() Topics: [RxJava](), [Code](), [implementation]() Tags: [android](), [code](), [coding](), [community](), [development](), [engineering](), [implementation](), [inclusive](), [leak](), [rxjava](), [software](), [sqldelight](), [thread]() ### AI overview This article investigates a memory leak caused by a disposal race in SQLDelight's RxJava integration. The implementation sets the disposable before adding the query listener, so a subscription that is already disposed can add a listener that is never removed. The article recommends checking listener and disposable ordering and avoiding unnecessary scheduler calls for observables originating from Observable.create(). ### Source excerpt Header image: The In-Between by Romain Guy. In this blog we'll look into how an easy mistake when using Observable.create() can lead to subtle leaks. I recently investigated the following leak, which I couldn't reproduce systematically: ┬─── ... ├─ com.example.hockey.PlayerQueries$selectAllQuery instance │ ↓ Query.listeners │ ~~~~~~~~~ ├─ java.util.concurrent.CopyOnWriteArrayList instance │ ↓ CopyOnWriteArrayList.array │ ~~~~~ ├─ java.lang.Object[] array │ ↓ Object[].[0] │ ~~~ ├─ sqldelight.runtime.rx.QueryListenerAndDisposable instance │ Retaining 4.3 kB in 56 objects │ ↓ QueryListenerAndDisposable.emitter │ ~~~~~~~ ... RxJava observer chain ├─ com.example.hockey.PlayersView$onAttachedToWindow$1 instance │ Anonymous class implementing io.reactivex.functions.Function │ ↓ PlayersView$onAttachedToWindow$1.this$0 │ ~~~~~~ ╰-> com.example.hockey.view.PlayersView instance Leaking: YES (View.mContext references a destroyed activity) In the above leaktrace, PlayerQueries$selectAllQuery is a generated SQLDelight query. Our PlayersView is listening for updates to that query while the view is attached by leveraging Query.asObservable(). Once the view is detached, the observable chain is disposed and the query is expected to let go of the corresponding listener. I inspected the heap dump and found that the view was indeed detached, the observable chain was correctly disposed, and yet the QueryListenerAndDisposable listener had not been removed from the query. Let's look at the Query.asObservable() implementation: fun Query.asObservable(): Observable> { return Observable.create(QueryOnSubscribe(this)) } private class QueryOnSubscribe( private val query: Query ) : ObservableOnSubscribe> { override fun subscribe(emitter: ObservableEmitter>) { val listener = QueryListenerAndDisposable(emitter, query) emitter.setDisposable(listener) query.addListener(listener) emitter.onNext(query) } } private class QueryListenerAndDisposable) 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 { ## 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 ## 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 ## 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: 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. ## From RxJava to Kotlin Flow: Backpressure DevFeed: [From RxJava to Kotlin Flow: Backpressure]() Original publisher: [Read original article]() Published: 2020-02-06T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [backpressure](), [kotlin-flow](), [RxJava](), [Kotlin](), [reactive](), [Reactive Streams]() Tags: [article](), [backpressure](), [coroutines](), [kotlin](), [kotlin-flow](), [reactive-streams](), [rxjava]() ### AI overview This article compares backpressure in RxJava and Kotlin Flow from a black-box perspective. It explains how RxJava Flowable uses Subscriber requests to regulate event production and introduces Kotlin Flow's backpressure solutions for developers considering migration. ### Source excerpt Disclaimer This article unfortunately is not that dive deep (because of complexity of internals of coroutines), but instead trying to compare RxJava and Kotlin Flow mostly as black box with trying to find out differences in behavior and how to migrate from RxJava with its backpressure solution to Kotlin Flow. Hopefully this article will give you direction on where to look at if you decide to migrate to Kotlin Flow. ## From RxJava 2 to Kotlin Flow: Threading DevFeed: [From RxJava 2 to Kotlin Flow: Threading]() Original publisher: [Read original article]() Published: 2020-01-25T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [RxJava](), [kotlin-flow](), [Kotlin](), [Concurrency](), [reactive](), [Parallelism](), [Android](), [Programming]() Tags: [android](), [concurrency](), [kotlin](), [kotlin-flow](), [observeon](), [parallelism](), [reactive](), [reactive-programming](), [rxjava](), [streams](), [subscribeon]() ### AI overview This article compares threading in RxJava 2 and Kotlin Flow. It explains cold streams and the roles of subscribeOn and observeOn, including how schedulers determine where a reactive chain starts and continues. ### Source excerpt Source Introduction For a long time RxJava was undisputed leader for reactive solutions on Android, though with Kotlin expansion and introducing cold streams (Flow) seems situation might be rapidly changing in the coming years. Though reactive programming is not related to threading in the first place, concurrency and parallelism are very important anyway. In this article we'll try to make short recap on threading in RxJava 2 (with some basic caveats on its usage) and then take a look at how threading works in Kotlin Flow, so if anyone would like to migrate their code without affecting functionality it would be nice and smooth. ## Operator fusion in RxJava 2 DevFeed: [Operator fusion in RxJava 2]() Original publisher: [Read original article]() Published: 2019-11-02T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [RxJava](), [Library](), [reactive](), [backpressure]() Tags: [2](), [article](), [backpressure](), [flowable](), [memory](), [overhead](), [performance](), [reactive](), [rxjava](), [technical]() ### AI overview This article explains operator fusion in RxJava 2 as an optimization intended to reduce performance and memory overhead. It first reviews Observable, Flowable, their related observer or subscriber types, and backpressure, then introduces the assembly and subscription stages of an Rx chain. ### Source excerpt Introduction RxJava is a very powerful library, though it has some issues as well. Specifically performance and memory issues, which come from problems library tries to solve and how the solution is designed from technical perspective. In order to minimize overhead in RxJava there are a number of optimizations, which are called "operator fusion". And we'll talk about them in this article. But first let's recap how RxJava reactive types work and what issues they have. ## assertLastValue for RxJava TestObservers DevFeed: [assertLastValue for RxJava TestObservers]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2019-08-18T07:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [RxJava](), [Testing](), [test]() Tags: [code](), [rxjava](), [snippet](), [test](), [testing]() ### AI overview This tutorial explains how RxJava TestObserver assertions can test emitted stream values, focusing on checking the final value rather than relying on a precise intermediate index. It discusses a checklist example where the final button state is the important result and notes that index-based tests can become brittle when intermediate states change. ### Source excerpt The TestObserver is an RxJava staple for testing. It allows you to assert values in a stream, in the specific order they were emitted. Here's a quick code snippet from the movies-usf repository 1: @Test fun onSearchingForMovieBladeRunner_shouldSeeSearchResult() { viewModel = MSMainVm(mockApp, mockMovieRepo) val viewStateTester = viewModel.viewState.test() viewModel.processInput(SearchMovieEvent("blade runner 2049")) viewStateTester.assertValueAt(1) { assertThat(it.searchedMovieTitle).isEqualTo("Searching Movie...") true } viewStateTester.assertValueAt(2) { assertThat(it.searchedMovieTitle).isEqualTo("Blade Runner 2049") // ... true } } If you look at the source for the base TestObserver, there are a bunch of these useful methods: assertValue(Predicate valuePredicate): Asserts that this TestObserver/TestSubscriber received exactly one onNext value for which the provided predicate returns true. assertValue(T value): Assert that this TestObserver/TestSubscriber received exactly one onNext value which is equal to the given value with respect to Objects.equals. assertValueAt(int index, Predicate valuePredicate): Asserts that this TestObserver/TestSubscriber received an onNext value at the given index for the provided predicate returns true. assertValueAt(int index, T value) Asserts that this TestObserver/TestSubscriber received an onNext value at the given index which is equal to the given value with respect to null-safe Object.equals. assertValues(T... values) Assert that the TestObserver/TestSubscriber received only the specified values in the specified order. assertValuesOnly(T... values) Assert that the TestObserver/TestSubscriber received only the specified values in the specified order without terminating. While all these operators are useful, most of them require you to know the precise index of the value you're testing. Typically though when i'm testing a feature built with a USF architecture, I really only care about the last value emitted in my test case. When work ## Flowing in the Deep - Event Streams in Kotlin DevFeed: [Flowing in the Deep - Event Streams in Kotlin]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2019-07-02T00:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Kotlin](), [Coroutines](), [RxJava](), [Streams](), [Android]() Tags: [android](), [backpressure](), [coroutine](), [coroutines](), [deep-dive](), [event](), [flow](), [flowable](), [introduction](), [kotlin](), [presentation](), [rxjava](), [scopes](), [streams](), [video]() ### AI overview This presentation introduces Kotlin Flow, compares it with RxJava Observable and Flowable, and explains its relationship to coroutines. It also covers implementation details, custom operators, coroutine channels, backpressure, and coroutine scopes for use in Android apps. ### Source excerpt The Kotlin team introduced a new type called Flow which looks similar to RxJava's Observable or Flowable. Have you ever wondered what's the difference between Flow and RxJava? How does Flow work under the hood? How is it connected to Coroutines? How do you write your own operator? What about Kotlin Coroutine Channels? ## Throttling in RxJava 2 DevFeed: [Throttling in RxJava 2]() Original publisher: [Read original article]() Published: 2019-06-24T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [RxJava](), [User experience (UX)]() Tags: [examples](), [rxjava](), [ux]() ### AI overview A tutorial explaining the differences between RxJava 2 throttle operators, including throttleFirst, throttleLast, throttleLatest, and throttleWithTimeout/debounce, and when to use them. It also discusses the user-experience implications of using debounce for repeated button clicks. ### Source excerpt Introduction I don't know for what reason but I see from time to time same misunderstanding on different throttle operators in RxJava. Usually nobody says about throttle, instead by default everyone says that debounce can be used. Especially using debounce to avoid multiple clicks on buttons is commonly suggested, which I believe is a bad UX (some examples here and here). Let's finally look at available options in RxJava and find out when it is better to use what. ## RxJava Observable to Single DevFeed: [RxJava Observable to Single]() Original publisher: [Read original article]() Published: 2019-05-27T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [RxJava](), [implementation]() Tags: [implementation](), [observable](), [rxjava](), [stream]() ### AI overview This tutorial explains how to transform RxJava Observable instances into Single instances. It compares operators such as single, singleOrError, Single.fromObservable, elementAt, and first, and describes how their underlying strategy handles emitted values, completion, and errors. ### Source excerpt Transforming Single to Observable is simple, as Single satisfies Observable's contract. Just call single.toObservable() and you're good. But transforming Observable to Single is not that simple: if it happens that Observable emits exactly one value and completes (or terminates with error without emitting values) then it is pretty straightforward, otherwise one need to set up some additional rules. In RxJava there are a number of operators for transforming Observable to Single: ## .hide() your Subjects - RxJava tip DevFeed: [.hide() your Subjects - RxJava tip]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2019-03-30T07:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [RxJava](), [Android]() Tags: [android](), [rxjava]() ### AI overview This tutorial explains RxJava's .hide() operator. It shows how hiding a Subject can expose an Observable instead, preventing an Android Activity from modifying ViewModel state, and introduces its relationship to operator fusion. ### Source excerpt A not so well known api in RxJava is the .hide() operator. When does one use the hide operator in Rx? ## From the docs: Hides the identity of this Observable and its Disposable. Allows hiding extra features such as Subject's Observer methods or preventing certain identity-based optimizations (fusion). there are a lot of complex operations that take place internally in RxJava (like internal queue creation, worker instantiation + release, numerous atomic variables being created and modified.) If this doesn't make too much sense, let's look at examples to make this clear. Consider a typical MVVM usecase: class MyAndroidVm : ViewModel() { private val outputSubject = BehaviorSubject.createOnDefault(initialViewState()) init { Observable.just(service.pollModelData()) .map { // ... do something with the Event that pipes a result // or view state eventually } .subscribe { viewState -> outputSubject.onNext(viewState) } } fun listenToViewState(): BehaviorSubject { return outputSubject } // ... } In this sample code, the ViewState is basically what the Activity would consume. So within the ViewModel, we pipe the data into a Subject, which is then exposed to the Activity like so: class MyAndroidActivity: Activity { // ... override fun onResume() { viewModel.listenToViewState() .observeOn(AndroidSchedulers.mainThread()) .subscribe { viewState -> // bind Android Views and ViewState object } } } This is all great, however the trouble with exposing a Subject is that it allows the activity to modify the internal state of the Behavior Subject from the outside. This is non-ideal as we only want the ViewModel controlling this. class MyAndroidActivity: Activity { // ... override fun onResume() { viewModel.listenToViewState() .onNext(badViewState()) // we want to avoid this .observeOn(AndroidSchedulers.mainThread()) .subscribe { viewState -> // bind Android Views and ViewState object } } } So we don't want to expose the Subject directly. It would make more sense instead to just ## Reactive abstractions and testing strategies for Android code DevFeed: [Reactive abstractions and testing strategies for Android code]() Original publisher: [Read original article]() Author: Artur Dryomov Published: 2018-08-26T00:00:00Z Content type: opinion Language: en Sources: [Artur Dryomov]() Topics: [Android](), [Testing](), [reactive](), [Unit testing](), [RxJava](), [kotlin-coroutines]() Tags: [android](), [kotlin-coroutines](), [network](), [reactive](), [rxjava](), [testing](), [unit-testing]() ### AI overview This article argues that Android developers should design codebases as pragmatic, platform-agnostic JVM environments where framework interactions are isolated behind composable abstractions. Using RxJava examples, it explains how abstractions can improve consistency and make platform-related logic, such as retrying network requests after reconnection, easier to unit test. ### Source excerpt Who knows how many test suites were not created because of a classic parry. It cannot be tested -- it uses a platform call! Well, it is not actually true all the time. Unit testing something that only a human eye and neural networks can catch -- like animations -- doesn't make sense. On the other hand, retrying a network request on a re-established connection can and should be tested. As a bonus, it is possible to gain a couple of perks. ## Advanced Model-View-Intent: The Missing Guide DevFeed: [Advanced Model-View-Intent: The Missing Guide]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2018-06-26T00:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [RxJava](), [Library]() Tags: [guide](), [library](), [mvi](), [rxjava]() ### AI overview A presentation about Model-View-Intent (MVI) shares practical tips and introduces RxRedux, a library for building state machines with RxJava. ### Source excerpt Together with my friend Kostiantyn Tarasenko we talked about Model-View-Intent (MVI) and were sharing some tips that worked well for us. We also introduced a library to help us build state machines with RxJava called RxRedux ## Introduction to Android Architecture and Development Concepts DevFeed: [Introduction to Android Architecture and Development Concepts]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2018-05-30T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Android](), [Kotlin](), [RxJava]() ### AI overview This tutorial series introduces Android development concepts including MVVM, Retrofit, RxJava, data binding, Architecture Components, LiveData, and Kotlin. It uses the locally stored finance-tracking app CashCaretaker as an example and begins with architecture. ### Source excerpt MVVM? Retrofit? RxJava? Data binding? Architecture components? LiveData? Kotlin? Right now, these buzzwords are heard all over the Android community. Every podcast/blog/conference talk is referencing one of these. Which can be very intimidating to new developers. Which one should I learn first? Do I need all of them? What are these things even used for? The purpose of this series is to break all of that down, and show that none of these buzzwords are truly that scary. We'll go over an application I've published called CashCaretaker which is a simple finance tracker with all data stored locally on the device. It uses all of the buzzwords I mentioned further up, and we can go through them step by step. You can checkout a simple gif of the project here: ## Reactive Apps with Model-View-Intent - Part 8: Navigation DevFeed: [Reactive Apps with Model-View-Intent - Part 8: Navigation]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2018-05-06T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [navigation](), [reactive](), [RxJava](), [Android]() Tags: [android](), [architecture](), [blog-post](), [callback](), [lambda](), [mvi](), [navigation](), [reactive](), [rxjava]() ### AI overview This tutorial explains how to apply the Coordinator pattern to navigation in an Android Model-View-Intent architecture. It describes passing a navigation callback into MviBasePresenter and reusing the state-rendering observable with an RxJava operator to trigger navigation when a particular state is reached. ### Source excerpt In my previous blog post we discussed how the Coordinator pattern can be applied on Android. This time I would like to show how this can be used in Model-View-Intent. If you don't know yet what the Coordinator pattern is I highly recommend to go back and read the introdcution. ## Patterns for Major Dependency Upgrades DevFeed: [Patterns for Major Dependency Upgrades]() Original publisher: [Read original article]() Author: Artur Dryomov Published: 2018-03-18T00:00:00Z Content type: article Language: en Sources: [Artur Dryomov]() Topics: [upgrade](), [RxJava](), [Development](), [Software]() Tags: [dependencies](), [development-process](), [libraries](), [maintainers](), [rxjava](), [upgrade]() ### AI overview The article discusses patterns for major dependency upgrades, using RxJava's transition and EOL as a central example. It explains that major upgrades can drastically change APIs, break code, consume substantial time, affect development processes, and require careful consideration of benefits and migration costs. ### Source excerpt RxJava 1.x reaches EOL on March 31, 2018, meaning no further development. That's not surprising since the 1.x was in a bugfix-only mode since June 1, 2017. This is an interesting event in a software lifetime, since not so many libraries actually live and prosper long enough to produce a superior version, at the same time handling support for an older version for so long. Fortunately enough, RxJava is one of these lucky projects with maintainers actually caring about users. Thank you, RxJava maintainers, you are real human beings and real heroes. [Next page]()