• DispatchQueue.main 에서 수행되어야 하는 작업의 추상화이다.
• schedule methods는 DispatchQueue.main 에서 호출되어지며, 스케쥴링 없이 즉각적으로 수행한다.
• Main Sehcudler는 SerialDispatchQueueScheduler이다.
• UI 작업의 수행이 일반적으로 사용된다.
• observeOn 연산자에 최적화되어 있다.
  • subscribeOn 을 사용하여 메인 스레드에서 observable을 구독하도록 하려면 ConcurrentMainScheduler가 해당 목적에 더욱 최적화되어 있으므로 ConcurrentMainScheduler를 사용하도록 한다.

asyncInstance

• 항상 비동기식으로 작업을 예약하고 기본 대기열에서 예약된 호출에 대해 최적화를 수행하지 않는다.
• asyncInstance는 Event의 async 전달을 보장하지만, instance는 이미 MainThread에 있을 경우 event를 sync하게 전달한다.
• 이미 Main thread에 있을 때 async 전달을 강제해야 하는 이유는 아래와 같다.
  • 동일한 파이프라인에서 하나의 이벤트가 새로운 이벤트의 전달을 트리거하는 재귀 반응 파이프라인이 존재한다.
  • 만일 이러한 이벤트가 sync하게 발생하면 Rx contract가 깨지고 RxSwift는 첫 번째 이벤트가 완료되기 이전에 두번째 이벤트를 전달하려고 시도햇다는 경고를 내보내게 된다.
  • 이 경우, MainScheduler.asyncInstance에서 주기를 깨는 것을 관찰할 수 있다.

https://stackoverflow.com/questions/58332584/rxswift-mainscheduler-instance-vs-mainscheduler-asyncinstance

Subscribe On

• Subscription Code 가 수행되는 scheduler를 변경할 수 있도록 한다. (subscribeOn())
• Subscription Code는 subscribe() 가 실행되는 thread와 동일한 thread에서 수행된다.

Observable.create { observer in
        // Subscription Code
}
.map { ... }
.subscribe(onNext: {
        ...
})

Observe On

• Opservation code가 수행되는 scheduler를 변경할 수 있도록 한다. (observeOn())

Observable.create { observer in
    ...
}
.map { ... }
.subscribe(onNext: {
        // Observation Code
})

http://rx-marin.com/post/observeon-vs-subscribeon/

• 초기 값을 sequence의 앞에 붙인다.

Observable.from(1...5)
.startWith(0)
.debug()
.subscribe()

concat

• 두 개 이상의 sequence를 직렬화 한다.
  • 하나의 Observable이 완료될 때까지 event를 전달하고 완료 되면 그 다음 Observable의 이벤트를 연이어 전달한다.
  • 다른 Observable이 완료되면 직렬화된 Observable은 .completed된다.

let disposeBag = DisposeBag()
let subject1 = PublishSubject<Int>()
let subject2 = ReplaySubject<Int>.create(bufferSize: 1)

_ = Observable.concat(subject1, subject2)
    .debug()
    .subscribe()
    .disposed(by: disposeBag)

subject1.on(.next(1))
subject1.on(.next(2))
subject1.on(.next(3))
subject2.on(.next(10))
subject1.on(.next(4))
subject2.on(.next(20))
subject1.on(.completed)

concatMap

• Observable에서 방출한 element를 새로운 Observable를 만들며, 만들어진 Observable의 element를 방출한다.
• concat + flatMap

let sequences = [
    "key🟢": Observable.of(1, 2, 3).debug("🟢"),
    "key🔴": Observable.of(10, 20, 30).debug("🔴")
]

_ = Observable.of("key🟢", "key🔴")
    .concatMap { sequences[$0] ?? .empty() }
    .debug("concatMap")
    .subscribe()

Merge

merge

• 같은 타입의 Event를 방출하는 Observable 을 합성한다.

let disposeBag = DisposeBag()
let subject1 = PublishSubject<String>()
let subject2 = PublishSubject<String>()

Observable.merge(
    subject1.debug("🟢"),
    subject2.debug("🔴")
)
    .debug("merge")
    .subscribe()
    .disposed(by: disposeBag)

subject1.on(.next("1"))
subject2.on(.next("A"))
subject1.on(.next("2"))
subject1.on(.next("3"))
subject2.on(.next("B"))
subject1.on(.completed)
subject2.on(.next("After completed"))

Combine

combineLatest

• Inner sequence의 최종값을 받아 방출하는 sequence를 만든다.

let disposeBag = DisposeBag()
let subject1 = PublishSubject<String>()
let subject2 = PublishSubject<String>()

Observable.combineLatest(
    subject1.debug("🟢"),
    subject2.debug("🔴")
) { (element1, element2) -> String in
    "🟢\(element1)  🔴\(element2)"
}
.debug("combineLatest")
.subscribe()
.disposed(by: disposeBag)

subject1.on(.next("1"))
subject2.on(.next("A"))
subject1.on(.next("2"))
subject1.on(.next("3"))
subject2.on(.next("B"))
subject1.on(.completed)
subject2.on(.next("After completed"))

zip

let disposeBag = DisposeBag()
let subject1 = PublishSubject<String>()
let subject2 = PublishSubject<String>()

Observable.zip(
    subject1.debug("🟢"),
    subject2.debug("🔴")
) { (element1, element2) -> String in
    "🟢\(element1)  🔴\(element2)"
}
.debug("combineLatest")
.subscribe()
.disposed(by: disposeBag)

subject1.on(.next("1"))
subject2.on(.next("A"))
subject1.on(.next("2"))
subject1.on(.next("3"))
subject2.on(.next("B"))
subject1.on(.completed)
subject2.on(.next("After completed"))

Trigger

withLatestFrom

• input Observable의 event가 방출된 이후에 기존 Observable의 새로운 element가 방출될 경우, 기존 Observable element와 input Observable의 element를 결합하여 방출한다.

let disposeBag = DisposeBag()
let subject1 = PublishSubject<String>()
let subject2 = PublishSubject<String>()

subject1.withLatestFrom(subject2) {
    $0 + " " + $1
}
.debug("withLatestFrom")
.subscribe()
.disposed(by: disposeBag)

subject1.on(.next("1"))
subject1.on(.next("2"))
subject2.on(.next("A"))
subject1.on(.next("3"))
subject1.on(.next("4"))
subject2.on(.next("B"))
subject2.on(.next("C"))
subject1.on(.next("5"))
subject1.on(.completed)
subject2.on(.next("After completed"))

amb

• 가장 먼저 Event가 발생한 sequence를 따르도록 한다.

let scheduler = MainScheduler.instance
let sequence1 = Observable<Int>.interval(
    .milliseconds(10),
    scheduler: scheduler
).take(5)
.map { "🟢 \($0)" }
let sequence2 = Observable<Int>.interval(
    .milliseconds(5),
    scheduler: scheduler
).take(5)
.map { "🔴 \($0)" }
let sequence3 = Observable<Int>.interval(
    .milliseconds(15),
    scheduler: scheduler
).take(5)
.map { "🟡 \($0)" }

Observable.amb([sequence1, sequence2, sequence3])
    .debug("amb")
    .subscribe()

switchLatest

• 가장 최신의 Observable이 방출하는 Event를 구독자에게 전달한다.

let disposeBag = DisposeBag()
struct Student {
    let name: String
    let scoreSubject: BehaviorSubject<Int>
}

let student🟢 = Student(
    name: "🟢",
    scoreSubject: BehaviorSubject<Int>(value: 1)
)
let student🔴 = Student(
    name: "🔴",
    scoreSubject: BehaviorSubject<Int>(value: 10)
)
let studentSubject = PublishSubject<Observable<Int>>()

