Simple reactive HTTP client & server with RxJava, Vert.x and Android

2017-11-09 Android, Java, RxJava, Vert.x No comments

During Hack Your Career event at the Silesian University of Technology, I’ve prepared a presentation titled Reactive Programming – Efficient Server Applications with a colleague from work. Arek told about theory of Reactive Programming, shown basic concepts, data types and a few examples in the code. During my part of the presentation, I’ve wrote a very simple server and client in Java (9 on the server, 7 on the client) with Vert.x (Core and Rx), RxJava 2, OkHttp 3, Android and RxAndroid. Presentation was targeted mainly to the university students with no experience with reactive programming, but it was an open event and anyone could attend it.

Below, we can see a very simple code snippet showing how to create a reactive HTTP server with Vert.x. We can create a stream of requests, make Flowable out of it, apply any kind of RxJava 2 operator including backpressure handling and subscribe the stream. Moreover, we can also reactively start the server with rxListen(int port) method. This is just a basic example, where will be sending request to the only one endpoint. In the case, when we want to handle more endpoints, we can use vertx-web library and design REST API.

final HttpServer server = Vertx

    .subscribe(request -> {
      logger.info("{} {}", request.rawMethod(), request.absoluteURI());
      request.response().end("request received");

    .subscribe(httpServer -> logger.info("server is running at port 8080..."));

We can build this server with Gradle as follows:

./gradlew shadowJar

and then, we can run it:

java -jar build/libs/server-fat.jar

Our client will be an Android application, which will read data from the accelerometer sensor, send it to the server and display it in the TextView on a mobile device. We will use ReactiveSensors library (which was recently migrated to RxJava 2) for getting sensor readings as a Flowable data stream. Next, we will apply backpressure DROP strategy, filter only events of changing sensors (we neglect changing of the accuracy), read only one event per one second with throttleLast(int, TimeUnit) operator and map event to a String with device coordinates. Next, we are ready to send data with Completable performRequest(String), which we created earlier. Sensors readings are acquired in the computation() scheduler, send to the server with io() scheduler and passed to the UI thread on Android with AndroidSchedulers.mainThread(). Distributing operations to the different schedulers is made with subscribeOn(Scheduler) and observeOn(Scheduler).

    .throttleLast(1, TimeUnit.SECONDS)
    .doOnNext(event -> performRequest(event)
    .subscribe(event -> tvReadings.setText(event));

It’s worth noticing that Completable performRequest(String) is using OkHttp 3 under the hood as a HTTP client, because it’s very simple example with one endpoint. In the case, we want to handle more endpoints on the client-side, it’s better to use Retrofit library.

It’s also interesting that in our case, we can simulate behavior of the accelerometer and other sensors with the latest Android device emulator available in the Android SDK. It works surprisingly smooth.

Complete working example can be found at: https://github.com/pwittchen/reactive-client-server.

Later, I’ve also shown, how to use RxJava to distribute computational operations to a different threads of the CPU cores, but I’ll probably publish a separate article about that on this blog. It was the same example I shown during my JDD presentation this year.

Slides from my part of the presentation are available below.

JDD 2017: Get ready for java.util.concurrent.Flow! – slides, code and recap

2017-10-05 Conferences, Java, RxJava 2 comments

Recently on the JDD 2017 conference, I gave a presentation regarding introduction to Reactive Streams standard in Java 9. I also talked about existing implementations of this standard with the strongest focus on RxJava2 and created simple Reactive Streams implementation in pure Java 9 during the presentation. Below, you can find slides from this talk.

Code snippets shown during this presentation are available at https://github.com/pwittchen/java-flow-experiments.
I have done a tiny live coding session during this talk. Luckily, everything went fine, the code was compiled and executed without errors. Everything I’ve done during this presentation and additional exploratory unit tests could be found in this repository so you can check it out if you’re interested.

There were also tweets made by the audience just before the presentation.

I can say that conference room was full. There were even people sitting on the floor due to lack of free chairs what really surprised me. In the Eventory app, more than 85 people joined the lecture, but in reality, there could be about 100 people or more. It was really flattering that such huge and great audience decided to listen to my talk. In fact, that was the biggest audience I have ever had during the public presentation so far. Moreover, people were asking many interesting questions during Q&A session and after the presentation, so it means they were interested in this topic and they wanted to learn more, understand it and apply it in their projects. If you haven’t had the opportunity to see this presentation, but you would like to, JDD organizers will provide video recordings from the sessions. In addition, you can monitor Talks page on this blog, where I publish my past and upcoming sessions. Probably, I’ll present this topic again during one or two meetups because people are interested in it.

Joining JDD 2017 as a speaker was a great experience. It cost me an additional work and effort after hours, but at the end of the day, it was totally worth it and it was much easier to establish contacts and meet new people as a speaker than as an attendee, what is important for me. Moreover, I could learn new things from other people as well because general level of the conference presentations was pretty high.

Thanks for the interesting questions, discussions, other good presentations and support before the talk!

Below you can find two pictures from this talk made by JDD 2017 photographers.

JDD 2017: Get ready for java.util.concurrent.Flow!

2017-10-02 Conferences, Java, Po polsku, RxJava No comments

Get ready for java.util.concurrent.Flow!

On the 3rd of October 2017 I will be giving a talk titled “Get ready for java.util.concurrent.Flow! at JDD 2017 Conference in beautiful Kraków, Poland.
The talk will be in Polish and you can find a short Polish description of it below.

W Javie 9 otrzymamy do dyspozycji nową klasę z pakietu java.util.concurrent o nazwie Flow. Idea stojąca za tym rozwiązaniem wywodzi się z projektu Reactive Streams. W związku z tym, najnowsza wersja Javy będzie posiadała natywne wsparcie dla tworzenia reaktywnych aplikacji zgodnych ze wspomnianym standardem. Już dziś możemy z tego standardu korzystać i warto się z nim zapoznać wcześniej. Co więcej, od jakiegoś czasu mamy do dyspozycji istniejące implementacje Reactive Streams, które są sprawdzone i gotowe do użycia w projektach na platformę JVM. Wszystkie biblioteki implementujące ten standard mogą ze sobą współpracować dzięki wspólnemu API. Programowanie reaktywne pozwala na pisanie wydajnych aplikacji, które optymalnie wykorzystują zasoby sprzętowe. To podejście pozwala również na dodanie czytelnej warstwy abstrakcji dla aplikacji wielowątkowych oraz wygodne zarządzanie strumieniem danych bez utraty czytelności kodu. Warto dodać, że programowanie reaktywne sprawdza się zarówno na serwerach obsługujących dużą liczbę żądań, jak i na urządzeniach mobilnych, gdzie większość operacji musi być wykonywanych asynchronicznie bez blokowania głównego wątku. Podczas prezentacji chciałbym przedstawić na przykładach popularne implementacje standardu Reactive Streams w Javie 8 takie jak RxJava2 i Project Reactor oraz przykładową, prostą implementację tego samego standardu w Javie 9 z wykorzystaniem klasy java.util.concurrent.Flow.

Date and time of the talk: Day 1, Track 4, Oct 3rd 3:00pm – 3:45pm

This will my very first talk on the JDD conference. I’ve attended this conference a few times as a participant in the past and now it’s time to give a talk as a speaker. I warmly invite everyone who is going to join JDD this year to attend my talk. I’ll try to do my best to keep you interested. There will be an overview of reactive programming, reactive libraries and reactive streams interfaces in Java 9. To keep you awake, we’ll do some live coding and demos on stage.


Due to the fact, I will be speaking on the JDD for the first time, and I’m participating in JUGmajster competition representing SJUG team with two of my colleagues Daniel Pokusa and Grzegorz Gajos. Check out their talks too!

You should also view complete conference schedule. In addition, don’t forget to visit main page of the conference at https://jdd.org.pl.

If you would like to have a discussion, ask a question or just have a beer together, don’t hesitate to reach me! 🙂

See you in Kraków!

Introducing ReactiveAirplaneMode

2017-08-15 Android, Open source, RxJava No comments

I’m continuing Rxfication of the Android. Recently I released brand new library called ReactiveAirplaneMode. As you may guess, it allows listening Airplane mode on Android device with RxJava observables. A usual I’ve hidden all implementation details, BroadcastReceivers and rest of the Android related stuff behind RxJava abstraction layer, so API is really simple. Just take a look on that:

    .subscribe(isOn -> textView.setText(String.format("Airplane mode on: %s", isOn.toString())));

In the code above subscriber will be notified only when airplane mode changes.

If you want to read airplane mode and then listen to it, you can use the following method:

    .subscribe(isOn -> textView.setText(String.format("Airplane mode on: %s", isOn.toString())));

If you want to check airplane mode only once, you can use get(context) method, which returns Single<Boolean> value:

    .subscribe(isOn -> textView.setText(String.format("Airplane mode on: %s", isOn.toString())));

If you want to check airplane mode only once without using Reactive Streams, just call isAirplaneModeOn(context) method:

boolean isOn = ReactiveAirplaneMode.create().isAirplaneModeOn(context);

You can add this library to your project via Gradle:

dependencies {
  compile 'com.github.pwittchen:reactiveairplanemode:0.0.1'

If you want to know more details, see sample app, documentation & tests, check repository with the source code at: https://github.com/pwittchen/ReactiveAirplaneMode.

Releasing ReactiveNetwork v. 0.10.0

2017-07-20 Android, Open source, RxJava No comments

I’ve recently released ReactiveNetwork library v. 0.10.0 for RxJava1.x and RxJava2.x.
ReactiveNetwork is an Android library listening network connection state and Internet connectivity with RxJava Observables, which I’m developing for approximately 2 years now.

In this version, I’ve done a few bug fixes and added new features for RxJava2.x version.

Below, you can find the release notes:

Release for RxJava1.x

  • bumped RxJava1 version to 1.3.0
  • bumped test dependencies
  • created Code of Conduct
  • updated Kotlin version in sample apps
  • added retrolambda to the sample Java app – issue #163
  • fixed behavior of network observing in disconnected state – issue #159

Release for RxJava2.x

  • bumped RxJava2 version to 2.1.1
  • bumped test dependencies
  • created Code of Conduct
  • updated unit tests
  • updated Kotlin version in sample apps
  • added retrolambda to the sample Java app – issue #163
  • fixed behavior of network observing in disconnected state – issue #159
  • added the following methods to ReactiveNetwork class:
    • Single<Boolean> checkInternetConnectivity()
    • Single<Boolean> checkInternetConnectivity(InternetObservingStrategy strategy)
    • Single<Boolean> checkInternetConnectivity(String host, int port, int timeoutInMs)
    • Single<Boolean> checkInternetConnectivity(String host, int port,
      int timeoutInMs, ErrorHandler errorHandler)
    • Single<Boolean> checkInternetConnectivity(InternetObservingStrategy strategy,
      String host, int port, int timeoutInMs,
      ErrorHandler errorHandler)

You can add it to your project via Gradle:


dependencies {
  compile 'com.github.pwittchen:reactivenetwork:0.10.0'


dependencies {
  compile 'com.github.pwittchen:reactivenetwork-rx2:0.10.0'

Now, in RxJava2.x version, we have the possibility to check Internet connectivity once without any pooling with new Single type. It may be helpful in the specific use-cases when we’re focusing on smaller battery usage, a smaller amount of data being sent over the network and lower number of network connections.

I’m planning to publish more real life usage examples of this library in the future articles on this blog.

I have plans for a few updates in the next version. If you’re interested in this project or you’re using it, please stay tuned and keep an eye on it at GitHub.

Release of prefser v. 2.1.0 with RxJava2 support

2017-06-19 Android, Java, Open source, RxJava 2 comments

I’ve recently released new version of prefser library for Android. In case you don’t know, it’s a wrapper for Android SharedPreferences with object serialization and RxJava Observables. This version has the new artifact, which has codebase migrated to RxJava2.x. As usual, I kept backward compatibility with RxJava1.x.

You can find more details about the project at https://github.com/pwittchen/prefser.

If you want to use it in your mobile project, you need the following dependencies in the build.gradle file:

dependencies {
  compile 'com.github.pwittchen:prefser-rx2:2.1.0'
  compile 'io.reactivex:rxandroid:2.0.1'

Short release notes can be found at https://github.com/pwittchen/prefser/releases.

This update was requested by at least two developers on GitHub and it’s my second most popular project, so I hope you’ll find it useful if you’re in the process of migrating from RxJava1.x to RxJava2.x. I still have 4 remaining RxJava1.x libraries waiting for the upgrade. If you want to perform any updates via Pull Requests, you’re more than welcome.

New reactive data types in RxJava2

2017-05-31 DSP2017, Java, RxJava No comments


I’m still exploring reactive programming world and RxJava library. Recently, I’ve migrated a few of my open-source libraries from RxJava1 to RxJava2 and written yet another project in RxJava2 from the beginning. Nevertheless, I’m still learning this library and its concept. It’s very wide topic. In RxJava1 we simply had one reactive data type called Observable. In RxJava2, we have more data types like Observable, Flowable, Single, Maybe & Completable. In this article, I’ll briefly explain their purpose and tell you when to use which. The general idea behind these types is code semantics. We should tell consumer of our code, what he or she can expect from our API. Introducing more reactive data types can increase readability and stability of our code base.


Observable is basically the same Reactive type, we had in RxJava1. It doesn’t have backpressure support.

We should use Observable, when:

  • our data source emits less than 1000 items, so there’s practically no chance of occurring OutOfMemoryException
  • we are working with GUI events, which usually don’t occurs very often and don’t have to be backpressured
  • we are working with synchronous code on legacy JVM like Java 1.6 and we want to have streams features like in Java 8



Flowable type has very similar semantics to Observable. We can operate on Flowable streams with map, flatmap, filter, etc. in the same way as on the Observable type. The main difference is backpressure support.

We should use Flowable when we are:

  • dealing with 10k+ elements in a stream
  • dealing with frequent events (e.g. sensors readings)
  • reading/parsing files from disk
  • reading values from database through JDBC
  • using network/streaming I/O
  • reading/writing to many blocking or pull-based data sources

To learn more, read note about Observable vs. Flowable on wiki of RxJava2 on GitHub.


Single reactive type has been redesigned from scratch in RxJava 2. It’s designed to handle just one event in an asynchronous manner. Good application of this type is single HTTP request when we expect just one response or error and nothing else. It can emit on onSuccess (single value) or onError event (error).



Maybe represents a deferred computation and emission of a maybe value or exception. Maybe is a wrapper around an operation/event that may have either:

  • A single result
  • Error
  • No result

Just take a look at the scheme.

The interface of the main consumer of this type have the following methods: onSuccess, onError, onComplete. Conceptually, Maybe is a union of Single and Completable providing the means to capture an emission pattern where there could be 0 or 1 item or an error signaled by some reactive source.



Completable type can be used when we have an Observable that we don’t care about the value resulted from the operation (result is void). It handles only onComplete and onError events. Conceptually, Maybe is a union of Single and Completable providing the means to capture an emission pattern where there could be 0 or 1 item or an error signalled by some reactive source.

Read more about Maybe type on RxJava wiki.


As we can see, RxJava2 gives us new types, which can help explain our intentions more clearly. We can adjust concrete type to the specific situation. In addition, we can use backpressure for the data sources, which emit a lot of elements to make our projects more robust and stable. Last, but not least RxJava2 is compatible with Reactive Streams API, which is going to be part of the Java 9 specification.


Introducing YaaS Java SDK

2017-05-28 DSP2017, Hybris, Java, Open source, RxJava, YaaS No comments


In my company, there’s a concept of so-called “innovation day”. I have the possibility to “use” 1 innovation day per 2 development sprints. Last year, I used only 1 day due to the tight release schedule and a lot of work. Now, we are right after release, so I had time to take innovation day once again. I’ve decided to create YaaS Java SDK. If you don’t know what the YaaS is, check out my previous article about Basic usage of YaaS proxy for the microservice. In a few words, it’s a proxy for the microservices with authorization & monitoring capabilities, which allows using other services available on the YaaS market. SDK created by me is really simple, was created in a short period of time and does not cover all features of the YaaS. This SDK allows performing authorized requests to the microservices hidden behind YaaS proxy.

Tech stack used for this project is as follows:

For unit testing I used:

Quick start

I wanted to make this SDK as simple as possible so the user can add YaaS integration to the Java application within just a few lines of code.

YaaSProject project = new YaaSProject.Builder()

Client client = new YaaS(project);

    .subscribe(response -> System.out.println(response.body().string()));

As you can see, it looks really simple and straightforward. In the code snippet above, we’ve done the following thigs:

  1. Defined YaaS Project with YaaS service
  2. Created YaaS Client
  3. Performed HTTP GET request to the endpoint of the microservice asynchronously
  4. Received and printed body of the HTTP response from the microservice on the current thread as a String

All of that was done with Single type from RxJava2, which wraps Response type from OkHttp. We have a reactive stream of HTTP response here and we can do with it whatever RxJava2 offers us. Like filtering, mapping, throttling, combining it with other stream and so on.

For more information, visit repository of the project at: https://github.com/pwittchen/yaas-java-sdk.

Future plans

I have the following plans related to this project, which may be realized when I’ll have time:

  • Add more unit tests (I didn’t have enough time to cover all cases)
  • Add continuous integration
  • Integrate YaaS with SAP Hybris Backoffice or SAP Hybris Core Platform through this SDK (PoC)
  • YaaS Android SDK (copy YaaS Java SDK, downgrade it to Java 7 & optionally migrate to Kotlin and create sample mobile app)
  • Optionally, add more features to YaaS Java SDK
  • Optionally, deploy an artifact to Maven Central repository
  • Optionally, create SDKs for different programming languages (especially those I don’t know well or I don’t know at all – just to learn them)


Interesting links related to this article:

Joining lists of RxJava Observables

2017-05-15 DSP2017, Java, RxJava No comments

In RxJava we have a few operators for joining Observables. The most common are:

Take a look at the documentation in these links. It has interactive marble diagrams showing how the operators work on the streams. You can move marbles along the lines and see how the output stream changes. It really helps to understand how it works.

Code snippets in this article are based on RxJava 2.1.0 with JUnit 4.12 and Google Truth 0.32 for unit tests.

Let’s say, we have the following Observables:

public Observable<String> emitNumbers() {
  return Observable.fromArray("1", "2", "3", "4").delay(1, TimeUnit.SECONDS);

public Observable<String> emitLetters() {
  return Observable.fromArray("a", "b", "c", "d");

We can merge them in the different ways.


Concat operator emits the emissions from two or more Observables without interleaving them.

We can perform the following operation:

public Observable<String> concatStreams() {
  return Observable.concat(emitNumbers(), emitLetters());

The easiest way to verify, how this operator works, is to create exploratory unit test as follows:

public void shouldConcatStreams() {
  // given
  Observable<String> observable = playground.concatStreams();
  List<String> expectedValues = Arrays.asList("1","2","3","4","a","b","c","d");
  List<String> joinedValues = new ArrayList<>();

  // when
  observable.blockingSubscribe(s -> joinedValues.add(s));

  // then

This operation can be represented graphically as well.

         1 --- 2 --- 3 --- 4
         a --- b --- c --- d
1 -- 2 -- 3 -- 4 --- a -- b -- c -- d  

As we can see one stream is appended to another regardless of the execution time of both streams.


Merge operator combines multiple Observables into one by merging their emissions.

Here we have a similar story, but changed operator:

public Observable<String> mergeStreams() {
  return Observable.merge(emitNumbers(), emitLetters());

We are writing another unit test:

public void shouldMergeStreams() {
  // given
  Observable<String> observable = playground.mergeStreams();
  List<String> expectedValues = Arrays.asList("a","b","c","d","1","2","3","4");
  List<String> joinedValues = new ArrayList<>();

  // when
  observable.blockingSubscribe(s -> joinedValues.add(s));

  // then

Merge operation should look like that:

         1 --- 2 --- 3 --- 4
         a --- b --- c --- d
a -- b -- c -- d --- 1 -- 2 -- 3 -- 4

This operator doesn’t synchronize the streams and merges them as values are emitted. Numbers are emitted later than letters, so letters are placed in the beginning of the output stream. Try to manipulate marble on the interactive diagram on the reactivex.io website to see how it should work.


The last operator, I’d like to discuss in this article is “Zip” operator. Zip combines the emissions of multiple Observables together via a specified function and emit single items for each combination based on the results of this function.

In simple words, it waits until many observables are emitted and then combines them into a pair (or triple Observable, etc. in the case or more Observables).

Now, we need to create a function, which will transform our streams and return combined stream.

public Observable<String> zipStreams() {
  return Observable.zip(emitNumbers(), emitLetters(),
      (s1, s2) -> String.format("(%s,%s)", s1, s2));

Next, we can verify it with test as usual:

public void shouldZipStreams() {
  // given
  Observable<String> observable = playground.zipStreams();
  List<String> expectedValues = Arrays.asList("(1,a)","(2,b)","(3,c)","(4,d)");
  List<String> joinedValues = new ArrayList<>();

  // when
  observable.blockingSubscribe(s -> joinedValues.add(s));

  // then

and it can be represented graphically like that:

        1 --- 2 --- 3 --- 4
        a --- b --- c --- d
 (1,a) -- (2,b) --- (3,c) -- (4,d)

Now, we have pairs of merged streams.


Of course, RxJava is complicated library and these methods are not covering all possibilities of merging and combining the Observable streams. Neverhteless, examples in this article are quite basic and may help you to understand how mentioned operators work. After that we can apply the best operator to appropriate situation.

Reference thread on StackOverflow: http://stackoverflow.com/questions/28843318/android-rxjava-joining-lists

Emitting different RxJava Observables depending on the condition with flatMap operator

2017-05-14 DSP2017, Java, RxJava No comments

Sometimes, we may need to emit different RxJava Observables depending on the specific condition dynamically. Moreover, it’s good to do it right without breaking a chain (stream of Observables). We want to combine different Observables together and do not want to nest one subscription inside another subscription because this will lead us to “subscription hell” similar to “callback hell”. Luckily RxJava has mechanisms to deal with such problems. In this article, I’m basing my examples on RxJava 2.1.0.

Let’s say we have two Observables:

public Observable<String> trueObservable() {
  return Observable.fromCallable(() -> "trueObservable");

public Observable<String> falseObservable() {
  return Observable.fromCallable(() -> "falseObservable");

and we have another Observable wrapping Boolean value:

public Observable<Boolean> createCondition(boolean returnedValue) {
  return Observable.fromCallable(() -> returnedValue);

This Observable can emit true or false depending on the provided parameter.

What we want to do is to:

  • emit trueObservable() when createCondition(boolean) returns true
  • emit falseObservable() when createCondition(boolean) returns false
  • emit falseObservable() when createCondition(boolean) emits empty Observable (default behaviour)

We can do it in the following way:

public Observable<String> emitTrueObservableDynamically() {
  return createCondition(true)
      .flatMap(condition -> condition ? trueObservable() : falseObservable());

In such case, this method will emit trueObservable(). When we change parameter of the createCondition(boolean) method to false, Observable will emit falseObservable(). When we replace createCondition(boolean) method with Observable.empty(), method will return falseObservable() by default. As we can see, it’s easily solved with flatMap and defaultIfEmpty operators.

This is quite useful technique, which we can apply to reactive applications to control our flow without breaking the chain. Please note, it’s just an example you can create more complicated constructions and handle more complicated types than just boolean and more than two use cases.

Reference thread for this article on StackOverflow: http://stackoverflow.com/questions/34195218/rxjava-exequte-observable-only-if-first-was-empty.