What is an Interactor? How does it fit within the MVP Design? What are the advantages/disadvantages of using an interactor vs putting the interactor code in the presenter?
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.
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.