studentSubject.switchLatest()
    .debug("switchLatest")
    .subscribe()
    .disposed(by: disposeBag)

studentSubject.on(.next(student🟢.scoreSubject))
student🟢.scoreSubject.on(.next(2))
studentSubject.on(.next(student🔴.scoreSubject))
student🟢.scoreSubject.on(.next(3))
student🔴.scoreSubject.on(.next(20))
student🟢.scoreSubject.on(.next(4))
student🔴.scoreSubject.on(.next(30))

Element

reduce

• Observable이 완료되었을 경우, 가공되어진 값을 방출한다.

Observable.from(1...10)
.reduce(0, accumulator: +)
.debug("reduce")
.subscribe()

scan

• 가공되어진 값을 지속적으로 방출한다.

Observable.from(1...10)
.scan(0, accumulator: +)
.debug("scan")
.subscribe()

toArray

• Sequence의 element를 array의 element로 변환한다.

Observable.of(1, 2, 3, 4, 5)
.toArray()
.subscribe {
    print("🟢", $0)
}

map

Observable.from(1...5)
.map { $0 * 10 }
.subscribe {
    print("🟢", $0)
}

enumerated

• 방출된 element의 index와 value를 포함하는 tuple을 방출하도록 한다.

Observable.from(1...5)
.enumerated()
.subscribe {
    print("🟢", $0)
}

Transforming Observables

• 🌟 Upstream에서 .error가 발생한다면, 생성된 Observable은 dispose 된다.

flatMap

• Observable에서 방출한 element를 새로운 Observable를 만들며, 만들어진 Observable의 element를 방출한다.

struct Student {
    let name: String
    let scoreSubject: BehaviorSubject<Int>
}

let student🟢 = Student(
    name: "🟢",
    scoreSubject: BehaviorSubject<Int>(value: 80)
)
let student🔴 = Student(
    name: "🔴",
    scoreSubject: BehaviorSubject<Int>(value: 90)
)
let studentSubject = PublishSubject<Student>()

studentSubject.flatMap { $0.scoreSubject }
    .debug()
    .subscribe()
    .disposed(by: disposeBag)

studentSubject.onNext(student🟢) // 80

student🟢.scoreSubject.onNext(85) // 85

studentSubject.onNext(student🔴) // 90

student🟢.scoreSubject.onNext(95) // 95

student🔴.scoreSubject.onNext(100)  // 100

flatMapFirst

• Observable에서 방출한 element를 새로운 Observable를 만들며, 만들어진 Observable의 element를 방출한다.
• 이전 observable이 완료되어야지만 다음 observable의 element를 받을 수 있다.

let student🟢 = Student(
    name: "🟢",
    scoreSubject: BehaviorSubject<Int>(value: 80)
)
let student🔴 = Student(
    name: "🔴",
    scoreSubject: BehaviorSubject<Int>(value: 90)
)
let studentSubject = PublishSubject<Student>()

studentSubject.flatMapFirst { $0.scoreSubject.debug($0.name) }
.debug("flatMapFirst")
.subscribe()
.disposed(by: disposeBag)

studentSubject.onNext(student🟢) // 80

student🟢.scoreSubject.onNext(85) // 85

studentSubject.onNext(student🔴) // 🌟 이전 observable(`student🟢`)이 완료되어야지만 다음 observable(student🔴)의 것을 방출한다.
student🔴.scoreSubject.onNext(100)

student🟢.scoreSubject.onNext(95) // 95

student🟢.scoreSubject.onCompleted()
studentSubject.onNext(student🔴) // 100

student🔴.scoreSubject.onNext(70)  // 70

flatMapLatest

• Observable에서 방출한 element를 새로운 Observable를 만들며, 만들어진 Observable의 element를 방출한다.
• 새로이 발행된 element가 전달되면, 이전 Observable은 dispose하고 새로운 Observable을 만들고 element를 방출한다.
  • 이전 observable이 dipose된다. 다음 observable의 값만 방출한다.

let student🟢 = Student(
    name: "🟢",
    scoreSubject: BehaviorSubject<Int>(value: 80)
)
let student🔴 = Student(
    name: "🔴",
    scoreSubject: BehaviorSubject<Int>(value: 90)
)
let studentSubject = PublishSubject<Student>()

studentSubject.flatMapLatest { $0.scoreSubject.debug($0.name) }
    .debug("flatMapLatest")
    .subscribe()
    .disposed(by: disposeBag)

studentSubject.onNext(student🟢) // 80

student🟢.scoreSubject.onNext(85) // 85

studentSubject.onNext(student🔴) // 90, 🌟 이전 observable(`student🟢`)이 dipose된다.

student🟢.scoreSubject.onNext(95) // 마지막 observable인 `student🔴`의 값만 방출된다.

student🔴.scoreSubject.onNext(100)  // 100

Observing Events

materialize

• Observable<Int> → Observable<Event<Value>>

dematerialize

• Observable<Event<Value>> → Observable<Int>

let disposeBag = DisposeBag()
struct Student {
    let name: String
    let scoreSubject: BehaviorSubject<Int>
}

let student🟢 = Student(
    name: "🟢",
    scoreSubject: BehaviorSubject<Int>(value: 1)
)
let student🔴 = Student(
    name: "🔴",
    scoreSubject: BehaviorSubject<Int>(value: 10)
)
let studentSubject = PublishSubject<Student>()

let materialized = studentSubject
    .flatMapLatest {
        $0.scoreSubject.materialize().debug($0.name)
    }
materialized
    .debug("materialized")
    .subscribe()
    .disposed(by: disposeBag)

materialized
    .dematerialize()
    .debug("dematerialized")
    .subscribe()
    .disposed(by: disposeBag)

studentSubject.on(.next(student🟢))
student🟢.scoreSubject.on(.next(2))
student🟢.scoreSubject.on(.error(CustomError.error))
studentSubject.on(.next(student🔴))
student🟢.scoreSubject.on(.next(3))
student🔴.scoreSubject.on(.next(20))

ignoreElements

• Event 중, .next(value)인 element들을 무시하고, .error 혹은 .completed만 허용한다.

let disposeBag = DisposeBag()
let subject = PublishSubject<String>()
subject
    .ignoreElements()
    .subscribe {
        print("🟢", $0)
    }.disposed(by: disposeBag)

subject.on(.next("1"))
subject.on(.next("2"))
subject.on(.next("3"))
subject.on(.error(CustomError.error))
subject.on(.next("After error"))

elementAt

• input번째 element들만 허용하도록 한다.

Observable.from(1...5)
.elementAt(2)
.subscribe {
    print("🟢", $0)
}

filter

• input의 요구사항에 대한 element들만 허용하도록 한다.

Observable.from(1...5)
.filter { $0 % 2 == 0 }
.subscribe {
    print("🟢", $0)
}

Skipping

skip

• 0..<n 범위의 element를 skip하도록 한다.

Observable.from(1...5)
.skip(2)
.subscribe {
    print("🟢", $0)
}

skipWhile

• input의 요구사항이 true인 동안에는 element를 skip한다.
• false가 된 이후로는 element를 skip하지 않는다.

Observable.from(1...5)
.skipWhile { $0 < 3 }
.subscribe {
    print("🟢", $0)
}

skipUntil

• 다른 observable이 event를 방출하기 전까지, element를 skip한다.

let disposeBag = DisposeBag()

let subject = PublishSubject<String>()
let trigger = PublishSubject<Int>()

subject
    .skipUntil(trigger)
    .subscribe(onNext: {
        print($0)
    })
    .disposed(by: disposeBag)

subject.on(.next("A"))
subject.on(.next("B"))

