Hello RxSwift

• RxSwift는 관찰 가능한 시퀀스와 함수 스타일 연산자를 사용하여 비동기 및 이벤트 기반 코드를 작성하고 스케줄러를 통해 매개 변수화 된 실행을 허용하는 라이브러리이다.

• RxSwift는 본질적으로 코드가 새 데이터에 반응하고 순차적으로 격리된 방식으로 처리할 수 있도록함으로써 비동기 프로그램 개발을 간소화한다.

Introduction to asynchronous programming

• 앱에서 다음의 모든 일들은 동시에 일어난 것처럼 보인다.

  • 버튼 탭에 반응하기
  • 텍스트 필드로 키보드 애니메이션을 하면 포커스가 사라짐
  • 인터넷에서 큰 사진 다운로드
  • 데이터를 디스크에 저장
  • 오디오 재생
  • 기타 등등...

• 프로그램의 모든 다른 비트는 서로의 실행을 차단하지 않는다.

• iOS는 다양한 스레드에서 서로 다른 작업을 수행하고 장치의 CPU 코어에서 수행 할 수 있는 모든 종류의 API를 제공한다.

• 그러나 실제로 병렬로 실행되는 코드를 작성하는 것은 다소 복잡하다.

• 특히 다른 부분의 코드가 동일한 데이터로 작업해야 하는 경우 더욱 그렇다.

• 어떤 코드가 먼저 데이터를 업데이트하는지 또는 어떤 코드가 최신 값을 읽는지에 대해 논쟁하기가 어렵다.

Cocoa and UIKit Asynchronous APIs

• Apple은 비동기 코드를 작성하는 데 도움이 되는 iOS SDK에 많은 API를 제공했다.

• 당신은 프로젝트에서 이것을 사용했고 아마도 모바일 앱을 작성하는 데 너무 근본적이기 때문에 생각을 다시하지 않았을 것이다.

  • NotificationCenter: 사용자가 장치의 방향을 바꾸거나 화면에 표시되거나 숨어지는 소프트웨어 키보드와 같이 관심 이벤트가 발생할 때마다 코드를 실행한다.
  • The delegate pattern: 임의의 시간에 다른 클래스나 API에 의해 실행될 메소드를 정의한다. 예를 들어 application delegate에서 새 원격 알림이 도착할 때 수행해야 할 작업을 정의하지만 이 코드가 실행될 때 또는 실행될 횟수는 알 수 없다.
  • Grand Central Dispatch: 작품의 실행을 추상화하는 데 도움이 된다. serial queue에서 순차적으로 실행되도록 코드를 예약하거나 우선 순위가 다른 여러 대기열에서 동시에 많은 수의 작업을 실행할 수 있다.
  • Closures: 클래스간에 전달할 수 있는 분리 된 코드를 작성하여 각 클래스가 실행 여부를 결정할 수 있다. 몇 번이나, 어떤 상황에서 실행할지 결정할 수 있다.

• 일반적인 클래스의 대부분은 비동기 적으로 작업을 수행하고 모든 UI 구성 요소는 본질적으로 비동기 적이기 때문에 앱 코드 전체가 어떤 순서로 실행되는지 가정하는 것은 불가능하다.

• 결국 앱의 코드는 사용자 입력, 네트워크 활동 또는 기타 OS 이벤트와 같은 다양한 외부 요소에 따라 다르게 실행된다.

• 사용자가 앱을 실행할 때마다 외부 요인에 따라 코드가 완전히 다른 순서로 실행될 수 있다. (당신이 당신의 앱을 테스트하는 로봇 군을 가지고있는 경우를 제외하고, 정확한 모든 kill-bot 동기화로 모든 사건이 일어날 것으로 기대할 수 있다.)

• 좋은 비동기 코드를 작성하는 것은 불가능하다는 것을 분명히 말하고있는 것이다.

• 위 목록에 있는 Apple의 위대한 API는 매우 진보적이며 작업에 매우 특화되어 있으며 다른 플랫폼이 제공하는 것과 비교하면 매우 강력하다.

• 문제는 복잡한 비동기 코드가 Apple SDK가 제공하는 다양한 API 때문에 부분적으로 작성하기가 어려워진다.

• 델리게이트를 사용하려면 하나의 패턴을 채택 해야하며, 클로저에 사용할 패턴, NotificationCenter에 구독하는 방법 등이 필요하다.

