First, consider that no unique solution solves every issue for any business. Each application has its challenge, particular features, and business rules which can influence how to deal with the situation.
Watts S. Humphrey said that “Every business is a software business.”
This article discusses the importance of software architecture, the most common errors, and how to avoid mistakes and choose the right approach for your mobile application.
What is software architecture, and what’s it for?
Software architecture refers to a set of processes, techniques, and rules that defines patterns to develop an application. It helps the developer to create software that attends to the business requirements with attributes such as quality, performance, maintainability, scalability, usability, etc.
Why use software architecture? Is it a must?
Imagine you’ll build a house. What decisions do we need to consider before starting the process? Perhaps the house design, the materials used, or the people involved. Notice that these decisions are a must-step and define the foundation and quality of the house.
Likewise, a mobile architecture is based on decisions about essential parameters that determine the quality of the software, scalability, and more. In other words, it’s the organization of a system that includes all elements, how they interact with each other, the environment in which they operate, and the guides used to design the application.
Standard approaches
Let’s check the advantages and disadvantages of the most popular mobile architectures used as a standard approach, i.e., without the need to think about a custom implementation:
MVC (Model — View — Controller)
Advantages:
- Development becomes fast.
- It can benefit multiple developers to work together.
- Easier to debug and update the application.
Disadvantages:
- Increased complexity and can be challenging to scale.
- Must have strict rules on methods.
- Potential for an excessive number of updates.
👉 Apple inc. shared that MVC is central to a good design for a Cocoa application. The benefits of adopting this pattern are numerous.
MVP (Model — View — Presenter)
Advantages:
- Very understandable.
- Easier code maintenance.
- Easier to test components in isolation.
Disadvantages:
- Tight coupling between the View and the Presenter.
- It can be challenging to test since the presenter depends on N services, which implies more mocking in the tests.
- It can be challenging to scale.
MVVM (Model — View — ViewModel)
Advantages:
- Facilitates easier parallel development.
- Reduces the quantity of business logic required for each step.
- Easier to handle the unit test and can be tested without concerns about UI.
Disadvantages:
- It can be overkill for simpler UI or business logic.
- The data bindings can take more work to debug.
- In more complex apps, it does not provide the necessary abstraction to avoid large files.
👉 John Gossman, Software Engineer and Executive at Microsoft, reflected on the advantages and disadvantages of the MVVM pattern and its application in specific situations, noting that it can be “overkill” when creating simple user interfaces.
VIPER (View — Interactor — Presenter — Entity — Router)
Advantages:
- Very clear separation of responsibilities.
- Very easy to test.
- Scalable and flexible.
Disadvantages:
- Too much boilerplate.
- Steep initial learning curve.
- Time-consuming.
👉 Using VIPER, developers must understand that they'll need more time to implement a good foundation for each module or functionality. It will be a tedious and time-consuming task, and that’s why many developers use MVVM since it offers a similar abstraction but with less effort. You can find more about the VIPER design pattern here.
There are different approaches to making a solid foundation that provides quality, performance, maintainability, and more. The best option will depend on the necessary decisions to consider before starting the application, as seen in the example of building a house.
How to find the right architecture?
You can start by identifying the system needs and the possible issues faced during the development. Developing and maintaining an app without architecture is long, expensive, probably hard to scale, and even harder to test, resulting in more mistakes.
Consider that a standard architecture or a good custom approach to developing software always brings some benefits. It enforces development principles like SOLID (Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle) that help to support flexibility and maintainability.
In addition, it makes testing more efficient and easier to implement, reducing the probability of being prone to bugs. As well as providing a clear path to work, a good mobile architecture saves time and money in the long run.
Custom Approach
The most popular mobile architecture often splits the components into three layers: presentation, business logic, and data. This division is a good start to preparing a custom approach and will provide a clear path to split into more pieces if needed, as made by the VIPER pattern:
- Presentation Layer: consists of all the operations and components to provide the app to the user, what the user sees, the interface (UI), and feels when using the app, i.e., the user experience (UX).
- Business Layer: it‘s about the logic and rules for handling the data business, workflows, and operations, like data caching, security, data validation, exceptions, and more.
- Data Layer: responsible for routing the communication via API and network to support the data transactions. This layer contains everything related to data utilities, service agents, and data access. Also, it can be responsible for data persistence and error reporting.
Knowing what each piece is responsible for makes it possible to determine what kind of modification is viable according to the system business.
An interesting example is the usage of the modular approach for building a mobile application and how we can customize the current approach to provide better and even more separated layers.
In modular architecture, the idea is separate and isolate the elements of a building, then combine them with other modules to create a unit. By looking at the Data Layer, you understand all the responsibilities it contains — including data transactions via API and data persistence. This means we can split this Data Layer into two more different layers:
- Service Layer: responsible only for communication via API and error reporting (that also can be a separate layer);
- Storage Layer: responsible for data persistence, both combined by the Data Layer to provide the same, but even clearer and easier to manage and test.
Conclusion
There are different ways to provide the same path, and the success of this path requires careful consideration of architecture and tech stack.
Before starting to build any mobile application, pay attention to the business requirements and possible issues that can be faced during the development. A good workflow, design process, and agile methodologies can provide all the necessary content to make the best decision for your business.
Finally, remember that a good mobile architecture can bring many previously discussed benefits and disadvantages. The most important thing is to have the capability to refine, modify, and improve.
