SAE NURUKI

1 June, 2022

My recommend iOS System Design Pattern

Overview

The system design policy for the iOS App is to be implemented with the following ideas in mind, so that we can implement based on the common understanding.
Unfortunately this design policy is not always followed in the current source code, continuous refactoring is also required to bring it closer to the ideal state.
This document is divided into two major chapters. GUI Architecture and System Architecture.

1. GUI Architecture

1-1. Presentation Domain Separation (PDS)

It all starts with separating the UI logic from the Domain logic.
Don't implement Data Transformation or Data Fetching in UIViewController. Be aware that only UI-related processing should be implemented in the ViewController, as it can easily become a Massive View Controller.

1-2. MVVM

We use the MVVM + RxSwift pattern.

In the MVVM pattern, data binding between User Input and View Output can be very complex, so we will avoid that problem. (Be aware of unidirectional data flows such as Flux and Redux.)
Define the Inputs and Outputs that will be used on the ViewModel, respectively: clarity about what is input from the UI and what is output to the UI will make unit testing of the ViewModel easier, and simplifying the data flow will make it easier to identify problems.
Note that it is not necessary to use Observable for Input and Driver for Output, but be sure to implement with Thread in mind.

The connection between ViewModel and Model in MVVM tends to be defined vaguely, but implementation should be done with Dependency Injection in mind.
By expressing interfaces in terms of Protocols, it is possible to replace actual implementations with test implementations in a stub-like manner.
Also, by explicitly connecting only the necessary domain logic to the ViewModel, it becomes clear which domain logic is needed by the UI.

1-3. MVVM + C

In addition, the coordinator pattern separates the screen transition logic from the View.
This improves ViewController reusability and prevents ViewControllers from being tightly coupled with each other.

System Architecture

2-1. Inspired by Clean Architecture

GUI Architecture is only intended to clearly separate UI logic from Domain logic, but it is necessary to design the entire System.
In Mobile App, implementation of Clean Architecture is not strictly defined because it makes it more complicated.
Imagine Layers spread out in concentric circles, and the implementation that we have just applied PDS will clarify modules that change little and achieve domain-driven design.
As shown in the right figure below, let's apply and deepen the GUI architecture, which has been explained in Chapter 1.

We do not require a strict Clean Architecture.
Each of the MVVM+C patterns mentioned the above should be designed to allow Dependency Injection into ViewModel.
The Domain provided by the service should be loosely coupled to each other and only available by Injection to the ViewModel.

5 February, 2023

SwiftUI Technology Selection Considerations

Overview

SwiftUI and Combine were introduced in iOS13, and async/await was introduced in Swift5.5, causing a significant change from the existing UIKit implementation. As time has passed since the introduction of SwiftUI, related articles and case studies have increased. There are fewer applications that still support iOS13 or earlier, and these refactoring tasks are becoming necessary.

Technology Selection Considerations

The main focus of this article is two points:

• Coexistence of "Source of Truth" promoted by SwiftUI and Combine implementation
• Use of Combine asynchronous processing and Swift's async/await asynchronous processing

I believe that by designing these issues in a clean manner with the UI architecture, each of their strengths can be maximized. The following figure shows a MVVM architecture design.

Data update only in UI

• Follow Apple's "Source of Truth" promotion
• Maintain properties at the highest layer of the View Hierarchy and render updates hierarchically top-down with data updates
• Make it a single directional data flow, like Flux or Redux

Data management of Domain and UI connection

• Use Combine to subscribe to data changes with ObservableObject
• Bilateral binding with View, but design each data flow to be a single flow
• Enable asynchronous actions separated from the Main Thread

Data handling of Domain

• The domain logic is designed to be modularized by functionality, and dependencies are made clear by dependency injection into the UI logic
• Implementations like functional programming, where functions are processed when called from the UI logic
• Processes are executed simply and asynchronously without using the Observable pattern, using Swift's async/await function.

View

In SwiftUI, all data within the View hierarchy must be defined with a single source of truth. Unlike in UIKit, where Views are defined as a Class type, SwiftUI defines Views as Struct type. This change is significant because Views do not maintain state, but instead render a blueprint each time the data is updated.

