I. Overview of APP architecture

1. Application architecture


Specifically, it focuses on two aspects: 1, how the APP is decomposed into different interface and conceptual level components, and 2, the control flow and data flow paths used in different operations between and among these components.

For example, Apple’s MVC pattern can be described by a three-tier structure of Model, View, and Controller.



The pattern above shows three levels of three modules. In a real app architecture, there are many possibilities for building parts

2. The Model and the View

The Model layer and the View layer are the two most common of these categories. The Model layer is the content of the app, and it doesn’t depend on any app framework (like UIKit). The View layer is the part of the App framework that makes the Model layer visible and allows users to interact, transforming the Model layer into an app.

3.App is essentially a feedback loop

The View layer and the Model layer need to communicate. So there needs to be a connection between the two. Assume that the View layer and model layer are cleared

Clearly separated, and without an undecoupled link, communication between the two requires some form of translation:



4. Architecture techniques

The Cocoa framework, a standard for The Apple platform, provides some architectural tools. Notification broadcasts values from a single source to several listeners. Key value observation (KVO) can report changes in properties on one object to another. However, the architecture tools in Cocoa are very limited, and we will use some additional frameworks. Such as reactive programming, but unlike notifications or KVO, it focuses on morphing between source and target, allowing logic to be expressed while moving information between components. We can create property bindings using techniques such as reactive programming or KVO. The binding accepts a source and an object, and whenever the source changes, the target is updated. This is syntactically different from observing manually. Instead of writing the logic for observing, we just specify the source and target, and the framework takes care of the rest for us.

5. The App task

For the program to work, the View must depend on model data to generate and exist, and we configure the view so that it can make changes to the Model and be updated when the Model is updated. So, we need to decide how to perform the following tasks in the app: 1. Build — who is responsible for building the Model and View and connecting them together? Update model — How to handle View Action? 3. Change the View – How to apply model data to the View? Viewstate – how to handle navigation and other states other than modelstate? 5. Testing – What testing strategy should be adopted to achieve a certain level of test coverage?

6.IOS architecture mode:

Common patterns of IOS architecture:

    • Model-view-controller Standard Cocoamodel-View-Controller (MVC) is the design pattern used by Apple in the sample project. It is the most common schema in Cocoa App, and it is the baseline for discussing schemas in Cocoa. The importance of MVC Because Apple uses this pattern in all of its instance projects, and because Cocoa itself was designed for this pattern, Cocoa MVC has become an official app architecture pattern certified for iOS, macOS, tvOS, and watchOS.
    • In contrast to MVC, MVVM uses view-Model in each scenario to describe the presentation logic and interaction logic in the scenario. The view-model contains no reference to the View or controller at compile time. It exposes a set of properties that describe the value that each view should have when it is displayed. Applying a series of transformations to the underlying Model object yields values that can eventually be set directly to the View. The actual work of setting these values to the view is done by pre-built bindings that ensure that when the display values change, they are set to the corresponding view. Reactive programming is a great tool for expressing such declarative and transformational relationships, so it is naturally suitable (though not strictly necessary) for dealing with the View-Model. In many cases, the entire View-Model can be expressed in declarative form in a responsive programming binding.

    •  Model-View-Presenter

      Model-view-presenter (MVP) is a very popular mode on Android, and has its own implementation on iOS.

      It is roughly a pattern between standard MVC and MVVM in terms of overall structure and technology used.

      The MVP uses a separate Presenter object, which plays the same role as the View-Model in MVVM.

      In contrast to the View-model, presenter removes the responsive programming part and instead exposes the values to be displayed as attributes on the interface.

      However, whenever these values need to change, the Presenter immediately pushes them to the view below (the view exposes itself as a protocol to the Presenter).







    • Component-based Architecture (React Native)