HANJUN iOS

Accessibility - VoiceOver

H4NJUN — Tue, 12 Apr 2022 18:40:19 +0900

안녕하세요.

오늘은 Accessiblity, 그중에서도 VoiceOver에 관하여 알아보겠습니다.

1. Accessibility

https://developer.apple.com/design/human-interface-guidelines/accessibility/overview/introduction/

Introduction - Accessibility - Human Interface Guidelines - Apple Developer

Accessibility People use Apple’s accessibility features, such as reduced transparency, VoiceOver, and increased text size, to personalize how they interact with their devices in ways that work for them. An accessible app supports such personalizations by

developer.apple.com

Accessibility는 우리말로 접근성이라는 뜻을 가지고 있습니다.

네이버 특수교육학 용어사전

네이버 특수교육학 용어사전에서는 접근성을 위와 같이 정의하고 있습니다.

간단히 말하자면 어떤 환경에서도 불편함 없이 서비스를 이용할 수 있는 정도를 의미합니다.

즉, 접근성이 좋은 앱은 모든 사용자에게 최선의 사용자 경험을 제공하는 것이죠.

우리는 이미 사용자로서 여러 가지 접근성 요소들을 경험하고 있습니다.

어두운 환경에서 눈의 필요를 줄여주기 위한 다크 모드, 화면을 보지 못하는 상황에서 사용자에게 알림을 주는 햅틱 등이 그 예입니다.

애플이 단지 멋있는 화면을 위해서 다크 모드를 제공하고 있던 게 아니라는 것이죠.

개발자들은 접근성을 향상시키기 위해서 다양한 요소을 적용할 수 있습니다.

기기의 설정에 따라 다른 글자크기를 적용하는 Dynamic Type, 시력이 좋지 않은 분들을 위해 화면의 콘텐츠를 읽어주는 VoiceOver 등이 존재합니다.

Dynamic Type은 UI에 많은 영향을 끼치기 때문에 적용시키기 어려운 부분이 있을 수 있지만 VoiceOver는 비교적 간단하게 적용시킬 수 있습니다.

지금부터는 VoiceOver에 대해서 알아보겠습니다.

2. VoiceOver

https://www.apple.com/accessibility/vision/

Accessibility - Vision

Apple products and services include built-in features for a range of vision needs. Find the right feature for you to make something wonderful.

www.apple.com

VoiceOver는 사용자가 화면을 볼 수 없는 상황에도 iPhone을 사용할 수 있도록 도와주는 제스처 기반의 화면 읽기 도구 입니다.

설정 -> 손쉬운 사용 -> VoiceOver에서 활성화시키거나, Siri에게 켜달라고 부탁함으로써 활성화할 수 있습니다.

처음 VoiceOver를 활성화하신 분들은 당황할 수 있는데요(제가 그랬습니다..)

앞서 말했다시피 VoiceOver는 제스처 기반의 화면 읽기 도구이기 때문에 제스처가 기존과 완전히 달라지게 됩니다.

변경된 제스처들은 여기서 확인하실 수 있습니다.

간단하게 탭과 쓸어 넘기기만 다루고 넘어가겠습니다.

화면을 한 번 터치하게 되면 터치된 영역에 존재하는 항목을 선택하고 읽어줍니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

화면을 두 번 터치하게 되면 현재 선택된 항목을 활성화합니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

화면을 좌우로 쓸어 넘기면 이전, 다음 항목을 가리키고 읽어줍니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

추가적으로 로터라는 것이 존재하는데 좀 더 아래서 알아보도록 하겠습니다.

2. VoiceOver 적용 방법

이번에는 UIKit에서 VoiceOver를 적용하는 방법에 대해서 알아보겠습니다.

1. isAccessibilityElement

먼저 해당 요소가 접근성 요소인지를 확인해야 합니다.

UIKit이 제공하는 대부분의 View들은 이 속성을 true로 가지고 있습니다.

하지만 UIImageView와 같이 기본값이 false인 View들이 존재하기 때문에 해당 View의 접근성 요소를 적용하기 위해서는 이 속성을 true로 변경해야 합니다.

이 값이 true면 VoiceOver 실행 시 해당 요소를 선택할 수 있습니다. false일 경우에는 선택이 되지 않습니다.

let label: UILabel = UILabel()
label.text = "Hi"
label.isAccessibilityElement = false // VoiceOver 실행 시 선택 안됨

2. accessibilityLabel

요소가 선택되었을 때 읽어질 문자열입니다.

label이나 button에 title을 추가한 경우에는 자동으로 해당 문자열이 accessibilityLabel이 됩니다.

let label: UILabel = UILabel()
label.text = "Hi"
label.accessibilityLabel = "안녕"

3. accessibilityValue

요소의 상태를 나타내는 문자열입니다.

TextField 또는 Slider와 같이 동적으로 변하는 상태 값을 가지고 있을 경우 해당 값을 읽어줍니다.

accessibilityLabel이 해당 요소가 어떤 요소인지를 나타내는 문자열이라면 Value는 해당 요소의 상태를 알려주는 문자열입니다.

 let slider: UISlider = UISlider()
 slider.accessibilityLabel = "크기"
 // slider는 accessibilityValue를 기본값으로 가지고 있다.

4. accessibilityHint

accessibilityLabel만으로 해당 요소가 어떤 역할을 하는지 완벽하게 설명하기 어려울 때 부가적인 설명을 위한 문자열입니다.

공식 문서에서는 Hint에 동작과 어떤 View인지를 포함하지 말라고 합니다.

~~연락처를 추가하려면 버튼을 탭 하세요~~보다는 연락처 추가처럼 간단하게 작성해야 합니다.

let slider: UISlider = UISlider()
slider.accessibilityLabel = "음량"
slider.accessibilityHint = "음악 음량 조절"

5. accessibilityTraits

요소의 특징을 나타내는 속성입니다.

Button같이 특징을 가지고 있는 View들의 경우 기본 값으로 요소의 특징에 맞는 값을 가지고 있습니다.

accessibilityTraits는 여러 개의 값을 가질 수 있습니다.

label.setTitle("add", for: .normal)
label.setImage(UIImage(systemName: "plus"), for: .normal)
label.accessibilityTraits.insert(.image)

insert()와 remove()를 통해 추가, 제거를 할 수 있습니다.

https://developer.apple.com/documentation/uikit/uiaccessibility/uiaccessibilitytraits

Apple Developer Documentation

developer.apple.com

공식 문서에서 볼 수 있듯이 accessibilityTraits는 매우 많은 값을 가지고 있습니다.

해당 요소가 어떻게 동작하는지 잘 고려해서 accessibilityTraits를 적절하게 지정해야 합니다.

여기서 꼭 고려하셨으면 좋겠는 속성이 있습니다.

바로 header 속성입니다.

아까 VoiceOver에는 로터라는 기능이 있다고 말씀드렸습니다.

https://support.apple.com/ko-kr/HT204783

iPhone, iPad 및 iPod touch의 VoiceOver 로터에 관하여

VoiceOver 로터를 사용하여 VoiceOver의 작동 방식을 변경할 수 있습니다. VoiceOver 음량 또는 말하기 속도를 변경하고 화면에서 다음 항목으로 이동하는 등의 다양한 작업을 수행할 수 있습니다.

support.apple.com

VoiceOver를 활성화시킨 상태에서 두 손가락으로 돌리면 로터가 등장합니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

이렇게 로터를 통해서 VoiceOver의 동작 방식을 변경시킬 수 있습니다.

두 손가락으로 돌려서 옵션을 설정하고 위아래 스와이프를 통해서 설정한 옵션을 사용할 수 있습니다.

한 글자씩 읽기, 단어씩 읽기 등 다양한 옵션이 있지만 저는 머리말이라는 옵션을 주목하시면 좋겠습니다.

시력이 좋지 않아 화면을 보기 어려우신 분들은 화면의 어느 위치에 어떤 요소가 위치해있는지 파악하기 어렵습니다.

따라서 화면 전체를 일일이 스와이프 하면서 원하는 요소를 찾아야 하는데요.

원하는 요소를 조금이나마 빨리 찾기 위한 방법이 바로 이 머리말입니다.

앱스토어의 예시를 보겠습니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

머리말로 옵션을 설정하면 머릿말 속성을 가진 요소로만 이동을 할 수 있게 됩니다.

원하는 요소를 찾는 시간이 훨씬 단축되는 거죠.

근데 이렇게 머리말 속성을 부여하는 값이 바로 header입니다.

CollectionView나 TableView의 HeaderView를 만든다고 해서 머리말로 설정되지 않습니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

class MyCollectionViewHeader: UICollectionReusableView {
    private lazy var label: UILabel =  {
        let label = UILabel()
        return label
    }()
 
     func configureAccessibility() {
        self.label.accessibilityTraits = .header // 헤더 설정
    }
    
    // ...
}

위와 같이 accessibilityTraits를 header로 설정하여야 머리말로서 동작합니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

오늘은 Accessibility와 VoiceOver에 대해서 알아보았습니다.

접근성 요소를 지원하고 나서 세 손가락 삼중 탭을 통해서 화면 커튼을 켠 상태로 테스트해보시기를 추천드립니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

https://www.apple.com/accessibility/

Accessibility

Every Apple product and service includes built-in accessibility features designed for you to make something wonderful.

www.apple.com

애플의 접근성 페이지를 확인하면 더 나은 접근성을 위해서 얼마나 고민하고 있는지 알 수 있습니다.

저희도 iOS 앱 개발을 하고 있는 만큼 이러한 요소들을 충분히 고려해서 앱을 만드는 것이 중요하다고 생각됩니다.

Model-View-ViewModel(MVVM)

H4NJUN — Fri, 8 Apr 2022 15:58:34 +0900

안녕하세요.

저번 시간에는 MVP 패턴을 통해서 Controller의 역할을 줄이고, UIKit과 분리되어 테스트 가능한 Presenter를 만들어보았습니다.

하지만 여전히 해결하지 못한 문제가 남아있었죠..

바로 Presenter가 View를 알고 있다는 사실입니다.

아무리 Protocol을 통해 참조를 하고 있더라도 View에 대한 Presenter의 종속성은 남아 있습니다.