SwiftUI provides many new Property Wrappers specifically for Views. By properly utilizing these, you can achieve a single-direction data flow similar to that of Redux. Additionally, being the single source of truth ensures that changes can be made safely from any thread.

The State is defined at the top-most View of the necessary hierarchy. Lower-level Views make use of the State by either Binding or copying the Data from the top-most View.

• @Binding allows for Read & Write operations on Child Views
• let allows for Read Only operations on Child Views

ViewModel

ViewModel is a design method used in MVVM UI architecture that binds UI logic and domain logic bidirectionally. It aims to subscribe to the results of domain logic processing using the Observer pattern or to process it isolated from the main thread.

To maximize the effects of the Observer pattern, Combine, which was introduced in iOS 13, is adopted. RxSwift, which has been supported for a long time to realize reactive programming in Swift, is still very convenient as an open-source.

However, as iOS natively supports conversion to Combine through features such as NotificationCenter.default.publisher, Timer.publish(), and NSObject.KeyValueObservingPublisher, let's actively adopt Combine.

The bidirectional binding in MVVM has the disadvantage that data changes in both directions. I introduce a mechanism for changing data in one direction, like Redux.

Please define ViewModel based on the above as a template. ViewModel is defined as a struct and consists of three components: Input, which collects triggers, Output, which collects observable data, and a definition of the data flow from Input to Output.

To prevent bidirectional reading and writing of data, we make Input a request for data changes and Output a read-only data, and subscribe to data changes in one direction.

The key here is the ObservableObject and Published of Combine. By conforming to ObservableObject, data will be reloaded in the view when there is a change. The Published property wrapper can tell SwiftUI to trigger the view's reload.

Model

The domain logic separates itself from the UI logic by utilizing the concept of separation of concerns (SoC). SoC means building a program with components that are separated by concerns or responsibilities. By modularizing the functionality, the necessary functions can be tied to the necessary UI. This is called Dependency Injection.

For example, as shown in the figure, the Purchase Service, which has payment-related functions, can be applied to the UI that requires payment information and processing, and made inaccessible from other UIs. Similarly, by tying the Auth Service to the UI that requires authentication information and processing, it is easy to understand which screens require authentication information.

Implementing this modular, function-based Model, which is separated by concerns, makes it possible to use it as a module or SDK call, using a different asynchronous description with async/await, rather than Combine.

Combine and Swift async/await are often referred to as overlapping technologies from the perspective of asynchronous processing, but GCD is more commonly described as being replaced by async/await.

2 May, 2021

Digital Marketo to Their New Office.

Nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus legentis in iis qui facit eorum claritatem. Investigationes demonstraverunt lectores legere me lius quod ii legunt saepius. Claritas est etiam processus dynamicus, qui sequitur mutationem consuetudium lectorum.

Nobis eleifend option conguenes.

Mauris tempor, orci id pellentesque convallis, massa mi congue eros, sed posuere massa nunc quis dui. Integer ornare varius mi, in vehicula orci scelerisque sed. Fusce a massa nisi. Curabitur sit amet suscipit nisl. Sed eget nisl laoreet, suscipit enim nec, viverra eros. Nunc imperdiet risus leo, in rutrum erat dignissim id.

Ut rhoncus vestibulum facilisis. Duis et lorem vitae ligula cursus venenatis. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nunc vitae nisi tortor. Morbi leo nulla, posuere vel lectus a, egestas posuere lacus. Fusce eleifend hendrerit bibendum. Morbi nec efficitur ex.

Mauris tempor, orci id pellentesque.

Nulla non ligula vel nisi blandit egestas vel eget leo. Praesent fringilla dapibus dignissim. Pellentesque quis quam enim. Vestibulum ultrices, leo id suscipit efficitur, odio lorem rhoncus dolor, a facilisis neque mi ut ex. Quisque tempor urna a nisi pretium, a pretium massa tristique. Nullam in aliquam diam. Maecenas at nibh gravida, ornare eros non, commodo ligula. Sed efficitur sollicitudin auctor. Quisque nec imperdiet purus, in ornare odio. Quisque odio felis, vestibulum et.