70강 - 글로벌 액터로 격리된 Protocol 을 extension 에서 conform 시 타입 본체의 격리 수준 질문

아 네. sujinnaljin 님.자료에 오류가 있었네요ㅠㅠ (제가 다시 에볼루션 문서를 확인해보니, 제가 해석을 잘못했었네요ㅠ) https://github.com/swiftlang/swift-evolution/blob/main/proposals/0316-global-actors.md여기 들어가 보시면, 아래 부분이 있는데, 이 부분의 해석을 제가 해석을 잘못했었던 것 같네요.A non-actor type that conforms to a global-actor-qualified protocol within the same source file as its primary definition infers actor isolation from that protocol:그러니까, 같은 파일 안에서도 conformance 선언 위치가 본체(primary definition) 안에 있어야 한다는 뜻이네요. 그렇다면 결국 정리하자면, 본체에 정의되어야 한다는 건(어차피 같은 파일 안에 있어야 한다는 것과 동일한 말이니) 공식 문서에 같은 파일 안에 있어야 한다는 것(within the same source file)이 크게 의미가 있는 것은 아니고 결국 본체에 채택할 경우, 격리된다는 의미겠네요.정리하자면, "프로토콜 자체가 글로벌 격리로 구현된 프로토콜의 경우, 동일한 소스파일(.swift)이라고 하더라도 확장에 프로토콜을 채택하면, 타입 전체가 글로벌 격리로 추론되지는 않음"라고 볼 수 있겠네요. 이 부분은 교재를 수정 및 수정이 필요한 부분을 추후 강의에 넣어놓도록 하겠습니다.제가 교재를 만들고, 강의를 찍을 당시 수십개의 에볼루션 문서 중에 중요한 내용을 다시정리해서 제 나름대로의 목차를 뽑아서 만들다 보니 사소한 오류들이 조금 있네요. 넓은 아량으로 이해를 부탁드립니다. 감사합니다. :)

Drawing Cycle 관련 질문

네 안녕하세요 taehun0933 님.아마 강의 내에서 제가 여러가지를 이론적으로 설명을 드리면서 다양한 가능성에 대한 설명을 먼저 드려서.. 조금 헷갈리실 수도 있을 것 같은데 (기본적으로 동적으로 변하는 상황이 드물기 때문에) 생성자에서 하시면 된다고 보시면 됩니다. :) ==> '동적으로 constraint를 변경할 상황이 아니라면 생성자에서 초기화해주는 것이 좋다'라고 정확하게 이해하셨습니다.감사합니다. :)

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

안녕하세요 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키워드가 전혀 들어가지 않는) 동기적인 방식으로 재진입 문제를 해결하는 것이라고 보시면 됩니다.) 위의 내용들을 잘 이해해 보시면 좋을 것 같고, 추가적으로 질문이 생기시면 또 질문주세요!감사합니다. :)