• 모든 비동기식 API에서 보편적인 언어가 없으므로 코드를 읽고 이해하고 실행에 대한 추론이 어려워진다.

• 이 섹션을 마무리하고 토론을 좀 더 자세히 살펴보기 위해 두 개의 코드 즉, 동기식 코드와 비동기식 코드를 비교한다.

Synchronous code

• 배열의 각 요소에 대한 작업을 수행하는 것은 많은 시간을 할애한다.

• 매우 간단하지만 견고한 응용 프로그램 논리 블록이다.

• 즉, 동기식으로 실행되며 컬렉션을 반복하면서 컬렉션을 변경할 수 없기 때문이다.

• 컬렉션을 반복할 때 모든 요소가 아직 있는지 확인할 필요가 없으며 다른 스레드가 컬렉션의 시작 부분에 요소를 삽입 할 경우 되감을 필요가 없다.

• 루프의 시작 부분에서 컬렉션 전체를 항상 반복한다고 가정한다.

var array = [1, 2, 3]
for number in array {
  print(number)
  array = [4, 5, 6]
}
print(array)

• for body 내부에서 배열을 변경할 수 있는가?
• 루프가 반복적으로 반복하는 컬렉션이 있는가?
• 모든 명령의 실행 순서는 무엇인가?
• 필요한 경우 번호를 수정할 수 있는가?

Asynchronous code

• 유사한 코드가 있는데 각 반복은 버튼을 탭하는 것에 대한 반응으로 발생한다고 가정하자.
• 사용자가 버튼을 반복해서 누르면 앱은 배열의 다음 요소를 출력한다.

var array = [1, 2, 3]
var currentIndex = 0

//this method is connected in IB to a button
@IBAction func printNext(_ sender: Any) {
  print(array[currentIndex])

  if currentIndex != array.count-1 {
    currentIndex += 1
  }
}

• 이전 코드와 동일한 문맥에서 이 코드를 생각해자.

• 사용자가 버튼을 탭하면 모든 배열의 요소가 출력되는가?

• 당신은 확실히 말할 수 없다.

• 비동기 코드의 또 다른 부분은 출력되기 전에 마지막 요소를 제거할 수 있다.

• 또는 코드를 이동하면 다른 요소가 컬렉션의 시작 부분에 삽입될 수 있다.

• 또한 printNext(_:)만 currentIndex를 변경한다고 가정하지만 다른 코드는 currentIndex도 수정할 수 있다.

• 위의 함수를 작성한 후 어느 시점에 추가한 영리한 코드일 수 있다.

• 비동기 코드 작성의 핵심 문제는 다음과 같다.

• a) 작업 조각이 수행되는 순서와 b) 변경 가능한 데이터를 공유하는 순서.

• 다행스럽게도, 이들은 RxSwift의 강점이다!

Asynchronous programming glossary

• RxSwift의 언어 중 일부는 비동기식, 리액티브 및 / 또는 함수형 프로그래밍에 매우 밀접하게 연결되어 있으므로 다음과 같은 기본 용어를 먼저 이해하면 더 쉽게 이해할 수 있다.
• 일반적으로 RxSwift는 다음 문제를 해결하려고 한다.

1. State, and specifically, shared mutable state

• 랩톱을 시작하면 정상적으로 작동하지만 며칠 또는 몇 주 동안 사용하면 괴상하게 행동하거나 갑작스럽게 멈추거나 말하기를 거절할 수 있다.

• 하드웨어와 소프트웨어는 동일하게 유지되지만 변경된 것은 상태이다.

• 랩톱을 다시 시작하자 마자 하드웨어와 소프트웨어의 동일한 조합이 한 번 더 정상적으로 작동한다.

• 메모리에 있는 데이터, 디스크에 저장된 데이터, 사용자 입력에 반응하는 모든 아티팩트, 클라우드 서비스에서 데이터를 가져온 후에 남은 모든 흔적 - 이것들이 랩톱의 상태이다.

• 특히 여러 비동기 구성 요소 간에 공유할 때 앱 상태를 관리하는 것이이 책에서 다루는 방법을 배울 수 있는 문제 중 하나이다.

2. Imperative programming

• 명령형 프로그래밍은 명령문을 사용하여 프로그램의 상태를 변경하는 프로그래밍 패러다임이다.

