Detailed explanation of iOS APP architecture design

iOS APP Architecture Design

1. Overview of APP Architecture

1. Application Architecture

2. Model and View

3[1]. The essence of an app is a feedback loop

4. Architecture Technology

5. App[2] Tasks

6. Five modes of iOS architecture:

2. Overview of 5 Commonly Used Patterns in APP Design

1. Model-View-Controller

2. Model-View-ViewModel + Coordinator

3. Model-View-Controller+ViewState

4. Model Adapter-View Binder (MAVB)

5. Elm Architecture (TEA)

3. Other APP Architecture Models

1. Model-View-Presenter

2. VIPER, Riblets, and other “Clean” architectures

3. Component-based architecture (React Native)

1. Overview of APP Architecture

1. Application Architecture

App architecture is a branch of software design that is concerned with how to design the structure of an app. Specifically, it focuses on two aspects: how to decompose the app into different interface and conceptual hierarchical components, and the control flow and data flow paths used in different operations between these components and within themselves.

We usually use a simple block diagram to explain the architecture of an app. For example, Apple's MVC pattern can be described by a three-layer structure of model, view, and controller.

The modules in the diagram above show the three layers of this pattern with different names. In an MVC project, most of the code will fall into one of these layers. The arrows show how these layers are connected.

However, this simple block diagram does little to explain how the pattern operates in practice. This is because in real app architectures, there are many different ways to build components. How do events flow through the layers? Should components know about each other at compile time or at runtime? How do you read and modify data in different components? And what path should state changes take through the app?

2. Model and View

At the highest level, app architecture is a set of categories into which different parts of an app are grouped. In this book, we call these different categories layers: A layer is a collection of interfaces and other code that follows some basic rules and is responsible for a specific function.

The Model layer and the View layer are two of the most common of these categories.

The Model layer is the content of the app, and it does not depend on any app framework (such as UIKit). In other words, the programmer has complete control over the model layer. The Model layer usually includes model objects (folder and recording objects in the recording app example) and coordination objects (such as the Store type responsible for storing data on disk in our app example). The part of the model stored on disk is called the documentation model.

The view layer is the part that depends on the app framework. It makes the model layer visible and allows users to interact, thus turning the model layer into an app. When creating iOS applications, the view layer almost always uses UIKit directly. However, we also see that in some architectures, UIKit's encapsulation is used to implement different view layers. In addition, for some other custom applications such as games, the view layer may not be UIKit or AppKit, it may be some encapsulation of SceneKit or OpenGL.

Sometimes, we choose to use structures or enumerations to represent instances of models or views instead of objects of classes. In practice, the distinction between types is important, but when we talk about objects, structures, and enumerations in the model layer, we will refer to all three as model objects. Similarly, we will call instances of the view layer view objects, even though they may actually be objects, structures, or enumerations.

View objects usually form a single view hierarchy, in which all view objects are connected in a tree structure. At the root of the tree is the entire screen, with several windows on the screen, followed by more small views on the branches and leaves of the tree. Similarly, view controllers usually form a view controller hierarchy. However, model objects do not need to have a clear hierarchical relationship, and they can be independent models that are not related to each other in the program.

When we talk about a view, we usually mean a single view object like a button or a text label. When we talk about a model, we usually mean a single model object like a Recording instance or a Folder instance. In most of the literature on this topic, "model" can mean different things in different contexts. It can refer to a model layer, specific objects in the model layer, the document model, or unrelated documents in the model layer. Although it may be verbose, we will try to make these distinctions as clear as possible in this book.

Why is the classification of Model and View considered the foundation of the foundation?

Of course, it is absolutely possible to write an app without distinguishing between the model layer and the view layer. For example, in a simple dialog box, there is usually no independent model data. When the user clicks the OK button, we can read the state directly from the user interface element. However, in general, the lack of a model layer will make the program's behavior lack the basis for clear rules, which will make the code difficult to maintain.

