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

 안녕하세요🐶

 

이번 시간에는 리스폰더 체인 (Responder Chain) 에 대해서 공부해보겠습니다.

 

리스폰더 체인을 공부하면

앱 내에서 이벤트가 어떤 방식으로 전달되는지 알 수 있게 될 것입니다.

 

이 글에서 다루는 것:

UIResponder, Responder Chain, First Responder, UIEvent

 

 

 

그럼 시작해볼게요🔥

---

 

리스폰더 체인은 리스폰더 오브젝트들이 동적으로 구성된 이벤트 전달 체인 입니다.

 

앱은 리스폰더 오브젝트를 사용하여 이벤트를 처리합니다.

 

여기서 리스폰더 오브젝트란 UIReponder 클래스의 인스턴스를 가리킵니다.

 

대표적으로 UIView (그리고 UIView의 서브클래스인 UIWindow) , UIViewController, UIApplication 가 있습니다.

 

리스폰더는 Event Raw Data 를 받을 수 있습니다.

 

만약 리스폰더가 이벤트를 받았다면 리스폰더는 반드시 그것을 처리하거나, 다른 리스폰더 오브젝트로 넘겨주어야 합니다.

 

앱이 이벤트를 전달받았을 때,

UIKit 은 자동으로 이벤트를 처리하기에 가장 적절한 리스폰더 오브젝트로 이벤트를 전달합니다.

 

 

여기서 이벤트를 처리하기에 가장 적절한 리스폰더 오브젝트를 First Responder 라고 합니다.

원래는 이런 뜻

 

처리되지 않은 이벤트들은 리스폰더에서 다른 리스폰더로

실시간 리스폰더 체인 (Active responder chain) 에 따라 이동합니다.

 

이 리스폰더 체인은 앱의 리스폰더 오브젝트에 따라 동적으로 구성됩니다.

 

아래 그림은 Label, Textfield, Button 그리고 두 개의 백그라운드 View 로 UI 를 구성한 앱의 리스폰더들을 보여주고 있습니다.

 

그림의 화살표를 통해 오브젝트들은 리스폰더 체인으로 구성되는 것입니다.

 

화살표 방향으로 처리되지 않은 이벤트들이 전달 됩니다.

 

 

 

 

만약 Textfield 가 전달받은 이벤트를 처리하지 않는다면 어떻게 될까요?

 

UIKit 은 TextField 의 수퍼뷰인 UIView 로 우선 전달합니다.

 

만약 이 UIView 도 이벤트를 처리하지 않는다면, UIWindow 의 루트 뷰인 (두 번째 청록색) UIView 로 전달 될 것입니다.

 

루트 뷰에서, 리스폰더 체인은 루트 뷰를 소유한 뷰 컨트롤러로 이벤트를 전달합니다.

 

윈도우로 전달하는 것은 그 이후 입니다.

 

 

>> 윈도우에 대해 궁금하다면?? <<

 

 

만약 윈도우가 이벤트를 처리할수 없다면, UIKit 은 이벤트를 UIApplication 오브젝트로 전달합니다.

 

이후 앱 델리게이트에 전달될 가능성도 있습니다.

---

 

Determining an Event's First Responder

" 이벤트의 First Responder 결정하기 "

 

위에서 UIKit 은 이벤트를 가장 적절한 리스폰더 오브젝트에 전달한다고 언급했는데요.

 

그리고 이 오브젝트를 'First Responder' 라고 부른다고도 말했습니다.

 

그렇다면 UIKit 은 어떤 기준으로 이 First Responder 를 결정하는 것일까요???

 

바로 발생한 이벤트의 타입입니당

 

여기서 말하는 이벤트는 UIEvent 의 인스턴스인데, type 에 따라 여러 종류의 이벤트가 있습니다.

 

 

여기서 가장 자주 발생하는 이벤트는 바로바로 터치 이벤트이겠죠?

 

참고로

Press 는 물리 키에서 발생하는 이벤트

Remote-control 은 헤드폰 등의 외부 기기에서 누르는 버튼에서 발생하는 이벤트,

Editing menu 의 경우 우리가 아이폰에서 Text 를 짧게 혹은 길게 누를 때 뜨는 그 메뉴입니다.

 

Editing Menu

 

Shake-motion 이벤트는 흔들 때 발생하는데,

이것은 리스폰더 체인에서 처리하지 않고 Core Motion 오브젝트로 전달됩니다.

 

---

 

컨트롤은 UIControl 을 서브클래싱한 클래스의 오브젝트들을 가리킵니다.

 

컨트롤은 target-action mechanism 으로 이벤트를 처리하죠.

 

그래서 컨트롤은 액션 메시지를 이용해 바로 자신의 타켓 오브젝트와 소통합니다.

 

액션 메시지는 이벤트가 아닙니다.

하지만 여전히 리스폰더 체인을 이용합니다.

 

컨트롤의 타겟 오브젝트가 설정되어 있지 않을 경우,

UIKit은 타겟 오브젝트부터 시작하여

액션 메서드를 구현한 오브젝트를 찾을 때까지 리스폰더 체인을 돌아다닙니다.

 

예를 들어 UIkit 의 editing menu 는 위와 같은 방식으로 작동하는데,

cut(_ :), copy(_ : ), paste(_ :) 메서드를 구현한 오브젝트를 찾으러 리스폰더 체인을 돌아다니는 겁니다.

 

