Share
Sign In
Swift | 학습 내용 정리
[UIKit + RxSwift] MVVM 구조에서 Input-Output 패턴으로 UI 컨트롤하기
한결
👍
Input - Output 패턴Login 정보 검증 화면TableView, CollectionView가 함께 있는 뷰에서의 Rx + MVVM Input-Output 패턴
💬
RxSwift의 기본 컨셉은 아래 콘텐츠를 통해 간단하게 정리해보았습니다.
커스텀한 Observable 객체를 이용해서 MVVM 패턴으로 간단한 iOS 앱을 만들어왔다. View 객체에서 발생하는 이벤트를 인식하고 이벤트에 따른 비즈니스 로직을 ViewModel에서 처리하고, 그걸 View가 원하는 Output으로 돌려주는 형태로 코드를 작성했다. 자연스럽게 앱 전반에서 '이벤트 방출 - 구독 - 연산 - 결과 도출'의 매커니즘으로 모든 이벤트를 Asynchronous하게 처리하는 RxSwift의 여러 API를 학습하게 되었고, 이를 통해 간단하게 UI를 컨트롤 하는 방식을 기록한다.
MVVM(Input-Output 패턴) + RxSwift 로 코드를 구성한 화면은 아래의 이미지와 같다.
로그인 화면에서는 email, password를 입력받는 TextField의 텍스트 입력 이벤트를 구독하여 조건에 따라 UI를 컨트롤한다.
shopping list 라는 타이틀을 가진 화면에서는 역시 TextField의 텍스트 입력 이벤트를 구독해서 테이블뷰에 셀을 보여주고, 컬렉션 아이템 터치 이벤트를 통해 테이블뷰를 컨트롤한다.
Input - Output 패턴
MVVM 아키텍쳐의 주요 골자는 View를 컨트롤 하는 View 객체, 앱에서 활용될 데이터에 대한 명세~메서드를 구축하는 Model 객체, 그리고 그 두 객체 사이를 연결하여 이벤트에 대한 로직을 처리하는 ViewModel 객체의 조합이다.
Input - Output 패턴도 이런 골자를 지키면서, 이벤트가 들어오는 Input 객체와 로직의 처리 결과로 View에게 반환되는 Output 객체를 각각 구분하는 컨셉을 가진다. ViewModel에서 활용되는 패턴으로, View에서는 Input 객체에 이벤트를 실어 ViewModel이 이벤트를 구독할 수 있게 한다. Input과 Output 객체를 연결하는 통로는 transform(Input) → Output 이라고 하는 메서드를 보통 활용한다.
프로토콜로 Input - Output 패턴으로 ViewModel 구현의 제약을 정해줄 수도 있겠다.
protocol InputOutputType { associatedtype Input associatedtype Output var disposeBag: DisposeBag { get set } func transform(input: Input) -> Output }
Input - Output 패턴이 적용된 ViewModel의 전형적인 모습은 아래와 같다.
import RxSwift import RxCocoa final class ViewModel { private let disposeBag: DisposeBag() struct Input { // 구독할 이벤트별로 프로퍼티를 지정해준다. } struct Output { // 이벤트 처리 결과에 따라 만들어진 Observable을 보통 반환한다. } func transform(input: Input) -> Output { .. return Output } }
내가 파악한 Input - Output 패턴의 핵심은 요정도이다.
View단에서 전달하려고 하는 Event Input과 View단에서 필요로 하는 Data(Disposable한) Output을 각각의 구조체에 묶어 보다 명확하게 인지할 수 있다.
결국 Output 객체의 프로퍼티로 전달하는 값도 Disposable을 반환하는 Observable 객체이다.
이벤트에 따라서 변화하는 Output 값을 View 단에서도 Observer에 구독시켜서 UI를 업데이트 한다.
RxSwift, RxCocoa 라이브러리가 가지는 API를 잘 활용하면 보다 편하게 Event Emit을 컨트롤 할 수 있다.
Login 정보 검증 화면
로그인 화면에서 이메일 주소 정보가 xxxx@xx.xxx 의 형태와 같이 입력이 되는지 / 비밀번호가 8자 이상인지와 같은 조건을 검증하고 싶다. ViewController에서 TextField의 Delegate 패턴을 적용하여 처리할 수 있겠다.
커스텀한 Observable 객체로는 Observable<String?>(fieldInput) 형태로 값의 변화를 ViewModel이 인지할 수 있게 property로 구축해둘 수 있을 것 같다.
RxCocoa 기반으로는 TextField.rx.text 와 같은 형태로 Rx에서 제공하는 Wrapper로 이벤트를 감싸서 텍스트 필드의 입력 이벤트(정확하게는 입력된 String? 값에 대한 이벤트)를 Observable 형태로 만들 수 있다.
import RxSwift import RxCocoa final class SomeViewController: UIViewController { private let textField = UITextField() .. private func bindView() { .. let input = SomeViewModel.Input( // text 입력에 대한 이벤트를 ViewModel의 Input 인스턴스에 반영 textFieldChange: textField.rx.text ) } }
이렇게 형성한 이벤트 Emit을 Input 객체에 전달해주면, ViewModel의 transform 메서드가 인자로 받은 Input 객체의 해당 이벤트 프로터티를 활용하여 내부 연산을 돌린다.
final class SomeViewModel { .. struct Input { let textFieldChange: ControlProperty<String?> } struct Output { let emailValidationText: PublishRelay<String> } func transform(for input: Input) -> Output { .. let emailValidationText = PublishRelay<String>() // 전달받은 textfield의 이벤트를 여기서 구독하여 특정 값 처리를 한다. input.textFieldChange.orEmpty .map { self.emailValidator(for: $0) && $0.count >= 3 } .subsribe(self) { owner, valid in emailValidationText.accept(valid ? "검증 성공" : "검증 실패") } .disposed(by: disposeBag) .. return Output( emailValidationText: emailValidationText ) } }
ControlProperty<Type> 은 ViewController 코드에서 textField.rx.text 로 넘겨준 Observable의 타입이다.
RxCocoa에서 지원해주는 Event Emit Wrapper에 대한 타입이다.
UIControl interface에 적용을 받는 View 요소들을 감싸서, Control 이벤트를 Rx가 이해할 수 있게 맵핑해주는 것으로 보인다.
UITextField 역시 addTarget 메서드로 이벤트를 제어할 수 있는 객체이기 때문에 해당 wrapper로 감쌀 수 있겠다.
transform 메서드에서는 전달받은 Observable에 대한 구독을 진행하기 전에 필요로 하는 형태로 변형 / 연산 / 결합 등을 하는 Stream 과정을 거친다.
Rx에서는 UI 이벤트뿐만 아니라 내부 비즈니스 로직에서 활용될 수 있는 상태값에 대한 Observable을 여러 형태로 가공하기 위해서 Operator를 제공한다.
입력받은 TextField의 text가 이메일 주소 형태와 동일한지 검증하는 절차도 이 Stream 과정에 반영된다.
이 과정까지도 Observer에 대한 구독이 발생하지 않았기 때문에 어떤 처리도 되지 않는다.
.subscribe .bind .driver 와 같은 Subscribe Operator가 체이닝 되는 시점에 비로소 Observer에 필요로 하는 이벤트가 전달된다. (이래서 비동기성 API라고 하는 것 같다.)
subscribe 함수가 체이닝 되면서 email 검증 결과에 대한 Bool 값에 따라 Output에 필요한 새로운 Observable을 생성한다.
dispose로 직접 구독을 취소하지 않고 있기 때문에, textfield의 입력이 발생할 때마다 해당 로직이 반복된다.
ViewModel의 transform 메서드에서 맵핑된 Output 객체는 다시 ViewController에서 Observable로 활용된다. ViewController에서 이벤트에 대한 Observable을 전달했다면, ViewModel에서는 어떤 값을 Emit 하는 것이라고 판단하면 편하다.
// SomeViewController private func bindView() { .. let input = .. // 위에 작성한 코드 참고 let output = viewModel.transform(for: input) // email 검증에 따른 결과 값(여기서는 PublishRelay<String>한 Observable)을 // emailValidationLabel 이라고 하는 Observer에 구독한다. output.emailValidationText .bind(to: emailValidationLabel.rx.text) // view에 바인딩 .disposed(by: disposedBag) .. }
Output으로 전달받은 PublishRelay Observable을 emailValidationLabel 이라고 하는 View 객체에 바인딩하면서 새로운 구독을 형성했다.
PublishRelay, BehaviorRelay 는 RxCocoa 라이브러리가 각각의 Subject를 더욱 UI 컨셉에 맞게 한 번 더 감싼 Observable 객체라고 생각하면 된다.
Subject와의 큰 차이는 .onComplete .onError 에 대한 처리를 신경쓰지 않는다는 것이다.
이렇게 Input-Output 구조로 형성된 Event → Emit → Subscribe → transform → New Emit → UI Bind 형태의 고리는 ViewController가 deinit 되기 전까지 유지된다. (disposedBag을 사용했기 때문에.)
위의 과정을 내가 이해한 바에 따라 간단하게 도식화 해보면 아래의 그림과 같이 나올 수 있다. 그렇지만 역시 중요한건 이것 또한 MVVM의 어느 한 방법에 불과하다는 것이다. MVVM에 정답은 없다. LogInView에 대한 코드는 여기서 확인 가능하다.
TableView, CollectionView가 함께 있는 뷰에서의 Rx + MVVM Input-Output 패턴
테이블뷰, 컬렉션뷰가 함께 있는 위와 같은 뷰도 Input-Output 패턴을 활용하는 방식은 동일하다. 다만, 테이블뷰나 컬렉션뷰는 리스트 형태의 데이터를 기반으로 스크롤이 되는 UI를 그려야 하기 때문에 Cell을 바인딩하고, 그 Cell에 각 indexPath에 맞는 데이터를 바인딩해줘야 한다. delegate, datasource 프로토콜에 구현된 메서드를 활용하는 것과 그 방식이 크게 차이나지는 않는다.
우선, 리스트 형태의 데이터 Observable을 테이블뷰, 컬렉션뷰에 UI로 바인딩 해보자. 준비되어야 할 것은 결국 Disposable한 데이터 Observable이다. ViewModel의 Output 객체에서 반환해주는 Relay, Subject를 잘 활용하자.
// SomeViewController private func bindView() { .. let cellButtonTouch = PublishRelay<Int>() let input = SomeViewModel.Input( .. cellButtonIndex: cellButtonTouch ) let output = .. // 위에 작성한 코드 참고 output.collectionViewDatalist .bind(to: collectionView.rx.items( cellIdentifier: Cell.id, cellType: Cell.self )) { row, item, cell in // 이 클로저 안에서 cell instance에 대한 ui 작업 호출 cell.bindView(for: item) cell.someButton.rx.tap .bind(with: self) { _, _ in cellButtonTouch.accept(row) } .disposed(by: cell.disposeBag) // ⭐️ } .disposed(by: disposeBag) .. }
cellIdentifier, cellType 과 같은 인자를 보면 UITableViewDatasource 와 같은 프로토콜이 강제해주는 cellForItem 과 활용법이 거의 비슷함을 알 수 있다.
cell 안에 구성되어 있는 View 요소의 이벤트를 감지해서 ViewModel이 처리해줄 수 있어야 하는 경우가 많다.
예를들어, 어떤 아이템에 대해 좋아요를 처리한다던지, 장바구니에 담기를 한다던지..
그런 경우에는 해당 요소를 인지할 수 있는 특정 Observable을 만들어 ViewModel의 Input 객체에 넣어줄 수 있는 형태로 맵핑해주는 과정이 필요하다.
위에서는 핸들링 하고자 하는 Cell의 row 값을 PublishRelay<Int> 형태의 Observable로 맵핑하여 Input에 넣어주고 있다.
결국, Rx로 테이블뷰나 컬렉션뷰를 다루기 위해서도 각 이벤트, 각 데이터에 대한 Disposable 한 Observable을 만들어 Input - Output에서 각각 구독할 수 있게 만들어야 하는 것이 핵심이다.
UITableViewDelegate나 UICollectionViewDelegate와 같은 프로토콜에서는 didSelectItemAt 라는 형태로 개별 Cell 선택에 대한 이벤트를 처리해주는 메서드가 있다.
RxCocoa에서도 Cell 내부 요소 말고, Cell 자체를 선택하는 이벤트에 대한 Observable을 처리해주는 방식이 있다.
// SomeViewController private func bindView() { .. let cellSelected = PublishRelay<(Int, SomeData)>() Observable.zip( collectionView.rx.itemSelected, collectionView.rx.modelSelected(SomeData.self) ) .bind(with: self) { vc, cellTuple in // itemSelected에서 확인되는 IndexPath 값과 // modelSelected에서 확인되는 cell의 Data 값을 // Tuple 형태로 반환해준다. cellSelected.accept((cellTuple.0.row, cellTuple.1)) } .disposed(by: disposeBag) .. }
.itemSelected 는 선택된 cell의 indexPath를 Observable Stream에 넘겨준다.
collection.rx.itemSelected .bind(with: Object, onNext: (Object, IndexPath) -> Void)
.modelSelected(model.Type) 은 선택된 cell에 바인딩 된 data 값을 지정해서 Observable Stream에 넘겨줄 수 있다.
collection.rx.modelSelected(SomeData.self)
두 Operator를 모두 잘 활용하고, 보통 합쳐서 활용하는 경우가 많아서 .zip Operator를 활용해, Tuple 형태로 Observable Stream에서 활용한다.
TableView, CollectionView를 함께 Rx + Input-Output 패턴으로 다룬 코드는 여기서 확인할 수 있다.
결국, 내가 생각하기에 RxSwift, RxCocoa를 활용해서 앱을 그리고 이벤트를 처리하는 것은
이벤트 수집과 방출을 위한 Observable을 어떻게 만들고
만들어진 Observable의 구독을 위해 Disposable한 형태로 전달해서
다시 View에서 구독할 수 있는 또 다른 Observable로 만들어내는 구독 과정을
잘 연결하는 과정이라고 생각한다. 확실히 커스텀한 Observable 객체를 만들어서 MVVM 패턴으로 활용해본 경험이 RxSwift에 접근하는데 많이 도움이 된 것 같다. RxSwift의 더욱 다양한 Operator, Trait 들을 활용해보면서 Rx가 가지는 기본 컨셉, Asynchronos 한 앱 구성에 익숙해지도록 해봐야 할 것 같다.
Ha
Subscribe to 'hankyeol'
Welcome to 'hankyeol'!
By subscribing to my site, you'll be the first to receive notifications and emails about the latest updates, including new posts.
Join SlashPage and subscribe to 'hankyeol'!
Subscribe
👍
Other posts in 'Swift | 학습 내용 정리'See all
한결
[SwiftUI] 스유에서 뷰를 그리고(draw) 업데이트하는 데이터 흐름 관리 - @propertyWrappers 1
@propertyWrapper..? propertyWrapper는 Swift 5.1+ 에 소개된, 이름 그대로 property를 감싸는 역할을 하는 어트리뷰트다. 어떤 상태를 가지는 property를 정의하고 값을 반영하는 과정을 추상화 할 수 있게 해준다. 제네릭을 이용해서 다양한 타입을 가질 수 있는 멤버 변수도 동일한 로직을 타게 할 수 있다. 말이 너무 어려운데, propertyWrapper로 많이 관리되는 UserDefaults가 역시 나에게도 이해가 쉬웠다. UserDefaults는 String으로 된 키와 저장할 값을 기반으로 값(상태)을 저장하거나 불러올 수 있다. 저장은 새로운 값으로 업데이트가 될 수 있다는 뜻으로도 쓰일 수 있다. (덮어 쓸 수 있다는 말) UserDefaults에 값을 저장, 업데이트,불러오는 등의 로직은 아주 단순하지만 사용할 때마다 그 구문을 반복해야 한다. 그래서 보통 UserDefaults를 관리하는 객체를 만들어서 활용하는데, 이때 propertyWrapper 개념을 접목하면 조금 더 활용도가 높아진다. propertyWrapper 어트리뷰트가 붙은 객체는 내부적으로 wrappedValue라고 하는 연산 프로퍼티를 구현해주어야 한다. 이 wrappedValue 로직을 통해 멤버에 대해 동일한 로직을 반영해줄 수 있다. 생성자를 통해서 기본값도 넣어줄 수 있다. 정의한 propertyWrapper 객체는 어트리뷰트처럼 활용할 수 있다. @로 호출한 propertyWrapper의 생성자에 필요한 초기 값을 넣어준 형태로 멤버에 반영해주면, 따로 해당 멤버의 값(상태)을 불러오거나 업데이트 하는 로직을 신경쓰지 않아도 된다. SwiftUI에서도 다양한 propertyWrapper들이 활용되고 있는데, 특히 뷰를 그리고, 뷰를 업데이트하는 데이터(상태 값)를 효율적으로 관리할 수 있게 도와주는 로직이 구현되어 있다. @State 이름에서 알 수 있듯이, View 객체의 데이터 상태를 관리하는 멤버 앞에 붙는다. View struct 안에서 활용되기에 당연히 View 객체 안에서 초기화 되어야 한다. 특정 View 객체 안에서 사용되고, 초기화되기 때문에 외부에서 주입을 받아 상태가 관리되지 않아야 한다. (사실 주입은 받을 수 있겠지만, 내부에서 그 주입받은 상태가 관리되지 않기 때문에 private 사용이 권장된다.) 뷰 객체 내부에서 활용되는 자식 뷰 객체에게 그 상태값을 바인딩 프로퍼티와 함께 전달해줄 수 있다. 가장 좋은 점은, @State로 관리되는 상태값에 따라 뷰가 fresh-render되고 뷰가 살아있는 동안 그 상태값이 유지된다는 것이다. class의 인스턴스와 같은 참조형을 상태값으로 활용할 수는 있지만, 해당 인스턴스의 값을 변경한다고 하더라도 상태가 변경되었다고 인지되지는 않는다. (@Published, @ObservableObject와 같은 wrapper가 붙으면 말이 달라지긴 하지만) State 의 구현부를 타고 가보면 DynamicProperty 라는 프로토콜을 채택하고 있는 것을 볼 수 있다. DynamicProperty 프로토콜은 내부적으로 update라고 하는 메서드를 가지고 있고, 이 메서드를 통해서 변경된 상태를 인지하고 뷰를 새롭게 업데이트 해주게 된다.
한결
Swift - 의존성 주입과 MVVM
의존성과 주입 의존성 : 다른 것에 의지하여 생활하거나 존재하는 성질. 이라고 국어 사전에 정의되어 있다. 코드에 의존성이 생긴다는 것은 어떤 것일까? 쉽게 생각해보면, 어떤 클래스 내부에서 다른 클래스로 인스턴스를 생성하고, 그 인스턴스를 활용하는 것을 코드적인 의존성이 만들어졌다고 볼 수 있을 것 같다. 위의 SomeViewController 코드에서 보면, SomeViewController라고 하는 클래스는 APIService라고 하는 특정한 클래스에 의존성을 가지고 있다. APIService 내부에 구현된 fetch 라고 하는 메서드를 내부에서 활용하는데, APISerivce 클래스 구현부에서 해당 메서드의 이름을 fetches 라고 바꾼다고 하면 어떻게 될까? 당연하게도 SomeViewController 코드에서도 그 이름에 맞게 코드를 바꿔줘야 한다. 이것만이 아니라, 해당 인스턴스를 다른 클래스의 인스턴스로 바꾼다고 가정하면 코드로 바꿔줘야 하는 부분은 더 늘어날 수 있다. 코드에서는 의존성이 발생하지 않게 하는 것은 쉽지 않다. *싱글톤으로 작성된 객체를 타입 멤버로 접근한다면, 클래스 내부에서 의존성이 생기지 않을 수는 있겠다. 주입 : 흘러 들어가도록 부어 넣음. 이라고 국어 사전에 정의되어 있다. 코드에서 '주입'을 한다는 것은 쉽게 생각해보면 인스턴스를 생성할 때, 생성자에 값을 넣어(=주입하여) 내부의 저장 속성의 값을 초기화 시켜주는 것이라고 생각해볼 수 있다. 그러면 의존성을 주입한다는 것은, 외부에서 특정 클래스의 인스턴스를 만들어서 생성자로 전달을 하는 행위를 말하는 걸까? 아래의 코드처럼 APIService의 인스턴스를 단순히 생성자로 넣어준다고 하더라도 SomeViewController는 여전히 APIService에 의존성을 가지고 있다. 의존성을 넣어주는 것이기 때문에 의존성 주입이라고 볼 수 있겠지만, 정확하게 APIService 라고 하는 타입의 인스턴스를 넣어줘야 해서 확장성이 떨어진다. Swift에서의 의존성 주입 그러면 확장성을 갖추면서도 의존성을 외부에서 분리시키는 방법은 Swift에서 어떻게 할 수 있을까? 혼자 질문을 던지고 바로 답을 내려버리는 것 같아서 좀 그렇지만, Protocol as a Type의 개념을 활용할 수 있을 것 같다. Swift에서 프로토콜은 정말 다양한 방식으로 활용되는데, 단순히 어떤 객체에 구현부를 강제하는 것을 넘어서 비슷한 역할을 하는 객체들을 하나의 타입으로 묶어줄 수 있는 모듈러 역할로 활용할 수 있다. 즉, 특정 프로토콜을 동일하게 채용하는 클래스는 어느정도 '아 그 프로토콜의 일을 하겠구나'를 쉽게 유추할 수 있다. 이렇게 동일한 프로토콜을 채용한 객체(=클래스의 인스턴스)를 생성자로 주입시키면 어떨까? 이럴경우, SomeViewController는 이제부터 SomeDataRelatedProtocol이라는 프로토콜 타입에 의존성을 가지게 된다. 그러면 외부에서 해당 프로토콜을 채용한 어떤 객체 타입도 주입할 수 있게 된다.(Protocol as a Type) 주입하는 객체를 쉽게 교체할 수 있고, 쉽게 확장할 수 있다. 역으로, 주입되는 객체 역시 SomeDataRelatedProtocol이라는 프로토콜에 의존성을 가지기 때문에 오히려 역의 의존성 체계가 설계된다. 즉 구체적인 객체가 추상적인(=프로토콜 타입) 요소에 의존하게 되는 의존 관계 역전 원칙을 따르게 된다. MVVM 아키텍처는 왜 쓰는걸까? 아니 아키텍처는 왜 나누는 건가? 작은 앱을 혼자서 만들어간다면 ViewController 안에 데이터 모델링 코드, Network API 코드, 뷰를 그리는 코드 등을 모두 구현하는 것도 나쁘지 않을 수 있다. 어차피 ViewController가 어떻게든 접근해야 하는 객체나 뷰를 만들기 때문이다.
한결
[Swift - UIKit] Swift 프로젝트에서 VC간에 데이터를 전달하는 4가지 방법
모바일 앱의 특성상, 작은 화면에서 한 번에 많은 데이터를 보여주는 것이 쉽지 않다. 그래서 하나의 앱에서도 다양한 형태의 데이터를 다양한 페이지에서 보여주고 있다. 그런 이유로 페이지간 데이터 전달이 중요한데, 지금까지 내가 학습한 4가지의 데이터 전달 방식에 대해 기록해두고 기억해보고자 한다. Swift는 기본적으로 클래스, 구조체로 화면에 대한 구조(=인스턴스)를 만든다. 구조의 멤버들은 뷰의 객체로서(아닌 경우도 있지만) 짜여진 구조에 맞게 데이터를 그려낸다. 인스턴스를 만드는 것이기 때문에 그 인스턴스가 생성되는 시점 + 생성되어 활용되는 그 구조의 공간이 무엇보다 중요하다. 전환하고자 하는 페이지(거의 VC)의 인스턴스를 생성하면, 내부의 멤버에 직접/간접적으로 접근해서 값을 할당해주는 것이 값 전달의 기본이다. 인스턴스의 멤버에 값 할당하기 해당 방법으로는, 넘어가고자 하는 VC의 인스턴스를 생성하고 해당 VC의 생명주기가 활성화되기 전에 인스턴스 멤버나 인스턴스 메서드를 실행시키는 형태로 다른 VC에 값을 전달한다. 넘어가고자 하는 VC에 대한 명확한 공간(=인스턴스)를 하나의 스코프 내에서 컨트롤 할 수 있기 때문에, 어떻게보면 가장 쉬운 데이터 전달 방식이 될 수 있다. '이전 VC에 대한 인스턴스를 생성하여 값을 넘겨주는 방식으로 넘어오기 전 VC로 접근할 수 있겠구나!' 라고 생각할 수 있겠지만, (어떻게 보면 당연하지만) 그렇지 않다. 넘어온 VC 환경에서 이전 VC에 대한 인스턴스를 생성한다는 것은 (아래 그림처럼) 완전히 새로운 VC의 인스턴스 환경을 구축하는 것과 같다. (⇒ 평행 세계에 이름만 같은 공간을 찾아가는 느낌이랄까) 그렇기 때문에, 넘어오기 전의 환경으로 컨택스트를 넘겨줄 수 없다는 의미가 된다. 클로저 활용하기 해당 방법으로는, 넘어가거나, 넘어온 VC에 값을 전달하는 간단한 익명함수(클로저)를 선언하고 (멤버 변수) VC 인스턴스에 접근하는 곳에서 해당 익명함수(클로저)의 내부 로직을 구현해주고 필요한 시점에 클로저를 호출시켜 컨택스트를 해당 시점으로 가져오는 형태로 다른 VC에 값을 전달한다.