Android MVP Architecture Extension with Interactors and Repositories
Nature’s truth is evolution, and new developments are led by natural selection. As a result, there are many diverse species with numerous similarities, and they all adapt best to their environment. The concept that one is superior to the other is only applicable under limited circumstances when one is more suited for survival. When the circumstances change, so does the concept. This is equally true for any software design. In its own right, one answer is superior to the other. As previously stated, several enhancements were discovered in order to better respond to certain conditions. All of these scenarios arose for Android apps with a large codebase and several developers working on the project at the same time.
There were two restrictions found in such conditions:
Attention reader! Don’t stop learning now. Get hold of all the important Java Foundation and Collections concepts with the Fundamentals of Java and Java Collections Course at a student-friendly price and become industry ready. To complete your preparation from learning a language to DS Algo and many more, please refer Complete Interview Preparation Course.
- DataManager centralization: In the MVP architecture, the DataManager is meant to outsource all duties to ApiHelper, DbHelper, and PreferenceHelper. It’s an excellent architecture for most use situations since it allows you to intercept Helper calls and do some pre-processing. However, for large projects, this class can grow to be rather huge.
- DbHelper centralization: The DbHelper was created to get data from the database using the DAO classes. This is also excellent for most projects with fewer DB queries, but it can get extremely huge for large projects.
The problem of centralized DataManager might perhaps be addressed by exposing the Helper instances to the Presenters. This will eliminate the DataManager delegation calls, reducing the codebase to a few functions that need cross Helpers calls or a series of Helper calls. This approach would be a good fit for the existing MVP design. Tapping untapped potential necessitates taking two moves forward once we have arrived at our objective. We now propose some major improvements to the existing MVP design in order to make it appropriate for very big projects with many developers working on it at the same time. Let us begin by identifying the obstacles associated with such initiatives.
Large Project? Don’t worry
Large projects contain numerous features, and in order to manage those features, a modularized codebase is required. Even inside a module, the ideal strategy is to separate the programs such that all of the features are encapsulated, which means that all of the dependencies for that feature may be resolved in its package at most. To allow many developers to collaborate on the same project while avoiding code merges with each pull request, we must provide feature encapsulation.
To learn about Android MVP, just visit here.
DataManager decentralization yields an Interactor structure, whereas DbHelper decentralization yields Repositories.
- Interactor: Instead of a singleton DataManager, each Presenter receives its own instance of an Interactor. The interactor has the same duties as the DataManager, but it is solely concerned with the data access and processing calls necessary by the feature it is providing.
- The DbHelper is organized into Repositories. For example, all database queries for a User table are performed via a UserRepository rather than the DbHelper. UserRepository, like DbHelper, routes all of its queries through UserDao.
GeekTip: In contrast to a singleton DbHelper, the Repository is instantiated on demand, and each Interactor receives a new Repository instance.
When compared to the original MVP architectural blueprint we can see that the DataManager and DbHelper have been replaced with Interactors and Repositories, which are available to each Presenter individually.
The MVP architecture has undergone significant changes
gfgMVPInterctor: It is an interface that lists the data access APIs shared by all application components as well as the access methods for the sampleAPIHelper and PreferencesHelper singletons.
gfgMVPInterctor is implemented by BaseInteractor. This BaseInteractor is extended by all subsequent Interactors. BaseInteractor receives a singleton ApiHelper and a singleton PreferenceHelper.
Component-wise Interactors extend the BaseInteractor and implement an interface that extends the gfgMVPInterctor and includes its own APIs. Example: GfGMvpInteractor is an extension of MvpInteractor that includes doServiceCall, doGoogleLoginApiCall, and doFacebookLoginApiCall. GFGLoginInteractor, like BaseInteractor, extends BaseInteractor and implements GfGLoginMvpInteractor.
The Presenter is structured similarly to the original MVP architecture, with the exception that the DataManager is replaced with the component’s interactor. GFGLoginMvpPresenter is an example of an interface. In the definition, Interactor has been included beside View.
Let’s look at a real-world user repo example to better understand the whole concept:
You can see that the login feature components are independent of the rest of the program and have all of their dependencies wrapped. Any developer working on the login function is free to work independently of other developers working on other projects.
These components increase the architecture’s extensibility and flexibility, albeit at the expense of extra labor. I must emphasize that the basic MVP design is suitable for most projects of reasonable complexity, but this expanded version is suitable for very big projects with hundreds of features and several people working on it concurrently. We are really happy to use the original architecture in our app’s codebase.