# Reactive Programming Published articles for Reactive Programming. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Understanding Dispatchers: Main and Main.immediate DevFeed: [Understanding Dispatchers: Main and Main.immediate]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2025-04-02T12:22:06Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Coroutines](), [kotlin-coroutines](), [Kotlin](), [Android](), [Programming]() Tags: [android](), [android-app-development](), [android-apps](), [android-studio](), [coroutine](), [coroutines](), [coroutines-flow](), [kotlin](), [kotlin-beginner](), [kotlin-coroutines](), [kotlin-multiplatform](), [main-thread](), [multithreading](), [reactive-programming](), [threadpools](), [threads]() ### AI overview A deep dive into Kotlin coroutine dispatchers on Android, explaining the difference between Dispatchers.Main and Dispatchers.Main.immediate. It describes how HandlerContext dispatches work and when execution is posted to the main thread or performed synchronously on the current thread. ### Source excerpt A deep dive into Kotlin Coroutine Dispatchers. Understand the subtle but important difference between Dispatchers.Main and Dispatchers.Main.immediate in Android. ## 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. ## Graphical Applications in Haskell with FRP and Reflex DevFeed: [Graphical Applications in Haskell with FRP and Reflex]() Original publisher: [Read original article]() Published: 2022-07-10T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Functional programming](), [Reflex FRP](), [ui](), [real-time](), [Programming](), [Declarative programming]() Tags: [functional](), [functional-programming](), [haskell](), [programming](), [reactive](), [reactive-programming](), [real-time](), [user-interface]() ### AI overview This article introduces functional reactive programming for interactive graphical user interfaces in Haskell. It explains how behaviours represent values that vary continuously over time and events represent occurrences at particular points in time, allowing programmers to describe reactive systems without handling time-related implementation details directly. The article also covers Reflex and building user interfaces with Reflex-Dom. ### Source excerpt Contents 1 Functional Reactive Programming 1.1 Behaviours 1.2 Events 2 Reflex 2.1 Building UIs with Reflex-Dom 2.2 Reflex Combinators 3 Example: 101companies 1 Functional Reactive Programming Functional reactive programming is a general paradigm well suited to programming real-time systems in a high-level and functional way. Real-time systems or reactive systems are those that handle continuous time-varying values, discrete events in real time, and react accordingly. A good example of these systems is a mobile robot. They must take into consideration continuous inputs like wheel speed, orientation, and discrete events such as detection of another object. The class of reactive systems we're interested in here is interactive graphical UIs. A user interface has multiple components that can be seen as discrete events and continuous time-varying values. An input box, where one might write their name, is an example of a time varying value (it continously changes - whenever the user types something); a button is an example of a discrete event in time: at certain points in time the user will click the button. This will make more sense with practice and code samples. So the promise of functional reactive programming is that we can program these complicated reactive systems in a pure functional way. But how? Functional Reactive Programming introduces two key concepts: Behaviours and Events. Behaviours are first-class values that vary over continuous time. That means a behaviour is a value that changes with time and can be passed to/returned by functions. Events are first-class values that occur at some points in time. They may refer, e.g., to happenings in the real world time - such as a mouse click or a key press. And then, it says that the FRP implementation will handle all time-related details so that the programmer can describe their reactive system without thinking about what happens at any particular point in time, but rather thinking about what happens accross all poin ## 3.17.0 Release with Computed Columns, Audit Columns, Pattern Matching, Reactive Transactions and Kotlin Coroutine Support DevFeed: [3.17.0 Release with Computed Columns, Audit Columns, Pattern Matching, Reactive Transactions and Kotlin Coroutine Support]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-06-22T15:15:05Z Content type: release Language: en Sources: [jOOQ]() Topics: [releases](), [SQL](), [Kotlin](), [reactive](), [Transactions]() Tags: [audit-columns](), [client-side-computed-columns](), [computed-columns](), [coroutine](), [coroutines](), [implicit-join](), [java-17](), [jooq](), [jooq-3-17](), [jooq-development](), [kotlin](), [kotlin-coroutines](), [pattern-matching](), [postgresql](), [r2dbc](), [reactive-programming](), [reactive-transactions](), [release](), [release-notes](), [sql](), [stored](), [stored-computed-column](), [udt](), [virtual](), [virtual-computed-column]() ### AI overview The jOOQ 3.17.0 release adds client-side computed columns for read and write operations, audit columns, pattern-matching SQL transformations, and more implicit JOIN capabilities. It also sets Java 17 as the baseline for the Open Source Edition while commercial distributions continue supporting Java 8 and 11. ### Source excerpt This release contiues the work from previous releases around more sophisticated SQL transformation capabilities, including: Client side computed columns for both read and write operations Audit columns Pattern matching SQL transformations More implicit JOIN capabilities Client side computed columns A ground breaking new core feature available in all commercial distributions isthe new client side computed ... Continue reading 3.17.0 Release with Computed Columns, Audit Columns, Pattern Matching, Reactive Transactions and Kotlin Coroutine Support -> ## Loom and Thread Fairness DevFeed: [Loom and Thread Fairness]() Original publisher: [Read original article]() Published: 2022-05-27T08:20:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [Java](), [openjdk](), [Concurrency](), [Concurrent Programming](), [Programming](), [reactive]() Tags: [http](), [io](), [java](), [openjdk](), [project-loom](), [reactive-programming](), [thread](), [threads]() ### AI overview This technical article examines thread scheduling fairness for CPU-bound workloads running on Project Loom's virtual threads. It introduces Loom's virtual-thread model and contrasts it with operating-system threads and reactive programming for handling highly concurrent applications. ### Source excerpt Table of Contents Project Loom Scheduling Discussion Project Loom (JEP 425) is probably amongst the most awaited feature additions to Java ever; its implementation of virtual threads (or "green threads") promises developers the ability to create highly concurrent applications, for instance with hundreds of thousands of open HTTP connections, sticking to the well-known thread-per-request programming model, without having to resort to less familiar and often more complex to use reactive approaches. Having been in the workings for several years, Loom got merged into the mainline of OpenJDK just recently and is available as a preview feature in the latest Java 19 early access builds. I.e. it's the perfect time to get your hands onto virtual threads and explore the new feature. In this post I'm going to share an interesting aspect I learned about thread scheduling fairness for CPU-bound workloads running on Loom. ## Fast Reactor Tests With Virtual Time DevFeed: [Fast Reactor Tests With Virtual Time]() Original publisher: [Read original article]() Author: piotr-kubowicz Published: 2021-12-27T00:00:00Z Content type: tutorial Language: en Sources: [Backend Development on nexocode]() Topics: [reactive](), [Testing](), [Programming](), [Concurrency](), [Code](), [Kotlin]() Tags: [asynchronous](), [code](), [concurrency](), [jvm](), [kotlin](), [network](), [programming](), [reactive](), [reactive-programming](), [reactive-streams](), [testing](), [timeout](), [unit-test]() ### AI overview This tutorial explains how to use Project Reactor's Virtual Time and StepVerifier to test delayed and asynchronous reactive code without waiting for real time to pass. It also discusses controlling external storage behavior and the limitations of polling-based test approaches. ### Source excerpt Sometimes your code deals with a situation when things happen slowly. Maybe you schedule a background task that runs after some time. Or run a special action when asking for data that takes far too long. Either way, it is a tricky case that needs to be tested well. But what to do if we don't want a test that waits a lot? Project Reactor, a reactive programming library for JVM, handles concurrency in a high-level and declarative fashion. Its test utility, StepVerifier, allows using Virtual Time: 'mock' the clock and advance time in your tests faster than the system clock runs. ## Java Reactive Programming - Effective Usage in a Real World Application DevFeed: [Java Reactive Programming - Effective Usage in a Real World Application]() Original publisher: [Read original article]() Author: Stefan Nothaas Java Software; Backend Engineer Published: 2021-03-16T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [Java](), [reactive](), [Programming](), [Back end](), [Microservice](), [Kafka](), [API]() Tags: [api](), [backend](), [backpressure](), [blocking](), [java](), [kafka](), [reactive](), [reactive-programming](), [services]() ### AI overview This article explains how trivago's search backend team applied reactive programming in Java to a production microservice. It covers handling blocking I/O, backpressure, varying loads, message and error propagation, and implementation challenges. ### Source excerpt This article presents how trivago's search backend team used reactive programming in Java effectively when designing and implementing one of our many Java backend services. Compared to tradi... ## Kotlin Mumbai x Android Worldwide DevFeed: [Kotlin Mumbai x Android Worldwide]() Original publisher: [Read original article]() Author: Siddhesh Patil Published: 2021-01-19T07:57:37Z Content type: article Language: en Sources: [Sid Patil - Android Engineer and Kotlin Advocate]() Topics: [Kotlin](), [reactive](), [Java](), [Google]() Tags: [android](), [android-worldwide-event](), [best-android-developer-groups-in-india](), [developer-communities-in-mumbai](), [event](), [global](), [google-developer-experts](), [himanshu-singh-gde-for-android](), [kotlin](), [kotlin-user-group-mumbai](), [kug](), [niharika-arora-gde-for-android](), [reactive-programming](), [rxjava-vs-kotlin-flows](), [smallcase](), [subhrajyoti-sen-gde-for-android](), [time](), [using-joda-time-on-android]() ### AI overview A recap of the Kotlin Mumbai and Android Worldwide event, featuring talks on reactive programming with Kotlin flows and on Java's calendar class and Joda Time. ### Source excerpt Kotlin Mumbai joins communities from around the globe for a worldwide event. Niharika Arora, Himanshu Singh and Shubrajyoti Sen take us through Kotin Flows and Joda Time! ## 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 ## Tackling the Awkward Squad for Reactive Programming DevFeed: [Tackling the Awkward Squad for Reactive Programming]() Original publisher: [Read original article]() Published: 2020-09-15T17:48:50Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [reactive](), [Programming](), [IO](), [Scala](), [JavaScript]() Tags: [effects](), [implementation](), [javascript](), [ltu-forum](), [programming](), [reactive](), [reactive-programming](), [scala](), [streams]() ### AI overview This paper examines how reactive programming is embedded within applications that also use imperative languages such as JavaScript or Scala. It identifies long-running computations, side effects, and coordination between imperative and reactive code as key concerns, then proposes the Actor-Reactor Model, which separates actors and reactors and composes them through data streams. The model is demonstrated in the Stella language. ### Source excerpt https://2020.ecoop.org/details/ecoop-2020-papers/19/Tackling-the-Awkward-Squad-for-Reactive-Programming-The-Actor-Reactor-Model Sam Van den Vonder, Thierry Renaux, Bjarno Oeyen, Joeri De Koster, Wolfgang De Meuter Reactive programming is a programming paradigm whereby programs are internally represented by a dependency graph, which is used to automatically (re)compute parts of a program whenever its input changes. In practice reactive programming can only be used for some parts of an application: a reactive program is usually embedded in an application that is still written in ordinary imperative languages such as JavaScript or Scala. In this paper we investigate this embedding and we distill "the awkward squad for reactive programming" as 3 concerns that are essential for real-world software development, but that do not fit within reactive programming. They are related to long lasting computations, side-effects, and the coordination between imperative and reactive code. To solve these issues we design a new programming model called the Actor-Reactor Model in which programs are split up in a number of actors and reactors. Actors and reactors enforce a strict separation of imperative and reactive code, and they can be composed via a number of composition operators that make use of data streams. We demonstrate the model via our own implementation in a language called Stella. ## Using Kotlin Coroutines to Reduce Reactive Code Complexity DevFeed: [Using Kotlin Coroutines to Reduce Reactive Code Complexity]() Original publisher: [Read original article]() Author: piotr-kubowicz Published: 2020-05-12T00:00:00Z Content type: tutorial Language: en Sources: [Backend Development on nexocode]() Topics: [Coroutines](), [Kotlin](), [reactive]() Tags: [coroutines](), [jvm](), [kotlin](), [reactive](), [reactive-programming](), [reactive-streams]() ### AI overview The article compares Kotlin coroutines with reactive programming for backend code. It explains that reactive streams can add complexity and hide empty-result cases, using a Reactor zip example where an empty input can cancel the resulting stream. ### Source excerpt Using Reactive Programming is tempting because it promises to handle higher traffic on the same hardware. Yet this paradigm is also demanding: it increases code complexity and may make bugs harder to notice. Let's explore how you can use Kotlin and coroutines to reduce the cognitive load of maintaining reactive applications. Sample code Imagine you are developing a website that can be used by both logged-in and anonymous users, just like Wikipedia. At the same time, there are proper mechanisms in place to block misbehaving users. Our focus will be the back-end code returning a welcome message displayed on top of the main page: ## From RxJava to Kotlin Flow: Throttling DevFeed: [From RxJava to Kotlin Flow: Throttling]() Original publisher: [Read original article]() Published: 2020-03-02T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [reactive](), [kotlin-flow](), [RxJava](), [Programming]() Tags: [backpressure](), [kotlin](), [kotlin-flow](), [reactive](), [reactive-programming](), [rxjava]() ### AI overview A comparison of throttling operators in RxJava and Kotlin Flow, explaining how debounce, throttleLast or sample, and throttleFirst limit events in reactive streams. The article uses UI interactions such as search input and button clicks as examples. ### 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 It is advised to take a look at the overview of Throttling operators in RxJava before reading this article: Throttling in RxJava 2 Introduction Throttling is also one of the essential features of reactive programming. Streams might emit more values than we're expecting to receive, so ability to limit number of events in a stream is very important. Most common place where it applies is handling UI events. Examples of usage might be handling button clicks (to not allow double clicks), usage with search view when we'd like to wait for user to stop typing before querying some data and so on. In this article we'll try to compare throttling operators in RxJava and 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 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. ## Implementing Dark Mode Using the Observer Pattern DevFeed: [Implementing Dark Mode Using the Observer Pattern]() Original publisher: [Read original article]() Published: 2019-11-08T00:00:00Z Content type: tutorial Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Dark Mode](), [iOS](), [Swift](), [reactive](), [Programming]() Tags: [collaboration](), [dark-mode](), [engineering](), [ios](), [mobile](), [reactive-programming](), [swift]() ### AI overview This article explains how SoundCloud implemented Dark Mode in its iOS app while maintaining compatibility with earlier iOS versions. It describes using Swift to build a type-safe observer pattern that propagates color-theme changes to dependent observers. ### Source excerpt Last week's update to the SoundCloud iOS app includes support for Dark Mode. This took several months of work and collaboration between... ## MVI - The Good, the Bad, and the Ugly DevFeed: [MVI - The Good, the Bad, and the Ugly]() Original publisher: [Read original article]() Published: 2019-07-24T18:52:57Z Content type: opinion Language: en Sources: [Posts on Adam Bennett]() Topics: [Redux](), [Android](), [Development](), [reactive]() Tags: [algorithms](), [android](), [android-development](), [architecture](), [article](), [blog](), [career](), [compose](), [development](), [engineering](), [finance](), [flow](), [functional](), [growth](), [java](), [jetpack](), [kotlin](), [money](), [mvi](), [opinion](), [opinions](), [patterns](), [reactive](), [reactive-programming](), [software](), [startups](), [testing](), [thoughts](), [training](), [tutorial](), [ui]() ### AI overview An opinionated introduction to MVI, also known as Redux, for Android development. The article explains its unidirectional data flow, event and result modeling, reducers, sealed classes, and integration with functional reactive programming, while considering its benefits and downsides. ### Source excerpt For those keeping track of the latest trends in view architecture patterns, MVI, aka Redux, has seemingly become the latest and greatest for Android Development. There's tonnes of things to love about MVI - but what are the downsides, and what should you know going into it? For the sake of this article, I'm basing my thoughts on an adaptation of MVI which I've used for a while now for both personal projects and at work. You can find the important classes here for a deeper dive, but I'll run through the basics here too. ## Perfect is the Enemy of the Good DevFeed: [Perfect is the Enemy of the Good]() Original publisher: [Read original article]() Author: Keegan Rush Published: 2018-11-13T00:00:00Z Content type: opinion Language: en Sources: [The Coded Self]() Topics: [Development](), [Programming](), [Concurrency](), [reactive](), [Dependency injection](), [Mocking](), [App]() Tags: [architecture](), [architecture-pattern](), [async](), [concurrency](), [dependency-injection](), [development](), [dispatchqueue](), [mocking](), [programming](), [queue](), [reactive](), [reactive-programming]() ### AI overview The author reflects on a side project whose elaborate architecture and extensive tooling created hidden complexity, debugging difficulties, and development friction. The article examines the use of RxSwift, VIPER, Swinject, Cuckoo, and Flow Operations in an app and argues that architectural perfection can undermine practical progress. ### Source excerpt How the Wrong Architecture Can Cripple Development A couple of years ago, I was working on a side project with a few friends. We thought that it would be the next big thing. We put our collective best efforts into it; I worked long, hard hours fleshing out the scaffolding of the perfect architecture. Little did I know that my effort would doom the project to join the abyss of failed projects as quickly as it had begun. We had the best tools Since this was The Next Big Thing™, we used everything at our disposal. RxSwift for reactive programming VIPER for our architecture pattern Swinject for dependency injection Cuckoo for mocking Flow Operations for managing navigation The Flow Operations were a particularly interesting concept, inspired by the Advanced NSOperations session from WWDC 2015. We used Flow Operations to manage navigation in the app. For instance, if you wanted to register a new user, you'd invoke a RegisterFlowOperation. A FlowOperation was a subclass of Operation: class FlowOperation: Operation The Operation class represents the code and data for a task of your choosing. It also handles concurrency and dependencies. So, our Flow Operations represented the task of flowing from one screen to another in an app. Operations can be dependent on each other - for instance, the EditProfileFlowOperation is dependent on the SignInFlowOperation. If you've already signed in, you can edit your profile, but if you haven't, then you'll be directed to sign in if you invoke the EditProfileFlowOperation. How does it work? There was a lot of hidden complexity in the Flow Operation system, and some trickiness that you wouldn't notice until you started using it. I'll briefly go over some of the code. You could sell products in this app we were building. This is how you'd start the Sell Flow: private func startSellFlow() { DispatchQueue.global().async { [navController = navController] in let flow = SellFlowOperation(navigationController: navController) flow.beginFlow() flow. ## JavaScript Workshop with Kyle Simpson DevFeed: [JavaScript Workshop with Kyle Simpson]() Original publisher: [Read original article]() Author: Daw Chih Liou Published: 2018-10-15T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [JavaScript](), [Functional programming](), [frontend development](), [Programming]() Tags: [article](), [babel](), [engineering-culture](), [frontend](), [frontend-development](), [functional-programming](), [javascript](), [reactive-programming](), [webpack](), [workshop]() ### AI overview A recap of a five-day JavaScript workshop led by Kyle Simpson at trivago. The workshop covered JavaScript foundations, recent language features, asynchronous programming, functional programming, scope, hoisting, closures, compilation, and execution. The article also discusses applying functional programming and empathetic communication in frontend development. ### Source excerpt It has been a couple of months since Kyle, author of the "You Don't Know JS" series, visited our trivago headquarters a... ## Java 9 Flow API: timing out events DevFeed: [Java 9 Flow API: timing out events]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-25T11:46:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [reactive](), [Java 9](), [Concurrency](), [Programming](), [Streams]() Tags: [await](), [concurrency](), [flow](), [flow-api](), [java-9](), [jdk](), [programming](), [reactive](), [reactive-programming](), [streams](), [subscriber](), [subscription](), [timeout]() ### AI overview This tutorial explains how to design a timeout operator for Java 9 Flow API publishers. It models each event as a race between item arrival and a timer, signals a TimeoutException when the timer wins, and addresses serialized downstream signals when timeout and upstream events occur concurrently. ### Source excerpt Introduction One of the main properties of reactive programming is that the events may arrive over time instead of immediately available to a consumer. In traditional Future-based programming, one could wait for the result in a blocking manner via Future.get(long, TimeUnit). Other data sources, such as network InputStream have either their own built-in timeout facility or one has to use external means to close the stream after certain period of time to unblock the reader to it. Java 8 Streams have also no direct timeout support. In the reactive mindset, one can consider timing out events (items) as requesting an element and racing its arrival against the clock. If the item arrives in time, we should ignore the clock. If the clock fires first, we should stop the sender of the items and somehow notify the consumer of the situation. Perhaps the simplest way is to signal onError with a TimeoutException. Since there could be multiple items from a flow, we have to do this racing for each potential items over and over until the flow terminates. The timeout operator Since there is "time" in timeout, we'll need a source of time that can be started and stopped at will. The first tool that comes into mind is the java.util.Timer class, however, even its Javadoc suggest one uses a ScheduledExecutorService instead. If one has to deal with a lot of timed operations, besides of timing out flows, having the control over such signals via a (set of) ScheduledExecutorServices is desirable. Therefore, let's define our timeout API with it: public static Flow.Publisher timeout( Flow.Publisher source, long timeout, TimeUnit unit, ScheduledExecutorService timer) { return new TimeoutPublisher<>(source, timeout, unit, timer); } (Note that if one uses the Executors.newScheduledExecutorService(), it has to be shutdown at some point, otherwise it's non-daemon thread by default would prevent the JVM from quitting.) One primary responsibility of this type of operator is to make sure the ## RxJava vs. Kotlin Coroutines, a quick look DevFeed: [RxJava vs. Kotlin Coroutines, a quick look]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-05T15:11:00Z Content type: comparison Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [kotlin-coroutines](), [Kotlin](), [Coroutines](), [reactive](), [Usability](), [Programming]() Tags: [asynchronous](), [blocking](), [business-logic](), [code](), [coroutine](), [coroutines](), [experimental](), [kotlin](), [kotlin-coroutines](), [main-thread](), [programming](), [reactive](), [reactive-programming](), [retry](), [runblocking](), [rxjava](), [suspend](), [thread](), [timeout](), [zip]() ### AI overview This article compares RxJava and Kotlin Coroutines through an example involving delayed unreliable services, timeouts, cancellation, retries, and combining results. It emphasizes usability over raw performance and describes coroutine code as more sequential and synchronous-looking, while noting that coroutines were experimental at the time. ### Source excerpt Introduction Does Kotlin Coroutines make RxJava and reactive programming obsolete? The answer depends on who you ask. Enthusiasts and marketing departments would say yes without hesitation. If so, sooner or later developers would have to convert Rx code into coroutines or write something with coroutines from the start. Since Coroutines are currently experimental, there is always the prospect deficiencies, especially regarding the overhead, will be resolved eventually. Therefore, this post will focus more on usability than raw performance. The scenario Let's say we have two functions imitating unreliable service: f1 and f2, both returning a number after some delay. We have to call these services, sum up their returned values and present it to the user. However, if this doesn't happen within 500 milliseconds, we don't expect it to happen reasonably faster, thus we'd like to cancel and retry the two services for a limited amount of time before giving up after some number of retries. The Coroutine Way Programming via coroutines feels like programming with the traditional ExecutorService- and Future-based toolset with the difference that the underlying infrastructure will use suspension, state machine(s) and task rescheduling instead of blocking a thread. First, we need the functions that exhibit the delaying behavior: suspend fun f1(i: Int) { Thread.sleep(if (i != 2) 2000L else 200L) return 1; } suspend fun f2(i: Int) { Thread.sleep(if (i != 2) 2000L else 200L) return 2; } Functions that participate in a coroutine execution should be declared with the suspend keyword and executed within a coroutine context. For demonstration purposes, the logic will sleep for 2 seconds if the parameter supplied to the functions is not 2. This will give a chance to the timeout logic to kick in yet the 3rd attempt to succeed before the timeout. Since going asynchronous usually ends up leaving the main thread, we need a way to block it until the business logic completes before letting the ## ViewModel and LiveData: State-Management Pitfalls in Google's Architecture Components Samples DevFeed: [ViewModel and LiveData: State-Management Pitfalls in Google's Architecture Components Samples]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-06-25T09:00:00Z Content type: opinion Language: en Sources: [Hannes Dorfmann]() Topics: [Programming](), [reactive](), [Google](), [RxJava](), [GitHub](), [REST API]() Tags: [architecture](), [blog-post](), [google](), [livedata](), [mvi](), [mvvm](), [pitfalls](), [reactive](), [reactive-programming](), [rxjava](), [state-management](), [viewmodel]() ### AI overview An opinionated review of ViewModel and LiveData in Google's Architecture Components samples, focusing on state management, pagination, lifecycle awareness, and differences from RxJava. ### Source excerpt At I/O 2017 Google surprised us with a new initiative: Architecture Components. I really appreciate this initiative. In this blog post I would like to share my thoughts about ViewModel and some pitfalls you might stumble upon when using ViewModel and LiveData by taking a look at the official Google samples. ## RxJava 1 -\> RxJava 2 (Understanding the changes) DevFeed: [RxJava 1 -\> RxJava 2 (Understanding the changes)]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2017-06-21T07:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [RxJava](), [reactive](), [Programming](), [interfaces]() Tags: [classes](), [continuation](), [flowable](), [gradle](), [import](), [interfaces](), [migration](), [programming](), [reactive](), [reactive-programming](), [reactive-streams](), [rxjava](), [series](), [subscriber](), [subscription]() ### AI overview A migration guide for RxJava 1 users explains the major RxJava 2 changes, including its adoption of the Reactive Streams specification, four core interfaces, and package and Gradle dependency changes. ### Source excerpt In case you haven't heard: RxJava2 was released sometime back. RxJava 2 was a massive rewrite with breaking apis (but for good reasons). Most dependent libraries have upgraded by now though, so you're safe to pull that migration trigger with your codebases. Folks starting out directly with Rx2 might enjoy this guide but it's the ones that started with Rx 1 that will probably appreciate it the most. 2 part series This is a continuation post in a 2 part series: Understanding the changes Disposing subscriptions Let's get started. In this first part, I want to dive into making sense of the Rx2 changes from the point of view of an Rx1 user. Why things changed with RxJava2 # tl;dr- Reactive Streams spec ## Reactive Streams is a standard for doing "reactive" programming and RxJava now implements the Reactive Streams specs with version 2.x. RxJava was sort of a trailblazer in reactive programming land but it wasn't the only library around. There were others that also dealt with reactive paradigms. But with all the libraries adhering to the Reactive Streams spec now, interop between the libraries is a tad bit easier. The spec per say is pretty straightforward with just 4 interfaces: Publisher (anything that publishes events, so Observable,Flowable etc. - more on this later) Subscriber (anything that listens to a Publisher) Subscription (Publisher.subscribe(Subscriber) => Subscription when you join a Publisher and a Subscriber, you are given a connection also called a Subscription) Processor (a Publisher + a Subscriber, sound familiar? yep Subjects for us RxJava 1 luddites) If you're slightly more curious about the design goals, I also suggest the following resources: What's different in 2.0 wiki page - this is really the place I kept coming back to and referencing when I needed to understand the details Fragmented Ep #53 with JakeWharton (forgive the shameless promotion) - ultimate lazy person's guide to understand why/what things changed with RxJava2, as explained by an act ## Google Agera vs. ReactiveX DevFeed: [Google Agera vs. ReactiveX]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2016-04-24T11:44:00Z Content type: comparison Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [reactive](), [Android](), [android-development](), [API](), [Programming]() Tags: [android](), [android-development](), [api](), [apis](), [java](), [reactive-programming](), [rxjava]() ### AI overview This article compares Google's Agera reactive library for Android with established reactive libraries including RxJava, Reactor, and Akka-Streams. It describes Agera's valueless Observer and Updatable APIs, then examines subscription and pipeline contention issues in those designs and related reactive APIs. ### Source excerpt Introduction If you are following events around Android development, or just happen to follow all things reactive, there was a "big" announcement from Google: they've released their reactive programming library targeting Android specifically: Agera. Of course, one has to look into the details to get an accurate picture. "By Google" means a team in Google working on Google Play Movies. Certainly its sounds more amplified to say Google than the full path to the team. I happen to do this as well when someone asks where I work: in a lab at the Hungarian Academy of Sciences instead of at the Engineering and Management Intelligence Research Laboratory at the Institute for Computer Science and Control of the Hungarian Academy of Sciences. (Plus, you don't get tired and lost while I'm emitting these words :) It doesn't really matter who released it, all that matters what they released and how it relates to the well established reactive libraries, RxJava, Reactor and Akka-Streams, altogether. The Core API The Agera library is built around the valueless Observer pattern: Observables take Updatables and signal change via update() calls. It is then the responsibility of those Updatables to figure out what changed. This is practically a zero argument reactive dataflow which relies on side-effects per update(). interface Updatable { void update(); } interface Observable { void addUpdatable(Updatable u); void removeUpdatable(Updatable u); } They look innocent and reactive, right? Unfortunately, they've run into the issue with the original java.util.Observable and the other addListener/removeListener based reactive APIs (which I categorized as 0th generation). Agera Observable The problem with this pair of methods is that every Observable who adds behavior over an incoming Updatable has to remember the original Updatable in some whay for the case when the same Updatable is removed: public final class DoOnUpdate implements Observable { final Observable source; final Runnable action; ## Operator-fusion (Part 1) DevFeed: [Operator-fusion (Part 1)]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2016-03-11T13:06:00Z Content type: article Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [reactive](), [Programming]() Tags: [implementation](), [programming](), [reactive](), [reactive-programming](), [reactive-streams](), [rxjava]() ### AI overview This article introduces operator fusion in reactive programming: combining successive operators to reduce dataflow overhead in time and memory. It discusses optimization techniques, experimentation in the reactive-streams-commons repository, and relationships to RxJava, Project Reactor, and Akka Streams. ### Source excerpt Introduction Operator-fusion, one of the cutting-edge research topics in the reactive programming world, is the aim to have two of more subsequent operators combined in a way that reduces overhead (time, memory) of the dataflow. (Other cutting-edge topics are: 1) reactive IO, 2) more native parallel async sequences and 3) transparent remote queries.) The key insight with operator-fusion is threefold: many sequences are started from constant or quasi-constant sources such as just(), from(T[]), from(Iterable), fromCallable() which don't really need the thread-safety dance in a sequence of operators, some pairs of operators can share internal components such as Queues and some operators can tell if they consumed the value or dropped it, avoiding request(1) call overhead. In this mini-series, I'll describe the hows and whys of operator-fusion, as we currently understand it. By "we", I mean the joint research effort on optimizing Reactive-Streams operators beyond what's there in RxJava 2.x and has been in previous versions of Project Reactor. The experimentation happens in the reactive-streams-commons, Rsc for short, GitHub repository. The results of the Rsc is now driving Project Reactor 2.5 (currently in milestone 2) and verified by a large user base. Hopefully, RxJava can benefit from the results as well (but maybe not before 3.x). If you are following Akka-Streams, you might have read/head about operator-fusion there as well. As far as I could understand their approach, their objective is to make sure more stages of the pipeline run on the same Actor, avoiding the previous, very likely, thread-hopping with their sequences. Essentially, there is now a mode where the developer can define the async boundaries in the pipeline. Does this sound familiar? From day 1, Rx-based libraries let you do this. Generations Reactive libraries and associated concepts evolved over time. What we had 7 years ago in Rx.NET, requirements and implementation-wise is significantly different w [Next page]()