안녕하세요~✋ 치콩입니다! 🐔

블로그 이전 준비가 아직 덜되어서,, 일단 요기에 쓰고 글을 옮기는걸로!

오늘은 회사에서 외근처리로 KWDC23을 다녀왔습니다!

KWDC는 KoreaWide Developers Conference 의 약자라고 해요!

아침부터 부랴부랴 코엑스 그랜드볼룸으로 이동하였는데 언제나 느끼지만 강남은 너무 먼것 같습니다..

인천살고 있는 저에겐 강남은 너무 멀어요 ㅠㅠ

집에서 8시에 나갔는데 10시쯤 도착 하였습니다! ㅎㅎ

거두절미 하고 후기를 남겨보려고 해요!

도착하자마자 입장 줄이 엄청 길었어요,, 아무래도 1000명 이상의 인원이 모이는 컨퍼런스다 보니까 줄을서서 입장했는데요!

입장할때 굿즈로 귀여운 개구리 가방..? ( 뜯어보지 못했지만 언뜻 보기에 그렇게 보였어요! ) 과 KWDC23 뱃지를 주셨습니다!

그리고 입장하자마자 펼쳐진 광경은....

크으,, 입이 쩌억 벌어졌습니다!

그리고 

스폰서 회사에서 많이 오셨더라구요!

카카오뱅크, 점핏, 요기요, 유데미, 현대-기아 자동차 에서 부스를 운영하셨습니다!

요 부스들을 돌며 스티커를 모아야 최종 굿즈인 애플 티셔츠를 얻을수 있었기에,, 입장하자마자 각 부스를 돌아 다녔습니다!

부스를 돌면 굿즈도 주셨어요!

현대-기아 자동차에서는 양말과 자동차 모형 장식품(?)

카카오 뱅크에서는 수건과 스티커들!

점핏에서는 스티커들!

요기요에서는 룰렛으로 굿즈를 주셨습니다! 저는 요기요 할인쿠폰을 받았어요!

유데미 에서는 손풍기와 스티커를 주셨습니다!

굿즈 엄청 많이 받았죠!? 뿌듯 합니다 ㅎㅎ

굿즈만 봐도 행복하네요,, 사실 컨퍼런스가 처음이라 굿즈받으러 간다는게 무슨소린지 몰랐는데

이제야 이해가 되는것 같습니다!

그리고 잠실 세션장에서 고대 유물들을 보았습니다! 역대 맥들인것 같은데 너무 귀욥...

그래서 세션은 어떠 하였느냐!

너무나도 유익한 시간들 이였어요

사실 트랙이 많아서 무엇을 골라 들어야 하나 고민을 했었는데요..!

사실 가기전부터 듣고싶은 세션들을 표시해 뒀습니다! 

점심을 먹고 들어가니 1시 30분 세션이 거의 끝나가서,, 실질적으로 들었던 세션은

1. 라이노님 - Swift 언어 히스토리 탐방

2. 제온님 _ 카카오뱅크 - 우리가 모듈화를 할 수 밖에 없었던 이유

3. 강성규님 _ 현대자동차 - 제조업에서 SwiftUI + TCA로 앱 개발하기

4. 토브님 - SwiftData 언박싱 대신해드립니다!

이렇게 들었습니다!

Swift 언어 히스토리 탐방 세션을 보며 느낀점은,,

나 swift 정말 몰랐구나,, 싶더라구요 언어의 히스토리를 알아야 왜 이 언어가 이런 특징을 갖게 되었나를 알수 있다고 생각했습니다!

해당 세션을 들으며 스위프트 언어의 발전 과정 그리고 언어의 특징들에 대해 이해할 수 있었던것 같아요!

그리고 해당 세션에서 라이노님께서 추천해주신 포럼! 바로 스위프트 포럼입니다!

라이노님 께서 이 포럼을 둘러보는것, 가입시 일주일에 한번 메일로 보내주는 내용들만 읽어도 매우 유용하다고 하셨습니다!

https://forums.swift.org

위 사이트인데요! 저도 이글을 작성한 이후 가입해서 습관적으로 둘러보려고 해요 ㅎㅎ

