Introduction
In any program, both the functional side and performance and the organization of processes are important. A logical architecture for mobile application development is needed for large projects, where it is crucial for its viability, as well as for small ones. The larger the project, the more complex its structure will be in practice. If you do not think over the structural features in advance, then you lose the ability to control the program development at some point.
The initial architectural plan saves money, effort and time, and will largely determine the fate of the project. Even when developing something elementary, you need to set goals and choose a design approach based on them.
The article reveals to a greater extent the basic concepts and definitions of things, but there are and deepen the features of familiar processes, OOP principles, and other things. Below, the procedures for selecting and adjusting the software structure are disclosed in detail, the tasks investigated in the process are also considered, as well as tools for different types of work.
What is application architecture
In simple terms, a mobile application architecture is just a set of patterns and various methods that help developers create structured programs. The simplest “mobile application” in terms of content consists of architectural layers:
- Kernels are the main components of the project, closed from the consumer.
- User interface.
- Reusable elements (databases, libraries, etc.).
- Files that create the environment (.plist, AppDelegate, etc.).
- Resource information (graphic and sound files).
The “client-server” system allows you to determine the principles of interaction in the Internet, which have clients (C), delivery nodes and the “server” itself (S). Each of these technologies uses or defines new patterns between S and C. This process is called an exchange / interaction protocol.
Two-tier structures
Any modern network contains elements of the so-called client exchange server. As a basis, they are based on a 2-tier structure (two-tier), which got its name from a design that includes the distribution of three basic elements by two points: C and S.
A two-tier structure is used in a system where the server fully and directly responds to the request, relying on its own resources. The server does not use third-party sources for the needs of the client, even partially.
Within the framework of a two-level system, the positions of the elements on both the C and S sides determine the main models for their data exchange:
- Terminal Server is a common presentation of information.
- File Server is gaining access to a remote database and other file sources.
- Database server is providing remote information systems.
- An application server is a remote program.
Terminal Server as a model of distributed interaction of packs of information emerged first, and worked even before the invention of PCs and local networks. Its work was carried out on a universal electronic computer, which served as a “server”. Terminals with various keyboards were connected to S. Users entered information with their help, then they were transferred to the mainframe, where processing took place and the result was formed. This result was reflected on the terminal screen.
In the period of the emergence and spread of personal computers, as well as local networks, the file server system was first implemented. It provided access to file databases, including remote formats. For such a model, a dedicated Internet node becomes a server, which hosts the information bases. The user receives software where the application and presentation components are combined, and also uses the connected remote resource base as a local file. Protocols constitute a set of calls to low-level processes.
The further development of the area was the emergence of the database server model. This became possible thanks to the emergence of specialized database management systems (DBMS). In this case, the core of the system runs on S, and the application software on C. The interaction protocol is provided by the SQL language. This approach allows you to reduce network congestion, to simplify interfaces and administration a little (although the problem of combining different functions is acute). The downside is high network traffic.
The concept of an already active database server gradually began to evolve. In it, a part of the application component options forms procedures stored on the S side, and the application processes are shifted to the C side. The advantage of the concept lies in the allocation of convenient centralized administration of functional aspects, reducing development costs and network traffic.
The next approach is an application server. It transfers the functionality of the application component to the server, reducing user-requested configurations and greatly simplifying administration. This approach has increased requirements for server security, performance and reliability.
Three-tier architecture
This trend is associated with the increasing use of distribution computing. The S applications are the basis, but the network software is divided into more components located on different PCs. These elements interact with each other, exchanging information in a pre-agreed format. This client-server architecture is called three-tier. Simply put, an application server is simply added to the two-phase system. The elements are distributed like this:
- The provision of information packages is provided by the client side.
- An application element is located on a dedicated software server.
- Management and administration is provided by the WBS.
If the three-tier system is expanded by allocating additional servers, which will represent services and refer to other servers, the system will become multi-tier. It is also called N-tier.
Mobile application architecture: basic principles, pros and cons
Mobile software companies typically employ two groups of employees:
- Back-end – developers and coders responsible for the operation.
- Front-end – employees who are responsible for testing, program debugging and feedback.
Designing applications, depending on the tasks, can be carried out in several ways:
- Microservice.
- Modular.
- Monolithic.
A microservice approach won’t always be appropriate. Since the system should be logical and well-developed, highly paid performers are needed to develop it. You will need people who understand all the nuances of production. And, this requires significant start-up investments.
Modern developers use two main approaches to work: API First and Loose Coupling. Thanks to them, you can adjust the structure during operation, as well as change modules without affecting other segments.
API First is a method for quickly writing and testing a project in parallel. This approach saves money, reduces risks, and dramatically increases work speed.
Loose Coupling is a mechanism that controls changes to individual components and constrains individual coupling nodes as needed. In the system, all objects are interconnected and must influence each other. If there is no mutual influence, then bugs and vulnerabilities arise. During testing, circuits can be turned off and on, tracking changes and correcting errors on the fly.
Loose Coupling and API First allow programs to act as microservices, the architecture for a mobile application of which consists of independent elements that can freely function and scale across devices of different kinds. Such a complex works more correctly, since the nodes perform their own tasks and can be adjusted and “rebuilt”. In addition, the mobile app with such a system is characterised by:
- Intuitive controls.
- Variable display and scaling.
- Fast response.
- Fault tolerance.
- Writing convenience, even when considering the use of different languages.
The modular approach is a slightly simplified version of microservis, which also consists in dividing it into component parts, each of which is responsible for one task and is related to others. It is somewhat simpler to implement and cheaper, but also requires investment in development.
An alternative type of application architecture is a monolithic structure. Monolithic applications differ from others in that they are written as a single unit of code. Components are much more dependent on each other, designed to work together without significant system changes. This approach is the oldest and most primitive, and although it takes little time, now the monolithic method is almost never used. The main disadvantage is that technologies, platforms and devices change rapidly, and software must always correspond to the times, but changing the monolithic structure is difficult and fraught with consequences.
Android mobile application architecture: approaches, layers
Application Development Approaches
There are several tactics for creating mobile software on Android. Let us examine them in more detail.
MVP (Model-View-Presenter) is a popular pattern that is used for software architecture design. The Android mobile application architecture has three layers:
- Model is interface and user data.
- Presenter is an intermediary between the interface and the core of information.
- View is responsible for the delivery of data in a specific processing.
The advantages of the principle are easy debugging, reuse of written code, and separation of functions from individual components.
S.O.L.I.D – “clean architecture” – is a concept introduced in 2012 by R. Martin, which includes the following principles:
- The developer of the complex should not rely on the existence of specific libraries. Frameworks can be tools, not constraints.
- You need to be able to test your business logic without affecting other structure units.
- Flexibility of the interface and its structure.
- Business logic is not tied to the database.
- Freedom from external factors and agents.
MVVM (Model-View-ViewModel) is an mobile application development architecture pattern, alternative to MVC and MVP. Conceptually, it separates presentation layers and business logic data. The demarcation is more clearly defined than in other approaches.
Layers
The Android mobile application architecture is developed by specialists of different categories. All work, whether it is a request for data from the API or its processing, is distributed over layers (areas). For example, we will take a clean architecture, consisting of three levels:
- Representation.
- Business logic.
- Data.
The representation layer is a user area that includes graphics, an interface, and captures actions and events, client results. This layer is used to check for faults and test the overall operability of the software.
Operations can be divided into sublevels:
- User interface containing Activity and client data.
- ViewModel or similar layer that formats information and coordinates their display in the interface.
The business logic layer contains all the requirements applicable to the gadgets application. All tools for performing operations are located here.
At the data level, there are, of course, blocks of information and methods of interaction with them. These operations can be divided into:
- The repository level that allows you to implement the structural logic of access to the database. Obtaining the requested “information” is the main responsibility of this structural unit. It is necessary to check the location of the data in different ways (for example, first through the local network, and then through the API).
- Information source layer responsible for receiving data. Implements the logic for accessing the API to get information.
In theory and practice, the layers interact in different ways. In theory, each layer has access only to adjacent structural elements. Therefore, the architectural scheme of the software looks like this:
- The user interface interacts with the ViewModel.
- The ViewModel only communicates with the business logic layer.
- Business logic is limited to communicating with the repository.
- The Repository layer functions in conjunction with the data source.
In practice, given a clean architecture, the structure in the Android Studio IDE is divided into classes with a zone of responsibility.
IOS mobile application architecture: approaches, layers
The architecture of the iOS mobile application in its structure can largely repeat the options with Android. However, as elsewhere, there are some peculiarities.
IOS Application Development Tactics
There are enough software architecture design patterns in the modern world:
- MVC.
- MVP.
- MVVM.
- VIPER.
All except the last one work on the same principles as patterns for Android (Models, Views, Controller / Presenter / ViewModel). VIPER is a rather peculiar candidate, as it does not belong to the MV (X) category. Instead of the usual three layers, it suggests five:
- View is delivery and transformation of information into the desired format.
- The Interactor is responsible for the business logic associated with blocks of information.
- Presenter is a component of business logic associated with the UI and responsible for methods in the first layer.
- Entities are simple resources of blocks of information.
- The Router component is responsible for transitioning between modules.
Actual development principles
Having superficially analyzed the approaches to software architecture design, certain conclusions were formed:
- MVC does not fit the modern industry requirements.
- MVP allows you to clearly coordinate the formation of software, but it is still recognized as very voluminous. Allows to test your project on the go. Deprecated for modern programs.
- MVVM has a high level of testability, is excellent for development, combines the advantages of the above two approaches, but is free of their disadvantages.
- Viper is the preferred approach for modern architectural research. It has excellent distribution of responsibilities, testability is subordinated to the layer of distribution of responsibilities and therefore also has a higher level.
Important! It is quite logical to use multiple architectures in one project, if appropriate. If you need the simplest architecture of an ios MVC mobile application, but one or more screens are difficult to maintain on such an architecture, you can approach them through MVVM.
Hybrid mobile application architecture
When choosing an architecture, developers first of all look at the required type of software.
A native application is a program for one of the platforms, for example, specifically for Android, iPhone OS, or another. Native is the predisposition of an individual software to a specific platform. The program works on it, often flawlessly, while on others it either does not open at all, or does not work correctly.
Mobile web application optimized for smartphones. Such a site works on any platform, but requires a constant connection to the network, since most of the operations take place on the “server”.
Hybrid software combines the features of the two previous approaches. The principle is that most of the data is programmed with reference to the server, but only the necessary minimum remains on the user’s side.
Important! The hybrid architecture of mobile applications is becoming more and more relevant every year. However, it is needed in development rather for simple tasks, but it is better to complete complex projects through Native. Good native software in production can be 4 times more expensive than hybrid software.
The main advantages of the hybrid approach are:
- Cross-platform – an application created once can be exported to any OS.
- Development speed and scalability.
- Relatively low cost.
- Using one language (JavaScript or Dart).
- Same memorable interface.
This approach was used by major global brands. Hybrid sites are Aliexpress, eBay, etc. There is also the other side of the coin: Facebook and LinkedIn were developed as hybrids, but over time they were rewritten to be native for better performance.
There are also drawbacks to this method. The most unpleasant thing is that the performance is lower than that of analogues. There is a lack of customization flexibility, optimization, and problems with the placement of the application in stores. Also, the hybrid architecture of mobile applications limits the use of visual and graphic objects.
Which platform to choose for making an application in 2020-2021: iOS or Android?
The situation may turn out so that it is necessary to select only one platform during development: IOS or Android. The question of choice arises: is it much easier and faster to create software, where will the money be recouped faster?
It is necessary to formulate a clear concept of the program with the awareness of which consumer and in which location the stake is being placed. If you are counting on mass production, then Android is suitable for development (Asia, South America, Africa, etc.). iOS is more focused on users of less numerical, but more affluent (USA, Western Europe).
From the very beginning of the formation of the project it is important to clearly understand the method of distribution and monetization of the project. You can sell the app or provide it for free, but get paid with embedded ads. The purchasing power of IOS owners is 5 times higher, so it is more logical to provide a paid version of software on this platform, while on Android it is much more promising to add ads, since paid software is simply ignored by the majority.
The final choice should be based on the tasks set. For example, programs for the Apple OS are better monetized and are somewhat cheaper in development, but the demand for such projects is only in large cities, where there is more solvent population. If there is an expectation of mass demand, then it is better to focus on Android.
Conclusion: How to Choose the Right Mobile Application Architecture
Before you start creating any software, you need to form a strategy and conceptual rationale. Relying on it, you can not only correctly design the software in a graphic and functional sense, but also choose a win-win development approach from the very beginning. There is no definite answer which mobile application development architecture is better. Each situation requires individual consideration, and with that NIX Solutions can help you.