이벤트의 처리 방법

💼📝🔑⏰ 📙📓📘📒🎓

💼 사용자의 이벤트를 처리하는 방법

1. 콜백 메소드 재정의
2. 리스너 인터페이스의 구현
3. 액티비티를 통한 리스너의 구현
4. 뷰를 통한 리스너의 구현

💼 콜백 메소드를 통한 이벤트 처리

콜백 메소드란?

• 콜백 메소드를 재정의하면 특정 이벤트가 발생할 시점에
• 시스템에 의해 자동으로 콜백 메소드가 호출 되므로
• 이벤트의 발생 시점을 알수 있으며
• 이벤트에 대한 상세한 정보까지 얻을 수 있다.

📝 콜백 메소드 재정의

• 사용자와 상호 작용하는 주체가 View이므로 이벤트에 대한 콜백의 정의는 주로 View가 재정의 하여 제공한다.
• 사용자가 화면을 터치할 때, 키를 누르거나 떼는 등의 이벤트가 발생하면 콜백 메소드가 호출됨

📝 대표적인 콜백 메소드

• onTouchEvent : 터치 스크린 모션 이벤트를 다루고 싶을 때 실행
• onKeyDown : 키를 눌렀을 때 호출되는 메소드
• onKeyUp : 키를 눌렀다 뗄 떄 호출되는 메소드

📝 콜백 메소드 처리 흐름

