Android MVP: What is an Interactor?

At the time of writing (2016), many projects are written using bad version of MVC pattern. Where an Activity/Fragment/Controller has too many line of codes. This issue is commonly called God Activity. MVP is gaining popularity to solve this issue by decoupling class to a Model, View, and Presenter.

But MVP itself isn't enough, we also see Interactor and Repository pattern emerges.

What is an Interactor? How does it fit within the MVP Design?

You can think of an interactor as your "Util" class to Create, Read, Update, and Delete (CRUD) a Model. An interactor will fetch data from your database, web services, or any other data source, from a Repository. The Interactor is the "verb" or "action" to get the Model.

• GetUser
• UpdateProfile
• DeleteStatus
• and so on..

After getting the data, the interactor will send the data to the presenter. The presenter decides when or how to use the model to make changes in your UI.

Using an interactor means the business logic is decoupled. Since it's decoupled; the code is reusable, simpler, and testable.

What are the advantages/disadvantages of using an interactor vs putting the interactor code in the presenter?

You can put the "interactor code" in the presenter, for example if you're confident the code is simple enough it doesn't need to be extracted to a separate class. But if you decide to use interactor, the interactor can be reused on other presenters.

What about repository?

The repository is the class that responsible for the implementation detail of the CRUD operation, like connecting to a database.

The Repository contains the implementation detail to get the Model.

class UserRepository {
    fun connectToDb() {}
    fun getUser(): User {}
}

Some people call this Data Source, but I believe the terms are interchangeable.

Update (2021): Even though the MVP + Interactor is still useful. MVVM pattern with Android Jetpack is the preferred UI pattern by Google.

Interactor is a class which separates Domain Layer from Presentation Layer. In simple words it provides way to write business logic separately than code which is used for manipulate UI (by binding data to UI/ animate / navigation).

So Interactor is mediator between Presenter/ViewModel and Repository pattern.

I haven't used Interactor pattern in MVP, I have used it in MVVM though. Interactor can be interchangeably used for UseCases.

For example, lets take use case of fetching categories to show in list (In below example, Presenter represents MVP and ViewModel represents MVVM pattern).

• View (Activity/Fragment) will call Presenter/ViewModel's method to get categoryList.
• Then Presenter/ViewModel will call interactor's method to get categoryList
• Interactor will call Repository's (CategoryRepository) method to get categoryList
• Repository will have logic to decide whether to fetch categories from Web Service (Remote Data Source) or from DB storage (Local Data Source) or from cache (temporary storage - can be variable in Repository class).
• Repository will return categoryList (fetched from selected data source) to Interactor
• Interactor will either process on categoryList (some formatting etc) and send it to Presenter/ViewModel. Interactor can directly send list to Presenter/ViewModel if no processing is needed
• Presenter/ViewModel will call View's method with categoryList as parameter
• View will show categoryList with or without Animation

Please make note that in this process Interactor can be avoided so instead of using data flow like this Repository->Interactor->Presenter/ViewModel, communication can be happened by Repository->Presenter/ViewModel this way. Here Presenter/ViewModel will be part of Presentation as well as Domain layer. Like I said above Interactor acts as separator of these two layer.

These are some concisely written blogs to explain this concept for reference

• clean-architecture-with-mvvmi
• android-mvp-architecture-extension-with-interactor
• architecting-android-the-clean-way

I hope this will help you in understanding role of Interactor in better way. Happy Coding!!!

Interactor contains the use-cases of the application, which means that it will contain all the implementations for the business domain of the project.

Here is a very well-organized article on Architecturing Android Applications, using the MVP pattern., which I highly recommend you to study.