Description
Android Activities should ideally contain exclusively logic handling the user interface (UI) and operating system interactions. Nevertheless, a common architectural issue consists of delegating too many functionalities and responsibilities to a single Activity. This leads to Activities slowly becoming god-classes. As the Android framework does not support the reuse of methods implemented in activities, code tends to be directly copied into other ones, increasing code duplication and impacting negatively the app’s maintainability. Additionally, testing might become a challenging task, as complex business logic could reside in Activities, which by themselves result arduous to unit test. Finally, as activities are kept in memory at runtime, “godactivities” can lead to the deterioration of apps’ performance.
Example
We created a simple MVP login Application.
Too counter the tendency of Activities to grow too big. We let activities only be the visual aspect of our application. Our LoginActivity implements the LoginView class.
Our LoginActivity has two text fields:
- Email field (edit_email)
- Password field (edit_password)
And two buttons:
- Create new user (buttonAddUser)
- Login button (btnLogin)
The event diagram of the Login Application:
We do not want our LoginActivity to create a database, and store and retrieve all the users. We want to share as much responsibilities to another layer as possible.
Our LoginActivity only does what our presenter tells it to do. So our LoginActivity does not become a God class. This also makes it easier to test our views and presenter.
Our interactor checks if the password given matches the password of the gotten user. This is a simplistic example and in real life applications, the validation of passwords would have been done differently.
Check out the Github page to view the complete repository.