The most important reason to define a model layer is that it provides a single source of truth for our program, which makes the logic clear and the behavior correct. In this way, our program will not be dominated by the implementation details of the application framework.

An application framework provides the infrastructure we need to build an app. In this book, we use Cocoa — or more precisely, UIKit, AppKit, or WatchKit, depending on the target platform — as the application framework.

If the model layer can be separated from the application framework, we can use it completely outside the scope of the app. We can easily run it in another test suite, or rewrite the new view layer using a completely different application framework. This model layer will be able to be used in the Android, macOS or Windows version of the app.

3. The essence of apps is feedback loops

The view layer and the model layer need to communicate. Therefore, there needs to be a connection between the two. Assume that the view layer and the model layer are cleared.

If the two are clearly separated and there is no connection that cannot be decoupled, communication between the two requires some form of translation:

Fundamentally, the user interface is a feedback device that is responsible for both display and input functions, so it is no wonder that the result is a feedback loop. The challenge faced by every app design pattern is how to deal with the communication, dependencies and transformations contained in the arrows in this diagram.

Different paths between the model layer and the view layer have different names. User-initiated events that result in a response from the view are called view actions, such as clicking a button or selecting a row in a table view. When a view action is sent to the model layer, it is converted into a model action (or a command that causes the model object to perform an action or update).

This command is also called a message (especially when the model is changed by a reducer, we call it that). The operations that transform view action into model action, and other logic along the way are called interaction logic.

A change in state on one or more model objects is called a model mutation. Model changes usually trigger a model notification, such as an observable notification from the model layer that describes what has changed in the model layer. When the view depends on model data, the notification triggers a view mutation to change the content in the view layer.

These notifications can come in many forms: Notification in Foundation, delegates, callbacks, or other mechanisms. The operations that transform model notifications and data into view changes, and other logic along the way is called presentation logic.

Depending on the app model, some state may be maintained outside of the document model, so that updates to that state do not follow the document model path. Navigation state in many patterns is a common example of this behavior, where parts of the view hierarchy (or scenes, as Cocoa Storyboards use terminology) may be swapped out or in.

The state of an app that is not a document model is called view state. In Cocoa, most view objects manage their own view state, and controller objects manage the rest of the view state. In Cocoa view state diagrams, there are often shortcuts added to feedback loops, or individual layers looping over themselves. In some architectures, view state is not part of the controller layer, but rather part of the model layer (although, by definition, a view controller is not part of the document model).

When all state is maintained in the model layer and all changes are propagated through a complete feedback loop path, we call it unidirectional data flow. This pattern is usually unidirectional when any view object or middleware object can only be created and updated through notifications from the model (in other words, the view or middleware cannot take shortcuts to update itself or other views).

4. Architecture Technology

The standard Cocoa frameworks on Apple platforms provide some architectural tools. Notification broadcasts a value from a single source to a number of listeners. Key-value observing (KVO) reports changes to properties on one object to another object. However, the architectural tools in Cocoa are quite limited, and we will use some additional frameworks.

Among the third-party technologies used in this book is responsive programming. Responsive programming is also a tool for communicating changes, but unlike notifications or KVO, it focuses on transforming between sources and targets, allowing logic to be expressed while transferring information between components.

We can create property bindings using techniques like Responsive Programming or KVO. A binding accepts a source and a target, and whenever the source changes, the target will be updated. This is syntactically different from manually observing, in that we no longer need to write the observation logic, but only need to specify the source and target, and the framework will handle the rest for us.

Cocoa on macOS includes Cocoa binding technology, which is a two-way binding. All observable objects are also observers. Establishing a binding connection in one direction will also create a connection in the opposite direction.

Neither RxCocoa (used in the .NET Core Components section) nor CwlViews (used in the MAVB section) support two-way binding.

In this book, all discussions about binding refer only to one-way binding.

5.App Tasks

For the program to work properly, the view must rely on the model data to be generated and exist. We configure the view so that it can

The model is changed and can 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 the two?

2. Update model - how to handle viewaction?

3. Changing the view - How to apply the model's data to the view?