우리가 모듈화를 할 수 밖에 없었던 이유 세션_카카오 뱅크를 보며 느낀점은,,

모듈화 평소에 들어보기만 했지 왜쓰는지 정말 하나도 몰랐거든요,,

그런데 카카오뱅크에서

모듈화를 적용한 이유와 적용과정 그리고 적용이후 어떻게 변화되었나를 정확한 수치로 말씀해주셔서 한번에 이해가 쏙쏙 되었습니다!

사실 제가 재직중인 회사의 프로젝트에서는 모듈화를 적용하지도 않고,, 적용하기엔 너무 작은 프로젝트거든요.. 그래서 대기업을 왜 가야하며, 대기업 진짜 가고싶다.. 라는 생각을 하게 되었습니다! 너무너무너무*1000 유익한 세션이였어요

개인적으로 이 세션이 오늘 세션들 중에서 가장 유익했던것 같습니다!

왜냐하면,, 모듈화를 공부해보고싶다 라고 평소에 생각은 하고 있었거든요..

해당 수치들과 관련 내용들은 if kakao2022에서 확인해 보실수 있다고 하셨습니다!

https://if.kakao.com/2022/session/88

제조업에서 SwiftUI + TCA로 앱 개발하기를 보며 느낀점은,,

사실 잘 이해가 안됐었거든요,, 현대자동차에서 앱을 왜 개발하실까..?

아니 그보다 현대자동차의 앱이 있었나,,,?

그런데 현대자동차의 앱은 우리가 생각하는 일반적인 서비스의 앱이 아니였습니다!

말 그대로 제조업에서 왜 앱을 개발하셨는지에 대해 알게 되었습니다!

그리고 이 세션을 들으며,, 나 진짜 swiftUI 열심히 공부해야겠다 싶더라구요,, 그리고 TCA에 대한 개념도,,

같이 듣던 친구가 TCA가 뭐의 약자냐고 해서 구글에 검색해봤더니 ㅋㅋㅋㅋㅋㅋㅋ

삼환계 항우울제 ...? 라고 뜨더라구요..? TCA 듣기만 했지 진짜 뭐의 약자인지 몰랐는데 

The Composable Architecture 라고 하더라구요 TCA는 어떻게 동작하는지 어떻게 설계해야 하는지에 대해 알게된 세션이였습니다!

SwiftData 언박싱 대신해드립니다!를 보여 느낀점은,,

coreData 와 Realm을 대체할 강력한게 나왔다! 싶더라구요,,

사실 저는 realm을 사용해본적은 없고,, coreData는 아주아주아주 기초만 아는 정도인데 세션의 내용을 보니,, swiftData 이거이거,, 완전 물건입니다. 여러 장점들이 많았지만.

일단 코드량 자체가 화~악 줄어들더라구요 그래서 저도 이런 부분들에 대한 공부를 해야겠다고 생각하게 되었어요

토브님께서 예제를 포함한 깃허브도 공유해 주셔서 개인 맥북에 베타로 올려서 천천히 공부해볼까,,,🤔 싶기도 합니다!

이렇게 네개의 세션을 듣게 되었는데 뭐 하나 빠짐없이 너무나도 유익한 발표들 이였습니다!

하지만 많은 장점들 만큼이나 아쉬운 점도 있었는데요,, 개인적으로 느낀 아쉬운 점들을 나열 해 보겠습니다!

첫번째! 점심시간이 너무 짧은 느낌이였어요 오전세션 끝나고 식당가를 찾아 갔지만 점심시간인 만큼 거의 모든식당이 다 줄을 섰어야 했는데 줄서서 먹고 세션장 가니까 1:30분 세션은 이미 시작한 이후더라구요.. 조금 아쉬웠습니다!

두번째! 제가 컨퍼런스는 처음 가보는거라 원래 컨퍼런스들이 그런지 모르겠는데,, 듣고싶은 세션을 늦으면 못듣더라구요 ㅠㅠ 원래 계획은 애매하게 시간이 겹쳐있는 현대자동차 세션을 보고 난 후, 매크로 부수고 부셔지기를 보는것 이였는데 현대차 TCA를 보고 바로 이동을 했으나,, 인원이 많아서 세션장 입장이 안되는 상황이였습니다 매크로 세션 보고싶었으나 조금 아쉬웠어요!

