Evolution of Mobility Architecture

Table of Contents

Design architectural patterns are the core of mobile application development. The architecture of the application provides you with reusable code and minimizes the code duplication that prevents high coupling and provides solutions for the recurring problems. Over the years Mobility Architecture has evolved to keep pace with the current feature needed by mobile applications and to cater to hyperautomation. This article takes us through this journey & also talks about architecture fitment for each of their use cases.

VIPER is a design architectural pattern for mobility development which is an alternative for MVC, MVVM and more. It provides a layer of abstraction that results in a more scalable, reusable and testable code.

Do you want to know when MVC(Module View Controller), MVVM (Model View-Viewmodel) and VIPER(View-Interaction-Presenter-Entity-Routing) design architecture, can be best used? We have created a quick analysis for you, let’s see for ourselves.

MVC :

The MVC architecture design pattern is used in the presentation layer. This type of architecture is suitable for small or single screen applications like Currency Converter or Login Application.

  • Model : This represents the data layer of the application. Which provides data and logic to view.
  • View : This is a visual representation for the user. User interacts with the system using view.
  • Controller : This layer accepts requests from users and passes to the Service / Data layer.

MVVM :

The MVVM architecture design pattern overcomes all drawbacks of MVC architecture. MVVM separate data layer and business logic layer using Model and View.

  • Model : This represents the data layer of application. It interacts with View (presentation layer ) using the View Model. Mostly it consists of Local and Remote data sources.
  • View Model : This is an intermediate layer between Data layer and presentation layer. It accepts requests from the presentation layer and sends it to the data layer. 
  • View : This represents the presentation layer. It sends requests to the  ViewModel using user interactions and listen callback for that request.

VIPER :

VIPER is an acronym for View-Interactor-Presenter-Entity-Router. Each module has their own responsibility in the architecture.

The VIPER  architecture design pattern overcomes all drawbacks of MVC and MVVM architecture. This pattern separates the presentation layer, data layer and routing for the system.

  • Entity : This represents  the data layer which communicates with the Interactor.
  • Interactor : This represents the medium between data layer and presenter. The main function of this layer is to accept requests from the presenter and take updates from Entity. This layer manipulates data and informs the presenter  for the updates.
  • Presenter : Presenter handles requests from the View and sends it to Router or Interactor. It acts as a mediator between all the components.
  • Router : Router handles navigation logic which triggers from presenter on the user action form View.
  • View : This is a Visual representation which takes requests from the user and sends it to the presenter for further processing.

Let’s see the difference between MVC(Model–view–controller) , MVVM (Model–view–viewmodel) and VIPER (View-Interactor-Presenter-Entity-Router) : 

MVC

MVVM

VIPER

Better for small or single screen applications like : Calculator, Currency converters. Better for medium and large scale applications. Better for large scale applications because it maintains routes and lots of files which are not suitable for small or single screen applications.
  • Model contains data like a database,file or objects.
  • Business logic handled by a controller which updates the model and view.
  • View contains UI components which are accessed by the user.
  • Model contains data like a database, files or objects.and business logic
  • ViewModel handles data which needs to show on the UI.
  • View contains component which shown on UI 
  • Entity contains data objects.
  • View handles UI  components which deliver action to the presenter.
  • Presenters deliver actions to the interactor or router.
  • The presenter updates the stage to present data on View.
  • If any computation is required then it is handled by an interactor which contains business logic. 
  • Navigation logic is encapsulated in a router which triggers from the presenter.  
UI testing requires efforts as a single controller handles multiple views and models Required less effort for unit testing if business logic is loosely coupled with different modules Low coupling between different modules which provide good environment for unit testing
Setup is very easy but hard to manage Setup is fairly difficult but maintenance of code becomes easy Setup requires time and and can involve a learning curve.However scaling and maintaining is the easiest later on

Subscribe to our Newsletter

Scroll to Top