4. 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. The answers to the above five questions are the basic elements of app design patterns. In this book, we will study these design patterns one by one.

6. Five modes of IOS architecture:

5 modes of IOS architecture:

• The standard Cocoa Model-View-Controller (MVC) is the design pattern used by Apple in sample projects. It is the most common architecture in Cocoa apps and is also the baseline used when discussing architecture in Cocoa.
• Model-View-ViewModel+Coordinator (MVVM-C) is a variation of MVC that has a separate "view-model" and a coordinator that manages the view controller. MVVM uses data binding (often used with responsive programming) to establish the connection between the view-model layer and the view layer.
• Model-View-Controller+ViewState(MVC+VS) This pattern centralizes all viewstate in one place instead of scattering them in the view and view controller. This is the same rule followed by the model layer.
• Model Adapter-View Binder (MAVB) is an experimental architecture used by one of the authors of this book. MAVB focuses on building declarative views and abandons the controller, using binding to communicate between the model and the view.
• Elm Architecture (TEA) is completely different from common architectures such as MVC or MVVM. It uses a virtual view hierarchy to build views and uses reducers to interact between models and views.

2. Overview of 5 Commonly Used Patterns in APP Design

1. Model-View-Controller

In Cocoa MVC, a small set of controller objects is responsible for handling all tasks outside the scope of the model or view layer.

This means that the controller layer receives all view actions, handles all interaction logic, sends all model actions, receives all model notifications, prepares all data for display, and finally applies them to the view changes. If we look at the diagram of the app feedback loop in the introduction chapter, we will find that there is a lot of communication between the model and the view.

On the arrows between the two diagrams, almost every label is a controller. And remember, although the build and navigation tasks are not labeled in this diagram, they are also handled by the controller.

Below is a block diagram of the MVC pattern, which shows the main communication paths of an MVC app:

The dashed lines in the diagram represent runtime references. The view layer and the model layer will not directly reference the controller in the code. The solid lines represent compile-time references. The controller instance knows the interfaces of the view and model objects it is connected to.

If we draw a border around the outside of this diagram, we get an MVC version of the app feedback loop. Note that there are other paths in the diagram that do not participate in the overall feedback loop (i.e. the arrows on the view and controller layers pointing back to themselves).

1. Build

The App object is responsible for creating the top-level view controller, which loads the view and knows what data to get from the model and display it. The controller either creates and owns the model layer explicitly or obtains the model through a lazily created model singleton. In a multiple document configuration, the model layer is owned by a lower level such as UIDocument or NSDocument. Individual model objects associated with a view are usually referenced and cached by the controller.

2. Change Model

In MVC, the controller receives view events primarily through the target/action mechanism and a delegate (set by the storyboard or code). The controller knows the view it is connected to, but the view has no information about the controller interface during compilation. When a view event arrives, the controller has the ability to change its internal state, modify the model, or directly change the view hierarchy.

3. Change the View

In our understanding of MVC, when a view action that changes the model occurs, the controller should not directly operate the view hierarchy. The correct approach is for the controller to subscribe to model notifications and then change the view hierarchy when the notification arrives. In this way, the data flow can be one-way: the view action is converted into a model change, then the model sends a notification, and the notification is finally converted into a view change.

4. View State

View state can be stored in the properties of the view or controller as needed. Compared to view actions that affect the model, actions that only affect the state of the view or controller do not need to be passed through the model. For the storage of view state, you can use a combination of storyboard and UIStateRestoring to implement it. The storyboard is responsible for recording the active controller hierarchy, while UIStateRestoring is responsible for reading data from the controller and view.

5. Testing

In MVC, the view controller is tightly connected to the rest of the app. The lack of boundaries makes it very difficult to write unit tests and interface tests for the controller, and integration testing is one of the few remaining viable testing methods. In integration testing, we build connected view, model, and controller layers, and then operate the model or view to test whether we can get the results we want.

