Description
As also remarked by two interviewees, a recurrent problem arises when common functionalities are not provided in base classes. This often leads to duplicated code, reducing the maintainability and testability of the app. Ideally, components should be independent from each other and their business logic should be clear and explicitly separated. By quoting one of the data points “your architecture should scream the purpose of the app”. Decoupled components make it easier to focus on app functionalities and their issues, without dealing with bloatware. Additionally, this enables a higher testability of the core logic of the app by making components unit-testable (ideally without requiring an emulator). Finally, by decoupling the business logic from frameworks, more emphasis is put on the business logic, making an app more testable, maintainable, and of low technical debt.
Example
We created a simple Boss Application which retrieves users from a dummy API.
The three main components from the BossApplication are:
- Model
- Presenter
- View
The event diagram of the Boss Application:
Each component can be easily tested. Since the MainPresenter has no actual reference to the MainActivity the MainPresenter is Android-independent making this presenter testable without an emulator. The MainPresenter is also not able to call methods from the MainActivity which are not specified in the MainView.
Which has a reference to the MainView.
Check out the Github page to view the complete repository.