• 당신의 개와 놀고있는 동안 명령형 언어를 사용하는 것처럼 - 명령형 코드를 사용하여 앱에 정확한 방법과 방법을 알려준다.

• 명령형 코드는 컴퓨터가 이해할 수 있는 코드와 유사하다.

• 모든 CPU는 간단한 명령어의 긴 시퀀스를 따른다.

• 문제는 복잡하고 비동기적인 응용 프로그램에 대한 명령형 코드를 작성하는 것이 사람에게 어렵다는 것이다.

• 특히 변경할 수 있는 공유된 상태가 포함된 경우에 그렇다.

override func viewDidAppear(_ animated: Bool) {
  super.viewDidAppear(animated)

  setupUI()
  connectUIControls()
  createDataSource()
  listenForChanges()
}

• 이 모든 방법이 무엇을 하는지 알 수는 없다.
• 뷰 컨트롤러 자체의 일부 속성을 업데이트하는가?
• 그리고 더 불안하게, 그들이 올바른 순서로 호출되었는가?
• 누군가 실수로 이러한 메소드 호출의 순서를 바꿔 소스 제어에 변경을 위임한 것일 수 있다.
• 이제 스왑된 호출로 인해 앱이 다르게 작동할 수 있다.

3. Side effects

• 변경 가능한 상태와 명령형 프로그래밍에 대해 더 많이 알게 되었으므로 부작용에 대한 두 가지 문제로 대부분의 문제를 해결할 수 있다.

• 부작용은 현재 범위 밖에서 상태가 변경된 것이다.

• connectUIControls()는 일종의 이벤트 핸들러를 일부 UI 구성 요소에 연결한다.

• 뷰의 상태가 변경되면 부작용이 발생한다.

• 즉, 앱은 connectUIControls()를 실행하기 전에 한 가지 방식으로 동작하고 이후에는 다르게 동작한다.

• 디스크에 저장된 데이터를 수정하거나 화면의 레이블 텍스트를 업데이트할 때마다 부작용이 발생한다.

• 부작용은 그다지 나쁘지 않다.

• 결국, 부작용을 일으키는 것은 모든 프로그램의 궁극적인 목표다!

• 프로그램 실행이 끝나면 어떻게든 세상의 상태를 바꿔야 한다.

• 잠시 실행하고 아무것도 하지 않으면 꽤 쓸모없는 앱이 된다.

• 부작용을 유발하는 문제는 통제된 방식으로 진행된다.

• 어떤 코드가 부작용을 일으키고 단순히 데이터를 처리하고 출력하는지 결정할 수 있어야 한다.

• RxSwift는 위에 나열된 문제를 해결하려 한다.

4. Declarative code

• 명령형 프로그래밍에서는 원하는 대로 상태를 변경한다.

• 함수형 코드에서는 부작용이 없다.

• 당신이 완벽한 세계에서 살지 않기 때문에 균형은 중간에 놓여 있다.

• RxSwift는 명령형 코드와 함수형 코드의 최상의 측면을 결합한 것이다.

• 선언 코드를 사용하면 동작을 정의할 수 있으며 RxSwift는 관련 이벤트가 있을 때마다 이러한 동작을 실행하고 작업할 수있는 불변의 격리된 데이터 입력을 제공한다.

• 이렇게하면 비동기 코드로 작업할 수 있지만 단순한 for 루프와 동일한 가정을 한다.

• 즉, 변경 불가능한 데이터로 작업하고 순차적이고 결정론적인 방식으로 코드를 실행할 수 있다.

5. Reactive systems

• 리액티브 시스템은 다소 추상적인 용어이며 다음과 같은 특성의 대부분 또는 전부를 나타내는 웹 또는 iOS 앱을 포함한다.

  • Responsive (반응) : 최신 앱 상태를 나타내는 UI를 항상 최신 상태로 유지한다.
  • Resilient (복원력) : 각 동작은 격리되어 정의되며 유연한 오류 복구를 제공한다.
  • Elastic : 코드는 다양한 작업 부하를 처리하며 종종 Lazy pull 기반 데이터 수집, 이벤트 조절 및 리소스 공유와 같은 기능을 구현한다.
  • Message driven (메시지 기반) : 구성 요소는 메시지 기반 통신을 사용하여 재사용 및 격리 기능을 개선하고 라이프 사이클과 클래스 구현을 분리한다.

