A Refined Approach To MVC Architecture in Android Part 1 — Why Activity and Fragment are not suitable to act as Views
This is the first of a series of articles in which we will explore a refined approach to the MVC architectural pattern that makes for a better separation of concerns between the view logic and business logic resulting in a more maintainable and highly testable application architecture. The resulting architecture enables easy A\B testing of different UIs.
In a nutshell, this article demostrates why MVC is quite suited as a presentation layer architectural pattern for android development.
This article assumes familiarity with dependency injection as it is at the heart of the approach I will be demonstrating. I will be using the Hilt dependency injection library but the principles can be applied using pure dependency inject or any DI library of your choice
In the Diagram 1, both the View and the Controller are dependent on the Model. Controller is also dependent on the View.
The Controller is responsible for orchestrating the presentation layer’s business logic, that is responding to user input captured by the View, data updates from the domain or data layers and controlling the state of the View.
There are different opinions on what the role of the Model is or should be, but in this context the Model is just a simple data class which models whatever data that we are working with, e.g a User.
The Important Question: What is the View from an Android application point of view?
A popular answer that springs up is that its the Activity and Fragment that should are Views. This might seem like a simple and natural designation but when we interrogate the structure and responsibilities of Activities and Fragments, we see that treating these components as Views in MVC is not a precise approach with respect to a proper separation of concerns between the “view logic” and the “business logic” of an application.
Why Activities and Fragments Are not Best Suited to Act as Views in MVC
The prescription of MVC is that the View presents and renders everything that is visible on the screen and offers interaction to the user. In essence the responsibility of the View component comes down to 2 things — presenting the user interface and capturing user interaction and passing it on to Controller. The View is a “dumb” component so to speak,
But looking at Activities and Fragments, they are responsible for far much more than simply presenting the UI and capturing user interactions. AppCompatActivity extends the Context class and also implements a myriad of android framework callback interfaces which makes it a “god class” . This inheritance hierarchy makes it possible for the Activity class to be able to start services, handle navigation, create intents, register broadcast receivers, receiv android framework callbacks like onActivityResult() and onRequestPermissionResult() and so on. Clearly the Activity is a bit more involved than what MVC prescribes as the View’s responsibility. The Fragment class is no exception.
Now consider a scenario where due to time constraints or lack of good designers and you might choose to outsource the design of the application UI because concentrate on the business logic of the application. Now considering the points I detailed regarding Fragments and Activities, you will not be guaranteed that the code you will get from the outsourcing will be easy to integrate into our application.
So what are Activities and Fragments best suited to be in MVC?
With all of the aforementioned considerations in mind, it becomes clear that that Activities and Fragments are actually better suited to act as Controllers.
Join me in PART 2 where we will see in code how extract all the view logic from our Activities and Fragments allowing us to achieve a lot of flexibility in our app architecture.
Thanks.