이것마저 해결할 수 있는 방법이 있지 않을까요??

Presenter가 View를 모르게 하는 방법..

사실 우리는 MVC를 공부하면서 비슷한 개념을 경험해봤습니다. 감이 오시나요??

차근차근 알아보도록 하겠습니다.

1. MVC에서?

Cocoa MVC

MVC를 학습하면서 위의 그림을 모두 보셨을 겁니다.

위 그림에서 주목해서 봐야할 부분은 봐야 할 부분은 바로..

이곳입니다.

MVC를 알아볼 때 Model이 Controller를 직접 알면 안 된다라고 공부했습니다.

따라서 관찰자 패턴을 통해서 해당 문제를 해결했었습니다.

그럼 View랑 Presenter도 비슷한 방법을 사용하면 되지 않을까??

맞습니다.

그래서 등장하게 된 것이 바로 MVVM(Model-View-ViewModel)입니다.

2. MVVM

Reference - https://tech.olx.com/clean-architecture-and-mvvm-on-ios-c9d167d9f5b3

MVVM 역시 MVC의 Controller, MVP의 Presenter와 같이 Model과 View의 중간자 역할을 하는 ViewModel이 존재합니다.

하지만 ViewModel은 Controller, Presenter와 다르게 View를 전혀 알지 못합니다.

View와 ViewModel을 연결해 서로를 동기화하는 것을 Data Binding이라고 합니다.

Data Binding을 하는 방법은 여러가지(Combine, RxSwift)가 있지만, 이번에는 클로저와 didSet을 통해 간단하게 관찰 가능한 객체를 만들어보도록 하겠습니다.

3. Observable

class Observable<T> {
    
    var value: T {
        didSet {
            self.listener?(value)
        }
    }
    
    private var listener: ((T) -> Void)?
    
    init(_ value: T) {
        self.value = value
    }
    
    func bind(_ closure: @escaping (T) -> Void) {
        self.listener = closure
        closure(value)
    }
}

구조는 매우 간단합니다.

value의 값이 변경되면 bind()를 통해 전달받은 클로저를 실행시킵니다.

해당 클로저는 아마 대부분 UI관련 클로저겠죠??

간단한 앱을 통해서 살펴보겠습니다.

+ 버튼과 - 버튼을 통해 Label의 값을 변경하는 앱입니다.

- Model

해당 앱에서 Model은 Label의 표시될 값과 숫자의 증감을 위한 로직입니다.

class Amount: NSObject {

    @objc dynamic var number: Int
    
    override init() {
        self.number = 0
    }
    
    func increase() {
        self.number += 1
    }
    
    func decrease() {
        self.number -= 1
    }
}

- View

MVVM에서는 MVP와 마찬가지로 ViewController를 View로 취급합니다.

class ViewController: UIViewController {
    
    private lazy var increaseButton: UIButton = {
        let button = UIButton()
        button.setImage(UIImage(systemName: "plus"), for: .normal)
        button.addTarget(self, action: #selector(increaseButtonTouched(_sender:)), for: .touchUpInside)
        return button
    }()
    
    private lazy var decreaseButton: UIButton = {
        let button = UIButton()
        button.setImage(UIImage(systemName: "minus"), for: .normal)
        button.addTarget(self, action: #selector(decreaseButtonTouched(_sender:)), for: .touchUpInside)
        return button
    }()
    
    private lazy var amountLabel: UILabel = {
        let label = UILabel()
        label.font = label.font.withSize(32)
        return label
    }()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        self.configureUI()
    }
    
    
    func configureUI() {
        // layout 설정
    }
    
    @objc func increaseButtonTouched(_sender: UIButton) {
        //viewModel 메서드 호출
    }
    
    @objc func decreaseButtonTouched(_sender: UIButton) {
        //viewModel 메서드 호출
    }
}

아직 ViewModel을 만들지 않았으니 대략적인 뼈대만 작성하겠습니다.

비즈니스 로직은 전혀 포함하고 있지 않습니다.

- ViewModel

MVVM에서 View는 ViewModel을 알고 있습니다.

그래도 의존성을 줄여주기 위해 ViewModel Protocol을 정의하겠습니다.

ViewModel을 정의하는 방법에는 여러 가지 방법이 있습니다만

Clean Architecture and MVVM on iOS에서는 Input과 Output을 분리해 정의하고 있습니다.

Input은 ViewModel이 View로부터 전달받을 이벤트들입니다.

Output은 ViewModel이 이벤트들을 처리한 후의 결과(View과 관찰할 속성)입니다.

protocol ViewModelInput {
    func viewDidLoad()
    func didIncrease()
    func didDecrease()
}

protocol ViewModelOutput {
    var amountText: Observable<String> { get }
}

typealias ViewModel = ViewModelInput & ViewModelOutput

이번 앱에서는 위와 같이 정의할 수 있겠습니다.

ViewController의 viewDidLoad()에서 호출될 메서드, 각 버튼을 눌렀을 때 호출될 메서드들이 Input이 되겠죠.

View가 Label에 표시할 값이 Output입니다.

해당 프로토콜을 채택한 구체 타입을 만들어보겠습니다.

class DefaultViewModel: ViewModel {
    
    var amountText: Observable<String>
    
    private var amount: Amount
    private var observation: NSKeyValueObservation?
    
    init(amount: Amount) { // 의존성 주입
        self.amount = amount
        self.amountText = Observable(String(amount.number))
    }
    
    func viewDidLoad() {
        self.observation = self.amount.observe(\.number, options: .new) { object, change in
            guard let number = change.newValue else { return }
            self.amountText.value = String(number)
        }
    }
    
    func didIncrease() {
        self.amount.increase()
    }
    
    func didDecrease() {
        self.amount.decrease()
    }
}

amount를 생성자에서 초기화해도 되지만 의존성 주입을 통해서 의존성을 줄여주겠습니다.

Model인 amount의 상태변화는 KVO를 통해 관찰하겠습니다.

이제 Binding 작업만 남았습니다.

- Data Binding

ViewController를 마저 작성하겠습니다.

//ViewController내에서 작성되는 코드입니다.

private var viewModel: ViewModel?

convenience init(viewModel: ViewModel) {
    self.init(nibName: nil, bundle: nil)
    self.viewModel = viewModel
}

ViewController는 ViewModel 프로토콜을 참조하고 있습니다.

마찬가지로 ViewController를 생성할 때 viewModel을 주입받겠습니다.

//ViewController에서 작성되는 코드입니다.

func bind() {
    self.viewModel?.amountText.bind { [weak self] value in
        self?.amountLabel.text = value
    }
}

view와 ViewModel을 Binding 할 bind() 메서드입니다.

ViewModel의 amountText가 변경될 시 Label의 Text를 변경합니다.

override func viewDidLoad() {
    super.viewDidLoad()
    self.configureUI()
    self.bind()
    self.viewModel?.viewDidLoad()
}

@objc func increaseButtonTouched(_sender: UIButton) {
    self.viewModel?.didIncrease()
}

@objc func decreaseButtonTouched(_sender: UIButton) {
    self.viewModel?.didDecrease()
}

적절한 위치에서 viewModel의 함수를 호출합니다.

마지막으로 ViewController를 생성할 때 Model, ViewModel을 생성해 주입하도록 하겠습니다.

이번 앱에서는 간단히 SceneDelegate에서 처리하도록 하겠습니다.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?


    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
 
        guard let windowScene = (scene as? UIWindowScene) else { return }
        self.window = UIWindow(windowScene: windowScene)
        
        let amount = Amount() // Model
        let viewModel = DefaultViewModel(amount: amount) // ViewModel
        let viewController = ViewController(viewModel: viewModel) // ViewController
        
        self.window?.rootViewController = viewController
        self.window?.makeKeyAndVisible()
    }
    
}

간단한 앱을 통해 MVVM 패턴을 알아보았습니다.

MVVM 역시 테스트하기 좋은 구조입니다.

ViewModel이 SwiftUI 또는 UIKit과 같은 UI 관련된 코드를 전혀 포함하기 않기 때문입니다.

또한 ViewModel은 그 어떤 View도 직접 참조하지 않습니다.

이 말은 동일한 ViewModel을 다른 View에서 사용할 수 있다는 소리입니다.

View와 ViewModel은 n : 1 관계이다.

반면에 다른 패턴들에 비해 코드량이 매우 늘어나게 됩니다.

위의 앱은 매우 간단한 구조임에도 불구하고

Int -> Amount(Model) -> Observable<String>(ViewModel) -> Label(View)로의 긴 변환 과정을 거쳐야 했습니다.

결과적으로는 모두 같은 데이터임에도 불구하고 말이죠.

또한 이번에 MVVM을 공부하면서 느낀 점은 정형화된 패턴이 없다는 것이었습니다.

여러 가지 자료를 찾아봤으나 자료마다 조금씩 다르게 MVVM을 설명하고 있었습니다.

따라서 MVVM 패턴을 사용할 경우 팀원들 간의 조율을 통해 정확히 패턴을 인지하고 가야 할 것 같습니다.

오늘은 여기까지 하겠습니다.

혹시 제가 잘못 이해하고 있는 부분이 있다면 꼭 알려주세요!!

Ref

https://fitzafful.medium.com/data-binding-in-mvvm-on-ios-714eb15e3913

Data Binding in MVVM on iOS

You’ve come to realize your View Controller in your new project has become very huge…

fitzafful.medium.com

https://tech.olx.com/clean-architecture-and-mvvm-on-ios-c9d167d9f5b3

Clean Architecture and MVVM on iOS

When we develop software it is important to not only use design patterns, but also architectural patterns. There are many different…

tech.olx.com

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

iOS Architecture Patterns

Demystifying MVC, MVP, MVVM and VIPER

medium.com

https://medium.com/@dev.omartarek/mvp-vs-mvvm-in-ios-using-swift-337884d4fc6f

MVP VS MVVM in iOS using swift

Introduction:

medium.com

Model-View-Presenter(MVP)

H4NJUN — Mon, 4 Apr 2022 20:41:57 +0900

안녕하세요.

지난 시간에는 MVC에 대해서 알아보았습니다.

MVC 역시 선배 개발자 분들의 수많은 고민이 담긴 훌륭한 아키텍처였지만, 해결하지 못한 문제들이 존재했습니다.

