Mobile Application Architecture and It’s Misreading/Misconceptions

9 min readJul 29, 2021

An application architecture describes the patterns and techniques used to design and build an application. The architecture gives us a roadmap and best practices to follow when building an application so that we end up with a well-structured app.

Software design patterns can help us to build an application. A pattern describes a repeatable solution to a problem.

All of us have heard about MVC, MVVM, VIPER, and sometimes MVP or VIP very often. We all have explored couple of them.

Everyone has their own preferred architectural design pattern. The reason for selecting our preferred patterns based on most common reasons are people say it’s great, industrywide popularity, want to explore, etc.

However,

Do we really understand?
What additional offerings?
Why to prefer one over the other?

If you look at those so-called architecture patterns, they are like names of files that you will be having in your application.

In application development, we see, talk, and read plenty of architecture design patterns like MVC, MVVM, MVP, VIPER, etc. Then debate on which pattern is better, best fit for our requirement.

Today, I wan’t jump into this debate. Our focus will be on understanding the basic components and the relations between the components to get more clarity around the fundamental components of the architecture.

In application architecture, the fundamental components or foundation of any architecture patterns are View and Model.

If you look at any application architecture, it follows a layered architecture.

User Interface Layer
Presentation Layer
Core/Business Layer
Model Layer
etc…

The layered architecture gives a good overview of the separation of the concerns.

However, it gets diluted even when we choose the most suitable architecture design pattern and start coding.

Is it because of the architectural design pattern you choose?

The answer is NO.

Every architecture design pattern has tried to solve the problems in its possible way. However, we as a developer interpreted it wrongly, by mapping the components to respect files.

Example,

MVC — Model, View (Storyboard), ViewController

MVVM — Model, View (Storyboard+ViewController), ViewModel

MVP — Model, View (Storyboard+ViewController), Presenter

VIPER — View (Storyboard+ViewController), Interactor, Presenter, Entity, Router

Misconceptions:

In MVC, Controller objects handle all the tasks that fall outside the model or view.
In MVVM, ViewModel objects handle all the tasks that fall outside the view layer. It also includes tasks fall inside model layer + business logic.
In MVP, Presenter objects handle all the tasks that fall outside view layer. It also includes tasks fall inside model layer + business logic.
In VIPER, Interactor/Presenter objects handle all the tasks that fall in model layer + business logic.

Height of misconception is,

Separate files for specific things means it is the best architecture.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Logically, for freshers, it’s a good start. However, worst for experienced developers.”

To know why I am saying this, please try an answer below questions,

Which file is responsible for handling the business logic?
Which file is responsible for requesting data from a network?
Which file is responsible for fetching/storing data from local storage?
Which file is responsible for transforming the raw information into the Data/Model?
Which file is responsible for making the data presentable on the UI?

A couple of design pattern has an answer for few but not all. None of the architecture design patterns give you a complete answer, that we can map to the files.

As I stated, we are not going to debate on this.
Instead of this let’s try to understand the logical components, logical responsibility of each, logical reasoning of its requirement.

What is a Model?

Model is not a model class, struct, POJO, or model file in any of the above-mentioned architecture patterns.

Model is an abstract description of the model object + data access layer. It has no dependency on the UI framework or UI Layer.

                        Model == Model Layer

What is a Model Object?

Model Object represents the Data. It is the State of the application and not the state of the view. This model/data/state might be received from different sources like server, database, local storage, or sometimes from user inputs.

What is Data Access Layer? The Data has to be fetched, request from the respective sources. The data access layer is purely responsible for fetching, requesting, and transform the data into the Model/Data object.

      Model Layer = Model Object + Data Access Layer

What is View?

The view is the User Interface that allows users to see and interact with the application. It directly uses the UI frameworks from the platforms. Storyboard, XIBs are working as a container of views, controls which users will see or interacting. Sometimes, you might create the instance of the view, controls and add it to the container of views. Hence, these objects are called view objects.

All the view objects are directly part of some view hierarchy which is controlled, managed by some View Controller Hierarchy. In short, they are coupled together let’s refer to it as a View Layer.

Hopefully, we all are on the same page for the Model Layer and View Layer.

Let’s summarize both the layer, User Interface which is our View Layer is responsible for display and take inputs from the users. Model Layer is responsible for holding the application state which they will have from various sources.

These layers need to communicate. How? What is it called? Who will take that responsibility?

Communication is the challenge that the various application architecture patterns fighting for.

Let’s see the pictorial representation to get a high-level understanding.

ViewLayer —> Communication with -> Model Layer

Let’s discuss each of the entities, the paths between both the layers, logical naming for it in little depth.

