RxJava has been gaining popularity in the past couple of years and today is widely adopted in the Android community. So much in fact that I can’t recall an Android developer interview in the past 3 years that doesn’t mention RxJava.
Here is a short list of the most common interview questions I have asked candidates (or been asked as an interviewee). Answers to all questions can be found further down.
read more
This is Part 2 of a short series about optimising your build speeds. If you haven’t already, please check out Part 1, which describes the different build caches you can use.
In this post, I’ll explain some other build properties you can tweak. Let’s start with the Gradle ones.
read more
One of my last tasks @ASOS was to investigate the slow build speeds of the Android application. This post is part of a short series about how we approached the problem, what we tried and what we found out. To be clear, don’t expect miracles and 🦄 here, but you’ll get a better understanding of what you can do to optimise your builds.
read more
With the exponentially increasing usage of Kotlin these days, many developers face the issue of how to test the newly created Kotlin classes. As we know all classes and methods are final be default in Kotlin, unless specifically open-ed. Unfortunately Mockito, one of the most popular mocking libraries for Java projects, can’t easily mock final classes. Since we don’t want to open up everything just for testing purposes, we need another solution.
Hadi Hariri highlighted in his excellent blog post that Mockito version 2.1.0 and above can perform the magic of mocking final classes. Since mocking is something used only in tests … and usually it just works, we’ve neglected Mockito and were still using a very outdated version (1.10.19) in our project. There were a few pain-points while updating to the latest one, so hopefully this post will save you some time when going through the same process.
read more
Consider the following example:
public Observable<Book> getFavoriteBook(User user) {
return Observable.just(user.getFavoriteBookId())
.flatMap(bookId -> bookService.getById(bookId))
.onErrorReturn(throwable -> DEFAULT_FAVORITE_BOOK);
}
Focus on the error handling part. In my experience in 95% of the cases the expectation behind the statement .onErrorReturn(...); is to ensure that the method getFavoriteBook() is “safe”, e.g. that an exception cannot be thrown from it at all, as if it was surrounded by a giant try-catch.