Integration tests are very complex to write, and they cover a wide range of areas. They not only test the logic, but also how the components are connected (although in some cases the perspective is different from UI testing). However, in MVC, it is usually possible to achieve around 80% test coverage through integration testing.

• Importance of MVC

Because Apple uses this model in all its sample projects, and Cocoa itself is designed for this model, Cocoa MVC has become the officially certified app architecture model on iOS, macOS, tvOS, and watchOS.

• history

The name MVC was first proposed in 1979 by Trygve Reenskaug to describe the application of the "template pattern" that already existed on Smalltalk-76. After he discussed terminology with Adele Goldberg, the name MVC was finalized (previous names included Model-View-Editor and Model-View-Tool-Editor, etc.).

In the original conception, the view is directly "attached" to the model layer and observes all model changes. The purpose of the controller is only to capture user events and forward them to the model. Both features are products of the way Smalltalk operates. They are not designed for modern app frameworks, so today this original conception of MVC is almost extinct.

The MVC implementation in Cocoa dates back to the days of NeXTSTEP 4, circa 1997. Prior to that, all roles that are now played by controllers were usually played by a high-level view class (such as NSWindow). Later, the idea that the presentation should be separated, that is, the view layer and the model layer should be completely isolated, which brought a strong demand for the introduction of a supporting object to facilitate communication between the two.

The concept of controller in NeXTSTEP is very similar to the presenter in Taligent's earlier Model-View-Presenter. However, now the name Model-View-Presenter is often used to refer to MVC-like patterns that abstract the view from the controller through protocols.

2. Model-View-ViewModel + Coordinator

MVVM is similar to MVC in that it is also based on a scene (a subtree in the view hierarchy that may be switched in or out when navigation changes). Compared to MVC, MVVM uses view-model in each scene to describe the presentation logic and interaction logic in the scene.

The view-model contains no references to views or controllers during compilation. It exposes a set of properties that describe the values ​​that each view should have when displayed. After applying a series of transformations to the underlying model objects, these values ​​can be obtained and can ultimately be set directly on the view. The actual work of setting these values ​​on the view is done by pre-established bindings, which ensure that when the displayed value changes, it is set to the corresponding view. Responsive programming is a great tool for expressing these kinds of declarations and transformation relationships, so it is naturally suitable (although not strictly necessary) to be used to deal with

view-model. In many cases, the entire view-model can be expressed in a declarative form using responsive programming bindings.

In theory, because the view-model does not contain a reference to the view layer, it is independent of the app framework, which allows the test of the view-model to be independent of the app framework.

Since the view-model is coupled to the scene, we also need an object that can provide logic when switching between scenes. In MVVM-C, this object is called a coordinator. The coordinator holds a reference to the model layer and understands the structure of the view controller tree, so that it can provide the required model objects for each scene's view-model.

Unlike MVC, view controllers in MVVM-C never directly reference other view controllers (and therefore, other view-models). View controllers use the delegate mechanism to tell the coordinator about view actions. The coordinator then displays new view controllers and sets their model data. In other words, the view controller hierarchy is managed by the coordinator, not by the view controller.

If we ignore the coordinator, then this diagram looks a lot like MVC, but with a stage between the view controller and the model. MVVM moves most of the work that was previously in the view controller to the view-model, but note that the view-model does not have a reference to the view controller at compile time.

The view-model can be separated from the view controller and view and can be tested separately. Similarly, the view controller no longer has internal view state, which has been moved to the view-model. The dual role of the view controller in MVC (being part of the view hierarchy and coordinating the interaction between the view and the model) has been reduced to a single role (the view controller is just part of the view hierarchy).

The addition of the coordinator pattern further reduces the view controller's responsibilities: now it does not need to care about how to display other view controllers. Therefore, this actually reduces the coupling between view controllers at the cost of adding a layer of controller interface.

1. Build

The creation of the model remains the same as in MVC, and is usually the responsibility of a top-level controller.

The model object now belongs to the view-model and not to the view controller.

