Closed shippingpark closed 20 hours ago
'동작하지 않는다면 datasource나 deleagate를 엮지 않은 건 아닌지 점검하라-'
오타를 찾았어요! 선물 주나요?
'동작하지 않는다면 datasource나 deleagate를 엮지 않은 건 아닌지 점검하라-'
오타를 찾았어요! 선물 주나요?
펭귄은 눈이 좋군
네 줄 후기 개발자는 tableView의 빵꾸를 매꿔야 하는 책임이 있다. 그 빵꾸는 같은 형태로 반복적으로 나타난다. 빵꾸를 매꾸는 재료에 해당하는 것이 datasource 라면, tableView의 빵구를 매꿀 수 있는 시점을 알려주는 것이 delegate 이다.
GPT랑 대화하면 delegate 옆에 항상 주석으로 옵셔널이라고 적혀있었는데 기본 동작을 제공하고 있으니 유연한 구현을 가능하게 하는 delegate는 항상 필요한 건 아니였군요!
오 멋져요!!
하지만 티나의 말처럼 delegate를 빵꾸를 매울 시점- 이라하면 단순히 사용자의 input 또는 '인터렉션에 반응하는 메서드'라는 delegate의 역할과 dataSource의 역할이 혼동될 수 있을 것 같아요! (빵꾸를 매울 시점은 dataSource 설명에 더 가까워 보입니당!) 그러니 tableView만 아는 이벤트 시점이라고 해석하는 것이 어떨까용? 이벤트 시점에는 아무런 데이터 처리가 일어나지 않아도 되니까요?!
오! 몽쉘의 이해처럼 delegate가 항상 필요한 건 아니다라는 근본적인 이해가 중요한 것 같습니다. 저는 dataSource는 정보, delegate 는 이벤트에 대한 시점 이라고 이해하고 있습니다요!! 더 나아가서 dataSource도 옵셔널로 구현되어 있긴 하다-! 를 짚으면 좋을 것 같아용! 아마 주석이 전하고자 한 의미는 코드적인 옵셔널이 아닌, 정말 문맥상 선택사항이라는 의미를 나타낸 것 같긴 합니다 ㅎㅎ
Q) 클래스의 액션 메서드와 인터페이스 빌더의 이벤트를 연결하기 위해 메서드 앞에 붙이는
어노테이션(Annotation)과 클래스의 프로퍼티와 인터페이스 빌더의 요소를 연결하기 위해
프로퍼티 앞에 붙이는 어노테이션(Annotation)을 빈칸에 알맞게 채워보세요.
@ / @
Q) UIKit의 요소를 크게 입력과 출력으로 구분한다고 할 때,
다음 중 다른 한 가지는 무엇일까요?
왜 그렇게 생각했나요?
(답이 중요하지 않으므로 정말 고민해보기!! 필요 시 각각의 단어는 검색해서 찾아보기)
Views and Controls
View Controllers
Animation and Haptics
Windows and Screens
Touches, Presses, and Gestures
Q) iOS 앱에서는 여러 [ ]에 의해 실행할 코드가 결정되는데요. 이것을 ‘[ ] 기반 프로그래밍’ 혹은 ‘[ ] 주도 프로그래밍’이라고 표현합니다. [ ]는 사용자 혹은 시스템 등에서 여러 상황에 전달합니다. 빈 칸에 알맞은 표현은 무엇일까요? 함수 이벤트 클래스 객체 액션
button.addTarget(self, action: #selector(buttonTapped), for: .touchUpInside)
@objc func buttonTapped() { // 버튼이 탭되었을 때 수행할 작업 }
TableView로 화면 만들기
delegate
와datasource
! TableView를 구성하려면 마주할 수 밖에 없었을 거에요!TableView는 TableViewCell을 관리할 책임을 가진, UIView를 상속받아 만들어진 타입이에요 Cell을 관리한다는 건 어떤 의미일까요?
TableView이란?
이벤트
에 반응하는 메서드를 가지고 있어요!UIKit
은TableView
가 수직구조로 반복되는 화면(cell
)에 대해 다양한 처리를 할 수 있도록 만들었어요TableView가 어떻게 동작하는 지를 이해하려면, UIKit을 만든 개발자의 입장에 이입해 보면 어떨까요? UIKit 개발자들은 TableView를 만들기 앞서, 고민을 했을 겁니다
어쩌면 UIKit 제작자들의 배려
반복되는 화면 생성을 도와주고 싶긴 한데, 어떤 모양의 cell을 반복하고 싶은건지 우리는 모르잖아?
그러니 UIKit 제작자들은 TableView가 사용할 cell이 어떤 모양일지를 개발자들에게 받기로 결심했어요. 즉, TableView는 그 자체만으로는 작동이 안 됩니다. 당연한 말이죠. 어떤 cell을 몇 개 올려야 할 지 모르니까요!
UIKit 개발자들은 개발자들이 TableView를 만들때 본인들이 원하는 cell을 집어넣어줄 것이라 기대 했어요 필요하니 만들어서 직접 넣을거야 기대하면서- 미리 로직을 작성했죠
그러니 아마 TableView의 내부는 이렇게 생겼을 거에요
(
weak
! 이라는 키워드가 등장했네요! 이 키워드는 참조에 대한 개념을 필요로 합니다. 다음 시간에! )UITableView의 저장속성인 dataSource는 현재 옵셔널 값이죠? 즉, UITableView를 생성한 직후, 해당 값은 nil인 상태입니다. 즉, UITableView 자체만으로는 어떤 cell을 얼마나 생성해야 할 지 모른다는 뜻 입니다.
아마 UITableView가 cell을 채우는 내부 로직은 아마 이렇게 생겼을 거에요
dataSource가 있으면 진행하겠다! 이런 식으로요.
dataSource가 없다는 건 TableView에서 보여줄 Cell에 대한 정보가 없다는 뜻이니 (0개라도 그 또한 정보) TableView를 쓸 이유가 없다는 뜻이 되기도 해요.
TableViewDataSource
즉, UITableView는 반드시 DataSource는 개발자가 넣어주기를 기대하고 있어요.
물론, UITableView를 생성하기 위한 파라미터로 DataSource를 받아야 했다면, TableView를 사용하기 위해 필요한 정보가 무엇인지 직관적으로 알 수 있었을 지도 몰라요.
블로그 글들을 읽다보면 심심치 않게 '동작하지 않는다면 datasource나 deleagate를 엮지 않은 건 아닌지 점검하라-'는 문구를 볼 수 있거든요 그만큼 간과하기 쉽다는 거겠죠 UITableView를 분명 생성했는데, 그 자체로는 완성되지 않았다니. 받아들이기 힘들겠지만 UIKit은 그렇게 생겼어요. 필요한 재료가 빵구난 채로 생성될 수 있고, 우리는 그 속에 원하는 재료를 심어 주어야 합니다.
이렇게 만든 근본적인 이유는 개발자가 그 부족한 부분을 원하는 형태로 채울 수 있게 배려해 주기 위함이었어요. (아주 상세히 말하자면, 생성할 당시에 데이터를 넣는 게 아니라, 필요한 순간에 dataSource를 넣을 수 있게 함으로서 주입시점을 늦추어 주기도 했죠! 속성의 변화가 정체성의 변화를 야기하지 않는, class 타입이여서 가능한 일 입니다)
자! 어쨌든 이러한 개념이 바로 dataSource입니다. dataSource는 프로토콜 타입을 받는 속성 값으로, 해당 타입에는 사용자(개발자)가 정의해 주길 바라는 메서드의 헤더가 정의되어 있어요 이건 '개발자야. 이 프로토콜 채택해서 메서드 내용 구체화해서 나한테(tableView) 줘라-' 란 뜻 입니다.
TableView
의datasource
속성은UITableViewDataSource
를 채택한 클래스를 타입 객체를 필요로 했었죠? UITableView의 비워진 dataSource 값을 채워줄 객체는 대부분 TableView가 올라간 View의 Controller, 즉UIViewController
가 직접 자기 자신을 주입하는 게 일반적이에요그래서 관습적으로 이런 말이 있는거죠
'동작하지 않는다면 아래 코드가 빠진 게 아닌 지 점검하라-'
여기서 self 란? UIViewController를 상속한 나의 ViewController를 의미합니다.
class ViewController: UITableViewDataSource
<- 이 상황다시 위의 코드를 볼까요?
위 코드는 ViewController의 내부에서 자신이 소유한 tableView의 dataSource 속성 값에
자기 자신
(ViewController의 인스턴스)을 넣어주고 있는 상황이랍니다!TableViewDelegate는?
TableView와 관련하여 발생한 사건의 시점은
TableView
가 알고 있어요 (예를 들면 사용자가 cell을 터치하는 이벤트) 하지만 TableView는 그 상황에서 어떠한 이벤트, 내용을 실행해야 할 지 몰라요.cell을 눌렀을 때 색이 변해야 하는 지 데이터를 요청해야 하는지... 그에 대한 정보를 아는 건 개발자죠.
하지만 개발자는 실행시키고 싶은 내용을 알고, 실행되어야 하는 시점을 몰라요 (사용자가 cell 터치한 순간이 언제인지) 그걸 아는 건 TableView 죠. (실행시키고 싶은 내용은 몰라요)
아까 뭐라고 했죠? calss에서 dataSource는 TableView의 생성 이후에 로직을 채울 수 있도록 그 로직의 주입 시점을 미룬 것 이라 했죠! UIKit 개발자는 이 덕분에 개발자가 무슨 일을 하고 싶은 지 모르고도 TableView라는 타입을 완성시킬 수 있었어요
delegate
도 마찬가지에요delegate는 TableView가 관리할 수 있는, 인지할 수 있는 시점에 실행될 수 있는 모든 메서드의 집합 이에요. TableView는 delegate를 외부에서 주입 받는다면, 해당 delegate의 메서드를 적절한 시점에 실행시켜 줄 것입니다.
맞아요! 우리 개발자들은 TableView 만이 아는 사용자의 input에 대응하고 싶으니
delegate
를 통해TableView
가 실행할 작업을대리
하고 싶은 겁니다.그러니 dataSource와 달리 delegate는 없어도 돼요. 사용자가 tableView를 두드리는 작업에 관심이 없다면요! 물론 delegate가 없다면, TableView만이 알고 있는 이벤트 시점을 알 수는 없겠죠!