세번째! 세션과 네트워킹의 두마리 토끼를 잡기엔 조금 힘들었어요 ㅜ_ㅜ 이것도 제가 컨퍼런스가 처음이라 원래 이런건지 잘 모르겠으나 세션들으러 왔다갔다 하느라 다른분들과의 네트워킹에는 집중 할 수가 없더라구요ㅠ ㅠ

아, ,물론 제가 낯가림이 심해서 못한것도 맞습니다 허허,, 이건 지극히 개인적인 아쉬움이에요!

낯가림을 빨리 없애서 저도 다른분들과 자유롭게 네트워킹 하는 그날까지! 성격을 고쳐보도록 하겠습니다 ㅜㅜ

전반적으로 너무 의미있고 뜻깊은 시간들 이였습니다~

오랜만에 만난 Apple Developer Academy @POSTECH 동문 분들 및 멘토분들도 너무너무 반가웠어요!

KWDC23 행사를 주최해주신 운영진분들, 스태프분들, 그리고 멋진 발표를 해주신 연사자분들 모두 고생 많으셨습니다!

행사 주최해 주셔서 감사합니다 🙇‍♂️

저는 이제 내일 회사에 제출할 보고서 작성하러....

안녕하세요~ 👋 치콩입니다!

글을 작성하기 앞서 앞으로의 블로그 작성글의 컨셉을 이렇게 소통이다 생각하고 누군가에게 설명하듯 작성하려고 합니다! 이 전의 글들은 나만 본다는 가정하에 나만 알기쉽게 작성하였는데,, 그러면 일기장에 쓰지 블로그에 글을 쓰는 의미가 없어지지 않을까,,🤔 싶은 마음이 들더라구요ㅋㅋㅋ 누군가에게 설명하듯 작성하다보면 나도 모르는 개념들을 조금 더 파악할 수 있지 않을까 싶은,, 아무튼 잘부탁드립니다

오늘은 미뤄졌고,, 아니 미뤄왔고,, 아니 그냥 하기 싫었고,, 그냥 핑계였고,,,,

어쨋든 공부해야지 해야지 하고 미뤄왔던 Combine에 대한 기초개념을 파악해 보려구 해요 🥳

RxSwift 와 Combine을 고민하였지만 결국 Combine은 애플에서 만든 프레임워크 이고 결국 Combine으로 대체되지 않을까하여

( 물론 찾아보니 UIKit에 Combine을 적용하려면 Rxcocoa 같은 CombineCocoa(?) 서드파티 라이브러리를 적용해야 한다고 하더라구요…? 그래도 전 Combine을 공부할겁니다 그냥 제가 그러고 싶어요 )

Combine의 등장 배경?!

다음과 같은 마법학교앱의 회원가입 기능이 있다고 가정해보자구요~

1. WizardName을 입력받기 위해 Target/Action 을 이용해서 유저로부터 입력을 받겠죠?
2. Timer를 통해 유저의 입력이 종료될때까지 기다려줘요 ( 입력이 끝날때까지 네트워크 통신을 하지 않을겁니다! 매번 통신을 요청하면 너무 비효율 적이잖아요? )
3. 입력이 끝났으면 네트워크 통신이 진행되는동안 KVO(Key-Value-Observing)을 통해 입력받은 이름이 유효한지 검사할꺼에요 ( PDF에선 그림이 짤렸지만 Progress가 돌고있습니다 통신 되는동안 응답값이 올때까지 기다려라! 하는걸 알려주는거죠!! )

위 같은 방식으로 Password의 유효성도 검증하게 될거에요

우리는 Combine을 알기 전, 익숙하게도 이렇게 코드를 작성해 왔잖아여?

그래서! 들어가는 비용이 어떠냐,,,

Network 통신을 위해 URLSession도 사용하고, Timer도 사용하고,

WizardName과 Password가 모두 유효한지 판단하여 버튼도 활성화 시켜주기 위해 KVC(Key-Value-Coding) 의 개념도 들어가고,