The initial view hierarchy is created the same way as in MVC, either through storyboard or code. Unlike MVC, the view controller no longer directly fetches and prepares data for each view, but instead delegates this work to the view-model. The view controller also creates the view-model when it is created, and binds each view to the corresponding properties exposed by the view-model.

2. Change Model

In MVVM, the view controller receives view events in the same way as in MVC (and the connection between the view and the view controller is established in the same way). However, when a view event arrives, the view controller does not change its internal state, the view state, or the model. Instead, it immediately calls a method on the view-model, which then changes its internal state or the model.

3. Change the View

Unlike MVC, the view controller does not listen to the model. The view-model is responsible for observing the model and translating the model's notifications into a form that the view controller can understand. The view controller subscribes to changes in the view-model, which is usually done through a responsive programming framework, but any other observation mechanism can also be used. When a view-model event comes, it is up to the view controller to change the view hierarchy.

To achieve one-way data flow, the view-model should always send view actions that change the model to the model, and notify relevant observers only after the model changes actually occur.

4. View State

View state exists either in the view itself or in the view-model. Unlike MVC, there is no view state in the view controller. Changes in the view state in the view-model will be observed by the controller, but the controller cannot distinguish between notifications from the model and notifications of view state changes. When using a coordinator, the view controller hierarchy will be managed by the coordinator.

5. Testing

Because the view-model and view layer are decoupled from the controller layer, you can use interface testing to test the view-model instead of using integration testing as in MVC. Interface tests are much simpler than integration tests because you don't need to build a complete component hierarchy for them.

To make the interface tests as comprehensive as possible, the view controller should be as simple as possible, but the parts that are not moved out of the view controller still need to be tested separately. In our implementation, this includes the interaction with the coordinator and the code responsible for initial creation.

• Importance of MVVM

MVVM is the most popular app design pattern on iOS that is an indirect variation of MVC. In other words, it is not very different from MVC; both are built around view controller scenes and use mostly the same mechanisms.

The biggest difference may be the use of responsive programming in the view-model, which is used to describe a series of transformations and dependencies. By using responsive programming to clearly describe the relationship between model objects and displayed values, it provides important guidance for us to understand the dependencies in the application as a whole.

The coordinator in iOS is a very useful pattern, because managing the view controller hierarchy is a very important thing. The coordinator is not inherently tied to MVVM, it can also be used in MVC or other patterns.

• history

MVVM was proposed by Ken Cooper and Ted Peters, who were working at Microsoft on what became Windows Presentation Foundation (WPF), Microsoft's app framework for .NET[3], which was officially released in 2005.

WPF uses an XML-based descriptive language called XAML to describe the properties on a view-model to which the view is bound. In Cocoa, without XAML, we have to use frameworks like RxSwift and some code (usually in the controller) to complete the binding between the view-model and the view.

MVVM is very similar to the MVP pattern we mentioned in the history of MVC. However, in Cooper and Peters's discussion, the binding of view and view-model in MVVM requires explicit framework support, but the presenter communicates changes in a traditional manual way.

Coordinators in iOS are a relatively recent (re)popularity, with Soroush Khanlou describing the idea on his website back in 2015. Coordinators are based on older patterns like app controllers, which have existed in Cocoa and other platforms for decades.

3. Model-View-Controller+ViewState

MVC+VS is an attempt to bring a one-way data flow to standard MVC. In standard Cocoa MVC, view state can be manipulated in two or three different ways, but MVC+VS tries to avoid this and make view state handling easier to manage. In MVC+VS, we explicitly define and express all view states in a new model object, which we call the view state model.

In MVC+VS, we don't ignore any navigation changes, list selections, text box edits, switch changes, model display or scroll position changes (or any other view state changes). We send these changes to the view state model. Each view controller is responsible for listening to the view state model, so the communication of changes is very direct. In the presentation or interaction logic part, we don't read the view state from the view, but get them from the view state model:

The resulting diagram is similar to MVC, but the portion of the controller's internal feedback loop (used to update the view state) is different; it now forms a separate view state loop, similar to the model's loop.

1. Build