Foundation of RxSwift

• 리액티브 프로그래밍은 새로운 개념이 아니다.

• 꽤 오랜 시간 동안 있었지만, 핵심 개념은 지난 10년 동안 두드러졌다.

• 그 기간 동안 웹 애플리케이션은 복잡해졌으며 복잡한 비동기 UI를 관리하는 문제에 직면 해 있다.

• 서버 측에서는 위에서 설명한 반응성 시스템이 필요하게 되었다.

• Microsoft팀은 이 장에서 설명한 비동기식, 확장형 실시간 응용 프로그램 개발 문제를 해결하는 데 어려움을 겪었다.

• 그들은 회사의 핵심 팀과 독립적으로 일했으며 2009년경에는 Reactive Extensions for .NET (Rx)이라는 새로운 클라이언트 및 서버측 프레임 워크를 제공했다.

• .NET 3.5의 설치 가능 애드온이었으며 나중에 .NET 4.0의 내장 코어 라이브러리가 되었다.

• 오픈 소스 코드는 다른 언어와 플랫폼에서 동일한 기능을 다시 구현할 수 있도록 허용함으로써 Rx를 크로스 플랫폼 표준으로 만들었다.

• 현재 RxJS, RxKotlin, Rx.NET, RxScala, RxSwift 등이 있다.

• 이러한 모든 라이브러리는 동일한 동작과 동일한 표현 API를 구현하려고 노력한다.

• 궁극적으로 RxSwift로 iOS 앱을 만드는 개발자는 웹에서 RxJS를 사용하는 다른 프로그래머와 앱 로직을 자유롭게 토론할 수 있다.

• 원래의 Rx와 마찬가지로 RxSwift도 가변적인 상태를 처리하고 이벤트 시퀀스를 구성하며 코드 격리, 재사용 및 분리와 같은 아키텍처 개념을 향상시킬 수 있다.

• 정의 부분으로 다시 되돌아가서,

  • RxSwift는 전통적으로 필수적인 코코아 코드와 순수한 기능 코드 사이의 적절한 위치를 찾는다.
  • 불변의 코드 정의를 사용하여 비동기적으로 입력 부분을 결정적이고 구성 가능한 방식으로 처리함으로써 이벤트에 대응할 수 있다.

• 이 책에서는 RxSwift로 개발하는 초석 개념과 실제 응용 프로그램에서 사용하는 방법에 대한 실제 사례를 다룰 예정이다.

• Rx 코드의 세 가지 빌딩 블록은 observables, operators 및 schedulers이다.

Observables

• Observable 클래스는 Rx 코드의 기초를 제공한다.

• 즉, 데이터 T의 불변 스냅샷을 "전달"할 수 있는 일련의 이벤트를 비동기적으로 생성하는 기능이다.

• 가장 간단한 말로 클래스는 다른 클래스에서 방출한 값을 시간이 지남에 따라 구독할 수 있다.

• Observable 클래스는 하나 이상의 관찰자가 실시간으로 어떤 이벤트에 반응하고 앱 UI를 업데이트하거나 새로운 데이터와 들어오는 데이터를 처리하고 활용할 수 있게 한다.

• ObservableType 프로토콜 (Observable 가 준수 함)은 매우 간단하다.

• Observable은 다음 세 가지 유형의 이벤트만 방출할 수 있다 (관찰자가 수신할 수 있음).

  • next 이벤트 : 최신 (또는 "다음") 데이터 값을 "전송"하는 이벤트다. 이것은 관찰자가 값을를 "받는" 방법이다.
  • completed 이벤트 : 이 이벤트는 성공한 이벤트 시퀀스를 종료한다. Observable이 수명주기를 성공적으로 완료했음을 의미하며 다른 이벤트는 발생하지 않는다.
  • error 이벤트 : Observable은 오류로 종료되며 다른 이벤트를 발생시키지 않는다.

• 시간이 지남에 따라 비동기 이벤트가 발생하는 경우, 타임 라인에서 관찰 할 수 있는 정수의 순서는 다음과 같다.

• Observable이 발생할 수있는 세 가지 가능한 이벤트에 대한 이 간단한 계약은 Rx의 모든 것이다.

• 보편적이므로 가장 복잡한 응용 프로그램 논리조차도 만들 수 있다.