응답도 기다리고, 뭣도 하고 뭣도하고 ..

자자 봅시다

네트워크와 통신을 하기 위해 우리는 비동기적으로 처리를 하게 될거에요 그쵸!? ( WizardName의 유효성을 기다리는동안 앱이 멈추거나 다른것을 하지 못하게 되면 사용자입장에서 너무 난처하잖아여,,, )

그리고 이 비동기와 아울어 Password의 유효성도 검증하고, 동기적으로 모두 유효한지 체크하여 MainThread 에서 UI도 업데이트를 통해 버튼을 활성화 시켜 주어야해요 - KVC(Key-Value-Coding)

이처럼 비동기를 처리하기 위해 Cocoa SDK에는 다음과 같은 비동기 인터페이스들이 있었죠!?

• Target / Action
• Notification Center
• URLSession
• Key-Value Observing ( KVO )
• Ad-hoc Callbacks

이 인터페이스들은 매우 중요합니다! 비동기 구현할때 알아야 하는 인터페이스 들이에요! 이것들이 혼합되면,,?

복잡하겠지만.. 어쩔수 있겠냐구요,, 해야지,,

그래서!! Apple에서는 이 개념들을 대체한다기 보다 공통적인 사항을 찾았다고 합니다!

시간이 지남에 따라 값을 처리하기 위한 API !!!

이게 뭐다? 이게 Combine의 등장 배경이라고 합니다!

Combine은 Swift로 작성된 프레임워크이기 때문에 다음과 같은 기능들이 포함된다고 합니다

• Generic
  • 작성해야 하는 코드의 양을 줄일수 있어요!
  • 비동기 동작에 대한 알고리즘을 작성한 후, 다른 종류의 다양한 비동기 인터페이스에도 적용할수 있어요!
• Type Safe
  • 안정성이 보장되기 때문에 런타임 아닌 컴파일시간에 오류를 찾아낼수 있어요!
• Composition First
  • 핵심 개념은 간단하고 이해하기 쉽지만(컴포지션 기반이기 때문에…?) 결합 될수록 더 많은 기능을 수행할 수 있다고 합니다! ( 그래서 Combine..? )
• Request Driven
  • 요청 기반의 프레임워크 이기 때문에 앱의 메모리 사용량과 성능을 신중하게 관리할수 있다고 합니다!

Combine의 3요소

1. Publishers
2. Subscribers
3. Operators

위 세개 알면 Combine 공부 끝나는 거임!

물론! 언제나처럼! 공감하겠지만! 세개를 알면 알수록 공부는 끝이 안날꺼임 …

세개의 세부사항에 대해서는 추후 천천히 알아가고 일단! 간단한(?) 기본 개념만 먼저 알아봅시다!

Publisher

값과 오류가 생성되는 방식을 설명한다고 합니다… 이게 무슨 소리지? 잠깐 공식문서의 개요를 봅시다,

https://developer.apple.com/documentation/combine/publisher

Declares that a type can transmit a sequence of values over time.
유형이 시간이 지남에 따라 일련의 값을 전송할 수 있다고 선언합니다.

A publisher delivers elements to one or more Subscriber instances.
Publisher는 하나 이상의 Subscriber 인스턴스에 element를 제공합니다.

The subscriber’s Input and Failure associated types must match the Output and Failure types declared by the publisher.
Subscriber의 입력(Input) 및 실패(Failure) 관련 유형은 Publisher가 선언한 출력(Output) 및 실패(Failure) 유형과 일치해야 합니다.

The publisher implements the receive(subscriber:)method to accept a subscriber.
Publisher는 Subscriber를 구독하기 위해 receive(subscriber:) 방법을 구현합니다.

오 뭔가 이해가 될듯 말듯 하네요? 그렇다면 내장된 Publisher의 프로토콜을 살펴볼까요?

public protocol Publisher<Output, Failure> {
    associatedtype Output
    associatedtype Failure : Error

    func receive<S>(subscriber: S) where S : Subscriber, Self.Failure == S.Failure, Self.Output == S.Input
}

주석을 제외하고 실제로 내장에 구현되어 있던 녀석 가져옴