As with traditional MVC, the work of applying document model data to the view is still the responsibility of the view controller, which also uses and subscribes to the view state. Because both the view state model and the document model need to be observed, we need many more functions for observing through notifications than in typical MVC.

2. Change Model

When a view action occurs, the view controller changes the document model (this remains the same as MVC) or changes the model state. We do not change the view hierarchy directly, all view changes must be notified by the document model and view state model.

3. Change the View

The Controller observes both the document model and the view state model and updates the view hierarchy only when changes occur.

View State

View state is explicitly abstracted from the view controller. It is handled in the same way as the model: the controller observes the view state model and modifies the view hierarchy accordingly.

4. Testing

In MVC+VS, we use integration tests similar to those in MVC, but the tests themselves are very different. All tests start with an empty root view controller, which then builds out the entire view hierarchy and view controller hierarchy by setting up the document model and view state model. The hardest part of integration testing in MVC (setting up all the components) is done automatically in MVC+VS. To test a different view state, we can reset the global view state and all view controllers will adjust themselves.

Once the view hierarchy is built, we can write two types of tests. The first type of test is responsible for checking that the view hierarchy is built as we expect, and the second type of test checks that view actions change the view state correctly.

• Importance of MVC+VS

MVC+VS is mainly a tool for teaching view state.

In a non-standard MVC app, adding a view state model, and observing that view state model in each view controller (on top of already observing the model), provides a number of advantages: arbitrary state restoration (this restoration does not rely on storyboards or UIStateRestoration), full user interface logging, and the ability to jump between different view states for debugging purposes.

• history

This particular system was developed by Matt Gallagher in 2017 as a teaching tool to demonstrate concepts such as unidirectional data flow and time travel in user interfaces. The goal of this pattern is to snapshot the state of a view at each action with minimal changes to a traditional Cocoa MVC app.

4. Model Adapter-View Binder (MAVB)

MAVB is an experimental mode centered on binding. In this mode, there are three important concepts: view binder, model adapter, and binding.

A view binder is a wrapper class for a view (or view controller): it builds the view and exposes a list of bindings for it. Some bindings provide data to the view (e.g., the text of a label), others emit events from the view (e.g., button clicks or navigation changes).

Although view binders can contain dynamic bindings, view binders themselves are immutable. This makes MAVB a declarative model: you declare view binders and their actions, rather than changing view binders over time.

Model adapters are encapsulations of mutable state, implemented by so-called reducers. Model adapters provide an input binding (for emitting events), and an output binding (for receiving updates).

In MAVB, you never create views directly; instead, you only create view binders. Likewise, you never deal with mutable state outside of model adapters. Transformations between view binders and model adapters (in both directions) are accomplished by mutating the bindings (using standard reactive programming techniques).

MAVB removes the need for a controller layer. Creation logic is expressed through view binders, transformation logic is expressed through bindings, and state changes are expressed through model adapters. The resulting block diagram is as follows:

1. Build

Model adapters (used to encapsulate the main model) and view state adapters (encapsulate the top-level view state) are usually in

The main.swift file is created before any views.

View binders are constructed using normal functions that accept the necessary model adapter as a parameter.

The Cocoa view is created by the framework. 2. Change the Model

While a view (or view controller) can take actions, the corresponding view binding allows us to specify an action binding. Here, data flows from the view to the output of the action binding. Typically, the output is connected to a model adapter, and the view event is transformed by the binding into a message that the model adapter can understand. This message is then consumed by the model adapter's reducer and changes the state.

2. Change the View

When the state of the model adapter changes, it generates a notification through the output signal. In the view binder, we can transform the output signal of the model adapter and bind it to a view property. In this way, the view property will automatically change when a notification is sent.

3. View State

View state is considered part of the model layer. View state actions and view state notifications follow the same path as model actions and model notifications.

4. Testing

In MAVB, we test our code by testing the view binder. Since the view binder is a list of bindings, we can verify that the bindings contain the items we expect and that they are configured correctly. We can use the bindings to test the initial build and when changes occur.

