Realizing Interactors with Android MVP Clean Architecture
<p>I'm currently building an android application and wanted to base it on "clean architecture" similarly as suggested by the following authors:</p>

<ul>
<li><a href="http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/" rel="nofollow noreferrer">Fernando Cejas - Architecting Android…The clean way?</a></li>
<li><a href="https://medium.com/@dmilicic/a-detailed-guide-on-developing-android-apps-using-the-clean-architecture-pattern-d38d71e94029#.flgbcikgw" rel="nofollow noreferrer">Dario Miličić - A detailed guide on developing Android apps using the Clean Architecture pattern</a></li>
<li><a href="http://devblog.songkick.com/2016/02/25/ingredients-for-a-healthy-android-codebase/" rel="nofollow noreferrer">Romain Piel - Ingedients for a healthy Android Architecture</a></li>
<li><a href="https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html" rel="nofollow noreferrer">Uncle Bob - The Clean Architecture</a></li>
<li><a href="http://hannesdorfmann.com/mosby/" rel="nofollow noreferrer">Hannes Dorfmann - Mosby Library</a></li>
<li><a href="https://github.com/pedrovgs/EffectiveAndroidUI" rel="nofollow noreferrer">Pedro Vicente Gómez Sánchez - Effective Android UI</a></li>
<li><a href="https://davidguerrerodiaz.wordpress.com/2015/10/13/a-brief-introduction-to-a-cleaner-android-architecture-the-mvp-pattern/" rel="nofollow noreferrer">David Guerrero - intro to a cleaner android architecture: the mvp pattern</a></li>
<li><a href="https://medium.com/@patrykpoborca/making-a-best-practice-app-5-clean-architecture-testing-84a1672dd000#.8tzuakgwr" rel="nofollow noreferrer">Patryk Poborca - Clean Architecture &amp; Testing</a></li>
</ul>

<h2>The current architecture:</h2>

<p>View (Fragment) &lt;-> Presenter &lt;-> Interactor &lt;-> Repository</p>

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

<p>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.</p>

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

<h2>The problem:</h2>

<p>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.</p>

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

<hr>

<p>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.</p>

<p>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.</p>

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