Orchestrating the Android Application into logical components, embracing a modular and logical approach to organize the application leads way to drifting away from monolithic model view controller (MVC) pattern and leveraging testable patterns like Model View Presenter (MVP) and Model-View-View-Model (MVVM).
MVVM Cross as it has come to be known allows integrating MVVM design pattern to Android and iOS platforms. Now you know how easy hybrid app development become when lucrative architecture is on a platter.
Are MVC, MVP, and MVVM architecture simply presentation patterns? Are these mainly designed to redeem the complexity of the code, facilitate the process and alleviate the headache of making scrambled user-interface code achievable and clean?
Without letting this conversation going around in circles – here is the crux:
As the conversation will revolve around various layers of the OSI model, here is the perfect picture:
MVC clearly stands for Model (a collection of class that explains business logic) + View (user interface built up of HTML, CSS, and Jquery) + Controller (processes incoming requests) (Logically dividing a problem situation into three solvable bits). Model is a data and business logic. The view is a User Interface. The controller is a request handler. This cleverly excludes the internal information from the user who is simply presented with a user interface/design. Being the most influential and important model to arrange the presentation layer in Android Applications, MVC eases testing and maintenance of applications.
Here the Model is not tied to the view. Both are separate and easily testable. But still there are some controller concerns:
It is a derived from MVC and separated presentation layer from the business logic layer. No one would like to re-do entire view in case the data has to be retrieved from the database instead of web service? An application needs to be extensible and maintainable in separate and independent layers. MVP architecture separates the views from the data source into at least three different layers. These work independently and make the application testable.
Model is same as in MVC. The activity or fragment is part of the view. Here the view interface can be implemented by making use of the activity.
The presenter is not at all tied to any view, but with the interface. This poses the risk of leaking the activity (for more than 10 seconds can make solutions complex and ultimately make the app vulnerable) with long-running tasks and the activities that have already died can as well be updated! (You sent a request to the server that took 10 seconds but the user closed the activity within 5 seconds. The UI is updated by the time, the callback is called. And finally, the application will crash as the activity is about to finish).
The fact that impels the bifurcation of concerns is that MVP is good in modeling the presentation layer but in case other layers are to be handled, there is still a requirement to have a better architecture.
Adding a comic strip here (just to sense you’re still interested in reading further)
A – Why did you just sigh?
B – I learned it in the computer club.
A – You did?
B – Yeah, sighing is the first rule of tech support.
Here is a trick to migrate the application and code it smartly, making it easily updatable, testable and maintainable: MVVM Architecture. It will add the right dash of sweet and salty effect into the coded application. Catch the flavor here,
C – I’m in the mood for a bacon melt on toast.
D – Why not have the salad bar instead?
C – (Thinking*) Bacon Bits or Cheesy Chunks or Croutons
C – (Mixes all Bacon Bits + Cheesy Chunks + Croutons) and says to D, “Microwave this for me, would you?”
Do you want the same thing to happen, when you are just about to start off with coding the application? Definitely, not agreeable.
MVVM architectures ease all the cons of MVC and MVP, making the coded application easily testable, modular, flexible and simultaneously reducing a lot of code that is glued with view and model.
Model behaves and looks like in MVC and MVP. View binds the observable variables in a flexible way. ViewModel wraps the model and prepares the observable data that is needed by the view.
MVC model has been extensively used and tested over multiple languages. E.g.: If there is a search box or a questionnaire survey on a website then attributes associated with each question or to-do item are stored in an instance of the model.
Controller sticks the model and view together adding event listeners to view and updates when users manipulate the view.
When an application scales up, many new models are created. The number of controllers also grow simultaneously. As the new layers of abstraction are added codebase becomes difficult to navigate.
In MVVM architecture, the ViewModel method relies heavily on the front end of the application. In this model, the view is tightly coupled with the model but in an unconventional way and this is completely different from the controller. It is in-fact a binder and allows Models to interact directly with the views. Allowing views to communicate directly with the backend, ViewModels works wonders for single page applications. Consuming a considerable amount of memory in comparison to controllers and overhead, ViewModels are not suitable for larger applications.
Breaking the streak, let’s boggle down the facts: There has been an increase in the proportion of websites with an increase in the proliferation of programming languages. Every new innovation facilitates in the management of codebase, making it more testable, manageable and helps bind the web pages with the database. Out of the various ways in which a website can be structured, MVVM vs. MVC vs MVP are just three different methods/architectures that define the logic behind the models, interfaces/views and database. Discover more ideas about what is MVVM, what is MVC architecture, the difference between MVC and MVVM here. If you are someone into competitive coding, this is worth a check. Find your future with us!
Neeti got her master's degree in software engineering in 2009 and has been working since for software companies of all sizes as a technical writer. What started as a high school passion has now been converted into a serious profession. She has a special knack of learning from all verticals and imbibing the extracts into her writing. She enjoys learning technical aspects of writing from her tasks where her experience and understanding are most impactful.