Tests performed in MAVB are very similar to those performed in MVVM. However, in MVVM, the view controller may contain logic, which results in the possibility of untested code between view-model and view. The view controller does not exist in MAVB, and the binding code is the only code between the model adapter and the view binder, so that it is much simpler to ensure full test coverage.

• The importance of MAVB

Among the main modes we are discussing, MAVB does not follow a direct precedent, it is neither a pattern ported from other platforms nor a variant of other modes. It is a self-contained, used for experimental purposes, and is a bit strange. The point we introduce here is that it shows something very different. However, this is not to say that this pattern does not draw lessons from other modes: binding, responsive programming, domain-specific languages, and reducers are already well-known ideas.

• history

MAVB was first proposed by Matt Gallagher on the Cocoa with Love website. This pattern refers to Cocoa binding, functional response animation, ComponentKit, XAML, Redux, and thousands of rows of experience using Cocoa view controller.

The implementations in this book use the CwlViews framework to handle view building, binding and adapter implementation.

5. Elm Architecture (TEA)

TEA and MVC are fundamentally different. In TEA, model and all view states are integrated into a single state object, and all changes in the app occur by sending messages to the state object. A state update function called reducer is responsible for handling these messages.

In TEA, each state change generates a new virtual view hierarchy, which consists of a lightweight structure that describes the form the view hierarchy should look like. The virtual view hierarchy allows us to write the code of the view part in a pure function; the virtual view hierarchy is always calculated directly from the state, and there will be no side effects in the middle. When the state changes, we use the same function to recalculate the view hierarchy instead of directly changing the view hierarchy.

Driver type (which is part of the TEA framework, which holds references to other layers in the TEA) compares the virtual view hierarchy and makes necessary changes to make the views match their virtual versions. The driver component in this TEA framework is initialized as our app starts, and it does not know which specific app to correspond to. We want to pass this information in its initialization method: including the initial state of the app, a function that updates the state through messages, a function that renders the virtual view hierarchy based on the given state, and a function that calculates notification subscriptions based on the given state (for example, we can subscribe to notifications when a model store changes).

From the perspective of the framework user, the TEA's block diagram about the change part is as follows:

If we trace the upper two layers of this chart, we will find that there is a feedback loop between the view and the model that we mentioned at the beginning of this chapter; this is a loop from view to state and then back to the view (coordinated through the TEA framework).

The following loop represents the way in TEA to handle side effects (such as writing data to disk): When processing messages in the state update method, we can return a command that will be executed by the driver. In our case, the most important command is to change the content in the store, which in turn is listened to by the subscribers held by the driver. These subscribers can trigger messages to change the state, and the state eventually triggers the re-rendering of the view in response.

The structure of these event loops makes TEA another example of a design pattern that adheres to the principle of one-way data flow.

1. Build

The state is built at startup and passed to the runtime system (i.e. driver). The runtime system has the state, and the store is a singleton.

The initial view level and the view level when updated later are constructed through the same path: through the current state, the virtual view level is calculated, and the runtime system is responsible for updating the real view level to match the virtual view level.

2. Change the Model

Virtual views have messages associated with them, which are sent when a view event occurs. Driver can receive these messages and use update methods to change the state. Update methods can return a command (side effects), such as us

Changes you want to make in the store. Driver intercepts the command and executes it. TEA makes it impossible for view to make changes to state or store directly.

3. Change View

The runtime system is responsible for this. The only way to change the view is to change the state. So, initialize the creation of the view hierarchy and more

There is no difference between new view levels. 4. View State

View state is included in the overall state. Since view is calculated directly from the state, navigation and interaction states will also be automatically updated.

4. Test

In most architectures, it often takes a lot of effort to get the test parts connected to each other. In TEA, we don't need to test this because the driver automatically handles this part. Similarly, we don't need to test the view changes correctly when the state changes. All we need to test is that for a given state, the virtual view level can be correctly calculated.