trigger.on(.next(0))

subject.on(.next("C"))
trigger.on(.next(1))

Taking

take

• 0..<n까지의 element를 취하도록 한다.

Observable.from(1...5)
.take(2)
.subscribe {
    print("🟢", $0)
}

takeWhile

• input의 요구사항이 true인 동안에는 element를 취하도록 한다.
• false가 된 이후로는 element를 취하지 않는다.

Observable.from(1...5)
.takeWhile { $0 < 3 }
.subscribe {
    print("🟢", $0)
}

takeUntil

• 다른 observable이 event를 방출하기 전까지, element를 취한다.

let disposeBag = DisposeBag()

let subject = PublishSubject<String>()
let trigger = PublishSubject<Int>()

subject
    .takeUntil(trigger)
    .subscribe(onNext: {
        print($0)
    })
    .disposed(by: disposeBag)

subject.on(.next("A"))
subject.on(.next("B"))

trigger.on(.next(0))

subject.on(.next("C"))
trigger.on(.next(1))

Distinct

distinctUntilChanged

• input의 요구사항에 따라, 중복해서 이어지는 element를 방출하지 않는다.

Observable.of(1, 1, 2, 3, 4, 4, 5)
.enumerated()
.distinctUntilChanged { $0.element == $1.element }
.subscribe {
    print("🟢", $0)
}

• Event를 방출하면 sequence가 종료된다.
  • element가 방출되면, .completed가 자동으로 방출된다.
  • 즉, dispose 된다.

Single

• .success(value) 혹은 .error 이벤트만 방출할 수 있다.

Single<Void>.create { single in

    single(.success(Void()))
    single(.error(CustomError.error))
//      single(.completed) ❌
    return Disposables.create()
}
.debug()
.subscribe()

Completable

• .completed 혹은 .error만 방출하며, 값을 방출할 수 없다.

Completable.create { completable in

//      completable(.success) ❌
    completable(.error(CustomError.error))
    completable(.completed)

    return Disposables.create()
}
.debug()
.subscribe()
}

Maybe

• success(value) 혹은 .completed 혹은 .error 를 방출한다.

Maybe<Void>.create { maybe in

    maybe(.success(Void()))
    maybe(.error(CustomError.error))
    maybe(.completed)

    return Disposables.create()
}
.debug()
.subscribe()

RxCocoa Traits

Driver

• .error를 방출하지 않는다.
• Observe가 Main scheduler에서 일어난다.
• Side Effect를 공유한다. (.share(replay: 1, scope: .whileConnected))

typealias Driver<Element> = SharedSequence<DriverSharingStrategy, Element>

• 의도된 UseCase는 어플리케이션을 Drive하는 시퀀스를 모델링한다.
  • CoreData 모델로부터 UI를 drive한다.
  • 다른 UI 요소(binding)의 값을 사용하여 UI를 drive한다.

[AS-IS]
fetchResult(query)
   .observeOn(MainScheduler.instance)
   .catchErrorJustReturn([])
   .share(replay: 1)
[TO-BE]
fetchResult(query)
   .asDriver(onErrorJustReturn: [])

func fetchAutoCompleteItems(_ query: String?) -> Observable<[String]> {
    return .empty()
}

let resultTextField = UITextField()
let queryTextField = UITextField()

//  let results = queryTextField.rx.text
//      .throttle(.milliseconds(300), scheduler: MainScheduler.instance)
//      .flatMapLatest { query in
//          fetchAutoCompleteItems(query)
//      }
//
//  let results = queryTextField.rx.text
//      .throttle(.milliseconds(300), scheduler: MainScheduler.instance)
//      .flatMapLatest { query in
//          fetchAutoCompleteItems(query)
//              .observeOn(MainScheduler.instance)
//              .catchErrorJustReturn([])
//      }
//      .share(replay: 1)

let results = queryTextField.rx.text
    .throttle(.milliseconds(300), scheduler: MainScheduler.instance)
    .flatMapLatest { query in
        fetchAutoCompleteItems(query)
    }
    .asDriver(onErrorJustReturn: [])

results.map { "\($0.count)" }
    .drive(resultTextField.rx.text)
    .disposed(by: disposeBag)

ControlProperty / ControlEvent

ControlProperty

• UI Element의 property를 나타내기 위한 Trait이다.
• 실패하지 않는다.
• share(replay: 1) 처럼 행위를 한다.
  • Stateful하다.
  • Subscription(즉, subscribe 호출) 시 마지막 요소가 생성된 경우 즉시 재생된다.
  • Subscriber에게 구독 즉시 초치값을 전송한다.
• base가 deallocated될 때 complete된다.
• Main scheduler에서 subscribe되는 것이 보장된다. (subscribeOn(ConcurrentMainScheduler.instance))
  • MainScheduler.instance 에서 event가 전달된다.

extension Reactive where Base: UISearchBar {

    var value: ControlProperty<String?> {
        let source = Observable<String?>.deferred { [weak base] () -> Observable<String?> in
            guard let base = base else { return .empty() }
            let text = base.text
            return base.rx.delegate
                .methodInvoked(#selector(UISearchBarDelegate.searchBar(_:textDidChange:)))
                .map { return $0[1] as? String }
                .startWith(text)
        }
        let bindingObserver = Binder(self.base) { (searchBar, text: String?) in
            searchBar.text = text
        }
        return ControlProperty(values: source, valueSink: bindingObserver)
    }

}

extension Reactive where Base: UISegmentedControl {

    var selectedSegmentIndex: ControlProperty<Int> {
        base.rx.controlProperty(
            editingEvents: [.allEditingEvents, .valueChanged],
            getter: {
                $0.selectedSegmentIndex
            },
            setter: {
                $0.selectedSegmentIndex = $1
            }
        )
    }

}

ControlEvent

• 절대 실패하지 않는다.
• Subscriber에게 초긱밧을 전송하지 않는다.
• base가 deallocated될 때 complete된다.
• Main scheduler에서 subscribe되는 것이 보장된다. (subscribeOn(ConcurrentMainScheduler.instance))
  • MainScheduler.instance 에서 event가 전달된다.

extension Reactive where Base: UICollectionView {

