[UIKit] UIResponder (feat. Responder, Responder Chain, FirstResponder)

오늘부터 미라클 모닝 시간에 1일 1유아이킷 포스팅을 해보려고한다. 구현위주의 공부를 하다보니, 기초지식이 너무 부족하다고 느껴졌고, UIKit의 구조를 정확하게 파악하고 싶어서 시작! 

 

🔵 UIResponder

xcode프로젝트르 만들면 AppDelegate와 SceneDelegate를 처음으로 접하게 되는데, 이 두개의 클래스는 동일하게 "UIResponder"를 상속받는다.

우선 공식문서가 정의한 개념부터 차근차근 읽어보자.

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

Apple Developer Documentation

An abstract interface for responding to and handling events.

이벤트에 응답하고 처리하기 위한 추상 인터페이스이다.

Responder objects—that is, instances of  UIResponder —constitute the event-handling backbone of a UIKit app. Many key objects are also responders, including the UIApplication object, UIViewController objects, and all UIView objects (which includes UIWindow). As events occur, UIKit dispatches them to your app's responder objects for handling.

Responder 객체는 UIResponder의 인스턴스이다. 그리고 이 인스턴스가 UIKit에서 이벤트 처리의 중추역할을 한다. UIKit의 많은 객체들, UIApplication, UIViewController, UIView같은 객체들이 모두 Responder이기도 하다. 이벤트가 발생하면 UIKit은 이벤트 Responder객체에게 전달해서 처리한다. 

There are several kinds of events, including touch events, motion events, remote-control events, and press events. To handle a specific type of event, a responder must override the corresponding methods. For example, to handle touch events, a responder implements the touchesBegan(_:with:), touchesMoved(_:with:), touchesEnded(_:with:), and touchesCancelled(_:with:) methods. In the case of touches, the responder uses the event information provided by UIKit to track changes to those touches and to update the app's interface appropriately.

화면을 터치하거나 제스쳐를 취하는 등 여러가지 이벤트가 있다. 어떤 특정한 이벤트를 처리하려면 반드시 해당 이벤트에 대한 메서드를 Responder객체가 오버라이드 해서 내용을 구현한다. touchesBegan, touchesMoved 같은 메서드를 뷰 컨트롤러와 UIView에서 정의할 수 있었던 것도 모두 이 객체들이 Responder이기 때문이다. 예를들어 터치이벤트가 발생하면 responder객체는 UIKit에서 제공하는 정보를 기반으로 앱의 인터페이스를 업데이트한다.

In addition to handling events, UIKit responders also manage the forwarding of unhandled events to other parts of your app. If a given responder does not handle an event, it forwards that event to the next event in the responder chain. UIKit manages the responder chain dynamically, using predefined rules to determine which object should be next to receive an event. For example, a view forwards events to its superview, and the root view of a hierarchy forwards events to its view controller.

이벤트를 처리하는 것 뿐만아니라 UIKit 의 responder들은 자신이 처리하지 않는 이벤트를 앱의 다른 요소들에게 전달하는 역할도 수행한다. 만약에 어떤 responder가 이벤트를 처리하지 않으면 이 객체가 Responder Chain의 다음 responder에게 이벤트를 전달한다. Responder chain은 UIkit에 의해 미리 정해진 규칙에ㄷ 따라 동적으로 관리된다. 예를들어 View는 자신의 super view에게 이벤트를 전달하고, 최상위에 있는 view는 ViewController에게 이벤트를 전달한다.

Responders process UIEvent objects but can also accept custom input through an input view. The system's keyboard is the most obvious example of an input view. When the user taps a UITextField and UITextView object onscreen, the view becomes the first responder and displays its input view, which is the system keyboard. Similarly, you can create custom input views and display them when other responders become active. To associate a custom input view with a responder, assign that view to the inputView property of the responder.

Responder 객체들은 UIEvent 객체들을 처리하지만 input view를 통해서 커스텀 입력을 받을 수도 있다. 가장 대표적인 custom input 예시는 키보드이다. 사용자가 화면에 있는 UITextField와 UITextView을 탭하면, 해당 뷰는 First Responder가 되어 입력뷰 (키보드)를 표시한다. 이처럼 개발자는 커스텀 입력뷰를 만들어서 어떤 responder객체가 활성화되면 화면에 표시되도록 할 수 있다.

 

🔹 UIResponder 의 역할 정리

그래서 요약해보면, 아래와 같다.

1. UIResponder는 이벤트가 발생하면, 처리해서 내용을 구현하는 일을 주로 맡아서 한다.
2. 이벤트를 처리하는 일 뿐만 아니라, 자신이 처리하지 않는 이벤트는 Responder Chain 규칙에 의해 정해진 다음 responder에게 이벤트를 전달하는 역할도 한다.
3. input view를 통해서 커스텀 입력을 받을 수도 있다.

공식문서를 보면서 이벤트를 처리해주는게 UIResponder인건 알겠다. 근데 모르는개념이 세가지 나와서 '파란색'글씨로 표시해뒀다. 해당 개념들을 차근차근 알아보면서 더 명확하게 이해해보자.

 

🔵 Responder 객체

Responder는 이벤트를 핸들링하고 반응할 수 있는 객체이다. 모든 Responder객체는 UIResponder에서 상속된 클래스들의 인스턴스이다. 그니까 UIResponder 클래스의 인스턴스들을 Responder 객체라고 한다. 대표적으로 UIView, UIView의 서브클래스인 UIWindow, UIViewController, UIApplication 등이 있다.

위에서 설명했듯, Responder는 이벤트를 전달 받았으면 반드시 그것을 처리하거나 다른 Resonder객체로 넘겨주어야한다. 앱이 이벤트를 전달받았을 때, UIKit은 자동으로 이벤트를 처리하기에 가장 적절한 Responder 객체로 이벤트를 전달한다.