1. Controller의 역할이 너무 커진다.(Massive View Controller..)

2. ViewController가 UIKit에 의존적이기 때문에 테스트하기 어렵다.

이러한 문제를 해결하기 위해서 고민한 결과 등장한 것이 바로 Model-View-Presenter(MVP)입니다.

1. MVP

MVP는 Controller가 UIKit과 의존적이기 때문에 테스트가 어려우니

UIKit에 독립적이면서 Controller의 역할을 하는 객체를 만드는 게 어떨까라는데서 시작합니다.

구조는 다음과 같습니다.

MVP

얼핏 봐서는 MVC와 뭐가 다르지?라고 생각하실 수 있습니다.

주의깊게 볼 부분은 바로 두 곳입니다.

우선 첫 번째로 MVP에서는 UIViewController를 Controller가 아닌 View로 취급합니다.

UIViewController를 View로 취급

그리고 두 번째로 MVC와 달리 중간자 역할을 하는 Presenter는 UIKIt에 완전히 독립적입니다.

즉, UIKit과 관련된 코드는 모두 View로 취급하는 것이죠.

이렇게 코드를 작성한다면 UI 관련된 코드와 비즈니스 로직이 완전히 분리되어 테스트하기 훨씬 용이한 구조가 되는 것이죠.

그럼 코드를 통해 직접 살펴보도록 하겠습니다.

+ 버튼을 누르면 값이 증가하고 - 버튼을 누르면 값이 감소하는 간단한 앱입니다.

Model

해당 앱에서 Model은 수량을 나타내기 위한 데이터입니다.

class Amount: NSObject {
    @objc dynamic var number: Int
    
    override init() {
        self.number = 0
    }
    
    func increase() {
        self.number += 1
    }
    
    func decrease() {
        self.number -= 1
    }
}

View

먼저 ViewController가 View로서 행할 메서드를 정의한 프로토콜을 작성해야 합니다.

이번 앱에서는 값이 변할 경우 그 값을 Label에 보여주기 위한 함수를 정의했습니다.

protocol CountView: AnyObject {
    func onValueChange(number: Int)
}

그리고 ViewController가 해당 프로토콜을 채택하도록 합니다.

변한 값을 Label에 적용시켜주도록 구현하였습니다.

extension ViewController: CountView {
    func onValueChange(number: Int) {
        self.amountLabel.text = String(number)
    }
}

Presenter

Presenter 또한 Presenter로서 필요한 메서드들을 정의한 Protocol을 작성해야 합니다.

해당 프로토콜은 위에서 정의한 View Protocol을 매개변수로 하는 생성자와 ViewController로부터 전달받은 이벤트들을 처리할 메서드들을 필요로 합니다.

이번 앱에서는 +버튼과 -버튼이 눌렸을 때 동작할 메서드들을 정의했습니다.

protocol CountViewPresenter {
    init(view: CountView)
    func viewDidLoad()
    func increaseButtonTouched()
    func decreaseButtonTouched()
}

작성한 프로토콜을 준수하는 Presenter를 만들겠습니다.

class CountPresenter: CountViewPresenter {
    private unowned var view: CountView
    
    private var amount: Amount!
    private var observation: NSKeyValueObservation?
    
    required init(view: CountView) {
        self.view = view
    }
    
    func viewDidLoad() {
        self.amount = Amount()
        self.view.onValueChange(number: 0)
        self.observation = self.amount.observe(\.number, options: .new) { object, change in
            guard let number = change.newValue else { return }
            self.view.onValueChange(number: number)
        }
    }
    
    func increaseButtonTouched() {
        self.amount.increase()
    }
    
    func decreaseButtonTouched() {
        self.amount.decrease()
    }
}

주의해야 할 점은 ViewController에서도 Presenter를 소유하고 있기 때문에 Presenter가 알고 있는 View는 순환 참조를 막기 위해서 Weak 또는 Unowned로 작성해야 합니다.

ViewController를 마저 작성해보겠습니다.

ViewController가 Presenter를 소유하도록 합니다.

이벤트가 발생하면 해당하는 Presenter의 메서드를 호출하도록 코드를 작성합니다.

class ViewController: UIViewController {
    /*
    View 선언
    */
    
    var presenter: CountViewPresenter?
    
    override func viewDidLoad() {
        super.viewDidLoad()
        self.presenter?.viewDidLoad()
    }
    
    @objc func increaseButtonTouched(_sender: UIButton) {
        self.presenter?.increaseButtonTouched()
    }
    
    @objc func decreaseButtonTouched(_sender: UIButton) {
        self.presenter?.decreaseButtonTouched()
    }
}

extension ViewController: CountView {
    func onValueChange(number: Int) {
        self.amountLabel.text = String(number)
    }
}

마지막으로 SceneDelegate와 같은 상위에서 ViewController를 생성할 때 Presenter 역시 생성해 주입하면 됩니다.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?


    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let scene = (scene as? UIWindowScene) else { return }
        
        let view = ViewController()
        let presenter = CountPresenter(view: view)
        view.presenter = presenter
        
        self.window = UIWindow(windowScene: scene)
        self.window?.rootViewController = view
        self.window?.makeKeyAndVisible()
    }
}

코드는 이곳에서 확인하실 수 있습니다.

위와 같이 코드를 작성하면 Presenter가 View를 직접 알지 않고 Protocol을 통해 알고 있기 때문에 View의 Mock을 만들기 쉬운 구조입니다.

class CountViewMock: CountView {
    var number: Int = 0
    func onValueChange(number: Int) {
        self.number = number
    }
}

테스트만을 위한 Mock 객체를 만들고 테스트를 진행할 수 있습니다.

//설명을 위해 작성된 코드입니다.
class PresenterTests: XCTestCase {
    
    private var presenter: CountPresenter!
    private var viewMock: CountViewMock!
    
    override func setUpWithError() throws {
        self.viewMock = CountViewMock()
        self.presenter = CountPresenter(view: viewMock)
        self.presenter.viewDidLoad()
    }

    override func tearDownWithError() throws {
        self.presenter = nil
        self.viewMock = nil
    }
    

    func test_increaseButton() {
        self.presenter.increaseButtonTouched()
        XCTAssertEqual(self.viewMock.number, 1, "잘못된 값입니다.")
        self.presenter.increaseButtonTouched()
        XCTAssertEqual(self.viewMock.number, 2, "잘못된 값입니다.")
    }
    
    func test_decreaseButton() {
        self.presenter.decreaseButtonTouched()
        XCTAssertEqual(self.viewMock.number, -1, "잘못된 값입니다.")
        self.presenter.decreaseButtonTouched()
        XCTAssertEqual(self.viewMock.number, -2, "잘못된 값입니다.")
    }
}

MVC에서는 테스트하기 어렵던 Controller에 작성된 코드들을 UIKit과 무관한 Presenter에 작성함으로써 훨씬 테스트하기 좋은 구조가 되었습니다.

하지만 보일러 플레이트 코드의 양이 늘어나 결과적으로 MVC에 비해서 코드 양이 어마어마하게 늘어난다는 단점이 존재합니다.

또한 Presenter 역시도 직접 View에게 화면을 그리라고 지시합니다. 즉 View와 Presenter가 1:1 관계를 가집니다.

이 말은 비슷한 UI일지라도 완전히 같지 않다면 새로운 Presenter를 필요로 하게 된다는 점입니다.

이러한 문제점은 과연 어떻게 해결할 수 있을까요??

또 다른 아키텍처를 살펴보면서 선배 개발자 분들의 고민의 흔적을 따라가 보도록 하겠습니다.

감사합니다.

Reference

https://betterprogramming.pub/implement-a-model-view-presenter-architecture-in-swift-5-dfa21bbb8e0b

Implement a Model-View-Presenter Architecture in Swift 5

Using the Realm database as a business logic layer

betterprogramming.pub

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

iOS Architecture Patterns

Demystifying MVC, MVP, MVVM and VIPER

medium.com

Model-View-Controller(MVC)

H4NJUN — Sun, 3 Apr 2022 17:55:37 +0900

안녕하세요.

오늘부터 아키텍처 패턴들에 대해서 하나씩 알아보도록 하겠습니다.

오늘은 그중에서 아마 가장 처음 접하게 될 Model-View-Controller, 즉 MVC에 대해서 살펴보겠습니다.

1. MVC

https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

Model-View-Controller

Retired Document Important: This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid. Model-View-Controller The Model-View-Controller (MVC) design pattern assigns objects in an ap

developer.apple.com

MVC는 앱을 Model, View, Controller 세개의 역할로 분리한 구조입니다.

Apple의 MVC

애플의 주장으로는 MVC를 사용하면

- more reusable(재사용성이 좋다)

- interface be better defined(인터페이스 정의가 더 쉽다)

- more easily extensible(확장성도 좋다)

- many Cocoa technologies and architectures are based on MVC(심지어 Cocoa Framework도 MVC를 기준으로 한다)

이러한 장점이 있다고 합니다.

정말 어마어마한 아키텍처 패턴이네요.

그럼 그 요소를 하나씩 알아보도록 하겠습니다.

2. Model

MVC에서의 모델은 다른 아키텍처에서 볼 수 있는 Entity와는 사뭇 느낌이 다릅니다.

데이터뿐만 아니라, 비즈니스 로직, 네트워크, 영구 저장소 등 데이터와 관련된 코드들은 모두 Model에 포함됩니다.

Model을 작성할 때 주의할 점은 Model은 여러 화면에서 재사용이 가능한 구조여야 합니다.

그러기 위해서는 View나 Controller에 의존적이어서는 안 되겠죠.

그렇다면 Model은 Controller에게 어떻게 변화된 정보를 알릴 수 있을까요?

어떻게 알릴건디..

여러 가지 방법이 있겠지만 NotificationCenter를 이용하는 방법과 Key-Value-Observing과 같은 옵저버 패턴을 사용해 해결하는 것이 대표적입니다.

Model이 상태가 변화하면 Model은 상태가 변했다는 사실을 관찰자들에게 알리는 거죠.

Model은 직접적으로 그 관찰자가 누군지는 모르지만 관찰자들은 Model의 정보가 바뀐 것을 알 수 있습니다.