    var itemSelected: ControlEvent<IndexPath> {
        let source = delegate.methodInvoked(#selector(UICollectionViewDelegate.collectionView(_:didSelectItemAt:)))
            .map { a in
                return a[1] as! IndexPath
            }

        return ControlEvent(events: source)
    }
}

• Observable이자 Observer이다.
• .next(value)를 받고, 수신할 때마다 Subscriber에게 방출한다.
• Sequence가 종료된 Subject를 subscription할 경우, 마지막 Event(.error 혹은 .completed) 를 방출한다.
• Sequence가 종료된 Subject에 대하여 dispose를 호출하면 오류가 출력된다.

Relay와의 차이점

• Relay는 complete나 error를 받지 않는다.
• Relay는 observable이 종료되어도, relay 내의 subject 종료되지 않는다.
  • 따라서, observable의 종료가 절대적으로 보장되지 않는다면, relay.bind 하는 것은 바람직하지 않다.

PublishSubject

• 초기값이 존재하지 않으며, 새로운 값만을 Subscriber에게 방출한다.

let disposeBag = DisposeBag()
let subject = PublishSubject<String>()
subject.on(.next("Before subscribed"))

// Subscription 1
subject.subscribe {
    print("🟢", $0)
}

subject.on(.next("1"))
subject.on(.next("2"))

// Subscription 2
subject.subscribe {
    print("🔴", $0)
}

subject.on(.next("3"))
subject.on(.error(CustomError.error))
subject.on(.next("After error"))

// Subscription 3
subject.subscribe {
    print("🟡", $0)
}.disposed(by: disposeBag)

subject.on(.next("4"))

BehaviorSubject

• 하나의 초기값을 갖으며, 새로운 Subscriber에게 초기값 또는 최신 값을 방출한다.

let disposeBag = DisposeBag()
let subject = BehaviorSubject<String>(value: "Initial value")
subject.on(.next("Before subscribed"))

// Subscription 1
subject.subscribe {
    print("🟢", $0)
}

subject.on(.next("1"))
subject.on(.next("2"))

// Subscription 2
subject.subscribe {
    print("🔴", $0)
}

subject.on(.next("3"))
subject.on(.error(CustomError.error))
subject.on(.next("After error"))

// Subscription 3
subject.subscribe {
    print("🟡", $0)
}.disposed(by: disposeBag)

subject.on(.next("4"))

ReplaySubject

• 버퍼 사이즈 만큼의 값들을 유지하며, 새로운 Subscriber에게 버퍼 사이즈만큼 값을 방출한다.
• 버퍼는 메모리에 할당되어져 있기 때문에, 이미지와 같이 큰 용량의 것을 버퍼로 갖지 않도록 한다.
• .error 가 발생하여도 우선 버퍼에 있는 값들은 전달된다.

let disposeBag = DisposeBag()

let subject = ReplaySubject<String>.create(bufferSize: 2)
subject.on(.next("Before subscribed"))

// Subscription 1
subject.subscribe {
    print("🟢", $0)
}

subject.on(.next("1"))
subject.on(.next("2"))
subject.on(.next("3"))

// Subscription 2
subject.subscribe {
    print("🔴", $0)
}

subject.on(.next("4"))
subject.on(.error(CustomError.error))
subject.on(.next("After error"))


// Subscription 3
subject.subscribe {
    print("🟡", $0)
}.disposed(by: disposeBag)

subject.on(.next("5"))

AsyncSubject

• .comleted되어야만 값이 나온다.
• .completed 이전의 event에 대해서는 어떠한 것도 방출하지 않는다.
  • subscribe하여도 마찬가지로 .comleted 되기 전 까지는 아무런 값을 방출하지 않는다.
• 종료 이벤트를 받으면 .next(lastElement) + .completed 를 방출한다.
• 종료된 이후에 subscribe할 경우, .next(lastElement) + .completed 를 받게 된다.
• 만약 값이 없이 그냥 .completed된 경우는 값 없이 그냥 completed만 받게 되며, error의 경우에는 .error를 받게 된다.

let subject = AsyncSubject<Int>()
subject.onNext(0)
subject.onNext(1)

subject.debug("🟢")
    .subscribe()
    .disposed(by: disposeBag)

subject.onNext(2)

subject.onCompleted()

subject.onNext(3)

subject.debug("🔴")
    .subscribe()
    .disposed(by: disposeBag)

• 모든 Observable sequence은 단지 sequence이다
• Sequence는 0개 혹은 더 많은 element를 갖을 수 있다.
• error 혹은 completed 이벤트를 받을 때, sequence는 더이상 element를 생산해낼 수 없다.

enum _Event<Element> {

    case next(Element)
    case error(Swift.Error)
    case completed

}

protocol _ObserverType {

    associatedtype Element
    func on(_ event: Event<Element>)

}

protocol _ObservableType {

    associatedtype Element

    func subscribe<Observer: ObserverType>(
        _ observer: Observer
    ) -> Disposable where Observer.Element == Element
}

class _Observable<Element>: ObservableType {

    func subscribe<Observer>(
        _ observer: Observer
    ) -> Disposable
    where Observer : ObserverType, Element == Observer.Element {
        fatalError()
    }

}

Creating

• Observable은 sequence의 생성 방법과 element 요소 생성에 사용되는 parameter를 정의할 뿐이다.
• subscribe 메서드가 호출되어야 sequence가 시작된다.

func syncObservable<E>(_ element: E) -> Observable<E> {
    return Observable.create { observer in
        observer.on(.next(element))
        observer.on(.completed)
        return Disposables.create()
    }
}

func asyncObservable(_ interval: DispatchTimeInterval) -> Observable<Int> {
    return Observable.create { observer in
        print("Subscribed")
        let timer = DispatchSource.makeTimerSource(queue: DispatchQueue.global())
        timer.schedule(deadline: DispatchTime.now() + interval, repeating: interval)

        let cancel = Disposables.create {
            print("Disposed")
            timer.cancel()
        }

        var next = 0
        timer.setEventHandler {
            if cancel.isDisposed {
                return
            }
            observer.on(.next(next))
            next += 1
        }
        timer.resume()

        return cancel
    }
}

empty

• element를 하나도 갖지 않는 Observable을 생성한다.
• completed 이벤트만 방출한다.
• 즉시 종료할 수 있는 Observable 반환하고자 할 때 시용한다.

Observable<Void>.empty()
.subscribe(
    onNext: { print("Element :", $0) },
    onCompleted: { print("Completed") }
)

never

• completed 이벤트마저 방출되지 않는, 종료되지 않는 Observable을 반환한다.

Observable<Void>.never()
.subscribe(
    onNext: { print("Element : ", $0) },
    onCompleted: { print("Completed") }
)

deferred

• “연기하다”
• 실제 Observable이 만들어지는 시점을 미룬다.
• Observable을 만들어내는 factory closure를 인자로 받는다.
• 실제로 구독이 일어나는 시점에서야 Observable을 만들어 낸다.

 static func _deferred(_ observableFactory: @escaping () throws -> Observable<Element>)

var flag = false
let deferred = Observable<Int>.deferred {
    flag.toggle()
    return flag ? Observable.from([1, 2, 3]) : Observable.from([4, 5, 6])
}

deferred
    .debug()
    .subscribe()
    .disposed(by: disposeBag)

deferred
    .debug()
    .subscribe()
    .disposed(by: disposeBag)

Disposing

• dispose를 직접 호출하는 것은 bad code smell이 나기 때문에 지양하도록 한다.
  • DisposeBag, takeUntil과 같은 메커니즘을 이용하여 subscription을 dispose하는 것이 더 좋은 방법이다.
• dispose가 호출되면, 해당 seqeunce는 더이상 작동하지 않는다.
• 만일 dispose() 혹은 DisposeBag에 disposable을 추가하는 등의 행위를 하지 않는다면? Observable이 완료되지 않으면 메모리 누수가 날 것이다.

public protocol _Disposable {

    func dispose()
}

Dispose Bags

• DisposeBag이 deallocate될 때, 추가되어져있던 Disposable들의 dispose를 호출한다.
  • dispose 메서드를 갖지 않으며, 즉 명시적인 호출을 허용하지 않는다.
  • 바로 정리가 필요할 경우 새롭게 생성한다.

    self.disposeBag = DisposeBag()

Hot vs Cold Observable

Hot

• 생성과 동시에 이벤트를 방출하기 시작한다.
  • Subscribe 되는 시점과 상관없이 Observer들에게 이벤트를 중간부터 전송한다.
  • 생성과 동시에 리소스를 소모한다.
• 여러 Observer가 하나의 Observable을 공유할 수 있다.
• ConnectableObservable 로 불리우기도 한다.
• e.g. .connect()

Cold

• Observer가 Subscribe하는 시점부터 이벤트를 생성하여 방출한다.
  • Subscribe되기 전에는 리소스를 소모하지 않는다.
• Observer마다 별도의 Observable 인스턴스를 갖는다.

• 함수와 데이터를 클래스로 배치하는 방법과 이들 클래스들을 서로 결합하는 방법을 설명한다.

• 중간 수준 의 구조를 아래와 같이 만들기 위한 목적을 지닌다.