여기서 이벤트를 처리하기에 가장 적절한 Resonder객체를 FirstResponder라고 한다!

 

🔵 Responder Chain

처리되지 않은 이벤트들은 리스폰더에서 다른 리스폰더로 Active Responder Chain을 따라 이동한다. resopnder chain은 앱의 responder 객체에 따라 동적으로 구성된다. (매번 같지는 않다는 얘기!)

아래 그림은 UILabel, UITextField, UIButton 그리고 두 개의 백그라운드 View로 UI를 구성한 responder들을 보여주는 그림이다. 그림에서는 화살표를 통해 responder 객체들이 responder chain을 구성한다.

화살표방향으로 처리되지 않은 이벤트들이 전달된다고 이해하면 된다.

만약 UIButton이 전달받은 이벤트를 처리하지 않는다면, UIKit은 Button의 super view인 UIView로 우선 전달한다. 이 UIView에서도 이벤트 처리를 하지 않는다면, UIView의 루트뷰인 UIView(두번째 청록색!)으로 전달된다. 여기서도 처리하지 않는다면, 이 view와 연결된 ViewController를 거쳐 UIWindow까지 연쇄적으로 전달된다. 여기서도 이벤트가 처리되지 못하면, UIApplication까지 올라가서 처리될 수도 있다. 여기서도 이벤트가 처리되지 않는다면, 삭제된다.

(UIView의 정의를 살펴보면, UIResponder를 상속받고 있다. UITextField는 UIControl을 상속받고있는데, UIContrl이 UIResponder를 상속받고 있기 때문에 위의 Responder chain을 호출할 수 있다.)

아래 Method들은 responder chain을 관리해주는 메소드들이다. 간단하게 설명하자면 아래와 같지만, 더 자세한 내용은 나중에 다뤄보도록 하자.

• becomeFirstResponder : window의 첫번째 responder로 만들기위해 사용
• resignFirstResponder : window의 최초 responder로서 상태를 양도하도록 요청받았음을 알린다. (즉, UITextField에서 resignFirstResponder()를 호출하면, 키보드가 사라지는게 그 예시이다.)

 

🔹 이벤트의 First Responder 결정하기

그럼 어떻게 UIKit은 firstResponder를 설정할까? UIKit은 '발생한 이벤트의 타입'을 기준으로 firstResponder를 설정한다. 여기서 말하는 event 는 UIEvent의 인스턴스인데, 여러 type의 이벤트가 존재한다.

https://developer.apple.com/documentation/uikit/uievent/1613840-type

Apple Developer Documentation

여기서 가장 자주 발생하는 이벤트는 터치 이벤트이다. (press는 물리 키에서 발생하는 이벤트, remote-control은 헤드폰 등 외부 기기에서 누르는 버튼에서 발생하는 이벤트, editing menu는 핸드폰에서 text를 짧게 혹은 길게 누를 때 뜨는 메뉴를 의미한다. shake-motion은 흔들때 발생하는데, 이것은 responder chain에서 처리하지 않고 core motion 객체로 전달된다.)

 

🔹 어떤 Responder가 이벤트를 포함하고 있는지 결정하기

UIKit은 뷰 기반의 hit-testing을 사용하여 터치 이벤트가 어디서 발생했는지 결정한다. 더 구체적으로 말하면, UIKit은 터치 이벤트가 발생한 위치와 뷰 계층의 뷰 오브젝트의 bounds와 비교한다.
UIView의 hitTest(_:with: ) 메서드는 view 계층을 돌아다니면서 이벤트가 발생한 터치 지점을 포함하고 있는 view의 계층 가장 최하단 subView를 찾고, 그것을 touch이벤트의 first responder로 지정한다. 만약 터치 이벤트가 발생한 위치가 view의 bounds 밖에 있다면, hitTest(_:with: )은 해당 뷰와 서브뷰를 모두 무시한다. (아래 hitTest 포스팅 링크로 들어가서 hitTest에 대해서 살펴보면 더 명확한 이해가 될 것이다!)

결과적으로 view의 속성 clipsToBounds가 false로 설정되어 있을 때, view의 bounds를 벗어난 서브뷰에서 터치가 발생했더라도 hitTest는 view를 리턴하지 않는다.

 

와.. 무슨말인지 정말 이해가 되지 않잖아? 다음 포스팅에서 hit testing에 대해서 살펴보자...... 도대체 이건 또 뭔개념이야!

https://zeddios.tistory.com/536

iOS ) hitTest

 

이렇게 오늘은 UIResponder에 대해서 알아봤다. 하나의 개념을 알기위해서 몇개의 개념을 찾아봤는지 모르겠다. 더이상 새로운 개념을 머리에 넣으면 아무것도 남지 않을 것 같기에, 오늘은 responder에 대한 정의와 개념만 정확하게 이해한 것으로 만족하고, hitTest에 대한 개념은 다음 포스팅으로 만나보자.... 

 

👀 hitTest에 대해서 알아보러가기 👉

https://didu-story.tistory.com/292

[UIKit] hitTest(_: with: ) - 터치이벤트에 반응할 view 찾기, first responder

 

📖 References

https://zeddios.tistory.com/538

iOS ) UIResponder

https://jeonyeohun.tistory.com/257

[iOS] UIResponder: iOS의 이벤트 처리 - Responder Chain과 First Responder

https://seizze.github.io/2019/11/26/iOS%EC%9D%98-Responder%EC%99%80-Responder-Chain-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0.html

iOS의 Responder와 Responder Chain 이해하기

https://woozzang.tistory.com/144

[iOS] 리스폰더 체인 (Responder Chain) 이란? (feat. UIResponder, First Responder, UIEvent)