To test the state change, we can create a given state and then use the update method and the corresponding message to change the state. Then by comparing the previous and subsequent states, we can verify that the update returns the expected result for the given state and message. In TEA, we can also test whether the subscription for the given state is correct. Like the view level, the update function and subscription are also pure functions.

Because all components (calculate virtual view levels, update functions, and subscriptions) are pure functions, we can test them completely isolated. Initialization of any framework components is not required, we just pass the parameters in and verify the results. Most of the tests in our TEA implementation are very straightforward.

• The importance of Elm architecture

TEA was first implemented in the functional language Elm. Therefore, TEA is an attempt to express GUI programming using functional methods. TEA is also the oldest one-way data flow architecture.

• history

Elm is a functional programming language designed by Evan Czaplicki. Its original purpose was to build front-end web apps. TEA is a pattern attributed to the Elm community, and its emergence is a natural result of the interaction between language constraints and target environments. The ideas behind it influence many other web-based frameworks, including React, Redux, and Flux. In Swift, there is no authoritative implementation of TEA, but we can find many research projects. In this book, we implemented this pattern according to our own understanding. The main work was completed by Chris Eidhof in 2017. Although our implementation is not yet "product-level", many ideas can be used in production code.

3. Other APP architecture models

1. Model-View-Presenter

Model-View-Presenter (MVP) is a very popular model on Android, and it also has corresponding implementations in iOS. In terms of overall structure and technology, it is roughly a model located between standard MVC and MVVM.

MVP uses a separate presenter object, which is the same as the view-model in MVVM. Compared to view-model, presenter removes the responsive programming part, but exposes the values ​​to be displayed as properties on the interface. However, whenever these values ​​need to be changed, presenter will immediately push them to the following view (the view exposes itself as a protocol to the presenter).

From an abstract point of view, MVP and MVC are very similar. Cocoa's MVC, except for its name, is an MVP - it is derived from the original MVP implementation of Taligent in the 1990s. View, state and association logic are the same in both modes. The difference is that modern MVPs have a separate presenter entity, which uses a protocol to define between presenter and view controller. Cocoa's MVC allows controllers to directly reference view, while presenters in MVPs can only know the view's protocol.

Some developers think that separation of protocols is necessary for testing. When we discuss testing, we see that standard MVC can be fully tested without any separation. So, we feel that MVP is not much different. If we have a strong demand for testing a fully decoupled display layer, we think the MVVM is a little simpler: let the view controller pull the value from the view-model through observation, rather than letting the presenter push the value into a protocol.

2. VIPER, Riblets, and other "Clean" architectures

VIPER, Riblets, and other similar patterns attempt to bring Robert Martin's "Clean Architecture" from web apps to iOS development, which mainly distributes the controller's responsibilities into three to four different classes and arranges them in strict order. Each class in the sequence does not allow direct references to the previous classes in the sequence.

To force a single-directional reference, these patterns require a lot of protocols, classes, and how data is passed in different layers. For this reason, many developers using these patterns use code generators. Our feeling is that these code generators, and any cumbersome patterns that require generators, are misleading. Attempts to bring the "Clean" architecture to Cocoa usually claim that they can manage the "mass" problem of view controllers, but it is ridiculous that doing so often makes the code base bigger.

Although decomposing an interface is an effective means of controlling the size of a code, we believe that this should be done on demand, rather than dogmatically operating every view controller. Decomposing an interface requires a clear understanding of the data and the tasks involved. Only in this way can we achieve optimal abstraction and minimize the complexity of the code.

3. Component-based architecture (React Native)

If you choose to use JavaScript instead of Swift programming, or if your app relies heavily on the interaction of web APIs, JavaScript will be a better choice, and you might consider React Native. However, this book focuses on Swift and Cocoa, so we limit the exploration patterns to these areas.

If you want to find something like React Native but based on Swift, you can check out our exploration of TEA. The implementation of MAVB also gets some inspiration from ComponentKit, which itself gets inspiration from React: it uses DSL-like syntax to build declarative and deformable view, which is similar to the render method of Component in React.