  • 변경에 유연한
  • 이해하기 쉬운
  • 다양하게 쓰일 수 있는 컴포넌트의 기반이 되는

🤔 코드수준 , 중간수준 , 고수준 이란 무엇인가? 코드수준 : 실제 소스 코드

설계 원칙(SOLID)이 중간 수준의 소프트웨어 구조를 형성하는데 작용한다.

중간수준 : 모듈 수준, (컴포넌트 원칙)

고수준 : 아키텍처

🤔 클래스, 모듈의 개념적 차이는?

• 동일한 개념을 뜻한다.
  • 클래스 : 단순히 함수와 데이터를 결합한 집합 (62p)
  • 모듈 : 단순히 함수와 데이터로 응집된 집합 (67p)

SRP: 단일 책임 원칙

오해

• 모듈은 단 하나의 일만 해야한다. ❌
• 함수는 단 하나의 일만 해야한다. ✅
  • 이 원칙은 SOLID 원칙에 속하지 않는다.

정의

"A class should have only one reason to change"

• SRP에서는 "변경의 이유(reason to change)"가 될 책임(responsibility)을 규정한다.
• "변경의 이유"란 바로 Actor(변경을 요청하는 집단, 사용자와 이해관계자)를 지칭한다.
• 따라서, 아래와 같이 기술될 수 있다.

하나의 클래스은 오직 하나의 Actor에 대해서만 책임을 갖는다.

• 단일 Actor를 책임지는 코드는 응집성(Cohesion)으로 묶인다.
  • 서로 다른 Actor가 의존하는 코드가 있다면, 코드를 분리하도록 한다.

OCP: 개방-폐쇄 원칙

정의

"You should be able to extend a classes behavior, without modifying it."

클래스의 행위는 확장할 수 있어야 하지만, 이때 개체를 변경해서는 안 된다.

• Open for Extension, 확장에는 열려있어야 하지만
• Closed for Modification, 변경에는 닫혀있어야 한다.

변경을 최소화하려면?

• 서로 다른 목적으로 변경되는 요소를 적절하게 분리한다. (SRP, 단일 책임 원칙)
  • 목적 : 변경의 이유, Actor의 요구사항
  • 요소 : 클래스의 내용
• 변경되는 요소 사이의 의존성을 체계화한다. (DIP, 의존성 역전 원칙)

Best Practice

• 변경을 최소화하기 위하여 책임을 분리(SRP)하고 행위가 확장될 때 변경이 발생하지 않도록(OCP) 처리 과정을 클래스 단위로 분할하고, 클래스는 컴포넌트 단위로 분리한다.
  • ﹦ (이중선) : 컴포넌트 단위
    • 화살표와 오직 한 방향으로만 교차한다. (컴포넌트 관계는 단방향으로만 이루어진다.)
  • → (열린 화살표) : 사용
    • A → B: A가 B를 호출한다.
  • ⇾ (닫힌 화살표) : 구현 혹은 상속
    • A ⇾ B: A가 B를 상속(혹은 인터페이스를 채택)하여 수직(혹은 수평)확장을 한다.

• 화살표는 변경으로부터 보호하려는 컴포넌트를 향하도록 그려진다.
  • View에서 발생한 변경으로부터 Presenter를 보호하고자 한다.
  • Presenter에서 발생한 변경으로부터 Controller를 보호하고자 한다.
  • Interactor는 다른 모든 것에서 발생한 변경으로부터 보호하고자 한다.
• 컴포넌트 계층구조를 이와 같이 조직화하면 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있다.

인터페이스의 목적

방향성 제어 (의존성 역전)

• FinancialReportGenerator → FinancialDataGateway<I> ⇽ FinancialDataMapper

  정보 은닉

• FinancialReportRequester
  • Interactor 내부에 대해 너무 많이 알지 못하도록 막기 위해서 존재한다.
  • 없을 경우, Controller는 FinancialEntities에 대해 Transitive Dependency 를 가지게 된다.
  • Transitive Dependency을 가지게 되면, 소프트웨어 엔티티는 ‘자신이 직접 사용하지 않는 요소에는 절대로 의존해서는 안 된다’는 소프트웨어 원칙을 위반하게 된다.

LSP: 리스코프 치환 원칙

정의

"Derived classes must be substitutable for their base classes."

클래스는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 치환할 수 있어야 한다.

• 사용자(Billing)의 행위가 사용하는 타입(License<Interface>)에 의존하지 않고 있어, 하위 타입들(PersonalLicense, Business License)로 치환할 수 있다.
  • 타입에 의존하게 된다면, 타입을 치환할 수 없게 된다.

ISP: 인터페이스 분리 원칙

정의

"Make fine grained interfaces that are client specific."

클라이언트별로 세분화된 인터페이스를 만들어라

• 오퍼레이션을 인터페이스 단위로 나눠라.
• 오퍼레이션을 인터페이스 단위로 나누지 않는다면,
  • 무관한 오퍼레이션을 변경하더라도 필요치 않은 배포가 필요로 하다.
  • 필요 이상으로 많은 것을 포함하는 모듈에 의존하는 것은 불필요한 컴파일·배포를 강제한다.

DIP: 의존성 역전 원칙

정의

"Depend on abstractions, not on concretions."

구체화(Concretion)에 의존하지말고, 추상화(Absraction)에 의존하라.

• 추상화에 의존하며, 구체화에 의존하지 않는 시스템을 유연성이 극대화된 시스템이라고 한다.

  • 구체화에 의존하는 경우(String)가 존재하지만, 이는 변경되는 일이 거의 없고 엄격하게 통제된다.
  • 안정성이 보장되어진 환경에 대해서는 구체화에 대한 의존성을 용납한다.
  • 변동성이 큰 구체화에 대한 의존을 피하도록 한다.
  • 인터페이스는 구현체보다 변동성이 낮다.

• 안정된 소프트웨어 아키텍처란 변동성이 큰 구현체에 의존하는 일은 지양하고, 안정된 추상 인터페이스를 선호하는 아키텍처이다.

실천법

• 변동성이 큰 구현체를 참조하지 않는다.
  • 인터페이스를 참조하라.
  • 객체 생성을 Abstract Factory를 사용하도록 강제한다.
• 변동성이 큰 구현체로부터 파생하지 말라.
  • 수직 확장을 지양하라.
  • 변경이 더욱 어려워진다.
• 구체함수를 overried 하지 말라.
  • 소스코드 의존성을 제고할 수 없고, 상속하게 되버린다.

Abstract Factory

• 객체를 생성하려면 해당 객체를 구체적으로 정의한 코드에 대하여 소스코드 의존성이 발생하니, 이때 사용할 수 있도록 한다.

• Application이 Service 인터페이스를 통하여 ConcreteImpl를 사용한다.
  • ConcreteImpl의 인스턴스 생성이 필요하다.
  • ConcreteImpl에 대한 소스코드 의존성이 발생하는 것을 막기 위하여 ServiceFactory를 이용한다.
• 소스코드 의존성은 곡선(아키텍처의 경계)과 교차할 때 모두 Absract Component로 향한다.
  • Abstract Component : 고수준의 비즈니스 로직
  • Concrete Component : 비즈니스 로직을 다루기 위한 세부사항들
• 의존성은 제어흐름과 반대방향으로 역전되어 흐른다. 이를 Dependency Inversion(의존성 역전)이라 칭한다.

Motivation

return body([
  division([
    header1("Chapter 1. Loomings."),
    paragraph(["Call me Ishmael. Some years ago"]),
    paragraph(["There is now your insular city"])
  ]),
  division([
    header1("Chapter 2. The Carpet-Bag."),
    paragraph(["I stuffed a shirt or two"])
  ])
])

• 쉼표, 괄호, 대괄호 등 많은 구두점이 존재한다.