3. View

iOS에서 View는 데이터를 사용자들에게 보여주는 역할뿐만 아니라 이벤트를 전달받는 역할도 하고 있습니다.

즉 사용자와 상호작용하는 영역을 담당하는 층입니다.

UIView를 상속받는 객체들은 대부분 View 영역이라고 생각하면 될 것 같습니다.

View의 경우도 재사용성이 매우 강조됩니다.

따라서 Controller를 직접 알고 있어서는 안 됩니다.

그럼 넌 또 어떻게 전달할건디;;

이러한 문제는 Target-Action이나 delegate, datasource와 같은 위임자 패턴을 통해 해결합니다.

TableView나 CollectionView를 다뤄보신 분들이라면 익숙하실 텐데요.

View는 어떤 이벤트가 발생하면 위임자에게 넘기겠다는 사실만 알고 있습니다.

상세한 구현은 위임받은 객체에 구현을 하는 것이죠.

4. Controller

Controller는 뷰와 모델 사이의 중개자 역할을 합니다.

View로부터 이벤트를 전달받아 해당 이벤트를 자신이 직접 처리해 View에게 다시 알리거나 Model의 변화가 필요한 경우 Model에게 알립니다.

Model의 변화가 발생하면 변화를 감지해 View에게 다시 그리기를 요청합니다.

따라서 Controller는 View와 Model을 모두 알고 있습니다.

지금까지 MVC에 개념을 알아보았습니다.

간단한 앱을 통해 직접 살펴보겠습니다.

+를 누르면 값이 숫자가 증가하고 -를 누르면 값이 감소하는 앱입니다.

이 경우 Model은 저 Label이 표시하기 위한 값이 됩니다.

// Model

class Amount: NSObject {
    @objc dynamic var number: Int
    
    override init() {
        self.number = 0
    }
    
    func increase() {
        self.number += 1
    }
    
    func decrease() {
        self.number -= 1
    }
}

View는 Label, + 버튼, - 버튼입니다.

class ViewController: UIViewController { // Controller
    
    private var amount: Amount?
    
