Recently, I had a very strange problem to debug. I had the following interactor:
public class GetUserUpdatesInteractor { private final UserRepository mUserRepository; private final InteractorSchedulers mSchedulers; @Inject public GetUserUpdatesInteractor(UserRepository userRepository, InteractorSchedulers schedulers) { mUserRepository = userRepository; mSchedulers = schedulers; } public Observable<Optional<User>> getUserUpdates() { return mUserRepository.getUserUpdates() .subscribeOn(mSchedulers.getExecutionScheduler()) // Schedulers.io() .observeOn(mSchedulers.getPostExecutionScheduler()); // Android mainThread() } }
The problem was that I wanted to makes a blocking call on the interactor. So I would do the following:
Optional<User> user = mGetUserUpdatesInteractor.getUserUpdates().blockingFirst();
The above line would make the app stuck in a deadlock and totally unresponsive. A short search in StackOverflow shows that using a blockingFirst() on something that has already set the AndroidSchedulers.mainThread() does not work well. In order for the app the be working, the schedulers must be moved outside of the interactors layer and let each caller decide whether to set schedulers or not.