  • 피상적인 문제로, 내용에서 집중을 분산시키기 때문에 피하는 것이 좋다.

• children을 위해 array literal을 사용하고 있기 때문에 type-checker는 Element가 동일한 타입을 갖도록 요구할 것이다.

• 가장 큰 문제는 이 계층 구조를 변경하는 것이 어색하다는 것이다.

division((useChapterTitles ? [header1("Chapter 1. Loomings.")] : []) +
    [paragraph(["Call me Ishmael. Some years ago"]),
     paragraph(["There is now your insular city"])])

Detail

Result builder Attribute

• var 및 subscript의 경우 선언은 getter를 정의해야하며 속성은 해당 getter의 속성인 것처럼 처리된다.
  • 이러한 방식으로 사용되는 result builder attribute는 result builder transform 함수의 본문에 적용되도록 한다.
• 프로토콜 요구 사항의 매개 변수를 포함하여 함수 유형의 매개 변수에 대한 속성으로도 사용될 수 있다.

Methods

• Result builder method는 result builder 유형에서 호출 할 수 있는 static 메소드이다.
  • BuilderType.<methodName>(<arguments>)

@resultBuilder
struct ExampleResultBuilder {

  /// 변환 된 함수의 개별 명령문 표현식 유형. 
  /// `buildExpression()`이 제공되지 않은 경우 기본값은 Component이다.
  typealias Expression = ...

  /// 모든 빌드 메소드를 통해 전달되는 부분 결과의 유형
  typealias Component = ...

  /// 최종 반환 된 결과의 유형. 
  /// `buildFinalResult()`가 제공되지 않은 경우 기본값은 Component이다.
  typealias FinalResult = ...

  /// Required by every result builder to build combined results from
  /// statement blocks.
  static func buildBlock(_ components: Component...) -> Component { ... }

  /// If declared, provides contextual type information for statement
  /// expressions to translate them into partial results.
  static func buildExpression(_ expression: Expression) -> Component { ... }

  /// Enables support for `if` statements that do not have an `else`.
  static func buildOptional(_ component: Component?) -> Component { ... }

  /// With buildEither(second:), enables support for 'if-else' and 'switch'
  /// statements by folding conditional results into a single result.
  static func buildEither(first component: Component) -> Component { ... }

  /// With buildEither(first:), enables support for 'if-else' and 'switch'
  /// statements by folding conditional results into a single result.
  static func buildEither(second component: Component) -> Component { ... }

  /// Enables support for 'for..in' loops by combining the
  /// results of all iterations into a single result.
  static func buildArray(_ components: [Component]) -> Component { ... }

  /// If declared, this will be called on the partial result of an 'if
  /// #available' block to allow the result builder to erase type
  /// information.
  static func buildLimitedAvailability(_ component: Component) -> Component { ... }

  /// If declared, this will be called on the partial result from the outermost
  /// block statement to produce the final returned result.
  static func buildFinalResult(_ component: Component) -> FinalResult { ... }
}

Transform

• Result builder transform은 명령문 블록과 그 안의 개별 명령문에서 작동하는 재귀 변환이다.

Statement blocks

• Statment 블록 내에서, 개별 statement는 별도로 연결되는 statement의 시퀀스로 표현된다.
• 각각의 시퀀스는 선택적으로 단일의 부분적인 결과를 생성할 수 있는 데, 이는 나중에 블록에서 사용될 수 있는 표현이다.
  • 변환이 모든 statment에 적용된 후, buildBlock 에 대한 호출이 생성되어 결합된 결과를 형성하며, 모든 부분적인 결과들은 unlabelled arguments로 표시된다.

Expression statements

• buildExpression 메소드를 선언하는 경우, 변환은 이를 unlabelled arguments수로 expression-statement를 전달한다.
  • 이 call expression은 이후 expression stament로 사용된다.
  • 이 호출은 statement-expression과 함께 타입 체크가 되며 해당 유형에 영향을 미칠 수 있다.
• statement-expression은 statement-expression의 결과 유형의 고유 변수를 초기화하는 데 사용된다.
  • 이 변수는 포함 블록의 일부 결과로 처리된다.
  • 이 변수에 대한 참조는 표현식 유형에 영향을 주지 않도록 독립적으로 유형 검사된다.

Assignments

• Assigment를 수행하는 expression statement는 항상 ()를 반환하지만 다른 모든 expression statements와 동일한 방식으로 처리된다.
• Result builder는 () 를 반환하는 expression을 다루는 것을 buildExpression 을 override하여 선택할 수 있다.

static func buildExpression(_: ()) -> Component { ... }

Selection statements

if / else 그리고 switch statement는 케이스에 따라 조건부로 값을 생성한다.

if i == 0 {
  "0"
}

📦
var vCase0: String?
if i == 0 {
  vCase0 = "0"
}
let v0 = BuilderType.buildOptional(vCase0)

if i == 0 {
  "0"
} else if i == 1 {
  "1"
} else {
  generateFibTree(i)
}

📦
let vMerged: PartialResult
if i == 0 {
  vMerged = BuilderType.buildEither(first: "0")
} else if i == 1 {
  vMerged = BuilderType.buildEither(second:
        BuilderType.buildEither(first: "1"))
} else {
  vMerged = BuilderType.buildEither(second:
        BuilderType.buildEither(second: generateFibTree(i)))
}

Imperative control-flow statements

• return 은 속성을 몇시적으로 제공하는 func, getter 에만 적용된다.
• break, continue, guard 는 지원되지 않는다.

Exception-handling statements

• throw, defer, do

• for .. in 문은 루프의 각 반복을 실행하여, 모든 반복의 부분적 결과를 배열로 수집한다.

  • 그리고 해당 배열이 buildArray로 전달된다.

Referecne

• swift-evolution-result-builders
• awesome-function-builders

The Render Loop

TL;DR

• 초당 120번 실행된다.
• Update Cosntraints, Layout, Display 3가지의 단계로 구성되어 있다.
• 불필요한 작업을 피할 때 매우 유용하다.

• Render Loop는 잠재적으로 초당 120번 실행되는 프로세스이다.

• Render Loop는 모든 콘텐츠가 각 프레임 에 대해 준비되었는지 확인한다.

• 이는 Update Constraints, Layout, Display 3가지의 단계로 구성되어져 있다.

  1. 모든 view들이 Leaf 에서 부터 window까지 View Hierarchy를 따라 올라가며 updateConstraints 를 수신한다.

  2. 모든 view들이 Window 부터 Leaf까지 내려가며 layoutSubviews() 를 수신한다.