    // View
    private lazy var increaseButton: UIButton = {
        let button = UIButton()
        button.setImage(UIImage(systemName: "plus"), for: .normal)
        // + 버튼 눌렀을 경우 호출될 메서드 지정
        button.addTarget(self, action: #selector(increaseButtonTouched(_sender:)), for: .touchUpInside)
        return button
    }()
    
    private lazy var decreaseButton: UIButton = {
        let button = UIButton()
        button.setImage(UIImage(systemName: "minus"), for: .normal)
        // - 버튼 눌렀을 경우 호출될 메서드 지정
        button.addTarget(self, action: #selector(decreaseButtonTouched(_sender:)), for: .touchUpInside)
        return button
    }()
    
    private lazy var amountLabel: UILabel = {
        let label = UILabel()
        label.font = label.font.withSize(32)
        label.text = String(0)
        return label
    }()
    
    private var observation: NSKeyValueObservation?
    
    override func viewDidLoad() {
        super.viewDidLoad()
        self.amount = Amount()
        //모델의 값 변화 관찰
        self.observation = self.amount?.observe(\.number, options: .new) {object, change in
            self.amountLabel.text = String(change.newValue ?? 0)
        }
    }
    
    @objc func increaseButtonTouched(_sender: UIButton) {
        self.amount?.increase()
    }
    
    @objc func decreaseButtonTouched(_sender: UIButton) {
        self.amount?.decrease()
    }

Controller에서 Button들에 addTarget을 통해 호출될 메서드를 지정하고

모델의 값을 관찰합니다.

애플의 말대로 MVC는 훌륭한 아키텍처임에는 틀림이 없습니다.

역할을 분리함으로써 View와 Model의 재사용성이 강해지고 이는 결국 유지보수에 용이합니다.

또한 UIKit 관련 객체들이 MVC를 기반으로 작성되었기 때문에 아키텍처를 구성함에도 어렵지 않습니다.

따라서 빠른 개발이 필요한 경우 적합한 아키텍처 패턴이라 생각합니다.

하지만 단점도 역시 존재합니다.

첫 째, Controller의 역할이 너무나도 많다는 점입니다.

위에서도 살펴보았듯이 Controller는 View의 위임자 역할도 해야 하고, Model의 관찰자 역할도 해야 합니다.

이렇게 한 개의 객체가 너무 많은 역할을 하면 좋지 않다는 점은 Solid원칙의 단일 책임 원칙을 통해서 알 수 있습니다.

두 번째, Controller의 테스트 코드 작성이 어렵습니다.

Controller의 작성된 코드가 굉장히 많음에도 불구하고

UIViewController의 Life Cycle과 관련된 코드들은 직접 앱을 실행시키지 않는 한 테스트가 어렵습니다.

오늘은 MVC에 대해서 알아보았습니다.

다음 시간에는 또 다른 아키텍처들을 통해 과연 MVC의 문제점을 어떻게 해결했을지 알아보겠습니다.

Property Wrapper

H4NJUN — Fri, 25 Mar 2022 23:55:50 +0900

안녕하세요.

요즘 SwiftUI에 대해서 학습을 하고 있는 와중에 @State니 @Binding이니 낯선 키워드들을 접하게 되었습니다.

그러고 보니 Combine을 사용하면서 @Published와 같은 Property Wrapper들을 사용하고 있었는데요.

오늘은 그 Property Wrapper에 대해서 알아보도록 하겠습니다.

1. Property Wrapper

https://docs.swift.org/swift-book/LanguageGuide/Properties.html#ID617

Properties — The Swift Programming Language (Swift 5.6)

Properties Properties associate values with a particular class, structure, or enumeration. Stored properties store constant and variable values as part of an instance, whereas computed properties calculate (rather than store) a value. Computed properties a

docs.swift.org

Property Wrapper를 한국말로 생각해보면 속성 포장지(?)라는 뜻을 가지고 있는데요.

저는 특정 프로퍼티에 특징을 부여한다!라는 뜻으로 이해했습니다.

@State의 경우에는 읽고 쓸 수 있는 프로퍼티라고 선언하는 것이고

@Published 같은 경우는 값을 방출할 수 있는 프로퍼티라고 말하는 것이죠.

만약 여러 프로퍼티들에서 같은 getter/setter가 반복해서 사용되는 경우

해당 코드를 Property Wrapper를 통해 정의해주게 되면 재사용성이 올라가고 프로퍼티를 정의하는 부분의 가독성이 좋아집니다.

그럼 Property Wrapper를 직접 정의하는 방법은 매우 간답합니다.

바로 @propertyWrapper 어노테이션을 구조체, 클래스, 열거형 앞에 붙여주면 됩니다.

그렇게 타입을 생성하면 wrappedValue, 즉 포장된 값을 포함하지 않다고 합니다.

TwelveOrLess 타입은 저장하려는 값과 12 중에 더 작은 값을 가지는 타입입니다.

따라서 다음과 같이 정의할 수 있겠죠.

@propertyWrapper
struct TwelveOrLess {
    private var number: Int = 0

    var wrappedValue: Int {
        get { return number }
        set { number = min(newValue, 12) }
    }
}

이렇게 정의한 Property Wrapper는 다른 타입의 프로퍼티 앞에 @TwelveOrLess를 붙여서 사용할 수 있습니다.

struct Rectangle {
    @TwelveOrLess var height: Int
    @TwelveOrLess var width: Int
}

하지만 이렇게만 정의하면 문제가 조금 있습니다.

바로 생성자의 변수의 Int 타입이 아니라 Property Wrapper타입인 것입니다.

이러한 문제는 Property Wrapper에 init(wrappedValue: Int)를 추가하므로 해결할 수 있습니다.

@propertyWrapper
struct TwelveOrLess {
    private var number: Int = 0

    var wrappedValue: Int {
        get { return number }
        set { number = min(newValue, 12) }
    }

    init(wrappedValue: Int) {
        self.wrappedValue = wrappedValue
    }
}

위와 같이 wrappedValue를 매개변수로 하는 생성자는 프로퍼티에 값이 할당된 경우 호출됩니다.

따라서 위와 같이 구조체에서 height와 width에 초기값을 주었을 때도 init(wrappedValue:)가 호출되는 것이죠.

따라서 초기값을 부여하지 않고 생성할 때도 의도한 대로 Int형을 이용해 인스턴스를 생성할 수 있습니다.

또한 Property Wrapper는 추가적인 기능을 제공할 수 있는 projectedValue라는 프로퍼티를 추가할 수 있습니다.

공식문서에서는 값의 변화 여부를 판단하는 데 사용하였습니다.

@propertyWrapper
struct TwelveOrLess {
    private var number: Int = 0
    private(set) var projectedValue: Bool = false

    var wrappedValue: Int {
        get { return number }
        set {
            if newValue > 12 {
                number = 12
                projectedValue = true
            } else {
                number = newValue
                projectedValue = false
            }
        }
    }

    init(wrappedValue: Int) {
        self.wrappedValue = wrappedValue
    }
}

위와 같이 Bool 타입의 projectedValue를 선언하고 12보다 값이 커서 값이 변경된 경우에는 projectedValue를 true로 설정했습니다.

projectedValue는 외부에서 해당 프로퍼티의 앞에 $를 붙여서 사용할 수 있습니다.

꼭 Bool 타입이 아니라 다른 타입으로도 선언이 가능하니 상황에 맞게 사용하면 될 것 같습니다.

SwiftUI - Stack

H4NJUN — Thu, 24 Mar 2022 23:31:14 +0900

안녕하세요.

오늘은 SwiftUI에서 View들을 배치하는 데 사용되는 Stack에 관해서 알아보겠습니다.

SwiftUI는 세 종류의 Stack을 제공하고 있습니다.

수직으로 뷰들을 배치하는 VStack, 수평으로 뷰들을 배치하는 HStack, 그리고 Z축으로 뷰들을 배치하는 ZStack이 있습니다.

(LazyVStack과 LazyHStack은 나중에 다루도록 하겠습니다.)

UIKit에서 StackView를 다루어봤던 분들이라면 어떤 식으로 뷰들이 배치가 되는지 상상이 되실거라 생각합니다.

지금부터 하나씩 살펴보도록 하겠습니다.

1. VStack

https://developer.apple.com/documentation/swiftui/vstack

Apple Developer Documentation

developer.apple.com

자식 뷰들을 수직으로 배치하는 뷰입니다.

struct ContentView: View {
    var body: some View {
        HStack{
            Text("One")
            Text("Two")
            Text("Three")
        }
    }
}

위와 같이 세 개의 Text를 선언하면 추가해보겠습니다.

세개의 Text가 수직으로 배치된 것을 확인할 수 있습니다.

2. HStack

https://developer.apple.com/documentation/swiftui/hstack

Apple Developer Documentation

developer.apple.com

자식 뷰들을 수평으로 배치하는 뷰입니다.

struct ContentView: View {
    var body: some View {
        HStack{
            Text("One")
            Text("Two")
            Text("Three")
        }
    }
}

VStack을 HStack으로 바꾼 결과를 확인해보겠습니다.

위와 같이 수평하게 뷰들을 배치한 것을 확인할 수 있습니다.

3. ZStack

https://developer.apple.com/documentation/swiftui/zstack

Apple Developer Documentation

developer.apple.com

자식 뷰들을 Z축으로 오버레이 하는 뷰입니다.

struct ContentView: View {
    var body: some View {
        ZStack{
            Text("One")
            Text("Two")
            Text("Three")
        }
    }
}

마찬가지로 ZStack으로 변경 후 실행해보겠습니다.

어떤 느낌인지 아시겠나요??

더 쉽게 이해하기 위해 도형을 통해 알아보도록 하겠습니다.

struct ContentView: View {
    var body: some View {
        ZStack{
            Color.red
                .frame(width: 100, height: 100)
                .offset(x: 0, y: 0)
            Color.green
                .frame(width: 100, height: 100)
                .offset(x: 10, y: 10)
            Color.blue
                .frame(width: 100, height: 100)
                .offset(x: 20, y: 20)
        }
    }
}

100 * 100 크기의 빨강, 초록, 파랑 뷰를 만들었습니다.

ZStack은 나중에 추가된 뷰일 수록 더 높은 Z좌표를 부여합니다.

따라서 가장 먼저 추가된 빨강 뷰가 가장 아래쪽에 놓이고 가장 나중에 추가된 파랑 뷰가 가장 위쪽에 놓이게 되는 것이죠.

배경이 필요한 경우나 뷰들이 오버레이 되는 경우가 필요할 때 사용할 수 있습니다.

위와 같이 Stack들을 생성하게 되면 기본적으로는 가운데 정렬입니다.

Stack을 생성할 때 alignment 옵션을 통해 정렬 방향을 정할 수 있습니다.

HStack, ZStack도 정렬 가능

VStack을 leading 정렬한 결과입니다.

또한 VStack과 HStack의 경우에는 뷰들 사이의 공간을 결정할 수 있습니다.

spacing을 100으로 설정한 결과입니다.

Ref.

https://developer.apple.com/documentation/swiftui/building-layouts-with-stack-views

Apple Developer Documentation

developer.apple.com

동시성 프로그래밍(8) OperationQueue

H4NJUN — Tue, 22 Mar 2022 00:46:29 +0900

안녕하세요.

오늘은 OperationQueue에 대해서 알아보도록 하겠습니다.

1. OperationQueue

https://developer.apple.com/documentation/foundation/operationqueue

Apple Developer Documentation

developer.apple.com

지난 시간까지 Operation에 대해서 알아보았는데요.

OperationQueue는 이름 그대로 Operation들의 실행을 제어하는 Queue입니다.

DispatchQueue를 생각하면서 OperationQueue는 어떤 속성들을 가지고 있는지 하나씩 확인해보겠습니다.

1) Serial or Concurrent?

https://developer.apple.com/documentation/foundation/operationqueue/1414982-maxconcurrentoperationcount

Apple Developer Documentation

developer.apple.com

OperationQueue는 maxConcurrentOperationCount라는 프로퍼티를 가지고 있습니다.

동시에 진행할 작업의 수를 결정하는 프로퍼티입니다.

OperationQueue를 생성하고 maxConcurrentOperationCount의 기본값을 확인하면 -1인 것을 확인할 수 있습니다.

이 값이 -1일 경우 시스템이 알아서 현재 상태에 따라 동적으로 동시 진행할 작업의 수를 결정합니다.

그렇다면 이 값을 1로 바꾼다면 Serial한 Queue를 만들 수 있겠죠?

class HJOperation: Operation {
    var number: Int
    
    init(number: Int) {
        self.number = number
    }

    override func main() {
        print("작업\(self.number) 시작")
        sleep(3)
        print("작업\(self.number) 완료")
    }
}

위와 같이 Operation 클래스를 만들고

let op1 = HJOperation(number: 1)
let op2 = HJOperation(number: 2)
let op3 = HJOperation(number: 3)

let queue = OperationQueue()

queue.addOperation(op1)
queue.addOperation(op2)
queue.addOperation(op3)

Operation 3개를 생성해 Queue에 추가해보겠습니다.

작업이 동시에 진행되는 것을 확인할 수 있습니다.

만약 maxConcurrentOperationCount를 1로 설정한다면

let op1 = HJOperation(number: 1)
let op2 = HJOperation(number: 2)
let op3 = HJOperation(number: 3)

let queue = OperationQueue()
queue.maxConcurrentOperationCount = 1

queue.addOperation(op1)
queue.addOperation(op2)
queue.addOperation(op3)

작업이 하나씩만 Serial하게 실행됩니다.

이 값을 1이 아닌 값으로 변경해 동시에 진행되기를 원하는 작업의 수를 직접 정할 수 도 있겠죠?

2) Quality of Service

https://developer.apple.com/documentation/foundation/operationqueue/1417919-qualityofservice

Apple Developer Documentation

developer.apple.com

OperationQueue도 DisaptchQueue와 마찬가지로 qualityOfService 프로퍼티를 이용하여 QoS를 설정할 수 있습니다.

OperationQueue의 QoS는 DispatchQueue의 6종류에서 .unspecified를 제외한 5개로 이루어져 있습니다.

역시 userInteractive > userInitiated > default > utility > background 순입니다.

직접 생성한 OperationQueue의 경우 기본값은 background입니다.

OperationQueue 또한 main 메서드를 통해 main Queue를 제공하는데요. 메인 큐에 경우에는 userInteractive가 기본값입니다.

let userInteractiveQueue = OperationQueue()
let backgroundQueue = OperationQueue()

userInteractiveQueue.qualityOfService = .userInteractive
backgroundQueue.qualityOfService = .background

backgroundQueue.addOperation(op1)
userInteractiveQueue.addOperation(op2)

QoS가 다른 두 개의 Queue를 생성하고 작업을 추가하면

QoS가 높은 Queue의 작업이 먼저 실행되는 것을 확인할 수 있습니다.

operationQueue뿐만이 아니라 각각의 Operation에도 QoS를 설정할 수 있습니다.

만약 Operation의 QoS가 명시되어 있을 경우 해당 QoS를 따릅니다.

Operation의 QoS는 기본값이 default입니다.

op1.qualityOfService = .userInitiated // op2의 QoS를 userInitiated로 증가

let defaultQueue = OperationQueue()
let backgroundQueue = OperationQueue()

defaultQueue.qualityOfService = .default
backgroundQueue.qualityOfService = .background

backgroundQueue.addOperation(op1)
defaultQueue.addOperation(op2)

op1의 QoS를 userInitiated로 증가시키면

backgroundQueue에 추가되었음에도 불구하고 op1이 먼저 실행되는 것을 확인할 수 있습니다.

또한 OperationQueue는 작업을 호출할 DispatchQueue를 지정할 수 underlyingQueue 프로퍼티가 있습니다.

만약 underlyingQueue가 명시된다면 최우선적으로 해당 Queue의 QoS를 적용합니다.

op1.qualityOfService = .userInitiated // op1의 QoS를 userInitiated를 증가

let defaultQueue = OperationQueue()
let backgroundQueue = OperationQueue()

defaultQueue.underlyingQueue = DispatchQueue.global(qos: .userInteractive)
// global userInteractiveQueue를 defaultQueue의 underlyingQueue로 지정

defaultQueue.qualityOfService = .default
backgroundQueue.qualityOfService = .background

backgroundQueue.addOperation(op1)
defaultQueue.addOperation(op2)

위와 같이 default QoS를 가지고 있던 Queue의 underlyingQueue를 userInteractiveQueue로 설정하면

다시 op2가 먼저 시작되는 것을 확인할 수 있습니다.

따라서 underlyingQueue의 QoS > Operation의 QoS > OperationQueue의 QoS 순으로 QoS가 정해진다고 볼 수 있습니다.

3) Operation 추가 방법

총 3가지 방법으로 Operation을 추가할 수 있습니다.

func addOperation(Operation)

앞서 했던 방식대로 Opertaion을 생성해 추가하는 방식입니다.

func addOperation([Operation], waitUntilFinished: Bool)

Operation들의 배열을 추가하는 방식입니다.

waitUntilFinished를 true로 설정했을 시 Operation들이 모두 완료될 때까지 현재 스레드를 차단합니다.

당연히 main 스레드에서의 사용은 주의해야겠습니다.

func addOperation(() -> Void)

DispatchQueue와 마찬가지로 클로저를 그대로 추가하는 것도 가능합니다.

Operation이 OpertaionQueue에 추가되면

start() 메서드를 호출할 필요 없이 스레드에 배정되면 isExecuting 프로퍼티가 true가 됩니다.

Opertaion의 isFinished 프로퍼티가 true가 되면(완료되거나, 취소되거나)

OpertaionQueue를 떠납니다.

4) waitUntilAllOperationsAreFinished()

OpertaionQueue의 존재하는 Operation이 모두 완료될 때까지 현재 스레드를 차단하는 메서드입니다.

단 현재 스레드에서는 OperationQueue에 작업 추가가 당연히 불가능하지만 다른 스레드에서는 추가가 가능합니다.

추가한 작업들도 모두 완료되어야 차단을 해제합니다.

backgroundQueue.addOperation(op1)
backgroundQueue.addOperation(op2)

