Integrating ErrorProne and NullAway with an Android project

2017-09-15 Android, Gradle, Java, Static Code Analysis No comments

Recently, with the remote help of guys from Uber in California, I integrated NullAway and ErrorProne with the one of my open-source Android projects.

What is NullAway?

Basically, it’s a tool to help eliminate NullPointerExceptions (NPEs) in your Java code. It detects situations where NPE could occur at the compile time.

Let’s have a look at the following code:

static void log(Object x) {
static void foo() {

NullAway will find out that we’re passing null and we’ll get appropriate error message:

warning: [NullAway] passing @Nullable parameter 'null' where @NonNull is required

It’s good to have checks like that because they eliminate possible bugs in advance and follows Clean Code principles.

A few words about ErrorProne

NullAway is built as a plugin to ErrorProne and can run on every single build of our code. Moreover, ErrorProne can perform other checks on our code, which can find out commonly people mistakes. E.g. it can detect a situation, where programmer forgot to add @Test annotation in the unit test method in a test suite and other things. It has built-in bug patterns, which are used during code analysis.

Integration with the Android project

I’ve integrated ErrorProne and NullAway with ReactiveNetwork Android library.

First, in the main build.gradle file, I’ve added the following lines:

ext.deps = [
            nullaway          : 'com.uber.nullaway:nullaway:0.1.2',
            errorprone        : '',

buildscript {
  repositories {
    maven {
      url ''
  dependencies {
    classpath 'net.ltgt.gradle:gradle-errorprone-plugin:0.0.11'
    classpath 'net.ltgt.gradle:gradle-apt-plugin:0.11'
    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files

Next, in the library/build.gradle file, I’ve added appropriate plugins in the top:

apply plugin: 'net.ltgt.errorprone'
apply plugin: 'net.ltgt.apt'

Afterwards, I could add dependencies:

dependencies {

  annotationProcessor deps.nullaway
  errorprone deps.errorprone

The last thing to do, is the task responsible for running analysis during project compilation:

tasks.withType(JavaCompile) {
  if (!name.toLowerCase().contains("test")) {
    options.compilerArgs += ["-Xep:NullAway:ERROR", "-XepOpt:NullAway:AnnotatedPackages=com.github.pwittchen.reactivenetwork"]

That’s it! Now, I could run analysis by typing:

./gradlew check

and fix the issues.

I think, a quite similar approach and configuration could be applied to a regular, pure Java project built with Gradle.

If you’re interested in the complete configurations, check it out in my project at:
You can also view Pull Request #226 made by @msridhar (kudos for him!).

Building and running SAP Hybris Commerce Platform via Gradle

2017-09-01 Gradle, Hybris No comments


I really like Gradle build system for JVM apps. It has flexibility like Ant and great dependency management capabilities like Maven. It addition, it doesn’t use XML notation, but Groovy programming language, so builds configurations are simple, concise, easier to read and easier to create. In my opinion, Gradle is truly modern build system for JVM apps. Nevertheless, there are projects, which are pretty old and use older systems like Ant. For example, all Hybris projects are based on Ant. Moreover, they have their custom setup and configurations, internal extensions system, etc. I was wondering if it’s possible to migrate Hybris Platform build from Ant to Gradle. That’s why I created a simple Proof of Concept.

Migrating from Ant to Gradle

If we want to use Gradle, we need to install it first.

sudo apt-get install gradle         # if we're on Ubuntu Linux
brew install gradle                 # if we're on macOS

For more details and instructions for other systems, check official Gradle installation guide.

Then, we need to go to our Hybris platform directory and navigate to hybris/bin/platform

After that, we need to initialize gradle inside this directory by running gradle command.
Next, we need to create gradle wrapper by running gradle wrapper command.
Now we should have the following elements in our directory:

  • .gradle (directory)
  • graldew (wrapper file for Unix)
  • gradlew.bat (wrapper file for Windows)

Afterwards, we can create build.gradle configuration file.

It should have the following contents:

ant.importBuild 'build.xml'
apply plugin: 'java'

repositories {

task run() {
  doLast {
     exec {
          executable "./"

task cleanGeneratedDirs(type: Delete) {
  delete "../../data"
  delete "../../log"
  delete "../../roles"
  delete "../../temp"

task cleanConfig(type: Delete) {
  delete "../../config"

dependencies {
  compile fileTree(dir: 'lib', include: ['*.jar'])

Now, we can execute the following command:

./gradlew clean build

and platform will be built.

In order to initialize the platform, we can call:

./gradlew initialize

If we want to start the Hybris server, we can simply call:

./gradlew run

To clear directories generated during build and initialization, we can run:

./gradlew cleanGeneratedDirs

I tried to make clean task dependent on this one, but I got a few errors and didn’t spend too much time on investigating them.

As you probably noticed, this solution is just a wrapper around Ant build defined in build.xml file and it’s not pure Gradle build configuration. Nevertheless, these tips may be useful for the people who need to have custom build configurations and dependencies. There’s no doubt that creating and maintaining configurations via Gradle is much easier and more convenient than doing the same job via Ant.


As we can see, it’s possible to migrate Hybris build from Ant to Gradle, but please remember that Hybris has a custom setup and it may not be the best decision in each case. We should always consider pros and cons of such solution and adjust it to our needs. In legacy systems, we often have to stick to existing setups because making “revolution” may be a huge overhead and doesn’t have to pay off. Moreover, all Hybris extensions also have build configurations based on Ant. On the other hand, I can highly recommend Gradle for greenfield JVM projects.


There’s another nice, short article describing migrating Java projects from Ant to Gradle: Easily Convert from Ant to Gradle (

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:

Using Tmux plugins with Tpm

2017-08-07 Linux, Tmux No comments

Recently, I decided to organize my Unix dotfiles in a better way. I had a few custom scripts I used in my Tmux bottom bar. I kept these scripts in .scripts directory and during installation or upgrade of my personal configuration, script was copying them from .scripts directory to /usr/local/bin/ directory. I wanted to make this configuration more solid and consistent, so I decided to transform these scripts into tmux plugins managed by tpm. I was already using a few plugins like:

In my Tmux bottom bar, I display battery level, uptime, CPU, RAM, IP number and song currently played on Spotify. Previously I just used scripts copied to /usr/local/bin/ and configuration looked like that:

set -g status-right "↑ #(showUptime) ⇅ #(showCpuUsage) ☰ #(showRamUsage) ∴ #(showIp) ↯ #{showBatteryLevel} ⧖ #(date '+%a, %b %d, %H:%M') "

I created the following plugins to replace these scripts:

In order to use Tmux plugins, we need to install Tmux Plugin Manager:

git clone ~/.tmux/plugins/tpm

and initialize it at the bottom of our .tmux.conf file:

run '~/.tmux/plugins/tpm/tpm'

After that, it’s good to reload shell (source ~/.zshrc) and Tmux config (tmux source-file ~/.tmux.conf)

Next, we can add our plugins to .tmux.conf file:

set -g @plugin 'tmux-plugins/tmux-sidebar'
set -g @plugin 'tmux-plugins/tmux-copycat'
set -g @plugin 'tmux-plugins/tmux-pain-control'
set -g @plugin 'tmux-plugins/tmux-urlview'
set -g @plugin 'pwittchen/tmux-plugin-battery'
set -g @plugin 'pwittchen/tmux-plugin-uptime'
set -g @plugin 'pwittchen/tmux-plugin-cpu'
set -g @plugin 'pwittchen/tmux-plugin-ram'
set -g @plugin 'pwittchen/tmux-plugin-ip'
set -g @plugin 'pwittchen/tmux-plugin-spotify'

When we are in Tmux, we can install plugins by pressing prefix + I to install plugins. In my case, prefix = Ctrl+b.
After that, we can hit Enter and we’re ready to go!

Now, I could update my .tmux.conf with the variables defined by my plugins:

set -g status-right " 🔉 #{spotify_song} ↑ #{uptime} ⇅ #{cpu} ☰ #{ram} ∴ #{ip} ↯ #{battery_level} ⧖ #(date '+%a, %b %d, %H:%M') "

After this operation, I could remove custom scripts from my dotfiles and desired functionality is delivered via plugins. Moreover, anyone can install these plugins via tpm without messing with custom scripts!

screenshot from tmux after configuration

Right now, my plugins are in kind of messy state and they don’t work perfectly across all operating systems (e.g. there are problems on macOS), but they’re usable under Linux Ubuntu 16.04 LTS and it’s a good beginning for organizing mess created by the custom scripts.

That’s it! I have plans to publish another article describing how to write your custom Tmux plugin, which can be managed via tpm.

Releasing ReactiveNetwork v. 0.11.0 with Walled Garden AKA Great Firewall support

2017-08-06 Android, Java, Open source No comments

In the latest release of ReactiveNetwork library, I focused on Walled Garden AKA Great Firewall support during checking Internet connectivity. There are countries with limited Internet access like China and in such cases, pinging commonly known host like may have different results than in other countries because it may be blocked. We may get false positive results because users will generally have an access to the Internet, but they don’t have access only to several websites. To solve that problem, I created WalledGardenInternetObservingStrategy and made it default strategy for checking Internet connectivity inside the library. Of course, you can still use SocketInternetObservingStrategy if you want to.

Detailed release notes are as follows:


  • added WalledGardenInternetObservingStrategy – fixes #116
  • made WalledGardenInternetObservingStrategy a default strategy for checking Internet connectivity
  • added documentation for NetworkObservingStrategy – solves #197
  • added documentation for InternetObservingStrategy – solves #198
  • bumped Kotlin version to 1.1.3-2
  • bumped Gradle Android Tools version to 2.3.3
  • bumped Retrolambda to 3.7.0


  • added WalledGardenInternetObservingStrategy – fixes #116
  • made WalledGardenInternetObservingStrategy a default strategy for checking Internet connectivity
  • added documentation for NetworkObservingStrategy – solves #197
  • added documentation for InternetObservingStrategy – solves #198
  • fixed package name in AndroidManifest.xml file – solves #195
  • bumped RxJava2 version to 2.1.2
  • bumped Kotlin version to 1.1.3-2
  • bumped Gradle Android Tools version to 2.3.3
  • bumped Retrolambda to 3.7.0
  • increased code coverage with unit tests

Repository address:

Happy coding!

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

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

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.

DSP 2017 – Summary

2017-05-31 DSP2017 2 comments


Some time ago, I’ve decided to participate in “Get Noticed 2017” (“Daj się poznać” in Polish) competition. It’s competition for Polish programmers in which people have to create a blog if they don’t have it (luckily, I could skip that step) and write at least 2 articles per week from the beginning of the March til the end of May, which is exactly today (for 3 months). Posts had to be categorized on the blog. You can find all my posts related to this competition in DSP2017 category. Besides this, competitors had to create their own open-source projects (or one project) and contribute to them during the competition. I already had my projects, so I kept resolving planned issues within them. Nevertheless, I created new, small projects. I treated that competition as a challenge and possibility to try something new. Moreover, it was some kind of motivation for doing more stuff. I already had a blog and OS projects, so I thought it will be easy for me and I’ll just keep doing what I already do. I was a little bit wrong.


I’ve written 28 articles on this blog in DSP2017 category (including this one). Writing two articles per week is a lot. Previously I was writing approximately 1 article per month or sometimes more when I wanted to. Now I was writing 8 articles per month, so It’s 800% more often than usual. It forced me to be a little bit more organized & creative. I also created a backlog of article topics and a backlog of the software projects (big & small) I wanted to create & eventually, describe.

In the chart below, you can see how the number of the articles increased when I started participating in the competition.

Moreover, I received more comments than usual. The peak in 2015 you see on the picture is an article about Test coverage report for Android application. For some reason, people found it interesting and had a lot of questions.

I observed slightly more visitors on the blog, but not very huge. There was a peak in the beginning of the March, but later it decreased to a bit higher level than it was to the starting point. Below you can see statistics from the Google Analytics from the last 90 days. The drops on the plots are on the weekends. It shows people usually visit my website during the work week. Interesting information is the fact that drop of the visitors in the beginning of the April on the weekend was smaller than usual because I was speaking at the conference, so probably people googled me these days.


During the DSP2017, I created the following new projects:

  • spotify-cli-linux – a command-line interface to Spotify on Linux written in Python
  • tmux-auto-pane – a tiny tool for creating pre-defined tile layouts in tmux on linux with xdotool written in Bash
  • YaaS Java SDK – Hybris as a Service Java SDK for microservice proxy

During the DSP2017, I updated the following projects:

  • ReactiveBeacons – Android library scanning BLE beacons nearby with RxJava (an update included migration to RxJava2)
  • ReactiveNetwork – Android library listening network connection state and Internet connectivity with RxJava Observables (an update included migration to RxJava2)
  • prefser – Wrapper for Android SharedPreferences with object serialization and RxJava Observables
  • swipe – detects swipe events on Android (with RxJava or listener)
  • pkup – semi-automated generating of PKUP report (tiny tool for formal reporting stuff at my work)

I also updated my dotfiles and a few on my public knowledge sources I store on GitHub, but they are not counted as a “regular projects”


During this competition I also gave a talk during Kariera IT Conference in Katowice, Poland titled How to make open-source projects, which people want to use. I was invited to this conference as a speaker, what was very flattering. I also received nice, valuable feedback from the conference organizers. Besides that, I also participated in the J On The Beach conference in Malaga, Spain as an attendee. Unfortunately, I haven’t found time to write an article summarizing this event. I can tell you it was really great. Besides the conference itself, location, weather & food were perfect! I also had to write two articles on the blog for the given week in advance, because I haven’t taken my laptop on this trip.


To wrap up, participating in this competition was quite challenging and harder than I thought it would be. Nevertheless, it helped me to be consistent and more organized. I also boosted my creativity and ability to produce more articles as well as writing and language skills (English is not my native language). It was hard but fun. The challenge is accomplished! There are over 1000 participants, so I treat this event rather as a challenge for myself than competing with others. Moreover, it’s hard to measure and compare such work among different people. Nevertheless, I’m looking for results anyway :-).


Woohoo! I was on the 14th place in the second round of the competition! Results are here: Unfortunately, there were better competitors in the final round. Congrats to organizer, winners and all the people who participated in this competition & meetup in Warsaw. It was a really fun experience! 🙂

You can also check my tweet from the meeting in MS Warsaw:

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:

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: