앱 제작 시 주로 코드로 작성하시는 이유가 있을까요?

안녕하세요 taehun0933 님!현업에서, 여러명이서 동시에 진행하는 프로젝트를 하실 수 있는 기회가 생기시면, (쉽게 동아리 같은 곳에서 협업을 해보셔도) 스토리보드를 사용하기 힘들다는 것을 많이 느끼게 되실 것이예요. (물론 초반 공부할 때는 이렇게 직관적인데 왜 굳이 스토리보드를 안쓰지? 이런 생각이 드실 수도 있지만요.)(1) 스토리보드 충돌이슈: 사실, 예전에는 가장 큰 이유가 스토리보드 사용하여 협업 시에 많은 충돌이 발생했었습니다. 화면이 많을 때 로드도 많이 발생하고, 잘못 클릭하면 엑스코드가 꺼지기도 하고요. 등등 스토리보드가 정말 정말 문제가 많았습니다. (그래서 협업 시엔 스토리보드 사용을 거의 금기시 했습니다.)(2) 사실, 결과론적으로는 스토리보드가 직관적이지만, 버전 관리 측면에서는 Git에서 변경 사항을 추적하기가 어렵습니다. 그리고 코드에 익숙해지면 (대부분의 현업 개발자들은 익숙하겠지만) 오히려 코드만 봐도 화면이 머리속에 그려지니.. 직관적인 측면에서 아주 떨어진다고도 할 수 없다고 생각하기는 합니다. (물론 그림으로 한눈에 보는 것과 어떻게 비교할 수 있겠냐만은..) 그만큼 대부분 현업에서 코드를 사용하다보니 대부분이 익숙하다고 보시면 됩니다.(3) VC에 UI 관련한 코드가 없어 더욱 VC가 본인의 책임에 집중하게 된다는 생각이 든다는 건.. MVC가 아닌 다른 아키텍처에서 대부분 해결이 가능합니다. 요새는 더더욱이 MVC 아키텍처를 사용하는 경우가 거의 없기 때문에.. VC에 UI 관련 코드만 남고, 로직 등은 뷰모델로 보내거나 할 수있기에.. 크게 중요한 관점은 아닌 것 같습니다. (MVVM, MVP, MVI 등등 너무 많죠.) 오히려 아키텍처적인 측면에서 보면 모든 것을 일치시켜 코드로 관리하고, 로직 등을 분리하는 것이.. 더 관리가 잘 되겠죠.(4) 재사용성의 측면: 재사용이 가능한 UI들은 코드로 만들어야 쉽게 재사용이 가능합니다. 스토리보드는 재사용이 불가능하니까요.(5) 코드리뷰의 용이성: 여러 명이서 협업 시에, 코드 변경 사항이 확실히 보이니 아무래도 명확하게 코드리뷰가 가능합니다. 제약(Constraints)가 이렇게 바뀌었네? 이런 것을 한눈에 볼 수 있죠.그래서 보통은.. 1인으로 개발한다면 스토리보드로 개발하는 것이 전혀 문제가 없지만, 협업을 위해서는 대부분 코드를 사용하게 된다고 보시면 될 것 같습니다. :)

델리게이트 패턴 관련 질문

아 네 안녕하세요 taehun0933 님! 일단 (스토리보드를 이용하는 것을) 처음 공부하시는 입장에서, 조금 쉽게 이해하시라고 그런 표현을 사용했었던 것 같은데, 말씀하신 대로 정확하게 이해하고 계십니다. :)당연히 UIKit 프레임워크에서UIButton, UITextField 등 모든 객체는 따로 존재하게 됩니다. 다만, 제가 강의 내용에서 "직접적인 커뮤니케이션"이라고 표현한 것은 단지 UITextFieldDelegate프로토콜을 채택하고, textField.delegate = self와 같은 설정을 굳이 해주지 않아도 UIButton(버튼)의 액션을 (스토리보드를 통해) 뷰컨트롤러의 직접적인 함수와 연결해서(@IBAction함수만 구현해서) 사용할 수 있다 정도의 의미라고만 생각해주시면 될 것 같습니다. (스토리보드 내부에 숨어있는 메커니즘을 통해 사용 편의성을 높인거죠.) 물론, 뒤에가서 (스토리보드가 아닌) 코드로 구현하면서 직접적으로 target-action을 어떻게 연결하는 지를 보여드리겠지만, (어쨌든 이런 스토리보드 내부적으로 숨어있는 target-action 메커니즘을 아직 모른다고 하더라도) (UITextField와는 다르게) 쉽게 버튼을 사용할 수있는 측면에서 말씀드리고 있는 것뿐이니, 특별한 이론적인 내용이 있어서 그렇게 표현한 것은 아니니 오해는 말아주세요..ㅎㅎ(말씀하신대로.. 아주 정확하게 따져보면, 당연히 모든 객체는 별도로 존재하고 텍스트필드는 델리게이트 패턴을 통해, 버튼은 target-action메커니즘을 통해 동작을 전달합니다. 다만, 스토리보드 편의성 측면에서 target-action의 내부 메커니즘을 몰라도 쉽게 사용할 수 있게 만들어 놓은 것 뿐입니다.) 감사합니다. :)

수강 기간 연장 부탁드릴 수 있을까요?

네 연장처리 해드렸습니다. :)

활용 앱 30강 에러 질문입니다

네 안녕하세요!https://pointed-earwig-996.notion.site/iOS-153d2c99af2c4aa0ad40171de4ceb824해당 내용은 자주하는 질문에서 아주 자세하게 설명드리고 있는내용이라, 자주하는 질문 중 아래 내용을 참고 부탁드립니다. :)(사진) 간단하게 말씀드리면, 엑스코드에서 추천해주는 FirstViewController.self는 잘못된 것입니다. (엑스코드 오류입니다.)버튼의 let 로 선언된 것을 lazy var로 선언하셔야합니다. 왜냐하면 self(FirstViewController) 객체가 먼저 메모리에 올라가 있는 상태에서 접근해야 하기 때문에, lazy var로 선언해주는 것은 button 생성 시점을, self 생성 시점 이후로 미뤄주는 것입니다.(필요하시다면 "지연 저장 속성"관련 swift 문법 내용을 찾아보시면 좋습니다.)쉽게 말하자면, self(FirstViewController) 생성 이후에 backButton 생성이 가능(self가 메모리에 올라가 있어야 접근가능)하기 때문이라고 보시면 됩니다. 감사합니다. :)

20강 Task 내부에서 nonisolated async 호출 예제 질문드립니다

아 네네, 해당 내용에서느 직관적인 이해를 위해서.. 편의상 그렇게 설명드리고 있는 것 뿐입니다 !비동기(async) 함수로 구현하시면, 백그라운드 쓰레드 어디에서도 실행될 수 있습니다.Task가 3번 쓰레드라고 가정하고, LibraryAccount 액터가 2번 쓰레드라고 가정하면, (정확하게 보자면) 비동기 readAny 함수의 경우, 비동기 함수이기 때문에 백그라운드 쓰레드(예를 들어, 4번, 5번, 6번 등) 어떤 곳에서도 실행될 수 있습니다. (async 함수의 특징) 그래서 await키워드가 붙여서 실행시켜야 하는 것이기도 하고요.(뭐 예를 들자면, readAny 비동기 함수가 4번에서 실행되었다가 3번 쓰레드에서는 그 일이 마칠때까지 기다리는 것이겠죠.)해당 내용에서 중요한 포인트는 2번 쓰레드(액터 내부)에서 실행되지 않는다는 내용을 설명드리기 위한 내용이라 최대한 직관적인 이해를 위해 (이미 수업의 앞의 내용들은 이해하시고 계시다는 전제 아래) 설명드리고 있다는 점을 이해 부탁드립니다. :)

19강 Actor 의 동작 관련해 질문드립니다

네 안녕하세요 sujinnaljin 님! 정확하게 이해하셨고, 저도 그렇게 그림을 그려드렸어요.(강의 내용 17강 5분 7초 ~ 6분 20초 내용의 그림을 다시 보시면 되고, 교재의 경우 p.166 ~ 167 페이지에 내부적으로 여러쓰레드에서 동작할 수 있다고 말씀드리고 있습니다.)잘 생각해보시면, 그게 앱 단에서 운영체제한테 쓰레드를 빌려쓰는 쓰레드 풀 방식의 개념하고 연결되기 때문에 당연히 그렇다고 보시면 됩니다. (운영 체제 측면에서 보시면, "1개의 쓰레드"도 하드웨어와 긴밀하게 동작하게 만드는 특정한 객체입니다.)(물론 메인 액터/메인 쓰레드의 경우) 프로그램을 실행하는 동안 운영체제가 아예 고정시켜서 특정 쓰레드 1개를 (메인으로 배치시켜서) 고정시키기 때문에, 1개의 앱이 메모리에서 실행될 때 "메인 쓰레드"는 내부적인 쓰레드 객체도 변할 일이 없겠지만,액터의 경우, (앱 단에서) 1개의 쓰레드만 (직렬적으로) 사용한다고 하더라도, (만약에 바쁘게 일을 계속 해야 한다면) 쓰레드를 운영체제에 반납할 일이 없겠지만, 덜 바쁜 일을 하게되면 당연히 운영체제에 사용하던 쓰레드를 반납하겠죠. (쓰레드풀 방식) 그러다가 액터에서 어떤 일을 수행해야 해서 쓰레드를 다시 운영체제에 빌려온다면.. 당연히 다른 쓰레드 객체이지 않을까요? (물론 우연으로 같은 객체일 수도 있겠죠.)그런데 그게 어차피 앱단에서는,, 그걸 우리가 신경쓸 일은 아니니까.. (운영체제와 앱 단에서 알아서 일어나는 일일 뿐이니까) 중요한 것이 아니라고 말씀드리는 것이고요!정확하게 이해하셨습니다 :) 감사합니다 !

기초앱 17강 Contraints 설정 질문입니다.

네 안녕하세요 한재님!수직정렬이 반듯하다는 의미가 어떤 의미일까요? 가능하시다면, 이미지를 첨부해주시면 좋을 것 같습니다.(Top Constraint 설정 부분은 잘못된 부분이 없어 보입니다.)혹시나 모르겠지만.. 시뮬레이터에서 한번 실행해 보시겠어요?Xcode 스토리보드에 약간의 오류가 있는 것으로 알고 있어서, 혹시나 스토리보드에서 보이는 화면하고 실제 시뮬레이터에서 실행하는 것과 다르게 보일 수도 있습니다. 실제 시뮬레이터에서 실행하면 정상적으로 실행될 수 있습니다. (단지 스토리보드 표시 오류라서요.. 이 부분 참고 부탁드립니다.) 추가적으로 질문을 주셔도 되고, 너무 해결이 안되는 부분이 있으시다면we.love.code.allen@gmail.com 으로 해당 전체 프로젝트 폴더를 압축해서 보내주시면 해결해드리도록 하겠습니다. 감사합니다. :)

Actor에서 Task vs Task.detached 사용 시 재진입 문제 질문

네 안녕하세요! 질문 내용에 대해, 2가지 포인트를 말씀드릴 수 있을 것 같은데요.(1) 여기서 이렇게 Task.detached로 구현되나 그냥 Task로 구현되나, 전혀 상관없이 downloadImage 함수 자체는 액터가 아닌 외부 쓰레드에서 실행되게 됩니다.let task = Task.detached { let image = try await downloadImage(from: url) return image }let task = Task { let image = try await downloadImage(from: url) return image }조금 의아하실 수도 있지만, 왜 그런지 설명드리면.. Task로 구현하시면 actor의 context를 상속받는 것은 맞지만, 실제 downloadImage(from: url) 함수 자체가 액터 내부의 메서드가 아닌 외부의 메서드이고, 해당 함수를 호출하면서, 앞에 await 이라는 키워드가 붙어있다는 것이, 결국엔 나의 쓰레드가 아닌 외부의 쓰레드를 사용한다는 의미라고 보시면 됩니다.(쉽게 한마디로 정리해서 말씀드리면, 비동기 메서드(함수)로 구현되어 있으면, (액터에서 호출하더라도) 액터가 아닌 외부 쓰레드에서 동작합니다.)그래서, 사실 Task 나 Task.detached나 구현하고, 실제 동작하는 것에는 전혀 차이가 없지만.. 여기서 Task.detached를 사용했다는 것은 "외부 쓰레드에서 실행된다는 의미를 조금 더 명확하게 해주기 위함"이라고 보시면 될 것 같습니다.(네 그래서, 위의 내용을 정확하게 이해하시는 것이 먼저 중요한 것 같고요.) (2) 만약에, 위의 (1)번 내용이 아니라고 가정하고, Task를 사용하는 것이 serial executor에서 실행이 된다고 가정을 해서 말씀을 드려도, 재진입 문제가 발생하지 않습니다.let task = Task { let image = try await downloadImage(from: url) return image } /// 일단 (완료되지 않은) 작업 상태를 보관 cache[url] = .loading(task)왜냐하면, 바로 아래에 있는 코드인, cache[url] = .loading(task) 때문에 그렇습니다. 쉽게 말씀을 드리면 위의 코드는 바로 아래의 코드와 동일합니다. (Task 안의 비동기적인 작업을 제외하고 생각하시면 쉬워요.)let task = Task{ } cache[url] = .loading(task)작업을 생성하자마자, 동기적으로 일단 cache에 상태를 .loading라고 저장해 놓습니다. 작업 자체를 생성하자마자 저장해놓는 (동기적인) 방식이기 때문에 (물론 작업 안에서는 비동기적인 일이 일어나지만..) 일단 캐시 자체를 바꿔놓았기 때문에 await을 통해 외부에서 접근하더라도 재진입 문제가 발생하지 않습니다.(그래서, "작업(Task)"자체를 생성하고 저장하는(중간에 await키워드가 전혀 들어가지 않는) 동기적인 방식으로 재진입 문제를 해결하는 것이라고 보시면 됩니다.) 위의 내용들을 잘 이해해 보시면 좋을 것 같고, 추가적으로 질문이 생기시면 또 질문주세요!감사합니다. :)

Task 클로저 내 `non-Sendable` 값 타입 접근 시, 캡처 리스트가 정의된 Task 순서에 따른 컴파일러 에러 차이