backgroundQueue.waitUntilAllOperationsAreFinished()
print("complete")

backgroundQueue.addOperation(op3)
//op3는 나중에 추가된다.

addOpertaion(op3)의 경우는 op1, op2가 마무리되어야 실행됩니다.

하지만 waitUntilAllOperationsAreFinished()를 호출한 스레드와 다른 스레드에서 작업을 추가한다면

backgroundQueue.addOperation(op1)
backgroundQueue.addOperation(op2)

DispatchQueue.global().async {
    backgroundQueue.waitUntilAllOperationsAreFinished()
    print("complete")
}

backgroundQueue.addOperation(op3)

새로 추가된 작업까지 완료되어야 현재 스레드 차단을 해제합니다.

5) 일시중지 - 재개

https://developer.apple.com/documentation/foundation/operationqueue/1415909-issuspended

Apple Developer Documentation

developer.apple.com

OperationQueue는 isSuspended 프로퍼티를 가지고 있습니다.

이 값을 true로 변경한다면 현재 실행 중인 작업은 일단 계속 실행하지만 새로운 작업을 실행하지는 않습니다.

이 상태에서도 Queue에 작업 추가는 가능합니다.

이 속성을 false로 변경한다면 작업 재개가 가능합니다. 기본값은 false입니다.

오늘은 OperationQueue에 대해서 알아보았습니다.

알아본 속성 이외에도 다양한 속성이 있으니 더 공부하면서 알아보도록 하겠습니다.

Ref.

https://www.inflearn.com/course/iOS-Concurrency-GCD-Operation/dashboard

iOS Concurrency(동시성) 프로그래밍, 동기 비동기 처리 그리고 GCD/Operation - 디스패치큐와 오퍼레이션

동시성(Concurrency)프로그래밍 - iOS프로그래밍에서 필요한 동기, 비동기의 개념 및 그를 확장한 GCD 및 Operation에 관한 모든 내용을 다룹니다., - 강의 소개 | 인프런...

www.inflearn.com

UIResonder & Responder Chain

H4NJUN — Thu, 17 Mar 2022 17:58:28 +0900

안녕하세요.

오늘은 UIResponder와 Responder Chain에 대해서 알아보겠습니다.

1. UIResponder

https://developer.apple.com/documentation/uikit/uiresponder/

Apple Developer Documentation

developer.apple.com

Responder Chain을 이해하기 위해서는 먼저 UIResponder에 대해서 알아야 합니다.

UIResponder는 이벤트에 반응하고 처리하기 위한 추상 클래스입니다.

UIKit이 제공하는 대부분의 객체들이 UIResponder를 상속받고 있습니다.

UIView, UIViewController 심지어 UIApplication까지 UIResponder를 상속하고 있다!

UIResponders는 다양한 이벤트들을 처리하기 위한 메서드들을 제공하고 있습니다.

자주 사용해본 touchesBegan(_:with:)과 같은 터치 이벤트들 이외에도 모션 이벤트, 프레스 이벤트, 원격 조종 이벤트들을 위한 메서드들도 제공하고 있습니다.

2. Responder Chain

그렇다면 Responder Chain은 무엇일까요?

Responder Chain은 UIResponder들의 연결 리스트라고 생각하면 됩니다.

UIResponder는 자신이 처리하지 못한 이벤트들을 다음 UIResponder에게 전달합니다.

UIResponder는 next라는 프로퍼티를 가지고 있습니다. 자신이 처리하지 못한 이벤트를 이 next Responder에게 보내는 것이죠.

그리고 First Responder는 이 연결 리스트에서 가장 앞 쪽에 위치한, 이벤트를 가장 먼저 전달받는 UIResponder입니다.

이 Responder Chain은 뷰 계층에 따라 동적으로 관리됩니다.

최상위 뷰(z축의 가장 위에 존재하는 뷰)부터 UIApplicationDelegate까지 이벤트를 처리할 수 있는 객체를 확인합니다.

Responder Chain

처리하지 못한 이벤트는 무시합니다.

(Storyboard에서 임의로 IBAction을 지정한 후 해당 IBAction을 제거한 경우에는 Unrecognized Selector라는 에러를 띄웁니다.)

아마 많은 분들이 무의식 중에 Responder Chain을 경험해보셨을 겁니다.

바로 키보드를 내리는 과정을 통해서입니다.

위와 같이 TextField와 회색 뷰를 포함하는 ViewController가 있습니다.

TextField를 터치하게 되면 키보드가 올라옵니다.

하지만 화면에 다른 곳을 눌러도 키보드는 내려가지 않습니다.

그리고 키보드를 내려주기 위해서 ViewController에서 다음과 같은 코드를 작성하셨을 겁니다.

final class ViewController: UIViewController {

    @IBOutlet weak var textField: UITextField!

    override func viewDidLoad() {
        super.viewDidLoad()
    }
    
    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
        super.touchesBegan(touches, with: event)
        self.textField.resignFirstResponder()
    }
}

touchesBegan(_:with:) 메서드를 재정의해서 textField가 더 이상 FirstResponder가 아니게 하는 것이죠.

키보드는 Text 입력이 가능한 View가 First Responder여야 화면에 나타나기 때문입니다.

이러면 정상적으로 키보드가 내려가게 됩니다.

그런데 회색 뷰를 터치해도 키보드가 내려가는 것을 확인할 수 있습니다.

분명 ViewController에서 touchesBegan(_:with:)를 재정의했는데 말이죠.

Responder Chain 때문에 이러한 일이 발생하는 겁니다.

회색 뷰는 touchesBegan(_:with:) 메서드가 재정의되어 있지 않기 때문이죠.

만약 회색 뷰를 Custom View로 만들고 touchesBegan(_:with:) 메서드를 재정의해 아무런 동작도 하지 않게 하거나

class CustomView: UIView {

    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
        // do nothing
    }
}

또는 next Responder를 nil로 만든다면

class CustomView: UIView {

    override var next: UIResponder? {
        return nil
    }
}

회색 뷰를 눌렀을 때는 화면이 내려가지 않게 됩니다.

오늘은 UIResponder와 Responder Chain에 대해서 알아보았습니다.

1. UIResponder는 이벤트에 대해서 반응하고 처리하는 객체이고

2. 이벤트는 FirstResponder부터 처리될 수 있는지 확인하고 Responder Chain을 통해서 처리하지 못한 이벤트를 전달한다.

동시성 프로그래밍(7) Operation

H4NJUN — Tue, 15 Mar 2022 20:49:28 +0900

안녕하세요.

지난 시간까지는 GCD를 이용한 동시성 프로그래밍에 대해서 배웠습니다.

이제부터는 동시성 프로그래밍을 위한 또 다른 방법, Operation에 대해서 알아보겠습니다.

1. GCD와의 차이

GCD를 이용해 동시성 프로그래밍을 할 수 있는데 Operation은 왜 필요할까요?

Operation도 내부적으로는 GCD를 이용해 동작합니다.

하지만 Operation은 GCD가 할 수 없는 조금 더 복잡한 일을 할 수 있습니다.

우선 Operation은 데이터와 기능을 캡슐화한 클래스입니다.

따라서 작업의 재사용성이 향상됩니다.

이미지 다운로드와 같이 반복되는 작업의 경우 Operation으로 정의해놓으면 Operation을 인스턴스화 하는 것만으로 작업을 생성할 수 있는 것이죠.

또한 Operation의 경우에는 작업의 취소, 순서지정, 상태 추적이 가능합니다.

DispatchWorkItem의 경우에는 약하게 지원하던 기능들을 Operation으로 더 강력하게 지원합니다.

그럼 Operation부터 알아보도록 하겠습니다.

2. Operation

https://developer.apple.com/documentation/foundation/operation

Apple Developer Documentation

developer.apple.com

Operation은 하나의 작업에 대하여 관련된 코드와 데이터들을 나타내는 추상 클래스입니다.

추상 클래스이기 때문에 직접 사용하지 않고 Operation을 상속받은 클래스를 생성하는 것으로 원하는 작업은 만들 수 있습니다.

Operation은 Single-Shot 객체입니다.

Single-Shot 객체는 한 번만 사용이 가능한 객체를 의미합니다.

Operation의 경우에는 작업이 완료된 인스턴스를 다시 실행시킬 수 없습니다.

Operation이 제공하는 메서드를 알아보겠습니다.

- start()

이름 그대로 작업을 시작하는 메서드입니다.

이 메서드를 호출하게 되면 작업 상태를 업데이트하고 main() 메서드를 호출합니다.

위의 과정은 동기적으로 실행됩니다.

따라서 일반적으로는 이 메소드를 재정의할 필요는 없습니다.

하지만 작업이 동시적으로 실행되기를 원하는 경우에는 start() 메서드를 재정의해야 한다고 합니다.

start() 메서드를 재정의한 경우 super 키워드를 호출해서는 안됩니다.

isExecuting, isFinished, isAsynchronous 프로퍼티를 작업의 상태에 따라 변경하여야 합니다.

OperationQueue를 이용하여 작업을 실행하게 될 경우, 기본적으로 비동기적으로 동작합니다.

start()메소드를 재정의해야 하는 경우가 헷갈려서 찾아본 결과 OperationQueue에 의해서 관리되는 작업이 아닌 작업 스스로 비동기적으로 실행되기를 원할 경우 재정의한다고 합니다.

https://stackoverflow.com/questions/38546198/nsoperation-start-vs-main

NSOperation, start vs main

According to Apple document on NSOperation, we have to override main method for non-concurrent operations and start method for concurrent operations. But why?

stackoverflow.com

- main()

Operation이 수행하기를 원하는 작업을 main() 메서드를 오버라이딩하여 작성하면 됩니다.

기본적으로 아무런 일도 하지 않습니다. 따라서 super 키워드를 호출할 필요가 없습니다.

- cancel()

cancel() 메서드는 직접적으로 작업을 멈추는 메서드는 아닙니다.

cancel() 메서드는 isCancelled 프로퍼티를 true로 변경합니다.

만약 작업이 실행되지 않은 경우라면 작업을 실행시키지 않습니다.

진행 중인 작업을 중단하고 싶은 경우에는 재정의한 main() 메서드 또는 start() 메서드에 isCancelled 프로퍼티를 확인하는 구문을 넣어야 합니다.