• 관찰 가능한 계약은 Observable 또는 Observer의 본질에 대한 어떠한 가정도 하지 않기 때문에 이벤트 시퀀스를 사용하는 것이 궁극적인 디커플링 관행이다.

• 델리게이트 프로토콜을 사용하거나 클래스가 서로 이야기할 수 있도록 클로저를 삽입할 필요가 없다.

• 실제 상황에 대한 아이디어를 얻으려면 두 가지 종류의 관찰 가능한 시퀀스를 살펴보자.

Finite observable sequences

• 관찰 가능한 시퀀스 중 일부는 0개, 1개 또는 그 이상의 값을 내보내고 나중에는 성공적으로 종료되거나 오류로 종료된다.

• iOS 앱에서는 인터넷에서 파일을 다운로드하는 코드를 고려해야 한다.

  • 먼저 다운로드를 시작하고 들어오는 데이터를 관찰하기 시작한다.
  • 그런 다음 파일의 일부가 들어올 때 반복적으로 데이터 청크를 수신한다.
  • 네트워크 연결이 끊어지면 다운로드가 중단되고 연결이 시간 초과되어 오류가 발생한다.
  • 또는 코드가 모든 파일의 데이터를 다운로드하면 성공으로 완료된다.

• 이 워크 플로우는 일반적인 관측 가능 객체의 수명주기를 정확하게 설명한다.

API.download(file: "http://www...")
.subscribe(onNext: { data in
  ... append data to temporary file
},
onError: { error in
  ... display error to user
},
onCompleted: {
  ... use downloaded file
})

• API.download(file:)는 Observable 인스턴스를 반환한다.

• 이 인스턴스는 데이터 값을 네트워크를 통해 전달한다.

• onNext 종료를 제공하여 다음 이벤트를 구독한다.

• 다운로드 예제에서 디스크에 저장된 임시 파일에 데이터를 추가한다.

• onError 클로저를 제공하여 오류를 구독한다.

• 클로저에서 error.localizedDescription을 경고 상자에 표시하거나 다른 작업을 수행 할 수 있다.

• 마지막으로 완료된 이벤트를 처리하기 위해 onCompleted 클로저를 제공한다.

• 여기서 새 View Controller를 다운로드하여 다운로드한 파일이나 앱 로직이 지시하는 다른 것을 표시 할 수 있다.

Infinite observable sequences

• 자연적으로 또는 강제 종료될 것으로 예상되는 파일 다운로드 또는 유사한 활동과 달리 단순히 무한한 다른 순서가 있다. 흔히 UI 이벤트는 무한한 관찰 가능한 시퀀스다.

• 예를 들어 앱의 기기 방향 변경에 대응해야 하는 코드를 생각해보자.

  • NotificationCenter에서 UIDeviceOrientationDidChange 알림에 대한 관찰자로 클래스를 추가한다.
  • 방향 변경을 처리하기 위해 메소드 콜백을 제공해야 한다. UIDevice에서 현재 방향을 잡고 최신 값에 따라 대응해야 한다.

• 그의 오리엔테이션 변화 순서는 자연스러운 것이 아니다.

• 장치가 있는 한 방향 변경이 발생할 수 있다.

• 또한 시퀀스는 사실상 무한하기 때문에 관찰을 시작할 때 항상 초기 값을 가진다.

• 사용자가 장치를 결코 회전시키지 않을 수도 있지만, 이는 이벤트 시퀀스가 종료됨을 의미하지는 않는다.

• 그것은 단지 사건이 발생하지 않았다는 것을 의미한다.

• RxSwift에서 다음과 같은 코드를 작성하여 장치 방향을 처리할 수 있다.

UIDevice.rx.orientation
  .subscribe(onNext: { current in
    switch current {
      case .landscape:
        ... re-arrange UI for landscape
      case .portrait:
        ... re-arrange UI for portrait
    }
})

• UIDevice.rx.orientation은 Observable을 생성하는 가상의 컨트롤 속성이다 (코드 작성이 매우 쉽고 다음 장에서 방법을 배운다).
• 현재 구독에 따라 현재 방향에 따라 앱 UI를 업데이트한다.
• onError 및 onCompleted 매개 변수는 건너뛸 수 있다.
• 이러한 이벤트는 해당 관측 가능 이벤트에서 방출 될 수 없기 때문이다.

