Realizing Interactors with Android MVP Clean Architecture

Question

I'm currently building an android application and wanted to base it on "clean architecture" similarly as suggested by the following authors:

• Fernando Cejas - Architecting Android…The clean way?
• Dario Miličić - A detailed guide on developing Android apps using the Clean Architecture pattern
• Romain Piel - Ingedients for a healthy Android Architecture
• Uncle Bob - The Clean Architecture
• Hannes Dorfmann - Mosby Library
• Pedro Vicente Gómez Sánchez - Effective Android UI
• David Guerrero - intro to a cleaner android architecture: the mvp pattern
• Patryk Poborca - Clean Architecture & Testing

The current architecture:

View (Fragment) <-> Presenter <-> Interactor <-> Repository

• The Fragment implements View and creates a Presenter.
• The Presenter references the Fragment by the View interface.
• The Presenter implements an Interactor.Callback Interface for data to be presented
• The Presenter creates and starts an Interactor.
• The Interactor fetches & updates data to perform business logic in a background thread from a Repository.
• The Interactor implements Repository.Callback for DB/Server data from the Repository.
• The Interactor registers at the Repository for Updates on data it requires.

In the current design there is 1 interactor per display (a display may include multiple fragments e.g. ViewPager with 30 fragments of the same type) and 1 presenter per fragment. Presenter and Interactor have no framework dependencies to allow easy testing.

My main concern is the implementation of the Interactors/UseCases and their relation to Presenters (MVP) or ViewModel (MVVM).

The problem:

It is planned to have the Interactor first fetch all required business objects (BO) for a display. The fetching is done synchronously from the data layer and each received BO directed to the Presenter. This causes a delay until all data is shown in the view.

Further it registers for updates for BOs it is interested in (the same as fetched before) to continuously update the view through the Presenters.

---

I'm thus looking for a guideline of how to set up an Interactor in my case. The implementations mentioned above have one task, work it off then are done and the Interactor background thread may be closed.

In my case the Interactor registers for updates from the datalayer and waits to handle them, then posts the data to the Presenter UI thread, thus lives as long as there is a presenter listening.

This functionality is different and I'm looking for a good practice to make it work with a "clean architecture".

Answer 1

So if I understand your question, your concern or doubts comes because your Interactor is not going to execute a task and then finish, but is going to be subscribed or listening until an operation is done.

In my opinion that's perfectly fine, an Interactor implements a use case, and in your program that async request is a use case, it doesn't matter if it takes time and is an asynchronous task or is a synchronous operation.

It is still a use case where the Presenter will instantiate the Interactor and when this has finished, it will send back the result of the operation. As long as you keep the modularity and the Presenter and Interactor are not coupled with direct dependencies but they communicate via indirection, that's perfectly fine.