Editing Menu

 

뷰 앞에 Gestsure recognizer 가 있다면, Gesture recognizer 가 먼저 이벤트를 전달받고 처리를 시도합니다.

 

만약 실패한다면, 리스폰더 체인에 따라 이벤트가 전달됩니다.

---

 

Determining Which Responder Contained a Touch Event

" 어떤 리스폰더가 이벤트를 포함하고 있는지 결정하기 "

 

 

UIkit 은 뷰 기반 hit-testing 을 사용하여 터치 이벤트가 어디서 발생하였는지 결정합니다.

 

더 구체적으로 말하자면, UIKit 은 터치 이벤트가 발생한 위치와 뷰 계층의 뷰 오브젝트의 bounds 와 비교를 합니다.

 

UIView 의 hitTest(_:with:) 메서드는 뷰 계층을 돌아다니며

이벤트가 발생한 터치 지점을 포함하고 있는 뷰의 계층 상 가장 최하단 서브뷰를 찾고,

그것을 터치 이벤트의 First Responder 로 지정합니다.

 

만약 터치 이벤트가 발생한 위치가 뷰의 bounds 의 밖에 있다면,

hitTest(_:with:) 는 해당 뷰와 서브뷰를 모두 무시합니다.

 

결과적으로 뷰의 속성 clipsToBounds 가 false 로 설정되어 있을 때,

뷰의 bounds 를 벗어난 서브뷰에서 터치가 발생하였더라도 hitTest(_:with:) 는 뷰를 리턴하지 않습니다.

 

이 hit-testing 동작에 대해서 좀 더 자세히 살펴보자면, hitTest(_:with:) 메서드를 살펴보아야하는데요.

 

 

hitTest(_:with:)

 

우선 이 메서드는 UIView 의 인스턴스 메서드이구요...

 

발생한 이벤트가 이 메서드를 호출합니다.

 

이 때 이벤트는 UIEvent 오브젝트를 가리키는 것입니다.

 

이 메서드는 전달받은 포인트에 위치한 뷰 중 자신을 포함하여 뷰 계층 최하단의 서브뷰를 반환합니다.

 

만약 호출된 뷰 계층의 바깥에서 발생한 이벤트일 경우 nil 을 반환합니다.

 

중요한 점은 호출된 뷰의 bounds 의 바깥에서 발생한 이벤트라면 nil 을 반환한다는 것입니다.

 

추가적으로 hidden이거나 alpha 값이 0.01 이하거나

user interation을 disabled 해놓은 뷰라면 무시됩니다.

 

이 메서드는 hit을 결정할 때 뷰의 컨텐츠를 고려하지 않습니다.

 

즉, 콘텐츠의 투명한 부분에서 이벤트가 발생하였어도 뷰는 반환됩니다.

 

터치가 발생한다면 UIKit 은 UITouch 오브젝트를 터치가 발생한 뷰와 관련시켜서 생성을 합니다.

 

터치의 위치나, 다른 파라미터가 변경되면 UIKit 은 동일한 UITouch 오브젝트를 새로운 정보로 업데이트 합니다.

 

이 UITouch 오브젝트에서 항상 변하지 않는 것이 있는데, 바로 view 속성 입니다.

 

이 속성은 만약 터치의 위치가 다른 뷰로 바뀌었어도 변경되지 않습니다.

( 즉, 손가락이 A 뷰에서 B 뷰 위로 이동하였어도 view 속성은 바뀌지 않습니다.)

---

 

Altering the Responder Chain

"리스폰더 체인을 변경하기"

 

 

우리는 리스폰더 오브젝트의 next 라는 속성을 오버라이딩해서 리스폰더 체인을 변경할 수 있습니다.

 

변경을 한다면, 리스폰더 오브젝트가 이벤트를 전달할 다음 리스폰더는 우리가 오버라이딩한 오브젝트가 됩니다.

 

많은 UIKit 클래스가 이미 이 next 속성을 오버라이딩 하여 사용하고 있습니다.

 

🟢 예를 들면:

UIView 오브젝트는 만약 자신이 뷰 컨트롤러의 루트 뷰라면, 다음 리스폰더 오브젝트는 뷰 컨트롤러가 됩니다.

 

루트뷰가 아니라면, 뷰의 수퍼뷰가 다음 리스폰더가 됩니다.

 

UIViewController 오브젝트는 만약 자신이 관리하는 뷰가 윈도우의 루트 뷰라면, 다음 리스폰더는 윈도우 오브젝트가 됩니다.

 

또한 만약 A 뷰 컨트롤러가 B 뷰 컨트롤러에 의해 present 되고 있다면

우리는 A 를 Presented ViewController, B 를 Presenting ViewController 라고 부르죠.

 

이 때 Presented ViewController의 다음 리스폰더는 presenting ViewController 입니다.

 

UIWindow 오브젝트 (즉 윈도우) 의 다음 리스폰더는 UIApplication 오브젝트 입니다.

 

 

 

 

끝!

---

🤖🟢[우짱의 iOS 블로그]🔵💻

iOS를 공부하면서 배운 내용을 기록하고 있습니다.

 

참고자료 1: https://developer.apple.com/documentation/uikit/touches_presses_and_gestures/using_responders_and_the_responder_chain_to_handle_events

 

참고자료 2: https://developer.apple.com/documentation/uikit/uiresponder