State of the art of Architectures in Mobile Clients to date ~ Yair Carreno

State of the art of Architectures in Mobile Clients to date

To date, the ecosystem of mobile solutions can count on its implementation with a varied list of architecture styles and design patterns.

The first thing to keep in mind is that the architectural style and design patterns used in its implementation are issues that, although related, do not mean the same thing. For example, on mobiles, there is a family of well-known design patterns applied to the presentation layer.

These are the patterns MVC(Model View Controller), MVP(Model View Presenter), MVI(Model View Intent), MVVM(Model View View Model), MVVM ViewState, Redux, VIPER. These patterns can be used in different styles of architecture, such as Clean Architecture or Hexagonal Architecture.

In some cases, the use of a certain pattern tends to be confused with the application's architecture, for example, saying that the use of the MVVM pattern typifies the solution as an application with Clean Architecture, is sometimes a frequent misunderstanding. Applying patterns such as MVVM helps enforce Clean Architecture guidelines but does not define the architecture style in its entirety. Clean Architecture is more than the application of specific patterns; it also involves applying certain practices in the field of design and implementation.

In that order of ideas, an application designed under Clean Architecture could include patterns such as MVP or MVI instead of MVVM and still comply with the guidelines of the architecture style.

Now, what pattern should always be used to ensure proper implementation?

All patterns are good candidates; however, the decision to prefer one pattern over another is based on the context of the solution itself, based on the requirements, the type of application, the equipment, and the standards defined in the company.

Each pattern provides certain advantages in dealing with one problem; however, they may not be sufficient to mitigate others. Thus, through analysis and weighting of objectives, the most appropriate is chosen. It is challenging to have a single pattern that solves all problems.

Now, it should also be mentioned that one of the most widely accepted patterns in large-scale applications has been MVVM. For example, Android incorporates it into its Architecture proposal, but again I reiterate that it is not the only alternative.

Could you combine design patterns in the presentation layer?

Yes. As far as the solution and its architecture allow, I do not see the impediment. In mobile solutions, a single applied design pattern is usually mentioned; however, if a particular feature requires an MVVM ViewState to fulfill the requirement, it should not be ruled out.

It is not about starting to mix patterns and making a code mess; it is about maintaining a limit to avoid becoming so orthodox as to leave teams without flexible tools. Everything managed in its proper proportion could generate the expected results.

Evolution of patterns in the presentation layer

The customer presentation layer, and especially the mobile presentation layer, has been changing in recent years.

On the iOS side, SwiftUI technology has been added to replace the well-known Storyboards / ViewControllers.

Android, for its part, does something similar by adding Jetpack Compose to replace the well-known Layouts / Activities.

This change in technology opens the opportunity to continue applying the same design patterns already mentioned and propose designs with other patterns seeking greater flexibility and benefits in the administration of the states of the views.

In such a way that the path of the patterns in terms of presentation layer has been basically from MVC to MVP, then to MVVM or MVI and now to design patterns that have the state of view known as Unidirectional State Flow ( USF) as an essential actor.

This pattern has two implementation variants, through Redux or MVVM ViewState.

Both patterns for its implementation are based on the state machine principle. However, it should be clarified that MVVM ViewState is not pure USF. MVVM ViewState is an enhancement made to the MVVM pattern to prioritize the state of the view.

Have you heard of Rx? What role do RxSwift, RxJava, RxJS, and other extensions play in this context?

Well, I could say a lot of importance.

Rx extensions allow you to implement many of the patterns mentioned above. For example, the MVVM pattern or the Redux pattern, or even the MVVM ViewState pattern.

These patterns can be implemented in the same way without using the Rx extensions. Still, I guarantee that omitting the use of Rx extensions could be a disadvantage, especially considering the ease and speed that a development team could acquire in delivering a feature.

That has been a short overview of current issues regarding architectural styles and design patterns, focused more on the presentation layer. The other layers and their respective components are left out as significant as Repositories, Uses Cases, Mappers, Cache Strategy, etc., for which it is better to dedicate a separate post.