Thinking Reactively
We assume that you are fairly comfortable with Java and know how to use classes, interfaces, methods, properties, variables, static/non-static scopes, and collections. If you are not familiar with concurrency or multithreading, that is okay. RxJava makes these advanced topics much more accessible.
Have your favorite Java development environment ready, be it IntelliJ IDEA, Eclipse, NetBeans, or any other environment of your choosing. We will be using IntelliJ IDEA, although it should not matter or have an impact on the examples in this book. We recommend that you have a project building framework such as Gradle or Maven, which we will explain how to use shortly.
In this chapter, before diving deeper into RxJava, we will cover some core topics:
- A brief history of Reactive Extensions and RxJava
- Thinking reactively
- Leveraging RxJava
- Setting up your first RxJava...
A brief history of ReactiveX and RxJava
As developers, we tend to think in counterintuitive ways. Modeling our world with code has never been short of challenges. It was not long ago that object-oriented programming was seen as the silver bullet to solve this problem. Making blueprints of what we interact with in real life was a revolutionary idea, and this core concept of classes and objects still impacts how we code today. However, business and user demands continued to grow in complexity. As 2010 approached, it became clear that object-oriented programming solved only part of the problem.
Classes and objects do a great job of representing an entity with properties and methods, but they become messy when they need to interact with each other in increasingly complex and often unplanned ways. Decoupling patterns and paradigms emerged, but this yielded an unwanted side effect of...
Thinking reactively
Suspend everything you know about Java (and programming in general) for a moment, and let's make some observations about our world. These may sound like obvious statements, but as developers, we can easily overlook them. Try to become aware of the fact that everything is in motion. Traffic, weather, people, conversations, financial transactions, and so on are constantly changing or moving through stages.
Technically, even something as stationary as a rock is in motion, as its spatial location changes constantly due to the earth's rotation and orbiting through space. When you consider the possibility that everything can be modeled as being in motion, you may find it a bit overwhelming as a developer.
Another observation to note is that these different events are happening concurrently. Multiple activities are happening at the same time. Sometimes,...
Why should I learn RxJava?
ReactiveX and RxJava address many problems that programmers face daily, allowing them to express business logic and spend less time engineering code. Have you ever struggled with concurrency, event handling, obsolete data states, and exception recovery? What about making your code more maintainable, reusable, and evolvable so it can keep up with your business? It might be presumptuous to call reactive programming a silver bullet that eliminates these problems, but it certainly is a progressive leap toward addressing them.
There is also a growing user demand to make applications responsive in real time. Reactive programming allows you to quickly analyze and work with live data sources such as Twitter feeds or stock prices. It can also cancel and redirect work, scale with concurrency, and cope with rapidly emitting data. Composing events and data as streams...
Setting up
Currently, there are three co-existing versions of RxJava: 1.x, 2.x, and 3.0. We will go through some of the major differences later in the section entitled RxJava 1.x, 2.x, 3.0 – which one do I use? and discuss which version you should use.
RxJava 3.0 is a fairly lightweight library and comes in at fewer than 4 megabytes (MBs) in size. This makes it practical for Android and other projects that require a low dependency overhead. RxJava 3.0 has only one dependency, called Reactive Streams ( http://www.reactive-streams.org/), which is a core library (made by the creators of RxJava) that sets a standard for asynchronous stream implementations, one of which is RxJava 3.0.
RxJava 2x is even smaller—closer to 2 MB—and has only one dependency on Reactive Streams too.
It may be used in other libraries beyond RxJava and is a critical effort in the standardization...
A brief exposure to RxJava
Before we dive deep into the reactive world of RxJava, here is a quick immersion to get your feet wet first. In ReactiveX, the core type you will work with is the Observable class. We will be learning more about the Observable class throughout the rest of this book. But essentially, an Observable pushes things. A given Observable<T> pushes things of type T through a series of operators until it arrives at an Observer object that consumes the items.
For instance, create a new Ch1_1.java file in your project and put in the following code:
import io.reactivex.rxjava3.core.Observable;
public class Ch1_1 {
public static void main(String[] args) {
Observable<String> myStrings =
Observable.just("Alpha", "Beta", "Gamma");
}
}
In our main() method, we have an Observable<String>...
RxJava 1.x, 2.x, or 3.0 – which one do I use?
As stated earlier, you are encouraged to use RxJava 3.0 if you can. This version will continue to grow and receive new features, while RxJava 1.x has not been developed further since March 21, 2018, and 2.x will be maintained for bug fixes only until February 28, 2021. However, there are other considerations that may lead you to use RxJava 1.x or 2.x.
If you inherit a project that is already using RxJava 1.x or 2.x, you will likely continue using it until it becomes feasible to migrate to RxJava 3.0. You can also check out David Karnok's RxJava2Interop project (https://github.com/akarnokd/RxJava2Interop), which converts Rx types from RxJava 1.x to RxJava 2.x and vice versa. After you finish this book, you may consider using this library to leverage RxJava 2.x even if you have the RxJava 1.x legacy code.
Migration to RxJava...
When to use RxJava
A common question ReactiveX newcomers ask is: What circumstances warrant a reactive approach? Do we always want to use RxJava? As someone who has been living and breathing reactive programming for a while, I have learned that there are two answers to this question.
The first answer, when you first start out, is yes! You always want to take a reactive approach. The only way to truly become a master of reactive programming is to build reactive applications from the ground up. Think of everything as Observable and always model your program in terms of data and event flows. When you do this, you will leverage everything reactive programming has to offer and see the quality of your applications go up significantly.
The second answer is that as you become experienced in RxJava, you will find cases where RxJava may not be appropriate. There will occasionally be times...
Summary
In this chapter, you have learned how to look at the world in a reactive way. As a developer, you may have to retrain yourself from a traditional imperative mindset and develop a "reactive" view. If you have done imperative, object-oriented programming for a long time, this may not be easy to accomplish, but the return on investment will be significant as your applications will become more maintainable, scalable, and evolvable. You will also have a faster turnaround and more readable code.
We also have covered how to configure an RxJava project using Gradle or Maven, and what decisions should drive whether you should choose RxJava 3.0, 2.x, or 1.x. We also got a brief introduction to reactive code and how Observable works through push-based iteration.
By the time you finish this book, you will hopefully find reactive programming intuitive and easy to work with...