  3. 마지막으로, 필요한 경우 모든 view가 그려진다.

• 각 단계는 동일한 목적을 갖는 평행한 method 세트를 지니고 있다.
  • 이것들의 목적은 낭비되는 작업을 피하며 작업을 연기하고 완전히 건너뛰게하는 것이다.
  • 예를 들어, UILabel의 크기를 구성하는 데에 있어 많은 속성들이 존재한다.
    • 속성이 변경될 때마다 텍스트 사이즈를 재측정하는 방법이 존재한다.
    • 그러나 일반적으로 이러한 항목을 연속적으로 변경하기 때문에 매우 비효율적이다.
    • 처음 Label을 설정할 때, 많은 property setter를 호출할 것이고, 각각의 setter에서 텍스트 사이즈를 다시 측정한다면 중간 것들이 모두 낭비될 것이기에 마지막에 측정되기만을 원할 것이다.
    • 이것이 Render Loop가 주는 이점이다.
    • Property setter에서 setNeedsUpdateConstraints() 를 호출하면 프레임이 화면으로 이동하기 직전에 updateConstraints() 를 호출하게 할 수 있다.

Example

var myConstraints: [NSLayoutConstraints] = []

override func updateConstraints() {
      // 1. 모든 constraints에 대하여 비활성화한다.
    NSLayoutConstraint.deactivate(myConstraints) 
    myConstraints.removeAll()
      // 2. Layout을 구현하는 constraints를 생성한다.
    let views = ["text1":text1, "text2":text2]
    myConstraints += NSLayoutConstraint.constraints(withVisualFormat: "H:|-[text1]-[text2]",
                                                    options: [.alignAllFirstBaseline],
                                                    metrics: nil, views: views)
    myConstraints += NSLayoutConstraint.constraints(withVisualFormat: "V:|-[text1]-|",
                                                    options: [],
                                                    metrics: nil, views: views)
      // 3. 모든 constraints를 활성화한다.
    NSLayoutConstraint.activate(myConstraints)

    super.updateConstraints()
}

• updateConstraints() 에서 모든 constaints를 deactivate / activate 하는 것은
  • layoutSubviews() 에서 모든 subviews를 remove / add 하는 것과 동일하다.
  • 불필요한 작업이 발생하고 있기 때문에, 한 번 이상은 작업을 수행하지 않도록 한다.

var myConstraints: [NSLayoutConstraints] = []

override func updateConstraints() {
    // 불필요하게 모든 constraints를 deactivate/activate 하지않도록 한 번 이상은 작업을 수행하지 않도록한다.

    if myConstraints.isEmpty {

        NSLayoutConstraint.deactivate(myConstraints)
        myConstraints.removeAll()

        let views = ["text1":text1, "text2":text2]
        myConstraints += NSLayoutConstraint.constraints(withVisualFormat: "H:|-[text1]-[text2]",
                                                        options: [.alignAllFirstBaseline],
                                                        metrics: nil, views: views)
        myConstraints += NSLayoutConstraint.constraints(withVisualFormat: "V:|-[text1]-|",
                                                        options: [],
                                                        metrics: nil, views: views)

        NSLayoutConstraint.activate(myConstraints)
    }
    super.updateConstraints()
}

Activating a Constraint

• Constraints를 추가하고자 하는 view 가 존재한다.
• View는 Window에 있다.
• Window는 Engine이라고 하는 internal 객체를 지니고 있다(hanging off).
• Engine이 Auto Layout의 계산의 핵심이다.

• Cosntraints를 view에 추가하면, constraints에 해당하는 방정식(equation)을 만들고 해당 방정식을 Engine에 추가한다.
  • 만일 방정식을 "X에 대한 해결"이라고 말한다면, "X는 변수"이다.

1. 각 방정식들이 Engine에 추가된다.
2. Engine이 이러한 변수 중 하나에 값을 할당 할 때마다 view에 변수의 출처를 알리고 이것이 변경되었다고 말한다.
3. Update Cosntraints 단계로 발생되며, setNeedsLayout() 를 받았기 때문에, 어떠한 지점에서 Layout 단계로 이동한다.
4. UIView는 layoutSubViews()를 받게 된다.
   • 이는, Engine에서 프레임으로 데이터를 복사하는 것이다.
   • View는 Engine에 변수의 값이 무엇인지 물어볼 것이다.
   • Engine은 그 값을 알려주고, setCenter, setBounds 를 호출한다.

Unrelated Views Don't Interact

• 연관되지 않은 View들에 대하여 Engine은 개별적인 방정식을 추가하게되고, 이는 linear 성능을 보여주게 된다.

Engine은 Layout Cache이고 Dependency Tracker이다.

• 어떤 constraints가 어떤 View에 영향을 미치는지 이해하고, 변경하면 필요한 것만 업데이트한다.

Building Efficient Layouts

Avoid Constraint Churn

• 모든 constraints를 지우는 것을 피하라.
  • 필요 없이 frame을 배치하게 되거나, 다시 배치할 필요 없는 view가 전달될 것이다.
• static constaints는 한번만 추가하라.
  • 잠재적인 layout에 공통적으로 적용되는 Constraints이 있는 경우 하나를 추가 한 다음 그대로 두어라
• Constraints가 변경이 필요할 때만 변경하여라.
• View를 remove 보다 hide하도록 하라.

Intrinsic Content Size

• 모든 view들이 intrinsicContentSize가 필요하지는 않다.
• Non-View 컨텐츠를 갖는 View (e.g. UIImageView, UILabel) 의 경우, 내용의 크기(e.g. image size, text size)를 반환한다.
• UIView는 intrinsicContentSize 를 이용하여 constraints를 만든다.
• intrinsicContentSize 는 engine에 넣을 크기 정보를 전달하는 방법이다.

System Layout Size Fitting Size

• systemLayoutSizeFitting(_:)는 engine에서 크기 정보를 다시 가져 오는 방법이다.
• 생각보다 가벼운 작업이 아니다.

Getting Size from the Engine

1. systemLayoutSistemFitting(_:) 가 호출되면, Engine이 생성된다.
2. Engine에 Cosntraints가 추가된다.
3. Layout이 해결된다.
4. 상위 view들의 frame 크기가 반환된다.
5. Engine이 폐기된다.

Inside the Black Box

• Black box의 내부에서는 아래와 같이 진행된다.
  1. View, Constraint, Property, IntrinsicContentSize 등을 구성한다.
  2. Layout Engine이 계산을 한다.
  3. Layout 얻는다.

The Layout Cycle

TL;DR

• frame 이 즉각적으로 변경될 것이라고 기대하지 말아라.
• layoutSubViews()를 override할 때 주의를 기울여라.

• 우리는 계산된 layout이 달라질 필요가 있는 Cosntraints가 바뀔 때까지 Application Run Loop를 반복하는 것으로 시작한다.
• 이로 인해 Deferred Layout Pass가 예약된다.
• Layout Pass가 나오면, Hierarchy를 살펴보고 View에 대한 모든 frame을 업데이트한다.

The Layout Cycle - Example

1. Layout을 변경하면 layout engine의 모든 것은 이미 변경되었지만 UI는 아직 업데이트되지 않은 상태이다.

2. 그런 다음 Layout Pass가 진행되면, UI가 실제로 변경된다.

• UI는 실제로 Layout Engine이 생각하는 것과 일치하도록 변경된다.

Constraint Changes

• 생성된 Constraints는 수학적 표현식으로 변환되고 Layout Engine 내에 유지된다.

• 표현식은 모든 constraints의 변경에 영향을 받는다.

  • Constraints를 activate / deactivate하거나 constraints의 우선 순위 또는 상수를 변경하는 것과 같은 몇 가지 명백한 사항이 포함된다.
  • 또한, View hierarchy를 조작하거나 재구성하는 것(view의 추가 및 삭제)과 같은 덜 분명한 것도 포함된다.
  • 이는 간접적으로 cosntraints의 변경을 유발할 수 있다.
  • 표현식은 특정 View의 origin이나 size와 같은 것을 나타내는 변수로 구성된다.

• Constraint가 변경되면, Layout Engine이 layout을 재계산한다.