Operators

• ObservableType과 Observable 클래스의 구현에는 훨씬 복잡한 논리를 구현하기 위해 함께 구성 할 수 있는 비동기 작업을 추상화하는 많은 메서드가 포함되어 있다.

• 이들은 매우 분리되어 구성 가능하기 때문에 이러한 방법을 가장 자주 연산자라고 한다.

• 이 연산자는 주로 비동기 입력을 받아 부작용없이 출력 만 생성하므로 퍼즐 조각과 같이 쉽게 맞고 더 큰 그림을 만들 수 있습니다.

• 예를 들어 수학 식 (5 + 6) * 10-2를 사용합니다.

• 명확하고 결정론적인 방법으로 미리 정의 된 순서대로 *, (), + 및 - 연산자를 입력 데이터 조각에 적용하고 결과를 가져 와서 해결될 때까지 표현식을 계속 처리 할 수 있다.

• 다소 비슷한 방식으로, Observable이 출력 한 입력에 Rx 연산자를 적용하여 표현식이 최종 값으로 결정될 때까지 입력 및 출력을 결정적으로 처리할 수 있다.

• 그런 다음 최종 결과 값을 사용하여 부작용을 유발할 수 있다.

• 다음은 일반적인 Rx 연산자를 사용하도록 조정된 방향 변경 관찰에 대한 이전 예제다.

UIDevice.rx.orientation
  .filter { value in
    return value != .landscape
  }
.map { _ in
    return "Portrait is the best!"
  }
  .subscribe(onNext: { string in
    showAlert(text: string)
  })

• UIDevice.rx.orientation이 .landscape 또는 .portrait 값을 생성 할 때마다 Rx는 해당 데이터 조각에 몇 개의 연산자를 적용한다.

• 필터는 .landscape가 아닌 값만 통과하도록 한다.

• 장치가 가로 모드에 있으면 필터가 이러한 이벤트를 억제하므로 구독 코드가 실행되지 않는다.

• .portrait 값의 경우지도 연산자는 Orientation 유형 입력을 가져 와서 "Portrait is the best!"텍스트 인 String 출력으로 변환한다.

• 마지막으로, 구독하면 다음 결과 이벤트에 가입한다.

• String 값을 가져 와서 해당 텍스트가 있는 경고를 화면에 표시하는 메서드를 호출한다.

• 연산자는 또한 매우 composable - 항상 데이터를 입력으로 가져 와서 결과를 출력하므로 단일 연산자가 독자적으로 할 수있는 것보다 훨씬 많은 것을 달성하는 여러 가지 방법으로 쉽게 연결할 수 있다!

Schedulers

• 스케줄러는 Rx에 해당하는 디스패치 대기열과 같다.

• RxSwift에는 사용 사례의 99%를 커버하는 미리 정의된 여러 가지 스케줄러가 있으며 잘하면 자신의 스케줄러를 만들지 않아도 된다는 것을 의미한다.

• 즉, 스케줄러는 매우 강력하다.

• 예를 들어, GrandDispatchQueueScheduler의 다음 이벤트를 관찰하고 싶으면 Grand Central Dispatch를 사용하여 주어진 큐에서 코드 실행을 직렬화하도록 지정할 수 있다.

• ConcurrentDispatchQueueScheduler는 코드를 동시에 실행한다.

• OperationQueueScheduler를 사용하면 주어진 NSOperationQueue에서 구독을 예약 할 수 있다.

• RxSwift 덕분에 다른 구독자의 동일한 구독에 대해 서로 다른 작업을 스케줄링하여 최상의 성능을 얻을 수 있다.

• RxSwift는 서브 스크립션 (아래 왼쪽)과 스케줄러 (오른쪽) 사이의 디스패처 역할을 하여 작업 내용을 올바른 컨텍스트로 보내고 서로의 결과물로 원활하게 작업 할 수 있도록 한다.

• 이 다이어그램을 읽으려면, 다른 스케쥴러에서 스케쥴 된 일련의 작업 (1, 2, 3, ...)을 수행하라.

  • 청색 네트워크 가입은 사용자 정의 NSOperation 기반 스케줄러에서 실행되는 코드 (1)로 시작한다.
  • 이 블록이 출력하는 데이터는 동시 백그라운드 GDC 대기열에 있는 다른 스케줄러에서 실행되는 다음 블록 (2)의 입력으로 사용된다.
  • 마지막으로 파란색 코드 (3)의 마지막 부분은 UI를 새 데이터로 업데이트하기 위해 주 스레드 스케줄러에서 예약된다.