안녕하세요! sujinnaljin 님!질문주신 내용이현재 강의의 48강 ~ 52강 내용하고 관련된 내용인데, 이번에 Xcode가 업데이트가 되면서 내부 메커니즘이 이번에 제대로 구현이 되었나 보네요.(Region Based Isolation 관련 내용이예요, https://github.com/swiftlang/swift-evolution/blob/main/proposals/0414-region-based-isolation.md )뒤에 강의에서 내용을 자세히 다루고 있으니.. 강의 내용을 보시면 되고, 그 전에 최대한 직관적이고 간단하게만 말씀드려보면, ValueCounter타입은 값타입이긴 하지만, Task의 클로저 자체는 변수 주소를 캡처해서 사용하기 때문에 valueCounter 변수 주소가 한번 전달(sending)이 되어 버리면, 그 이후의 코드에서는 사용할 수가 없습니다. (그게 Swift Concurrency에서 새롭게 도입한 Shared Mutable State를 다루기 위한 내부 메커니즘이라고 보시면 됩니다.)(즉, 위의 Task를 "1번 Task"라고 이름 붙이기로 하고, 아래 Task를 "2번 Task"라고 이름 붙이기로 하면.. 이미 1번 Task에서 valueCounter를 차지하고 써버리기로 된 것이기 때문에 2번 Task에서는 더이상 valueCounter의 변수에 조차 접근할 수 없어진 것입니다.)func test() { var valueCounter = ValueCounter() ​ Task {// valueCounter의 주소가 Task 내부로 완전 전달 (더이상 아래 코드에서 사용 불가) print(valueCounter.increment()) print(valueCounter.value) } Task { [valueCounter] in // valueCounter 주소에 접근 불가 var newValueCounter = valueCounter print(newValueCounter.increment()) print(newValueCounter.value) } }다만, Task와 캡처리스트 순서가 바뀌면 가능한 것입니다. 왜냐면 이번에는 캡처리스트를 먼저 사용했기 때문에, valueCounter변수의 주소가 Task 내부로 완전 전달(sending)이 된 것이 아니기 때문에.. 그 이후의 코드인 Task에서 valueCounter 변수에 접근이 가능한 것입니다.func test() { var valueCounter = ValueCounter() ​ Task { [valueCounter] in // valueCounter 주소가 완전 전달이 된 것이 아님 var newValueCounter = valueCounter print(newValueCounter.increment()) print(newValueCounter.value) } Task {// valueCounter 주소에 접근 가능 print(valueCounter.increment()) print(valueCounter.value) } } 네, 그래서 위와 같은 내용을 확인하시면 될 것 같고..강의 후반부 48강 ~ 52강 내용과 sending키워드 내용까지를 잘 보시면 질문 주셨던 내용에 대해 명확하게 이해하실 수 있으실 것 같습니다.(제가 강의 촬영 당시에는.. 컴파일러 내부에 sending키워드 관련 부분이 아마 정확하게 구현이 안되어 있어 크래시가 나지 않았는데, 정확하게 말씀드리면 해당 12강 강의 내용 중에 캡처리스트 부분에 대해 설명드리는 내용은 정확하게 컴파일러 업데이트가 되기 전 내용이라, 제대로 동작하고 있지 않은 것으로 보시면 될 것 같습니다. 즉, 지금 설명드린 내용이 Evolution문서와 정확하게 일치하게 컴파일러가 업데이트 된 내용이라고 보시면 됩니다.) 말씀드린 강의 후반부 내용 확인해보시고도 이해가 안되시는 부분이 있으시면 다시 질문주세요 ! 감사합니다. :)

18강 NSCache 예시 질문

네, sujinnaljin 님첫번째 질문)아, 네네 단순 예시라서 제가 꼼꼼하게 작성하지는 않았었네요! 말씀하신대로 정확하게 작성하신다면.. 아래와 같은 형태로 작성하시는 것이 당연히 맞습니다. (삭제도 딕셔너리에 접근하는 것이니까요.)func clearAll() { lock.lock() cache.removeAll() lock.unlock() } 두번째 질문)아 네, NSCache 자체는 내부적으로 일단 Thread-safe하기 때문에 @unchecked Sendable 만 사용하셔도 됩니다. (아래와 같은 처리를 안해도 된다는 것이겠죠.)func setValue(_ value: Value, for key: Key) { semaphore.wait() cache[key] = value semaphore.signal() }func setValue(_ value: Value, for key: Key) { lock.lock() cache[key] = value lock.unlock() } 그리고.. 일단 공식문서에 Thread-safe하다고 나와있으니, (저라면) 아래처럼 그냥 직접적으로 사용할 것 같고..func setValue(_ value: Value, for key: Key) { cache[key] = value }만약에 그 전에 (1) NSCache를 사용해본 적이 없거나, (2) 공식문서를 미리 확인하지 않았다는 가정을 해보면, 당연히 @unchecked Sendable + 안전하게 위(semaphore or lock)와 같은 처리를 사용할 것 같습니다. (물론 예를 들어, 위와 같은 메서드 로직에서 NSCache만 사용하는 것이 아니라, 다른 딕셔너리 등도 속성으로 같이 처리해주는 등이 있다면, 아무리 NSCache를 사용한다더라도, semaphore 나 lock 을 사용해야겠지만요.)답변이 되셨으면 좋겠습니다. :) 감사합니다...!