아하~ 그러니까 publisher 프로토콜에는 Output과 Failure의 타입이, 그리고 receive(subscriber:) 함수가 선언되어 있네요!?

receive(subscriber:) 함수에는 Self.Failure == S.Failure, Self.Output == S.Input 의 조건도 명시되어 있구요

오,, 공식문서 역시 정확하네요

다시 영상의 내용으로 돌아가서,,,

Failure 즉, Error를 생성할 수 없는 경우! ( 오류가 없는 경우,,? 다른 뜻인가 ,,,? )

암튼 이 경우에는 Never 를 할당 하면 된다고 합니다 ( 메모메모,, 왠지 제일 많이 쓸거같은 느낌이 든단말야? )

Publisher 프로토콜이 적용된 예시를 보도록 하죠! NotificationCenter입니다!

extension NotificationCenter {
    public struct Publisher : Publisher {
        public typealias Output = Notification
        public typealias Failure = Never

        public let center: NotificationCenter
        public let name: Notification.Name
        public let object: AnyObject?

        public init(center: NotificationCenter, name: Notification.Name, object: AnyObject? = nil)

        public func receive<S>(subscriber: S) where S : Subscriber, S.Failure == Never, S.Input == Notification
    }
}

이것도 Swift에 내장된 그대로 가져옴 ㅎㅎ ( 주석만 제거하고! )

NotificationCenter는 실패를 생성할 수 없는 경우인 Never 가 선언되어 있네요!?

그리고 해당 NotificationCenter를 초기화할때 NotificationCenter 와 Notification.Name 을 이용해 초기화 하는것을 볼수 있네요!

이처럼 NotificationCenter 자체가 Combine 등장과 함께 무언가로 대체 되는것이 아니고 Combine에 맞게 확장하여 사용하는것을 볼수 있습니다!

정리하면 Apple 에서는

Combine의 등장으로 기존의 Notification, URLSession 등 위에서 소개한 비동기 처리 인터페이스들을 새로운것으로 대체 하는게 아니라 Combine을 적용시키는 거임 OK? Right?

의 뜻이네요!!

너무 길어지는것 같아 다음 글에서는 Subscriber 와 Operator에 대한 간략한 설명을 살펴보겠습니다!

1년간 블로그에 새글이 없었다.

핑계라고 한다면,, 애플 아카데미에서 프로젝트를 하느라 바빳고 노느라 바빳다.

12월 16일 포항과의 인사를 끝내고 본가로 올라왔다.

걱정이 한둘이 아니였다, 우선 수료를 하긴 했는데 취업을 할 수 있을까?

9개월간 진짜 열심히 살았다 프로젝트 끝나고 공부 스터디 프로젝트 스터디 사이드 프로젝트 스터디..

12월 수료 한 후 집에 오자마자 짐을 풀고

일단 놀았다 1월부터 준비하자 라는 마인드로

1월이 되니 또 준비하기가 싫어졌다 마음은 불안한데 몸이 안따라줬음,,

그래서 생각정리 여행을 떠나기로 했다

1주일간 급하게 항공권을 구매하고 일본으로 여행을 갔다

아, 물론 가서 이력서랑 포폴 정리하려고 맥북도 챙겨갔다.

첫날 저녁 일본 카페에 앉아서 이력서를 정리하고 있는데 생각이 들었다

" 이러면 여행 온 의미가 없지 않나,,"

그대로 맥북을 캐리어에 넣고 여행 내내 꺼내지도 않았다, 개발에 대한 생각을 잠시 접어두고 그냥 즐겼다

맛있는것도 먹고 온천도 가고 이자카야 가서 혼술도 하고

그렇게 한국에 돌아오니 뭔가 마음이 편안해졌다

편안한 마음으로 다시 놀았다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

이정도면 그냥 취업할 생각 없는게 아닌가;;

2월 1일부터 이력서와 포폴을 정리하고

취업 플랫폼 ( 원티드, 사람인, 점핏, 잡코리아 )

무수히 많은 지원서를 냈다

iOS 직군은 신입으로 검색했을때 정~~~~말 없었다.

내가 들어갈 자리가 없다 라는 느낌보단