또한 Operation은 작업의 상태 추적이 가능하기 때문에 상태를 나타내는 프로퍼티들을 가지고 있습니다.

- isReady
- isExecuting
- isCancelled
- isFinished

이름만 들어도 작업이 어떤 상태인지 알 수 있을 것 같습니다.

직접 확인해보겠습니다.

class HJOperation: Operation {
    
    override func main() {
        sleep(3)
        print("main", "isReady:",isReady, ",isExecuting:", isExecuting,",isCancelled:", isCancelled,",isFinished:", isFinished)
    }
}

main() 메서드에 상태를 나타내는 프로퍼티들을 출력하는 코드를 작성했습니다.

1. 생성 후 start()

let op = HJOperation()
print("생성 후", "isReady:",op.isReady, ",isExecuting:", op.isExecuting,",isCancelled:", op.isCancelled,",isFinished:", op.isFinished)
op.start()
print("after start()", "isReady:",op.isReady, ",isExecuting:", op.isExecuting,",isCancelled:", op.isCancelled,",isFinished:", op.isFinished)

인스턴스를 생성하고 start() 메서드를 통해 작업을 실행해보겠습니다.

인스턴스가 생성되면 isReady 프로퍼티만 true인 것을 확인할 수 있습니다.

start() 메서드를 호출하면 isExecuting 프로퍼티가 true가 되고 main()메서드를 호출합니다.

작업이 완료되면 isExecuting 프로퍼티는 false가 되고 isFinished 프로퍼티가 true가 됩니다.

2. 생성 후 start() 호출하지 않고 cancel()

let op2 = HJOperation()
op2.cancel()
print("after cancel()", "isReady:",op2.isReady, ",isExecuting:", op2.isExecuting,",isCancelled:", op2.isCancelled,",isFinished:", op2.isFinished)

인스턴스를 생성하고 작업을 실행하지 않고 바로 cancel() 메소드를 호출해보겠습니다.

isCancelled 프로퍼티가 true로 변한 것을 확인할 수 있습니다.

이 상태에서 다시 start() 메소드를 호출하여도 작업을 실행되지 않습니다.

3. start() 호출 후 진행 중인 작업 cancel()

let op3 = HJOperation()
op3.completionBlock = {
    print("start() -> cancel()", "isReady:",op3.isReady, ",isExecuting:", op3.isExecuting,",isCancelled:", op3.isCancelled,",isFinished:", op3.isFinished)
}

let queue = OperationQueue()
queue.addOperation(op3)

sleep(1) // 작업에 실행을 보장하기 위해서 1초 대기
op3.cancel()

실행 중인 Operation에 대해서 cancel() 메서드를 호출시켜보았습니다.

Operation의 경우 completionBlock 프로퍼티를 통하여 작업 간의 종속성을 부여할 수 있습니다.

또한 start() 메서드의 경우 추가적인 구현이 없을 경우 동기로 실행되기 때문에 실험을 위하여 OperationQueue를 사용하였습니다.

OperationQueue의 경우 기본적으로는 비동기로 동작합니다.

실행 중인 작업에 경우 중간에 멈추지는 않습니다. 그러나 isCancelled 프로퍼티가 true가 된 것을 확인할 수 있습니다.

cancel 된 작업이 완료된 경우 isCancelled 프로퍼티와 isFinished 프로퍼티가 모두 true입니다.

이 과정을 그림으로 표현하면 다음과 같습니다.

오늘은 Operation에 대해서 알아보았습니다.

다음 시간에는 Operation들을 관리할 수 있는 OperationQueue에 대해서 알아보겠습니다.

Ref.

https://www.inflearn.com/course/iOS-Concurrency-GCD-Operation/dashboard

iOS Concurrency(동시성) 프로그래밍, 동기 비동기 처리 그리고 GCD/Operation - 디스패치큐와 오퍼레이션

www.inflearn.com

동시성 프로그래밍(6) Race Condition(경쟁 상태) 해결 방법

H4NJUN — Wed, 9 Mar 2022 20:14:28 +0900

안녕하세요.

저번 시간에는 동시성 프로그래밍을 하면서 발생할 수 있는 문제들에 대해서 알아보았는데요.

이번 시간에는 그러한 문제들을 해결하여 Thread-Safe한 코드를 작성하는 방법을 알아보겠습니다.

TSan(Thread Sanitizer)

Xcode는 Thread Sanitizer라는 기능을 제공합니다.

Sanitizer라는 단어가 낯설어서 찾아보니 살균제, 불쾌한 부분을 제거하다라는 뜻을 가지고 있더군요.

이름처럼 Thread Sanitizer는 Thread를 사용함에 있어서 불쾌한 부분, 즉 경쟁 상태가 발생하는 부분을 찾아줍니다.

사용 방법은 매우 간단합니다.

Product -> Scheme -> Edit Scheme -> Run -> Diagnostics에서 Thread Sanitizer를 체크하면 됩니다.

이 기능을 사용하면 빌드 시간이 길어질 수 있으니 사용 후에는 다시 꺼주어야 합니다.

직접 경쟁 상태가 발생하는 코드를 통해 확인해보겠습니다.

import UIKit
    
final class ViewController: UIViewController {

    private var sharedArray = [1, 2, 3, 4, 5] // 공유 자원
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let concurrentQueue = DispatchQueue.init(label: "com.hanjun.concurrent", attributes: .concurrent)
        
        concurrentQueue.async {
            self.removeLast()
        }
        
        concurrentQueue.async {
            self.last()
        }
    }
    
    func last() {
        print("Start last()")
        print(self.sharedArray.last ?? 0)
        print("End last()")
    }
    
    func removeLast() {
        print("Start removeLast()")
        self.sharedArray.removeLast()
        print("End removeLast()")
    }
}

공유 자원인 sharedArray의 마지막 원소를 출력하는 last() 메서드와 마지막 원소를 제거하는 removeLast() 메서드가 Concurrent한 Queue에서 비동기적으로 실행되고 있습니다.
따라서 서로 다른 두 개의 스레드에서 동시에 공유자원에 접근할 수 있기 때문에 경쟁 상태가 발생할 수 있겠죠?

위의 코드를 Thread Sanitizer를 켜고 실행시키면

경쟁 상태가 나타나는 곳을 찾아 알려줍니다.

thread9와 thread3에서 동시에 접근하고 있다고 알려줍니다.

Thread Sanitizer를 사용하면 이러한 부분을 발견하고 해결할 수 있겠죠?

Thread Sanitizer를 사용한다고 항상 경쟁 상태를 발견하지는 못하는 것을 확인했습니다.

Thread Sanitizer를 맹신하기보다는 경쟁 상태를 이해하고 방지하는 것이 중요하다 생각합니다.

경쟁 상태가 발생하는 부분, 즉 Thread-Safe하지 않은 곳을 찾아내는 방법을 알아봤으니

이제 Thread-Safe한 코드를 작성하는 방법을 알아봅시다.

1. NSLock

https://developer.apple.com/documentation/foundation/nslock

Apple Developer Documentation

developer.apple.com

NSLock은 Foundation이 제공하는 멀티 스레드의 작업을 조정하기 위한 객체입니다.

lock() 메서드를 통해 Thread가 lock을 획득할 때까지 스레드를 Block 할 수 있습니다.

unlock() 메서드를 통해 lock을 해제합니다.

공유 자원에 접근할 때 lock(), 완료되면 unlock()을 호출하면

한 번에 하나의 스레드만 자원에 접근할 수 있으므로 Thread-Safe한 코드를 작성할 수 있습니다.

코드를 수정해보겠습니다.

import UIKit
    
final class ViewController: UIViewController {
    
    private let lock: NSLock = NSLock()
    private var _sharedArray = [1, 2, 3, 4, 5] // 공유 자원
    
    private(set) var sharedArray: [Int] {
        get {
            self.lock.lock()
            defer { self.lock.unlock() }
            return _sharedArray
        }
        set {
            self.lock.lock()
            self._sharedArray = newValue
            self.lock.unlock()
        }
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let concurrentQueue = DispatchQueue.init(label: "com.hanjun.concurrent", attributes: .concurrent)
        
        concurrentQueue.async {
            self.removeLast()
        }
        
        concurrentQueue.async {
            self.last()
        }
    }
    
    func last() {
        print("Start last()")
        print(self.sharedArray.last ?? 0)
        print("End last()")
    }
    
    func removeLast() {
        print("Start removeLast()")
        self.sharedArray.removeLast()
        print("End removeLast()")
    }
}

NSLock 객체를 생성하고

getter와 setter에서 공유자원에 접근할 때 lock() 메서드를 호출하고 작업을 완료하면 unlock() 메서드를 호출합니다.

하나의 스레드가 공유자원에 접근하고 있을 때 다른 스레드가 lock을 획득하지 못하기 때문에 한 번에 하나의 스레드만이 접근할 수 있습니다.

Thread-Safe하다고 볼 수 있습니다.

2. DispatchSemaphore

DispatchSemaphore 또한 NSLock과 용도로 사용할 수 있습니다.

접근 가능한 Thread의 수를 1개로 제한하는 것이죠.

import UIKit
    
final class ViewController: UIViewController {
    
    private let semaphore: DispatchSemaphore = DispatchSemaphore(value: 1)
    private var _sharedArray = [1, 2, 3, 4, 5] // 공유 자원
    
    private(set) var sharedArray: [Int] {
        get {
            self.semaphore.wait()
            defer { self.semaphore.signal() }
            return _sharedArray
        }
        set {
            self.semaphore.wait()
            self._sharedArray = newValue
            self.semaphore.signal()
        }
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let concurrentQueue = DispatchQueue.init(label: "com.hanjun.concurrent", attributes: .concurrent)
        
        concurrentQueue.async {
            self.removeLast()
        }
        
        concurrentQueue.async {
            self.last()
        }
    }
    
    func last() {
        print("Start last()")
        print(self.sharedArray.last ?? 0)
        print("End last()")
    }
    
    func removeLast() {
        print("Start removeLast()")
        self.sharedArray.removeLast()
        print("End removeLast()")
    }
}

