In my team we’ve started using TravisCI for our projects — namely, for automatically building our app, Curated. We’re happy with the way it integrates with our Github repositories and its easy configurability. It’s also free to use for open source projects — a great quality for any tool.

Doing the initial setup — building the app by pulling the correct tools and then running unit tests when a PR is opened — was easy enough. Our next big hurdle was how to have Travis build a signed, release version of our APK? We wanted to be able to do…

In almost all RxJava example code and tutorials there is one class that reigns supreme — the Observable. It is the object which makes the whole magic of reactive programming possible. It’s simple — you only have to track 3 events — onNext, onError, and onCompleted and you can apply all of the hundreds of possible operators to make it do your bidding. Why would you need anything else, right?

Have you considered whether you actually need to know about those 3 events every time? Hint — in most cases, you don’t. The documentation over at ReactiveX goes on about…

I’m a big RxJava enthusiast. As an Android developer, I use it because it helps streamline my development by cutting down on a lot of the boilerplate that’s generally associated with asynchronous tasks.

As I got more comfortable with Rx, though, I noticed that a lot of my use cases for RxJava follow the same pattern in their setup and finish logic. A common example — loading data for a screen in an app. The code in almost all cases goes like this:

1. Show loading state
2. Load data
3. When data has loaded hide loading state and update UI.
4. Or if…