진짜 채용공고 자체가 너무 적었다

그렇게 80여개? 정도의 이력서를 찾아찾아가며 제출했고

5개정도의 회사에서 면접 제안이 왔다,

1개의 회사는 개인 사정으로 인해 면접 불참의사를 밝히고 4개의 회사에 면접을 봤다

결과적으로 4개의 회사중 3개의 회사에 합격하였고 3개의 회사에서 골라갔다.

누구나 가고싶어하는 네카라쿠배당토,, 의 대기업은 아니지만 내 목표는 뚜렷했다

1. 사수분이 계시는 회사에 들어가자

2. 우선 연봉보단 내 실력을 키울수 있는 환경에 들어가자

3. 경력을 우선 쌓자

3개의 조건에 부합하는 회사를 결정했고 현재 다니고 있다.

수습기간동안 사수분께서 이런 저런 사이드 프로젝트를 제시해 주셨다. 요구사항에 따라 사용해야할 기술들을 넣고 개발해보자고 하셨다.

많은 공부가 되었다 이게,, 일종의 테스트 였을까??

마지막 사이드프로젝트는 1주일안에 개발해 보자고 하셨고, 요구사항을 봤을때 1주일안에 도저히 무리일것 같았다

근데 어쩌겠어,, 난 신입이고 수습인데 까라면 까야지.. 

여차저차 1주일만에 개발을 하였고 사수분께 검사를 받았다.

사수분이 " 진짜 일주일만에 개발하시네요 그냥 한번 테스트 해본건데,,, "

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 기분좋은 칭찬이였다

말이 일주일 이지 그냥 한번 테스트 해보신 거였다고,, 

그렇게 3개월의 시간이 끝났고 수습이라고 할것도 없이 그냥 자동 전환이 되었다.

수습기간동안 만들었던 사이드 플젝들을 회고하며 사용했던 기술들에 대한 개념들을 다시한번 정리해봐야 할것같다,

시간에 쫒겨 개념이고 뭐고 그냥 일단 구현만 한거라,,, 개념을 자세히 파악해 보아야 할것 같다

이제 떳떳한 iOS 개발자가 되었지만 그럼에도 생각이 많다,

회사의 업무만 가지고는 개인적 성장이 더딜거같다.

6월 늦어도 7월부터는 SwiftUI기반의 사이드 프로젝트를 퇴근후 조금씩이라도 해볼 생각이다.

사내 앱이 일부는 Swift, 일부는 Objective - C 로 되어있기 때문에,

일단 컨버팅먼저,, 그리고나서는 SwiftUI로 조금씩 전환해 나가야겠다

최소지원버전이 올라간 만큼 SwiftUI도 안정적으로 되겠지,,

요즘은 Combine이라는 기술을 공부하려고 생각중이다.

회사 업무에 SwiftUI를 도입하기 전, 개인 사이드 프로젝트로 충분히 실력을 갈고 닦아서 서서히 회사 프로젝트에도 도입해 봐야지.

다음 글을 쓸때는 무수히 성장해 있길,,

• 사진 세트와 같은 정렬된 콘텐츠 세트를 관리하고 커스텀 가능하고 시각적인 레이아웃으로 제공
• 컬렉션은 엄격하게 선형 형식을 시행하지 않기 때문에 크기가 다른 항목을 표시하는 데 적합
• 컬렉션은 이미지 기반 콘텐츠를 과시하는 데 이상적
• 배경과 같은 부수적인 뷰는 항목의 하위 집합을 시각적으로 구별하기 위해 선택적으로 구현

• 컬렉션은 상호 작용과 애니메이션을 모두 지원한다
• 기본적으로 탭하여 선택하고, 길게 터치하여 편집하고, 스와이프하여 스크롤할 수 있다
• 필요한 경우, 커스텀된 작업을 수행하기 위해 더 많은 제스처를 추가할 수 있다
• 컬렉션 내에서 항목을 삽입, 삭제 또는 재정렬할 때마다 애니메이션을 활성화할 수 있으며 커스텀 애니메이션도 지원한다

고려사항

