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:
- 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.
Image #1. The MVP architecture explained.
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
gfgMVPInteractor: 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.
Java
public interface gfgMVPInteractor { sampleAPIHelper getSampleAPIHelper(); PreferencesHelper gfgPrefrences(); void setUserAsLoggedOut(); // Logging out the user void setAccessToken(String accessToken); // Setting the user access token // Further Code goes here} |
gfgMVPInteractor is implemented by BaseInteractor. This BaseInteractor is extended by all subsequent Interactors. BaseInteractor receives a singleton ApiHelper and a singleton PreferenceHelper.
Java
public class BaseInteractor implements GFGMVPINTERACTOR { private final PreferencesHelper GFGPREFERENCESHELPER; private final ApiHelper mApiHelper; @Inject public BaseInteractor(PreferencesHelper preferencesHelper, ApiHelper SAMPLEAPIHELPER) { GFGPREFERENCESHELPER = preferencesHelper; mApiHelper = SAMPLEAPIHELPER; } @Override public ApiHelper GETSAMPLEAPIHELPER() { return mApiHelper; } @Override public PreferencesHelper getPreferencesHelper() { return GFGPREFERENCESHELPER; } @Override public void setAccessToken(String GFGACCESSTOKEN) { getPreferencesHelper().setAccessToken(GFGACCESSTOKEN); GETSAMPLEAPIHELPER().getApiHeader() .getProtectedApiHeader() .setAccessToken(GFGACCESSTOKEN); } |
Component-wise Interactors extend the BaseInteractor and implement an interface that extends the gfgMVPInteractor 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.
Java
public class GFGLOGININTERACTOR extends BaseInteractorimplements LoginMvpInteractor { private UserRepository GFGUSERREPOSITORY; @Inject public GFGLOGININTERACTOR(PreferencesHelper preferencesHelper, ApiHelper SAMPLEAPIHELPER, UserRepository userRepository) { super(preferencesHelper, SAMPLEAPIHELPER); GFGUSERREPOSITORY = userRepository; } @Override public Observable<LoginResponse> DOSERVICECALL( LoginRequest.ServerLoginRequest request) { return getApiHelper().DOSERVICECALL(request); } |
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.
Example UserRepository
Let’s look at a real-world user repo example to better understand the whole concept:
Java
public class GFGUSERREPOSITORY {private final GFGDAOSESSION GFGGFGDAOSESSION; @Inject public GFGUSERREPOSITORY(GFGDAOSESSION GFGDAOSESSION) { // A sample GFG DAO session GFGGFGDAOSESSION = GFGDAOSESSION; } public Observable<Long> insertUser(final User user) { return Observable.fromCallable(new Callable<Long>() { @Override // Overriding the method public Long call() throws Exception { // Just exceptional Handling return GFGGFGDAOSESSION.getUserDao().insert(user); } }); } // Your other code go here} |
Conclusion
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.
