Hi Stanislav, thanks for reading my article first of all :) I need to say, that I’m actually trying to get rid of events in favour of RxJava so I might be of help. I can tell you what’s the best solution I found so far. I didn’t change my architecture, I just adapted it to accept RxJava. Ok so, let’s start.
Every domain object (Interaction, UseCase) is the RxJava observable. Do you remember the execute() method from the Interaction? Now it looks like this:
Then inside it, I create the Observable and I subscribe. With this, from the domain layer and bottom, I should only use Observables. I mean that every method in the Repository and Data layer should return Observable<T>. It’s gonna be a long journey but that’s the plan.
The cool thing about this, is that every layer, before returning the observable, can add its own operators to the chain to manipulate the stream. And with that, you don’t even need try catches, cause all the errors will be forwarded to the subscriber.
The only thing left is the Presentation layer. When I need to subscribe, I do something like this:
DataSubscriber is extending Subscriber<T> and it’s the class responsible for getting the events and updating the view. I’ve seen some implementations having DataSubscriber as an inner class inside the presenter, but that would make it almost impossible to test. That’s why I prefer having another class that’s super easy to test.
This is my first approach to move our architecture to Rx. For sure it’s not the best one, but I’m finding myself quite comfortable with it.
Anyway, there is already an article about moving the Clean Architecture to Rx: http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/
The code and explanations are quite clear. They decided to go with the subscriber as an inner class of the presenter, that I personally don’t like.
I hope I solved your doubts :) If not just tell me and I’ll be happy to help you :)