NSLock과 DispatchSemaphore와 같이 Lock을 사용하여 공유자원에 접근을 제한하는 방법을 알아보았습니다.

그러나 이러한 방법은 교착 상태를 유발할 가능성이 있습니다.

두 개 이상의 Lock을 사용하는 경우를 생각해봅시다.

import UIKit
    
final class ViewController: UIViewController {
    
    private let lockA: NSLock = NSLock()
    private let lockB: NSLock = NSLock()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let concurrentQueue = DispatchQueue.init(label: "com.hanjun.concurrent", attributes: .concurrent)
        
        concurrentQueue.async {
            self.lockA.lock()
            self.funcA()
            self.lockB.lock()
            self.funcB()
            self.lockA.unlock()
            self.lockB.unlock()
        }
        
        concurrentQueue.async {
            self.lockB.lock()
            self.funcB()
            self.lockA.lock()
            self.funcA()
            self.lockB.unlock()
            self.lockA.unlock()
        }
    }
    
    func funcA() {
        print(#function)
    }
    
    func funcB() {
        print(#function)
    }
}

funcA()와 funcB()가 한 번에 하나의 스레드만이 접근해야 하는 임계 구역(Critical Section)이라고 할 때,

각각의 메서드를 위해 lockA, lockB가 필요합니다.

두 개의 함수를 모두 필요로 하는 작업 두 개가 존재할 때, 두 개의 작업이 서로가 서로의 lock이 해제되기를 무한정 기다리는 상황이 발생하는 것이죠.

이전 포스트에서 교착 상태를 설명하면서 봤던 상황 말이죠.

따라서 Thread-Safe 한 코드를 작성하는 또 다른 방법을 알아보겠습니다.

3. SerialQueue + Sync

SerialQueue는 한 번에 하나의 작업만을 순차적으로 실행시키는 직렬 큐입니다.

공유자원에 접근하는 작업을 동일한 SerialQueue에서만 실행시킨다면??

한 번에 한 개의 스레드만이 공유자원에 접근하겠죠?

또한 Async가 아닌 Sync로 작업을 실행하게 되면 모든 스레드에서 일관된 값을 얻을 수 있습니다.

import UIKit
    
final class ViewController: UIViewController {
    
    private let serialQueue: DispatchQueue = DispatchQueue.init(label: "com.hanjun.serial")
    private var sharedArray = [1, 2, 3, 4, 5] // 공유 자원
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let concurrentQueue = DispatchQueue.init(label: "com.hanjun.concurrent", attributes: .concurrent)
        
        concurrentQueue.async {
            self.serialQueue.sync {
                self.removeLast()
            }
        }
        
        concurrentQueue.async {
            self.serialQueue.sync {
                self.last()
            }
        }
        
        // Here
        concurrentQueue.async {
            self.serialQueue.async {
                self.removeLast()
            }
            print(self.sharedArray) //[1,2,3,4]
        }
    }
    
    func last() {
        print("Start last()")
        print(self.sharedArray.last ?? 0)
        print("End last()")
    }
    
    func removeLast() {
        print("Start removeLast()")
        self.sharedArray.removeLast()
        print("End removeLast()")
    }
}

만약 작업을 sync 하게 실행시키지 않는다면

concurrentQueue에서 실행시킨 sharedArray를 출력하는 작업이 즉시 반환되어

removeLast()가 실행되기 이전 결과인 [1,2,3,4]가 출력됩니다.

import UIKit
    
final class ViewController: UIViewController {
    
    private let serialQueue: DispatchQueue = DispatchQueue.init(label: "com.hanjun.serial")
    private var sharedArray = [1, 2, 3, 4, 5] // 공유 자원
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let concurrentQueue = DispatchQueue.init(label: "com.hanjun.concurrent", attributes: .concurrent)
        
        concurrentQueue.async {
            self.serialQueue.sync {
                self.removeLast()
            }
        }
        
        concurrentQueue.async {
            self.serialQueue.sync {
                self.last()
            }
        }
        
        // Here
        concurrentQueue.async {
            self.serialQueue.sync {
                self.removeLast()
            }
            print(self.sharedArray) //[1,2,3]
        }
    }
    
    func last() {
        print("Start last()")
        print(self.sharedArray.last ?? 0)
        print("End last()")
    }
    
    func removeLast() {
        print("Start removeLast()")
        self.sharedArray.removeLast()
        print("End removeLast()")
    }
}

하지만 sync로 작업을 진행하게 되면 작업을 보내는 스레드가 보낸 작업이 완료될 때까지 기다리기 때문에

removeLast()가 실행된 후의 결과인 [1,2,3]을 얻을 수 있습니다.

물론 현재 스레드가 메인 스레드일 경우에는 sync로 작업을 보내면 안 됩니다.

이유는 이곳에서 알아보았습니다.

4. DispatchBarrier

SerialQueue + Sync를 사용하게 되면 매우 엄격한 Thread-Safe 코드를 작성하는 방법을 알아봤습니다.

읽기 작업과 쓰기 작업 모두 한 번에 하나씩만 실행하기에 매우 안전합니다.

하지만 조금 비효율적이라는 생각이 들기도 합니다.

읽기 작업의 경우에는 동시에 실행이 되어도 공유 자원의 영향을 끼치지 않기 때문에 Thread-Safe 하기 때문입니다.

즉 Concurrent Queue를 사용하면서 특정 작업에 경우에만 Serial하게 동작시키고 싶은 거죠.

이럴 경우 사용할 수 있는 것이 Dispatch Barrier입니다.

https://developer.apple.com/documentation/dispatch/dispatch_barrier/

Apple Developer Documentation

developer.apple.com

사용 방법은 간단합니다.

DispatchQueue의 async 메서드 중 위와 같이 DispatchWorkItemFlag를 요구하는 메서드가 존재합니다.

그중 barrier 변수를 넣어주면 Dispatch Barrier를 사용할 수 있습니다.

이렇게 작업을 실행하게 되면

큐에 이미 들어있던 작업들이 모두 완료되고 나서 한 개의 스레드에서 해당 작업이 실행됩니다.

다른 스레드는 해당 작업이 완료될 때까지 Block 됩니다

코드를 통해 살펴보겠습니다.

import UIKit
    
final class ViewController: UIViewController {
    
    private var sharedArray = [1, 2, 3, 4, 5] // 공유 자원
    private let secondConcurrentQueue = DispatchQueue.init(label: "com.hanjun.secondConcurrent", attributes: .concurrent)
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let concurrentQueue = DispatchQueue.init(label: "com.hanjun.concurrent", attributes: .concurrent)
        
        concurrentQueue.async {
            self.removeLast()
        }
        
        concurrentQueue.async {
            self.last()
        }
    }   
    
    func last() {
        self.secondConcurrentQueue.sync {
            print("Start last()")
            print(self.sharedArray.last ?? 0)
            print("End last()")
        }
    }
    
    func removeLast() {
        self.secondConcurrentQueue.async(flags: .barrier) {
            print("Start removeLast()")
            self.sharedArray.removeLast()
            print("End removeLast()")
        }
    }
}

last() 메서드와 removeLast() 메서드를 확인하면 됩니다.

last() 메서드의 경우 읽기 작업이기 때문에 sync로 작업을 실행합니다.(async로 작업을 실행하지 않는 이유는 값을 즉시 반환하면 안 되고 정확한 값을 읽어야 하기 때문입니다.)

removeLast() 메서드의 경우는 쓰기 작업이기 때문에 경쟁 상황이 발생해서는 안됩니다.

따라서 barrier를 사용해 removeLast() 메서드만이 실행되도록 합니다.

위와 같이 Dispatch Barrier를 사용하면 Concurrent Queue를 사용해도 Thread-Safe 한 코드를 작성할 수 있습니다.

오늘은 Thread-Safe한 코드를 작성하는 방법을 알아보았습니다.

이제 객체를 설계할 때 항상 해당 객체가 메인 스레드가 아닌 다른 스레드에서 접근하는 경우가 있는지 고려해야 한다는 것을 알게 되었습니다.

만약 다른 스레드에서 접근해야 한다면 위의 방법들을 이용하여 Thread-Safe 한 코드를 작성할 수 있도록 해야 합니다.

Ref.

https://www.inflearn.com/course/iOS-Concurrency-GCD-Operation/dashboard

iOS Concurrency(동시성) 프로그래밍, 동기 비동기 처리 그리고 GCD/Operation - 디스패치큐와 오퍼레이션

www.inflearn.com

https://varun04tomar.medium.com/thread-safety-in-ios-to-avoid-race-conditions-read-and-write-problem-deadlock-swift-4a583e1b8a95

Thread safety in iOS to avoid race conditions/read and write problem /deadlock : Swift

Multithreading is one of the most important concept of any software or hardware

varun04tomar.medium.com

HANJUN iOS

Accessibility - VoiceOver

1. Accessibility

2. VoiceOver

2. VoiceOver 적용 방법

1. isAccessibilityElement

2. accessibilityLabel

3. accessibilityValue

4. accessibilityHint

5. accessibilityTraits

Model-View-ViewModel(MVVM)

1. MVC에서?

2. MVVM

3. Observable

- Model

- View

- ViewModel

- Data Binding

Model-View-Presenter(MVP)

1. MVP

Model

View

Presenter

Model-View-Controller(MVC)

1. MVC

2. Model

3. View

4. Controller

Property Wrapper

1. Property Wrapper

SwiftUI - Stack

1. VStack

2. HStack

3. ZStack

동시성 프로그래밍(8) OperationQueue

1. OperationQueue

1) Serial or Concurrent?

2) Quality of Service

3) Operation 추가 방법

4) waitUntilAllOperationsAreFinished()

5) 일시중지 - 재개

UIResonder & Responder Chain

1. UIResponder

2. Responder Chain

동시성 프로그래밍(7) Operation

1. GCD와의 차이

2. Operation

- start()

- main()

- cancel()

- isReady- isExecuting - isCancelled- isFinished

동시성 프로그래밍(6) Race Condition(경쟁 상태) 해결 방법

TSan(Thread Sanitizer)

1. NSLock

2. DispatchSemaphore

3. SerialQueue + Sync

4. DispatchBarrier

- isReady
- isExecuting
- isCancelled
- isFinished