• 행이나 그리드 레이아웃이 충분할 때 새로운 디자인을 만들지 마세요.
  • 컬렉션은 사용자 경험을 향상시켜야 합니다.
  • 항목을 쉽게 선택할 수 있도록 하세요. 컬렉션에서 항목을 탭하는 것이 어렵다면, 유저입장에서 앱에대한 불편한 인식을 남길수 있습니다.
  • 레이아웃을 깨끗하게 유지하고 콘텐츠가 겹치지 않도록 콘텐츠 주위에 적절한 패딩을 사용하세요.
• 컬렉션에 텍스트만 표시한다면, 테이블 뷰를 고려하세요.
  • 스크롤 가능한 목록에 표시될 때 텍스트 정보를 테이블 뷰로 구성하는 것이 더 간단하고 효율적입니다.
• 동적 레이아웃을 변경할 때 주의하세요.
  • 컬렉션의 레이아웃은 언제든지 변경할 수 있습니다.
  • 사람들이 레이아웃을 보고 상호 작용하는 동안 레이아웃을 동적으로 변경한다면, 변경 사항이 합리적이고 추적하기 쉬운지 확인하십시오.
  • 동기 부여되지 않은 레이아웃 변경은 앱을 예측할 수 없고 사용하기 어렵게 만들 수 있습니다.
  • 레이아웃 변경으로 인해 컨텍스트가 손실되면, 유저 입장에서 불편한 앱으로 인식될 수 있습니다.

⇒ 참고 문서

TableView를 기준으로 설명 , (아마도) 동일한 프로토콜이 있다면 같은 기능을 수행할 것입니다.

Delegate

• TableCell을 탭(클릭) 했을때 어떠한 기능을 수행하는 권한을 위임하는 프로토콜

func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: IndexPath) 
func tableView(tableView: UITableView, willBeginEditingRowAtIndexPath indexPath: IndexPath)

• 외울필요? X 자동완성을 사용하자 ( 우리 신세대임..ㅋ )
• 메서드의 인자만 봐도 어떤 기능을 수행 할 지 짐작이 가능하다
• didSelectRowAtIndexPath → 이름부터가 선택 됐을때, 어떠한 동작을 수행할 것인지 에 대한 정의를 내리면 될것 같다
• willBeginEditingRowAtIndexPath ⇒ 공식문서 의 내용을 보니 행의 삭제와 같은 기능을 수행 할 때 어떤 동작을 결정할 지를 정의하면 된다

⇒ 물론 Delegate의 func들은 Optional이기 때문에 반드시 정의 할 필요는 없다.

DataSource

• TableView의 Cell을 어떻게 보여줄가 에 대한 권한을 위임(?) 하는 프로토콜
• 몇개의 행을 표시할 것인지? 각 행에는 어떤 내용을 보여줄 것인지등등 간단히 말해 View를 그리는 역할을 수행한다고 생각하면 된다

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: IndexPath) -> UITableViewCell
func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int

• 위 두가지 메서드는 Datasource 프로토콜을 채택 할 때 반드시 정의해 줘야 하는 메서드!
• 외우지 말자.. ( Datasource 채택하면 빨간줄 뜨면서 자동으로 채워진다! )
• numberOfRowsInSection ⇒ 이름만 봐도 몇개의 섹션을 나눌것 인지 정의하면 된다. 말 그대로 몇개의 행을 테이블 뷰에 표시 해 줄것인지 정의해 주면 된다 ( 정수를 반환하면 반환된 값 만큼 테이블뷰의 행이 생성된다 )
• cellForRowAtIndexPath ⇒ 각 행(cell)에 어떤 내용을 보여 줄 것인지 정의해 주면 된다. 말 그대로 어떤 내용을 표시해 줄지에 대한 정의를 내리면 되고, indecPath 를 통해 각 행이 for 구문 처럼 순차적으로 정의된다 ( 이해가 안가면 직접 구현해 보자 )
• 두개의 메서드 말고 추가적인 메서드들도 있으나, 모두 외울 필요없다, 필요하면 그때 그때 찾아 사용하자

⇒ 한줄 정리 : Delegate는 어떠한 동작 을 수행, DataSource는 어떠한 내용 을 표시