🪀 🪀 View Action 🪀🪀

This is an action triggered by the view layer in response to the action performed by the user such as tapping on buttons, selecting a row in a table view. This view action needs to be correctly acknowledged and communicate with the Model Layer.

🪀 🪀 Model Action 🪀🪀

This is an action that needs to be performed by the model layer such as requesting data, perform some operations as per the request, create/update model objects, etc.

🪀 🪀 Interaction Logic 🪀🪀

The logic of connecting these two layers will be known as Interaction Logic. The transformation of view actions into model actions and other logic along this path is called interaction logic.

🪀 🪀 Model Response 🪀🪀

This is a response to the request as one or more model objects are created/changed/updated as per the request. This model response can be triggered using notifications, observables, observers, delegates, callbacks, completion handlers, and any other available mechanism to tell that Model Layer has responded with information about what has changed.

🪀 🪀 Presentation Logic 🪀🪀

The received model response is great but it’s not presentable. The presentation logic will transform the model response presentable onto the views.

🪀 🪀 View Changes 🪀🪀

The presentation logic gives you the presentable state which will be used to update content on the view layer are called a view change.

As we stated earlier, there are two states one is the application state that is referred to as model objects and another is the view state that holds the control state like, button enable or disable, is loading, is screen presented, load more, etc.

🪀 🪀 View States 🪀🪀

The state of the view reflects the view state and keeps the view up to date. This view states can be stored if you want to implement the UI restorations, you want to start the user journey from where they left. The controller objects manage or take the responsibilities of holding the view states. In general, view objects manage their state. In short, View Layer is responsible for view states.

🪀 🪀 Navigation State 🪀🪀

The application is built of number of screens. It will navigate from or to the screen based on the defined app behavior. The path of navigation is referred as navigation state. These states are handled by within Storyboard using segues, handled within Controllers or other patterns.

🪀 🪀 Business Logic 🪀🪀

Application is responsible for handling some business logic with respect to the features it support. This will also come into this communication path before or after and in some cases it will come before and after.

Hope, the top section of this article has helped you to know the various responsibilities and guided us well to know the logical separation of these responsibilities.

The MVC, MVVM, VIPER, VIP may or may not be very vocal about all the above-mentioned responsibilities and its ownership. Which means we have few questions yet unanswered.

What next?

Try to answer, do we have this logical separation of responsibilities in our current application?
Try and evaluate all the known architecture design patterns, make the list of entities/files they explicitly spoke about in-terms of the responsibilities they handle?
Who will handle the responsibilities which the architecture design pattern does not explicitly support?
Will you use only the architecture design pattern entities/files and load them with additional responsibilities?
Is this helpful to choose the architecture design pattern for our next application purely based on this and not what people says about it?

The popular architecture patterns may or may not be very vocal about the responsibilities it takes but now this explanation will help us to get the more clarity on it.

Choose any architecture design pattern for an application. However, make sure these responsibilities are clear in our mind and reflect in our implementation.

We can choose any architecture design pattern that’s fits the requirement, team expertise, etc. Make sure we all have a clear understanding of separation of responsibilities and handling of it more clearly in our code.

Choose the suffix for names of the entities that are not there by design with in selected architectural design pattern.

Suffix which you can think of and choose the best fit for the right responsibility.

🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀

Helper, Handler, Manager, Router, Navigator, ViewState, Repository, Usecase, Cooridinator, and etc.

🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀🪀

Few of us might say, once we have this clear understanding of the various responsibility then why to choose the existing architectural design pattern? Can we create our own pattern?

Yes, we can. But it’s not that simple. Like, do we have expertise? who will take the responsibility of the defining the new architectural design pattern? Responsibility of training resources? Learning Curve? New resource onboarding? will it be accepted by other teams? Will it be accepted by the industry?

Architectural design pattern are guidelines and not the rules.

Instead of completely creating the architecture ourselves, we can use existing design patterns, which also ensure that things will work the way they’re supposed to. Patterns can be linked together to create more generic application architectures.

Conclusion:

All Architectures patterns have pros and cons. Due to the lack of in-depth understanding of responsibilities and ownership we laid to the misusing the selected architecture design pattern.

Now we all have clear knowledge of the layers and communication path with the components own responsibilities they have.

After reading this article, We all got more clarity of the responsibilities. We can read more or try to build our own understanding around the modules of your architecture design pattern. The ownership of the responsibilities of the logical components define in this article.

Now it doesn’t matter which architectural design pattern we use. MVC, MVP, MVVM or VIPER as far as we know the logical component and their responsibility. Implement it wisely. Clearly…