App architecture

• RxSwift가 앱의 아키텍처를 어떤 식으로든 변경하지 않는다는 것을 언급할 가치가 있다.

• 이벤트, 비동기 데이터 시퀀스 및 범용 통신 계약을 주로 처리한다.

• Apple 개발자 문서에 정의 된대로 MVC 아키텍처를 구현하여 Rx로 애플리케이션을 만들 수 있다.

• 원하는 경우 MVP 아키텍처 또는 MVVM을 구현하도록 선택할 수도 있다.

• 그런 식으로하려는 경우, RxSwift는 또한 자신의 단방향 데이터 흐름 아키텍처를 구현하는 데 매우 유용하다.

• 반응적인 앱으로 만들기 위해 처음부터 프로젝트를 시작하지 않아도 된다는 점에 유의해야 한다.

• 반복적으로 기존 프로젝트의 부분을 리팩터링하거나 단순히 앱에 새로운 기능을 추가 할 때 RxSwift를 사용할 수 있다.

• Microsoft의 MVVM 아키텍처는 데이터 바인딩을 제공하는 플랫폼에서 작성된 이벤트 기반 소프트웨어 용으로 특별히 개발되었다.

• RxSwift와 MVVM은 분명히 잘 어울리며, 이 책의 끝 부분에서 RxSwift로 패턴을 구현하는 방법을 살펴볼 것이다.

• MVVM과 RxSwift가 잘 어울리는 이유는 ViewModel을 사용하면 Observable 속성을 노출할 수 있으며 View Controller 글루 코드의 UIKit 컨트롤에 직접 바인딩 할 수 있다.

• 이렇게하면 모델 데이터를 UI에 바인딩하고 표현하고 코드를 작성하는 것이 매우 간단 해진다.

• 이 책의 다른 모든 예제는 샘플 코드를 간단하고 이해하기 쉽게 유지하기 위해 MVC 아키텍처를 사용한다.

RxCocoa

• RxSwift는 일반적인 Rx API의 구현이다.

• 따라서 Cocoa 또는 UIKit 특정 클래스에 대해서는 알지 못한다.

• RxCocoa는 RxSwift의 동반 라이브러리로서 UIKit 및 Cocoa의 개발을 지원하는 모든 클래스를 포함한다.

• 일부 고급 클래스 기능 외에도 RxCocoa는 다양한 UI 구성 요소에 반응적인 확장 기능을 추가하여 다양한 UI 이벤트를 즉시 구독 할 수 있다.

• 예를 들어 RxCocoa를 사용하여 다음과 같이 UISwitch의 상태 변경 사항을 구독하는 것은 매우 쉽다.

toggleSwitch.rx.isOn
  .subscribe(onNext: { enabled in
    print( enabled ? "it's ON" : "it's OFF" )
  })

• RxCocoa는 UISwitch 클래스에 rx.isOn 속성을 추가하여 일반적으로 유용한 이벤트 시퀀스를 구독 할 수 있다.

• 또한 RxCocoa는 UITextField, URLSession, UIViewController 등에 rx 네임 스페이스를 추가한다.

Installing RxSwift

• https://github.com/ReactiveX/RxSwift
• Cocoapods, Carthage를 통한 설치
• 이하 생략

Community

• http://community.rxswift.org
• https://github.com/RxSwiftCommunity
• http://rxswift-slack.herokuapp.com
• 이하 생략

Where to go from here?

• 이 장에서는 RxSwift가 다루는 많은 문제를 소개했다.

• 비동기식 프로그래밍, 변경 가능한 상태 공유, 부작용 등의 복잡성에 대해 배웠다.

• 아직 RxSwift를 작성하지 않았지만 RxSwift가 좋은 아이디어인 이유를 이해하고 문제가 해결되는 유형을 알고 있다.

• 이것은 나머지 책을 다룰 때 좋은 출발점이 될 것이다.

• 그리고 MVVM 아키텍처를 사용하여 매우 간단한 관측 자료를 만들고 실제 애플리케이션을 완성할 수 있도록 작업을 시작할 것이다.