1. 콜백 메소드를 재정의하기 위해서는 반드시 슈퍼클래스 View를 상속 받아야한다.
2. View의 onTouchEvent메소드를 수정할 수 없으므로, 이벤트를 사용할 클래스를 새롭게 생성해야 `onTouchEvent 메소드를 재정의 할수 있음.
3. Button이나 TextView 같은 위젯은 이벤트를 처리하기 위해 각각의 새로운 클래스를 만들어서 이벤트를 처리 해야하는 번거러움이 있음
4. 위젯이 콜백 메소드를 직접 사용하지 못하고 항상 새로운 클래스를 생성해야 한다.

📝 콜백 메소드의 한계

• 모든 이벤트에 대한 콜백 메소드가 정의되어 있지 않음.
• 선택 변경, 포커스 이동, 드래그, 진동센서, 조도센서 등과 같은 다양한 이벤트들에 대해 모두 콜백 메소드를 정의해서 제공할 수 없다.
• 확장성 제한 때문에 콜백 메소드를 재정의하는 방법은 자주 사용하는 몇 가지 이벤트에만 제한적으로 적용할 수 있다.
• 반드시 상속을 통해 콜백 메소드를 정의해야만 하는 단점이 있다.

💼 리스너 인터페이스를 통한 이벤트 처리

리스너 인터페이스란?

• 리스너는 특정 이벤트를 처리하는 인터페이스이며, 이벤트 발생을 처리한다.
• 대응되는 이벤트를 받는 하나의 메소드가 선언되어 있으며 모두 View의 내부 인터페이스로 선언되어 있다.
• 콜백 메서드의 한계점인
• 뷰를 항상 만들어야하는 단점을 해결하기 위한 방안
• 다양한 이벤트 처리가 가능

📝 대표적인 리스너 인터페이스와 메소드

• View.OnTouchListener : 터치 이벤트가 뷰에 보내졌을 떄 호출되는 메소드
• View.OnKeyListener : 하드웨어 키 값이 뷰에 보내졌을 때 호출되는 메소드
• View.OnCLickListener : 뷰가 클릭되었을 때 호출되는 메소드
• View.OnLongClickListener : 뷰가 클릭된 상태로 유지되었을 때 호출됨
• View.OnFocusChangeListener : 뷰의 포커스 상태가 변화 되었을 때 호출됨
• View의 내부 인터페이스로 OnTouchListener 인터페이스가 선언되어 있고, 이 인터페이스는 onTouch라는 추상 메소드를 포함한다.
• onTouch 메소드를 이벤트 핸들러라고 부른다.

📝 리스너 인터페이스 처리 흐름

1. 리스너 인터페이스를 구현하는 클래스를 선언하고 추상 메소드를 구현한다.
2. 리스너 인터페이스인 TouchListener를 선언 및 생성함. (TouchListenerClass)
3. 준비된 리스너 인터페이스를 View와 연결함 (setOnTouchListener)

📝 터치 이벤트 발생시 콜백 메서드와의 차이

• View에서 터치 이벤트가 발생하면 setOnTouchListener메소드로 등록된 리스너 인터페이스의 onTouch메소드(이벤트 핸들러)가 호출 된다.
• onTouch 메소드로는 이벤트와 관련된 정보가 event 인수로 전달된다.
• 리스너 인터페이스는 여러 View에 의해 공유될 수 있으므로 어떤 객체에서 발생한 이벤트인지 View 인수로 전달 받고, 콜백 메소드의 경우 특정 클래스에 소속되기 때문에 이벤트를 받는 객체가 정해져 있다.
• 콜백 메소드는 상속을 받아야만 재정의할 수 있는데 비해, 리스너는 인터페이스일 뿐이므로 임의의 클래스가 구현하여 사용할 수 있다.
• View를 상속받을 필요없이 View 객체에도 바로 붙일수 있으며 Button이나 TextView같은 위젯에서도 이벤트 처리가 가능하다.

📝리스너 인터페이스의 한계

• 리스너 인터페이스 구현을 위해 별도의 클래스를 하나 더 선언해야 한다.
• 모든 이벤트에 대해 클래스를 만든다면 소스 코드의 양도 많아지고 각 클래스마다 다른 명칭을 부여해야 한다.

💼 액티비티를 통한 리스너의 구현

• 리스너 인터페이스의 한계점인 클래스를 하나 더 선언해야 하는 문제점을 해결 하기 위한 방안
• 최소한 액티비티 하나는 존재하므로 액티비티가 리스너 인터페이스를 구현하는 것이 가능하다.

📝 액티비티의 리스너 구현

1. 액티비티는 Activity를 이미 상속 받지만 리스너 인터페이스는 개수에 상관없이 얼마든지 구현할 수 있다.
2. 선언문에서 리스너 인터페이스를 상속받고 본체에 이벤트 핸들러를 구현하기만 하면 된다.
3. 별도의 클래스를 추가로 선언하지 않고 액티비티가 리스너 인터페이스를 직접 구현한다.

📝 액티비티의 리스너 구현 처리 흐름

• 액티비티가 인터페이스를 자체적으로 구현하므로 별도의 클래스를 선언할 필요가 없다.
• 액티비티 객체가 이미 존재하므로 리스너 인터페이스를 생성할 필요도 없음.
• onTouch 메소드로 구현해 놓고 this(mainactivity)를 등록 메소드에 전달하면 된다.

📝 액티비티의 리스너 구현의 한계

• 리스너 인터페이스가 구현된 View는 액티비티에 강하게 종속된다.
• 리스너 인터페이스가 구현된 View를 다른 액티비티에 재사용하려면 액티비티가 구현하는 리스너를 분리하여 다른 액티비티로 옮겨야 한다.
• View와 관련된 메소드가 View 자신에게 포함되어 있지 않고 부모가 구현을 해주기 떄문에 독립성이 떨어짐

💼 View를 통한 리스너의 구현

• 액티비티의 리스너 구현의 한계점인 액티비티에 강하게 종속되어 재사용성이 떨어지는 부분을 해결하기 위한 방법이다.
• 액티비티 안에 View를 생성하고 클래스 선언문이 있으므로 View 자신이 필요로 하는 리스너 인터페이스를 상속받아 구현함

📝 View를 통한 리스너의 구현 처리 흐름

• View클래스 선언문에 implements 구문이 있고 View.OnTouchListener와 같이 인터페이스의 구현을 명시한다.
• setContentView에서는 View를 setOnTouchListener로 등록한다.
• 이벤트 처리를 위해 필요한 이벤트 핸들러를 이벤트가 발생한 View가 스스로 처리하는 방법으로
• 이벤트를 처리하는 메소드를 내부에 포함하기 때문에 구조상 깔끔하고 View의 재사용에도 유리하다
• 액티비티의 부담도 줄어들고 코드의 가독성이 향상된다.