Roman Iatcyna
Aug 9, 2017 · 2 min read

First of all, many thanks for such huge work with cool diagrams and git repository!

I currently work on a huge projects that desperately needs a refactoring, and I’m looking for appropriate ways of performing it.

I don’t really understand how it can be one Interactor per presenter. That doesn’t seem quite right.

When project is really huge (and api is not very friends, so you have tons of business logic on the client) you want to have many different Interactors that incapsulate only a single bit of business logic inside it, but not just extends Presenter.

How I see it: if there’s a UsersRepository, there might be RegistrationInteractor, EditProfileInteractor, FriendsInteractor, etc. etc.

So if you had two screens with corresponding presenters: UserProfileScreenPresenter and UserFriendsScreenPresenter, and it suddenly required to add possibility to edit friends on UserProfileScreen, you just inject corresponding interactor to that UserProfileScreenPresenter and do some actions with it.

If you do so, you don’t actually want to write Repository/Api/SharedPrefs sync logic each time inside every Interactor. Having this logic in a base class not actually a solution.

So what I’m actually getting to is the original Repository definition that declares Repository as a wall between logic and data. So in our case data are: sharedPrefs, serverAPI, localDB etc. And Interactors are logic and they must not really care where the data comes from. They don’t event know if the app works online or offline now, it doesn’t really matter for the logic they incapsulate.

And how I’m actually trying to make this work on the project I work on now:

Interactors are simple stateless mappers. The may contain some rules, ifs, checks. There may be few interactors inside one Presenter. Interactors depends on one or few Repositories (you might need FriendsRepository along with UserRepository for FriendsInteractor) which are shared between multiple interactors.

Repository is made reactive, so you can observe data. When one interactor perfoms some actions on Repository, its data changed and emitted to other interactors. Repository is responsible for fetching data from network, saving it to database, providing cached data before actual network call. Repository also does a mapping from Api models to Db models, and mapping to Interactors level.

N.b. Presenter not always need an Interactor, it can use a Repository if only wants to show its data without any interaction.

What do you think of this approach? I’m planning to make an article about this reactive repositories and describe it more properly with snippets and schemas.

    Roman Iatcyna

    Written by

    Lead Android Developer at Revolut, London