  • Layout이 재계산될 때, 표현식의 변수들은 새로운 값을 받는다.
  • 이런 일이 발생하면, 그들(변수? 이것이 지칭하는 무엇일까)이 나타내는 view들에 알림이 전송되고, superview가 layout이 필요한 것으로 표시된다.
    • 즉, View들이 superview.setNeedsLayout 를 호출한다.
  • 이것이 실제로 "Deferred Layout Pass"가 예약되는 원인이다.
  • Layout enigne에서 frame이 실제로 변경되지만 View Hierarchy에서는 아직 변경되지 않는 곳이다.

Deferred Layout Pass

• 올바른 위치에 있지 않은 모든 View의 위치를 변경 하도록 한다.
• Deferred Layout Pass에는 View hierarchy를 통과하는 "Update Constraints", "Reassign view frames"가 있다.

Update Constraints

• Constraints에 대한 보류 중인 변경 사항이 있으면, View Hierarchy를 통과하여 모든 View의 위치를 변경하기 전에 해당 변경사항이 지금 발생하는지 확인한다.

• View는 updateConstratins() 호출을 명시적으로 요청하기 위하여 setNeedsUpdateConstaints() 를 호출한다.

  • 그리고 이것은 setNeedsDisplay()와 거의 같은 방식으로 작동한다.

  • setNeedsUpdateConstraints() 를 호출하면 얼마 후 updateConstraints()가 호출된다.

  • 이 모든 것은 View가 다음 Layout Pass를 위하여 제때에 Constraints를 변경하는 기회를 가질 수 있는 방법이지만, 실제로는 필요하지 않은 경우가 많다.

    • 이상적으로, 최초의 constriants 설정은 Interface Builder에서 발생하여야 한다.
    • 만일 정말 constraints를 프로그래밍적으로 할당해야하는 경우에는 viewDidLoad 와 같은 위치가 훨씬 좋다.
    • 반면에, 해당 로직을 연관된 다른 코드와 분리하여 나중에 실행되는 별도의 메소드로 옮긴다면, 코드를 따라가기 훨씬 어려워지므로 가독성과 유지 관리가 어려워진다.

  • updateConstraints()의 사용은 성능으로 귀결된다.

    • Constraints을 변경하는 것이 너무 느리다면 updateConstraints() 가 도움이 될 수 있다.
      • Layout Engine이 updateCosntraint에서 발생하는 모든 constraint change를 batch로 처리할 수 있기 때문에, updateConstraints() 내에서 constraints를 변경하는 것이 다른 시간에 contstraints를 변경하는 것보다 더 빠르다.
      • 이는 Cosntratins 각각을 개별적으로 activate하는 것과는 대조적으로 Constraints Array에 대해 NSLayoutConstraint.activate()를 호출하여 얻는 것과 동일한 종류의 성능 이점이다.

• Update Constraints Pass가 완료되면 Constraints가 모두 최신 상태임을 알 수 있으며 View의 위치를 변경할 준비가 된 것이다.

Reassign view frames

• 여기에서 Top-Down으로 View Hierarchy 를 탐색하고 Layout이 필요한 것으로 표시된 모든 뷰에서 layoutSubviews()를 호출한다.
  • Reciever들의 위치를 재조정하기 위한 것이 아닌, subview의 위치를 재조정하기 위하여 호출하도록 한다.
  • Layout Engine으로부터 subview들에 대한 frame을 읽은 다음 할당한다.
• Constraints를 이용하여 표현할 수 없는 layout을 필요한 경우에만 layoutSubviews()를 override하여야 한다.
  • override를 할 경우, 어떠한 view들은 이미 배치되어져 있지만, 또다른 view들은 그렇지 않을 수 있다.
  • 배치되지 않은 view도 아마 곧 배치될 것이므로 약간 섬세한 순간이다.
• Custom Layout을 위하여 layoutSubViews() 을 override할 경우, 몇 가지 규칙이 존재한다.
  • 🌟 Do
    • super.layoutSubviews() 호출하라.
    • 하위 트리 내의 layout을 무효화하라.
  • ❌ Don't
    • setNeedsUpdateconstraints()를 호출하지 말아라.
    • 하위 트리 외부의 layout을 무효화하지 말아라.
      • Layout feedback loop가 발생하며 무한 루프에 빠질 수 있다.t
    • 무차별적으로 constraints를 수정하지 말아라.

Interacting with Legacy Layout

• 과거부터 현재까지, Layout을 구성하는 방법은 변경되어져 왔다.
  • 전통적으로 frame을 설정하는 것만으로 view를 배치하였다.
  • 다음은, superview의 size가 변경될 때 view의 size를 조정하는 방법을 지정하는 autoresizingMask가 있었다.
  • 다음으로, AutoLayout에서 constraints으로 모든 작업을 수행하게 되었다.
• 여전히 view.frame 을 직접 set하면 위치로 이동을 하지만, Framework가 Layout Engine에서 frame을 복사하여 적용하는 경우, 언제든지 해당 frame을 덮어 쓸 수 있다.
  • 문제는 가끔 frame을 설정해야한다는 것이다.
    • 예를 들어 layoutSubviews()를 재정의할 경우, 해당 View의 frame 설정해야 할 수 있다.
    • 운 좋게도 이를 위한 translatesAutoresizingMaskIntoConstraints가 존재한다.

translatesAutoresizingMaskIntoConstraints

TL;DR

• frame을 직접적으로 설정할 때 이 flag를 사용하라.
• Cosntraints를 사용할 때 이 flag를 false로 하여라.

• Legacy Layout 시스템에서와 같은 방식으로 작동하지만 AutoLayout 세계에서 작동한다.
• 만일 이 flag가 true이며 frame을 설정하게 될 경우, framework은 Layout Engine에서 frame을 강제하는 constraints를 생성한다.
  • 이는 즉, 원하는 만큼 frame을 설정할 수 있으며 AutoLayout을 사용하여 view의 위치를 유지할 수 있다는 것이다.
  • Constraints는 autoresizingMask의 행동을 구현한다.
  • Cosntraints를 사용하여 이 view와 관련된 다른 view들을 배치할 수 있다.
• *Constraints를 사용할 때에는 view.translatesAutoresizingMaskIntoConstraints = false *로 하여라.
  • 프로그래밍방식으로 생성된 view의 경우 기본값은 true이다.

Constraint Creation

 // NSLayoutConstraint(item:b, attribute:.Top, relatedBy:.Equal, toItem:view, attribute:.Top, multiplier:1, constant:10)

 b.topAnchor.constraintEqualToAnchor(view.topAnchor, constant:10)

• Cosntraint의 생성을 위하여NSLayoutConstraint factory method를 사용하였지만 가독성이 떨어져, 그 대신 Layout anchor가 새로이 도입되었다.

Constraining Negative Space

• 때때로 명확하지 않은 몇 가지 종류의 Layout이 있다.
  • 전통적으로, 명확하지 않은 layout은 Dummy View를 사용하여 해결하고는 하였다.
  • 하지만, 모든 View에 layer가 연결된 iOS에서는 비효율적이다. 이를 위하여 LayoutGuide가 도입되었다.

LayoutGuide

let guide = UILayoutGuide()
view.addLayoutGuide(guide)

• LayoutGuide는 단순히 Layout engine에서 사각형을 나타낸다.
• Anchor 객체를 노출하므로 constraints 생성 구문에서 작동한다.
• Layout anchor는 margin에서 사용할 수 없다.
• UIView는 layoutMarginsGuide를 노출한다.

Debugging Your Layout

• Constraints에 indentifier를 추가하도록 하라.
• Accessibility idnetifier를 설정하면 해당 identifier가 view와 쌍을 이루는 log에 표시되므로 원하는 view를 찾을 수 있다.
• Layout Guide에 identifier를 설정할 수 있다.
• constraintsAffectingLayoutForAxis를 사용하라.
  • 한 축 또는 다른 축에서 해당 view에 영향을 미치는 constraints만 알려준다.

Resolving Ambiguity

• 너무 적은 constraints 혹은 priority의 충돌로 인하여 발생할 수 있다.

Diagnostic tools

• po view._autolayoutTrace
• View Debugger
• exerciseAmbiguityInLayout