├── .gitignore ├── README.md ├── nyokki ├── ARC │ ├── ARC란 무엇인지 설명하시오..md │ ├── README.md │ ├── Retain Count 방식에 대해 설명하시오.md │ ├── Strong 과 Weak 참조 방식에 대해 설명하시오.md │ ├── 강한 순환 참조 (Strong Reference Cycle) 는 어떤 경우에 발생하는지 설명하시오..md │ └── 순환 참조에 대하여 설명하시오..md ├── Architecture │ ├── Architecture Plus │ │ └── Protocol Oriented Programming.md │ ├── MVVM, Ribs, VIP 등 자신이 알고있는 아키텍쳐를 설명하시오..md │ ├── README.md │ └── 의존성 주입에 대하여 설명하시오.md ├── Autolayout │ ├── Intrinsic Size에 대해서 설명하시오.md │ ├── Left Constraint 와 Leading Constraint 의 차이점을 설명하시오..md │ ├── README.md │ ├── Safearea에 대해서 설명하시오..md │ ├── hugging, resistance에 대해서 설명하시오..md │ ├── 스토리보드를 이용했을때의 장단점을 설명하시오..md │ └── 오토레이아웃을 코드로 작성하는 방법은 무엇인가? (3가지).md ├── Functional Programming │ ├── README.md │ ├── Swift Standard Library의 map, filter, reduce, compactMap, flatMap에 대하여 설명하시오.md │ ├── 고차 함수가 무엇인지 설명하시오.md │ └── 함수형 프로그래밍이 무엇인지 설명하시오.md ├── Swift │ ├── Anyobject에 대해 설명하시오..md │ ├── Codable에 대하여 설명하시오..md │ ├── Convenience init에 대해 설명하시오. .md │ ├── Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오..md │ ├── Delegates와 Notification 방식의 차이점에 대해 설명하시오..md │ ├── Extension에 대해 설명하시오..md │ ├── Generic에 대해 설명하시오..md │ ├── Hashable이 무엇이고, Equatable을 왜 상속해야 하는지 설명하시오..md │ ├── KVO 동작 방식에 대해 설명하시오..md │ ├── MVC 구조에 대해 블록 그림을 그리고, 각 역할과 흐름을 설명하시오..md │ ├── Optional 이란 무엇인지 설명하시오..md │ ├── README.md │ ├── Result타입에 대해 설명하시오..md │ ├── Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오..md │ ├── Struct 가 무엇이고 어떻게 사용하는지 설명하시오..md │ ├── Subscripts에 대해 설명하시오..md │ ├── class의 성능을 향상 시킬수 있는 방법들을 나열해보시오. .md │ ├── defer가 호출되는 순서는 어떻게 되고, defer가 호출되지 않는 경우를 설명하시오.md │ ├── defer란 무엇인지 설명하시오..md │ ├── instance 메서드와 class 메서드의 차이점을 설명하시오..md │ ├── mutating 키워드에 대해 설명하시오..md │ ├── property wrapper에 대해서 설명하시오..md │ ├── struct와 class와 enum의 차이를 설명하시오..md │ ├── 멀티 쓰레드로 동작하는 앱을 작성하고 싶을 때 고려할 수 있는 방식들을 설명하시오..md │ ├── 접근 제어자의 종류엔 어떤게 있는지 설명하시오.md │ ├── 탈출 클로저에 대하여 설명하시오..md │ └── 프로토콜이란 무엇인지 설명하시오..md ├── iOS │ ├── Foundation Kit은 무엇이고 포함되어 있는 클래스들은 어떤 것이 있는지 설명하시오.md │ ├── @Main에 대해서 설명하시오..md │ ├── App Bundle의 구조와 역할에 대해 설명하시오..md │ ├── App thinning에 대해서 설명하시오.md │ ├── App의 Not running, Inactive, Active, Background, Suspended에 대해 설명하시오. .md │ ├── Delegate란 무언인가 설명하고, retain 되는지 안되는지 그 이유를 함께 설명하시오..md │ ├── Frame, Bounds.md │ ├── GCD API 동작 방식과 필요성에 대해 설명하시오. .md │ ├── Global DispatchQueue 의 Qos 에는 어떤 종류가 있는지, 각각 어떤 의미인지 설명하시오. .md │ ├── NSCache와 딕셔너리로 캐시를 구성했을때의 차이를 설명하시오..md │ ├── NSOperationQueue 와 GCD Queue 의 차이점을 설명하시오..md │ ├── NotificationCenter 동작 방식과 활용 방안에 대해 설명하시오..md │ ├── OS 앱을 만들고, User Interface를 구성하는 데 필수적인 프레임워크 이름은 무엇인가?.md │ ├── README.md │ ├── TableView를 동작 방식과 화면에 Cell을 출력하기 위해 최소한 구현해야 하는 DataSource 메서드를 설명하시오. .md │ ├── UIApplication 객체의 컨트롤러 역할은 어디에 구현해야 하는가?.md │ ├── UIKit 클래스들을 다룰 때 꼭 처리해야하는 애플리케이션 쓰레드 이름은 무엇인가?.md │ ├── UINavigationController 의 역할이 무엇인지 설명하시오. .md │ ├── UIView 에서 Layer 객체는 무엇이고 어떤 역할을 담당하는지 설명하시오..md │ ├── UIWindow 객체의 역할은 무엇인가?.md │ ├── URLSession에 대해서 설명하시오..md │ ├── View 객체에 대해 설명하시오..md │ ├── app이 foreground와 background에 있을 때 제약.md │ ├── frame & bounds │ │ ├── frame & bounds.xcodeproj │ │ │ ├── project.pbxproj │ │ │ └── project.xcworkspace │ │ │ │ ├── contents.xcworkspacedata │ │ │ │ └── xcshareddata │ │ │ │ └── IDEWorkspaceChecks.plist │ │ └── frame & bounds │ │ │ ├── AppDelegate.swift │ │ │ ├── Assets.xcassets │ │ │ ├── AccentColor.colorset │ │ │ │ └── Contents.json │ │ │ ├── AppIcon.appiconset │ │ │ │ └── Contents.json │ │ │ └── Contents.json │ │ │ ├── Base.lproj │ │ │ ├── LaunchScreen.storyboard │ │ │ └── Main.storyboard │ │ │ ├── Info.plist │ │ │ ├── SceneDelegate.swift │ │ │ └── ViewController.swift │ ├── prepareForReuse에 대해서 설명하시오..md │ ├── scene delegate에 대해 설명하시오..md │ ├── setNeedsLayout와 setNeedsDisplay의 차이에 대해 설명하시오. .md │ ├── 다크모드를 지원하는 방법에 대해 설명하시오. .md │ ├── 모든 View Controller 객체의 상위 클래스는 무엇이고 그 역할은 무엇인가?.md │ ├── 상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오..md │ ├── 실제 디바이스가 없는 개발 환경에서 할 수 있는 것과 없는 것.md │ ├── 앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체를 무엇이라고 하는가?.md │ ├── 앱의 콘텐츠나 데이터 자체를 저장:보관하는 특별한 객체를 무엇이라고 하는가?.md │ ├── 앱이 In-Active 상태가 되는 시나리오를 설명하시오..md │ ├── 앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가?.md │ ├── 자신만의 Custom View를 만들려면 어떻게 해야하는지 설명하시오..md │ └── 하나의 View Controller 코드에서 여러 TableView Controller 역할을 해야 할 경우 어떻게 구분해서 구현해야 하는지 설명하시오..md ├── 네트워크 │ ├── REST API.md │ └── 네트워크 통신.md └── 라이브러리 │ └── 요약.md └── supersupremekim ├── ARC ├── ARC란 무엇인지 설명하시오.md ├── README.md ├── Retain Count 방식에 대해 설명하시오.md ├── Strong 과 Weak 참조 방식에 대해 설명하시오.md ├── 강한 순환 참조 (Strong Reference Cycle) 는 어떤 경우에 발생하는지 설명하시오.md └── 순환 참조에 대하여 설명하시오.md ├── Architecture ├── MVVM, Ribs, VIP 등 자신이 알고있는 아키텍쳐를 설명하시오.md ├── README.md └── 의존성 주입에 대하여 설명하시오.md ├── Autolayout ├── Intrinsic Size에 대해서 설명하시오.md ├── Left Constraint 와 Leading Constraint 의 차이점을 설명하시오.md ├── README.md ├── Safearea에 대해서 설명하시오.md ├── hugging, resistance에 대해서 설명하시오.md ├── 스토리보드를 이용했을때의 장단점을 설명하시오.md └── 오토레이아웃을 코드로 작성하는 방법은 무엇인가.md ├── Functional Programming ├── README.md ├── Swift Standard Library의 map, filter, reduce, compactMap, flatMap에 대하여 설명하시오.md ├── 고차 함수가 무엇인지 설명하시오.md └── 함수형 프로그래밍이 무엇인지 설명하시오.md ├── Swift ├── Anyobject에 대해 설명하시오.md ├── Codable에 대하여 설명하시오.md ├── Convinience init에 대해 설명하시오.md ├── Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오.md ├── Delegates와 Notification 방식의 차이점에 대해 설명하시오.md ├── Extension에 대해 설명하시오.md ├── Generic에 대해 설명하시오.md ├── Hashable이 무엇이고, Equatable을 왜 상속해야 하는지 설명하시오.md ├── KVO 동작 방식에 대해 설명하시오.md ├── MVC 구조에 대해 블록 그림을 그리고, 각 역할과 흐름을 설명하시오.md ├── Optional 이란 무엇인지 설명하시오.md ├── README.md ├── Result타입에 대해 설명하시오.md ├── Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오.md ├── Struct 가 무엇이고 어떻게 사용하는지 설명하시오.md ├── Subscripts에 대해 설명하시오.md ├── class의 성능을 향상 시킬수 있는 방법들을 나열해보시오.md ├── defer가 호출되는 순서는 어떻게 되고, defer가 호출되지 않는 경우를 설명하시오.md ├── defer란 무엇인지 설명하시오.md ├── instance 메서드와 class 메서드의 차이점을 설명하시오.md ├── mutating 키워드에 대해 설명하시오.md ├── property wrapper에 대해서 설명하시오.md ├── struct와 class와 enum의 차이를 설명하시오.md ├── 멀티 쓰레드로 동작하는 앱을 작성하고 싶을 때 고려할 수 있는 방식들을 설며.md ├── 접근 제어자의 종류엔 어떤게 있는지 설명하시오.md ├── 탈출 클로저에 대하여 설명하시오.md └── 프로토콜이란 무엇인지 설명하시오.md └── iOS ├── @Main에 대해서 설명하시오..md ├── App Bundle의 구조와 역할에 대해 설명하시오.md ├── App의 Not running, Inactive, Active, Background, Suspended에 대해 설명하시오.md ├── Delegate란 무언인가 설명하고, retain 되는지 안되는지 그 이유를 함께 설명하시오.md ├── Foundation Kit은 무엇이고 포함되어 있는 클래스들은 어떤 것이 있는지 설명하시오.md ├── GCD API 동작 방식과 필요성에 대해 설명하시오.md ├── Global DispatchQueue 의 Qos 에는 어떤 종류가 있는지, 각각 어떤 의미인지 설명하시오.md ├── NSCache와 딕셔너리로 캐시를 구성했을때의 차이를 설명하시오.md ├── NSOperationQueue 와 GCD Queue 의 차이점을 설명하시오.md ├── NotificationCenter 동작 방식과 활용 방안에 대해 설명하시오.md ├── README.md ├── SceneDelegate에 대해 설명하시오.md ├── TableView를 동작 방식과 화면에 Cell을 출력하기 위해 최소한 구현해야 하는 DataSource 메서드를 ᄉ.md ├── UIApplication.md ├── UIKit 클래스들을 다룰 때 꼭 처리해야하는 애플리케이션 쓰레드 이름은 무엇인가.md ├── UINavigationController 의 역할이 무엇인지 설명하시오.md ├── UIView 에서 Layer 객체는 무엇이고 어떤 역할을 담당하는지 설명하시오.md ├── UIWindow 객체의 역할은 무엇인가.md ├── URLSession에 대해서 설명하시오.md ├── View 객체에 대해 설명하시오.md ├── appthinning.md ├── iOS 앱을 만들고, User Interface를 구성하는 데 필수적인 프레임워크 이름은 무엇인가.md ├── prepareForReuse에 대해서 설명하시오.md ├── setNeedsLayout와 setNeedsDisplay의 차이에 대해 설명하시오.md ├── 다크모드를 지원하는 방법에 대해 설명하시오.md ├── 모든 View Controller 객체의 상위 클래스는 무엇이고 그 역할은 무엇인가.md ├── 상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오.md ├── 앱이 In-Active 상태가 되는 시나리오를 설명하시오.md ├── 앱이 foreground에 있을 때와 background에 있을 때 어떤 제약사항이 있나요?.md ├── 앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가?.md ├── 자신만의 Custom View를 만들려면 어떻게 해야하는지 설명하시오.md ├── 하나의 View Controller 코드에서 여러 TableView Controller 역할을 해야 할 경우 어떻게 구분해서 구현해야 하느.md └── 앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체를 무엇이라고 하는가?.md /.gitignore: -------------------------------------------------------------------------------- 1 | # Xcode 2 | # 3 | # gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore 4 | 5 | ## User settings 6 | xcuserdata/ 7 | 8 | ## compatibility with Xcode 8 and earlier (ignoring not required starting Xcode 9) 9 | *.xcscmblueprint 10 | *.xccheckout 11 | 12 | ## compatibility with Xcode 3 and earlier (ignoring not required starting Xcode 4) 13 | build/ 14 | DerivedData/ 15 | *.moved-aside 16 | *.pbxuser 17 | !default.pbxuser 18 | *.mode1v3 19 | !default.mode1v3 20 | *.mode2v3 21 | !default.mode2v3 22 | *.perspectivev3 23 | !default.perspectivev3 24 | 25 | ## Obj-C/Swift specific 26 | *.hmap 27 | 28 | ## App packaging 29 | *.ipa 30 | *.dSYM.zip 31 | *.dSYM 32 | 33 | ## Playgrounds 34 | timeline.xctimeline 35 | playground.xcworkspace 36 | 37 | # Swift Package Manager 38 | # 39 | # Add this line if you want to avoid checking in source code from Swift Package Manager dependencies. 40 | # Packages/ 41 | # Package.pins 42 | # Package.resolved 43 | # *.xcodeproj 44 | # 45 | # Xcode automatically generates this directory with a .xcworkspacedata file and xcuserdata 46 | # hence it is not needed unless you have added a package configuration file to your project 47 | # .swiftpm 48 | 49 | .build/ 50 | 51 | # CocoaPods 52 | # 53 | # We recommend against adding the Pods directory to your .gitignore. However 54 | # you should judge for yourself, the pros and cons are mentioned at: 55 | # https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control 56 | # 57 | # Pods/ 58 | # 59 | # Add this line if you want to avoid checking in source code from the Xcode workspace 60 | # *.xcworkspace 61 | 62 | # Carthage 63 | # 64 | # Add this line if you want to avoid checking in source code from Carthage dependencies. 65 | # Carthage/Checkouts 66 | 67 | Carthage/Build/ 68 | 69 | # Accio dependency management 70 | Dependencies/ 71 | .accio/ 72 | 73 | # fastlane 74 | # 75 | # It is recommended to not store the screenshots in the git repo. 76 | # Instead, use fastlane to re-generate the screenshots whenever they are needed. 77 | # For more information about the recommended setup visit: 78 | # https://docs.fastlane.tools/best-practices/source-control/#source-control 79 | 80 | fastlane/report.xml 81 | fastlane/Preview.html 82 | fastlane/screenshots/**/*.png 83 | fastlane/test_output 84 | 85 | # Code Injection 86 | # 87 | # After new code Injection tools there's a generated folder /iOSInjectionProject 88 | # https://github.com/johnno1962/injectionforxcode 89 | 90 | iOSInjectionProject/ 91 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # iOSInterviewQuestions 2 | 3 | # 스터디 방식 4 | - 하루에 3가지 면접 질문에 대해서 정리하여 22시까지 푸쉬한다. 5 | - 만약 시간 내에 모두 하지 못한 경우에는 10000원의 벌금 부과 6 | - 22시에 구글밋을 통해 서로 공부한 내용을 번갈아가며 설명을 하고 이 과정에서 보완, 수정한다. 7 | - 일주일에 최대 2회 개인 사정에 의한 스킵가능(단, 당일 사용 불가, 최소 하루 전에 알려줄 것)😀 8 | 9 | 출처 : https://github.com/JeaSungLEE/iOSInterviewquestions 10 | 11 | iOS개발자들에게 필요한 자료들을 정리하고 있는 중입니다. 12 | 13 | 면접때 받은 질문이나 공부한내용들 14 | 15 | 수정해야할 내용이나 추가해야할 내용은 언제든지 PR날려주세요! 16 | 17 | ``` 18 | 답이 적혀있지 않은 이유는 해당 내용을 암기식으로 외우기 보다 찾아보고 공부하면서 습득 하시는게 좋기때문입니다. 19 | 해당내용을 찾아보면서 관련된 내용들 까지 같이 공부하시면서 해당 내용을 본인의 것으로 얻으시기 바랍니다. 20 | ``` 21 | 22 | 모두의 힘을 모아봅시다 👯‍♀️👯‍♂️ 23 | 감사합니다:) 24 | 25 | # Required 26 | 아래 내용들은 최대한 많이 공부해놓는것이 좋습니다 📝 27 | 28 | + 면접시기가 wwdc이후 (7월~11월)이라면 해당년도 wwdc세션들을 봐 두시면 매우매우매우 좋습니다. 29 | 30 | [Apple All Videos](https://developer.apple.com/videos/all-videos/) 31 | 32 | ## iOS 33 | - Bounds 와 Frame 의 차이점을 설명하시오. 34 | - 실제 디바이스가 없을 경우 개발 환경에서 할 수 있는 것과 없는 것을 설명하시오. 35 | - 앱의 콘텐츠나 데이터 자체를 저장/보관하는 특별한 객체를 무엇이라고 하는가? 36 | - 앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체를 무엇이라고 하는가? 37 | - App thinning에 대해서 설명하시오. 38 | ### 39 | - 앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가? 40 | - @Main에 대해서 설명하시오. 41 | - 앱이 foreground에 있을 때와 background에 있을 때 어떤 제약사항이 있나요? 42 | - 상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오. 43 | - 앱이 In-Active 상태가 되는 시나리오를 설명하시오. 44 | - scene delegate에 대해 설명하시오. 45 | - UIApplication 객체의 컨트롤러 역할은 어디에 구현해야 하는가? 46 | - App의 Not running, Inactive, Active, Background, Suspended에 대해 설명하시오. 47 | ### 48 | - NSOperationQueue 와 GCD Queue 의 차이점을 설명하시오. 49 | - GCD API 동작 방식과 필요성에 대해 설명하시오. 50 | - Global DispatchQueue 의 Qos 에는 어떤 종류가 있는지, 각각 어떤 의미인지 설명하시오. 51 | ### 52 | - iOS 앱을 만들고, User Interface를 구성하는 데 필수적인 프레임워크 이름은 무엇인가? 53 | - Foundation Kit은 무엇이고 포함되어 있는 클래스들은 어떤 것이 있는지 설명하시오. 54 | - Delegate란 무언인가 설명하고, retain 되는지 안되는지 그 이유를 함께 설명하시오. 55 | - NotificationCenter 동작 방식과 활용 방안에 대해 설명하시오. 56 | - UIKit 클래스들을 다룰 때 꼭 처리해야하는 애플리케이션 쓰레드 이름은 무엇인가? 57 | - App Bundle의 구조와 역할에 대해 설명하시오. 58 | - 모든 View Controller 객체의 상위 클래스는 무엇이고 그 역할은 무엇인가? 59 | - 자신만의 Custom View를 만들려면 어떻게 해야하는지 설명하시오. 60 | - View 객체에 대해 설명하시오. 61 | - UIView 에서 Layer 객체는 무엇이고 어떤 역할을 담당하는지 설명하시오. 62 | - UIWindow 객체의 역할은 무엇인가? 63 | - UINavigationController 의 역할이 무엇인지 설명하시오. 64 | - TableView를 동작 방식과 화면에 Cell을 출력하기 위해 최소한 구현해야 하는 DataSource 메서드를 설명하시오. 65 | - 하나의 View Controller 코드에서 여러 TableView Controller 역할을 해야 할 경우 어떻게 구분해서 구현해야 하는지 설명하시오. 66 | - setNeedsLayout와 setNeedsDisplay의 차이에 대해 설명하시오. 67 | ### 68 | - NSCache와 딕셔너리로 캐시를 구성했을때의 차이를 설명하시오. 69 | - URLSession에 대해서 설명하시오. 70 | - prepareForReuse에 대해서 설명하시오. 71 | - 다크모드를 지원하는 방법에 대해 설명하시오. 72 | 73 | ## Autolayout 74 | - 오토레이아웃을 코드로 작성하는 방법은 무엇인가? (3가지) 75 | - hugging, resistance에 대해서 설명하시오. 76 | - Intrinsic Size에 대해서 설명하시오. 77 | - 스토리보드를 이용했을때의 장단점을 설명하시오. 78 | - Safearea에 대해서 설명하시오. 79 | - Left Constraint 와 Leading Constraint 의 차이점을 설명하시오. 80 | 81 | ## Swift 82 | - struct와 class와 enum의 차이를 설명하시오. 83 | - class의 성능을 향상 시킬수 있는 방법들을 나열해보시오. 84 | - Convinience init에 대해 설명하시오. 85 | - Anyobject에 대해 설명하시오. 86 | - Optional 이란 무엇인지 설명하시오. 87 | - Struct 가 무엇이고 어떻게 사용하는지 설명하시오. 88 | - Subscripts에 대해 설명하시오. 89 | - instance 메서드와 class 메서드의 차이점을 설명하시오. 90 | - Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오. 91 | - Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오. 92 | - KVO 동작 방식에 대해 설명하시오. 93 | - Delegates와 Notification 방식의 차이점에 대해 설명하시오. 94 | - 멀티 쓰레드로 동작하는 앱을 작성하고 싶을 때 고려할 수 있는 방식들을 설명하시오. 95 | - MVC 구조에 대해 블록 그림을 그리고, 각 역할과 흐름을 설명하시오. 96 | - 프로토콜이란 무엇인지 설명하시오. 97 | - Hashable이 무엇이고, Equatable을 왜 상속해야 하는지 설명하시오. 98 | - mutating 키워드에 대해 설명하시오. 99 | - 탈출 클로저에 대하여 설명하시오. 100 | - Extension에 대해 설명하시오. 101 | - 접근 제어자의 종류엔 어떤게 있는지 설명하시오 102 | - defer란 무엇인지 설명하시오. 103 | - defer가 호출되는 순서는 어떻게 되고, defer가 호출되지 않는 경우를 설명하시오. 104 | - property wrapper에 대해서 설명하시오. 105 | - Generic에 대해 설명하시오. 106 | - Result타입에 대해 설명하시오. 107 | - Codable에 대하여 설명하시오. 108 | 109 | ## ARC 110 | - ARC란 무엇인지 설명하시오. 111 | - Retain Count 방식에 대해 설명하시오. 112 | - Strong 과 Weak 참조 방식에 대해 설명하시오. 113 | - 순환 참조에 대하여 설명하시오. 114 | - 강한 순환 참조 (Strong Reference Cycle) 는 어떤 경우에 발생하는지 설명하시오. 115 | 116 | ## Functional Programming 117 | - 함수형 프로그래밍이 무엇인지 설명하시오. 118 | - 고차 함수가 무엇인지 설명하시오. 119 | - Swift Standard Library의 map, filter, reduce, compactMap, flatMap에 대하여 설명하시오. 120 | 121 | ## Architecture 122 | - MVVM, Ribs, VIP 등 자신이 알고있는 아키텍쳐를 설명하시오. 123 | - 의존성 주입에 대하여 설명하시오. 124 | 125 | # Optional 126 | 아래부터는 추가로 공부를 하면 좋을 내용들입니다. 127 | 128 | Objective-c나 rx는 회사, 팀마다 사용하는곳이 차이가있고 신입이나 주니어기준으로 필수라고 여겨지지않기에 옵셔널에 추가하였습니다. 129 | 130 | ## MRC 131 | - ARC 대신 Manual Reference Count 방식으로 구현할 때 꼭 사용해야 하는 메서드들을 쓰고 역할을 설명하시오. 132 | - retain 과 assign 의 차이점을 설명하시오. 133 | - 특정 객체를 autorelease 하기 위해 필요한 사항과 과정을 설명하시오. 134 | - Autorelease Pool을 사용해야 하는 상황을 두 가지 이상 예로 들어 설명하시오. 135 | - 다음 코드를 실행하면 어떤 일이 발생할까 추측해서 설명하시오. 136 | Ball *ball = [[[[Ball alloc] init] autorelease] autorelease]; 137 | 138 | ## Advanced 139 | - method swizzling이 무엇이고, 어떨 때 사용하는지 설명하시오. 140 | - NSCoder 클래스는 어떤 상황에서 어떻게 써야 하는지 설명하시오. 141 | - Responder Chain 구조에 대해 설명하고, First Responder 역할에 대해 설명하시오. 142 | - NSObject부터 UIButton 까지 상속 과정의 계층과 역할을 설명하시오. 143 | - shallow copy와 deep copy의 차이점을 설명하시오. 144 | - Push Notification 방식에 대해 설명하시오. 145 | - Foundation 과 Core Foundation 프레임워크의 차이점을 설명하시오. 146 | - NSURLConnection 에서 사용하는 Delegate 메서드들에 대해 설명하시오. 147 | - Synchronous 방식과 Asynchronous 방식으로 URL Connection을 처리할 경우의 장단점을 비교하시오. 148 | - Plist 파일 구조와 Plist 파일에 저장된 데이터를 다루기 적합한 클래스를 설명하시오. 149 | - Core Data와 Sqlite 같은 데이터 베이스의 차이점을 설명하시오. 150 | - JSON 데이터를 처리하는 방식과 파서, 객체 변환 방식에 대해 설명하시오. 151 | - 웹 서버와 HTTP 연결을 사용해서 데이터를 주거나 받으려면 사용해야 하는 클래스와 동작을 설명하시오. 152 | - Protocol에서는 왜 var만 되는지 설명하시요. 153 | 154 | ## Objective-C 155 | - Swift의 클로저와 Objective-C의 블록은 어떤 차이가 있는가? 156 | - Mutable 객체과 Immutable 객체는 어떤것이 있는지 예를 들고, 차이점을 설명하시오. 157 | - dynamic과 property 의미와 차이를 설명하시오. 158 | - @property로 선언한 NSString* title 의 getter/setter 메서드를 구현해보시오. 159 | - @property에서 atomic과 nonatomic 차이점을 설명하고, 어떤것이 안전한지, 어느것이 기본인지 설명하시오. 160 | - @property로 선언한다는 것의 의미를 설명하고, .h에 넣을 경우와 .m에 넣을 경우 차이점을 설명하시오. 161 | - -performSelector:withObject:afterDelay: 메시지를 보내면 인자값의 객체는 retain되는가? 그 이유를 함께 설명하시오. 162 | - Objective-C 에서 캡슐화된 데이터를 접근하기 위한 방법들을 설명하시오. 163 | - Fast Enumeration 이란 무엇인지 설명하시오. 164 | - unnamed category 방식에 대해 설명하시오. 165 | - Category 확장과 Subclass 확장의 차이점을 설명하시오. 166 | - Category 방식에 대해 설명하시오. 167 | - Objective-C 에서 Protocol 이란 무엇인지 설명하시오. 168 | - Objective-C++ 방식이 무엇인지 설명하고, 어떤 경우 사용해야 하는지 설명하시오. 169 | 170 | ## Rx 171 | - Reactive Programming이 무엇인지 설명하시오. 172 | - RxSwift에서 Hot Observable과 Cold Observable의 차이를 설명하시오. 173 | - Subject와 drive의 차이를 설명하시오. 174 | -------------------------------------------------------------------------------- /nyokki/ARC/ARC란 무엇인지 설명하시오..md: -------------------------------------------------------------------------------- 1 | # ARC(Auto Reference Counting)란? 2 | 3 | 스택에 저장된 데이터는 자동으로 제거 되기 때문에 특별한 메모리 관리가 필요 없으나 4 | 5 | 하지만 힙에 저장된 데이터는 데이터가 필요하지 않은 시점에 직접 제거해야 한다. 6 | 7 | 메모리 관리모델은 힙에 저장된 데이터를 관리하는데 참조 형식을 관리한다. 참조 형식은 클래스와 클로저 밖에 존재하지 않는다. 8 | 9 | 10 | 11 | > **스택과 힙** 12 | > 13 | > 스택은 함수 실행을 위한 임시적인 공간으로 크기가 작고 빠르게 사용하기 위한 데이터가 들어간다. 14 | > 15 | > 힙은 동적 할당(비어있는 메모리 공간을 찾아서 저장하는 방식)이 되어 일반적으로 긴 시간 동안 저장을 하며 크기가 크고 관리할 필요가 있는 데이터가 저장된다. 16 | 17 | 18 | 19 | ## RC(Reference Counting): 참조 카운트 20 | 21 | 메모리 관리 방식은 RC(Reference Counting)을 통해 메모리를 관리하게 된다. 22 | 23 | 인스턴스는 하나 이상의 소유자가 있는 경우에 메모리에 유지된다. 24 | 25 | 반대로 소유자가 없다면 메모리에서 제거된다. 26 | 27 | 제거 시점을 파악하기 위해서 소유자 수를 저장하는데 이것을 참조 카운트라고 한다. 28 | 29 | 30 | 31 | 인스턴스는 참조 카운트 1 이상이면 메모리에서 유지되고 참조 카운트가 0이되면 메모리에서 제거된다. 32 | 33 | 클래스 인스턴스를 변수에 저장하면 변수가 소유자가 되기에 참조 카운트가 1이 된다. 34 | 35 | 동일 인스턴스를 다른 변수에 저장하면 소유자가 늘어나기 때문에 참조 카운트가 2가 된다. 36 | 37 | 인스턴스를 소유하기 위해서는 특별한 메세지를 전달해야 하는데 38 | 39 | 코드레벨에서 확인하자면 인스턴스가 제공하는 retain 메서드 호출하는 것과 같다. 40 | 41 | 인스턴스가 더이상 필요하지 않다면 소유권을 포기해야하는데 이 메세지는 release 메소드 이다. 42 | 43 | 소유권을 포기하면 인스턴스 참조 카운트가 1 감소한다. 44 | 45 | 이렇게 참조카운트가 0이되면 즉시 메모리에서 제거 된다. 46 | 47 | 48 | 49 | Swift에서는 ARC를 제공하여 자동으로 RC관리를 해준다. 컴파일러가 메모리 관리 코드를 자동으로 작성해주기 때문에 코드가 줄어들고 메모리 안전성이 증가한다. 50 | 51 | 52 | 53 | Cocoa에서 사용하는 메모리 관리 모델은 MRC/ARC이고 Swift에서는 ARC만 제공한다. 54 | 55 | MRC란 수동 RC관리를 의미한다. 56 | 57 | 58 | 59 | 참고 60 | 61 | https://www.notion.so/ARC-ced8ef568b2d429cb22e7ee05b54da72 62 | 63 | https://velog.io/@grap_ios/%EB%A9%B4%EC%A0%91%EC%A7%88%EB%AC%B8-ARC-01-06 64 | 65 | https://babbab2.tistory.com/26 -------------------------------------------------------------------------------- /nyokki/ARC/README.md: -------------------------------------------------------------------------------- 1 | ## ARC 2 | - [x] ARC란 무엇인지 설명하시오. 3 | - [x] Retain Count 방식에 대해 설명하시오. 4 | - [x] Strong 과 Weak 참조 방식에 대해 설명하시오. 5 | - [x] 순환 참조에 대하여 설명하시오. 6 | - [x] 강한 순환 참조 (Strong Reference Cycle) 는 어떤 경우에 발생하는지 설명하시오. 7 | -------------------------------------------------------------------------------- /nyokki/ARC/Retain Count 방식에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | ## Retain Count 방식 2 | 3 | ### Retain 4 | 5 | NSObject 클래스 함수이며 6 | 7 | 객체의 레퍼런스 카운트를 증가시키고 객체가 메모리에서 해제되지 않도록 하기 위해 Retain 함수를 호출하여 래퍼런스 카운트를 증가시킬 수 있다. 8 | 9 | 10 | 11 | ### Release 12 | 13 | NSObject 클래스 함수이며 14 | 15 | 객체의 레퍼런스 카운트를 감소시키고 객체를 더이상 사용하지 않거나, 메모리에서 해제하고 될 때 Release 함수를 호출해 레퍼런스 카운트를 감소시킬 수 있다. 16 | 17 | 18 | 19 | 20 | 21 | 참고 22 | 23 | https://www.notion.so/Retain-Count-5746d886d39843b482c0a9a02b9f5f0e -------------------------------------------------------------------------------- /nyokki/ARC/Strong 과 Weak 참조 방식에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | ### Strong Reference(강한 참조) 2 | 3 | - 해당 인스턴스의 소유권을 가진다. 4 | - 소유하고 있기 때문에 자신이 참조하는 인스턴스의 retain count를 증가시킨다. 5 | - 값 지정 시점에 retain 되고 참조가 종료되는 시점에 release가 되어 reference count를 1 감소시킨다. 6 | - 인스턴스 선언시 어떤 키워드도 앞에 붙혀주지 않으면 strong이 default이다. 7 | 8 | 9 | 10 | ### Weak Reference(약한 참조) 11 | 12 | + 해당 인스턴스의 소유권을 가지지 않고, 주소값만을 가지고 있는 포인터 개념이다. 13 | + 자신이 참조하는 인스턴스의 reference count를 증가시키지 않는다. 때문에 release도 발생하지 않는다. 14 | + 자신이 참조는 하지만 weak 메모리를 해제시킬 수 있는 권한은 다른 클래스에 있다. 다시 말해, 약한 참조의 경우, 참조하고 있던 인스턴스가 사라지면 nil로 초기화가 된다. 15 | + 메모리가 해제될 경우 자동으로 레퍼런스가 nil로 초기화 해준다. 16 | + nil이 될 수 있기 때문에 weak 속성은 var만 가능하고 optional이어야 한다. 17 | + 소유자에 비해 짧은 생명주기를 가진 인스턴스를 참조할 때 주로 사용한다. 18 | 19 | 20 | 21 | ### Unowned Reference(비소유 참조) 22 | 23 | + 인스턴스의 소유권을 가지지 않는다. 24 | + 자신이 참조하는 인스턴스의 reference count를 증가시키지 않는다. 25 | + nil이 될 수 없다. optional로 선언해서는 안된다.(Swift 5.3 이전 버전) -> 초기화 함수에서 초기화를 해줘야 한다. 26 | + Swift 5.3 이후 버전에서는 Optional로 선언해도 된다. 단 비소유 참조의 경우, 참조하고 있던 인스턴스가 사라지면(nil이 되면) weak reference와 다르게(nil로 자동으로 초기화) nil로 초기화가 되지 않고, 해당 데이터에 접근하면 에러가 발생한다. -> 에러가 발생하지 않으려면 해당 데이터에 nil 값을 먼저 넣어주어야 한다. 27 | + 소유자보다 인스턴스의 생명주기가 더 길거나, 같은 경우에 사용한다. 28 | 29 | 30 | 31 | 참고 32 | 33 | https://devsrkim.tistory.com/entry/Swift-%EB%A9%94%EB%AA%A8%EB%A6%AC%EB%A5%BC-%EC%B0%B8%EC%A1%B0%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95-Strong-Weak-Unowned -------------------------------------------------------------------------------- /nyokki/ARC/강한 순환 참조 (Strong Reference Cycle) 는 어떤 경우에 발생하는지 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### 사전지식 2 | 3 | + **클로저의 캡처** 4 | 5 | 클로저의 바디(scope)에서 인스턴스의 프로퍼티에 접근하거나 인스턴스의 메소드를 호출하는 것을 캡쳐라고 한다. 클로저에서 사용되는 프로퍼티는 참조하는 형식(메모리 주소 저장)으로 데이터를 저장하기 때문이다. 6 | 7 | 풀어 얘기하자면, 클로저는 힙에 저장되며 만일 클로저를 저장한 데이터가 있다면, 해당 데이터는 스택에서 힙에 있는 클로저의 주소를 저장하여 클로저를 참조하게 된다. 8 | 9 | 이때 클로저 내부에서 외부 인스턴스의 프로퍼티에 접근하려고 하면 해당 외부에 존재하는 값타입의 변수 주소를 사용하기 때문에 캡처라고 한다. 10 | 11 | + **캡처리스트** 12 | 13 | 캡처리스트를 사용하는 이유 14 | 15 | + 값 타입은 값을 복사/캡처하기 때문에 외부적인 요인에 의한 값이 변경되는 것을 방지한다. 16 | + 참조 타입은 캡처리스트 내에서 메모리 주소를 캡처하여 weak/unowned 참조 선언이 가능하다. -> 강한 참조를 해결하는 방법이다. 17 | + 참고로 캡처리스트에서 바인딩도 가능하다. 18 | 19 | Swift 5.3 이후 추가된 내용 20 | 21 | + self의 사용 22 | 23 | ```swift 24 | class SomeThing { 25 | let name = "누군가" 26 | 27 | func doSomething() { 28 | DispatchQueue.main.async { 29 | print("나의 이름은 \(self.name)") 30 | } 31 | } 32 | } 33 | ``` 34 | 35 | 인스턴스 내부 클로저에서 인스턴스의 프로퍼티를 사용하기 위해서는 self.를 붙혀주어야 한다. 36 | 37 | Swift 5.3에서는 캡처리스트 [self]를 사용하면 self를 붙히지 않아도 된다. 38 | 39 | 구조체의 경우에서느 self를 생략하는 것도 가능해졌다. 40 | 41 | ```swift 42 | class SomeThing { 43 | let name = "누군가" 44 | 45 | func doSomething() { [self] in 46 | DispatchQueue.main.async { 47 | print("나의 이름은 \(name)") 48 | } 49 | } 50 | } 51 | ``` 52 | 53 | 54 | 55 | 클래스뿐 아니라 클로저에서도 강한 순환 참조가 일어난다. 클로저도 참조 타입이기 때문이다. 56 | 57 | 클래스 인스턴스의 프로퍼티에 클로저를 할당할 때 클로저에 참조를 할당하기 때문에 강한 순환 참조가 발생할 수 있고, 클로저의 본문이 인스턴스를 캡처할 때 클로저가 self를 캡처하게 되면서 강한 순환 참조가 발생할 수 있다. 58 | 59 | 60 | 61 | 62 | 63 | 참고 64 | 65 | http://jhyejun.com/blog/strong-reference-cycles-in-closure 66 | 67 | -------------------------------------------------------------------------------- /nyokki/ARC/순환 참조에 대하여 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## 순환참조 2 | 3 | - 서로가 서로를 소유하고 있어서 절대 메모리 해제가 되지 않는다는 것을 의미한다. 4 | - 컴파일시에 Swift에서 ARC로 관리를 해주지만 잘못하면 순환참조가 발생할 수 있다. 5 | 6 | 7 | 8 | 예를 들어, 두 개의 다른 클래스의 프로퍼티에 각각 클래스를 서로를 가르키는 프로퍼티가 존재하는 경우 9 | 10 | 각 클래스의 인스턴스를 생성한 후에 두 인스턴스를 서로 연걸하게 되면 서로가 소유자가 되어 강한 참조 상태가 된다. 11 | 12 | 이때 두 인스턴스에 nil을 입력하여도 13 | 14 | 참조카운트는 0이 되지 않아서 소멸자는 둘 다 호출되지 않으며 메모리 누수를 일으킨다. 15 | 16 | 17 | 18 | 이를 해결하기 위해서는 weak 참조, unowned 참조를 사용하면 된다. 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 참고 31 | 32 | https://devsrkim.tistory.com/entry/Swift-%EB%A9%94%EB%AA%A8%EB%A6%AC%EB%A5%BC-%EC%B0%B8%EC%A1%B0%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95-Strong-Weak-Unowned -------------------------------------------------------------------------------- /nyokki/Architecture/Architecture Plus/Protocol Oriented Programming.md: -------------------------------------------------------------------------------- 1 | # 프로토콜 지향 프로그래밍(Protocol Oriented Programming) 2 | 3 | Swift는 객체 지향 프로그래밍, 함수 지향 프로그래밍, 프로토콜 지향 프로그래밍을 모두 담고 있는 언어이다. 4 | 5 | 6 | 7 | 프로토콜 지향 프로그래밍의 장점은 8 | 9 | 여러 개의 프로토콜을 채택할 수 있고 메모리 구조에 대한 특정 요구 사항이 없다. (선택적 채택도 가능하다.) 10 | 11 | 또한 모든 타입에서 채택이 가능하다. (객체 지향 프로그래밍은 클래스만 상속하여 사용할 수 있었음.) 12 | 13 | 타입으로 사용 가능하므로 활용도가 높고 보다 깔끔한 구현과 재사용성을 높일 수 있다. 14 | 15 | ## 프로토콜 프래그래밍이 중요한 이유 16 | 17 | 구현이 아닌 인터페이스에 맞추어 개발하라는 말이 있다. 그만큼 인터페이스는 중요하다. 18 | 19 | 여기서 프로토콜과 인터페이스는 무슨 연관일까? 프로토콜은 의도한 행위만 노출 시키는 것이다. 그에 따른 상세 구현은 20 | 21 | 프로토콜을 채택한 곳에서 행위를 하는 것이기 때문에 그 **의도**만을 나타내는 인터페이스, 프로토콜 인 것이다. 22 | 23 | 24 | 25 | 의도한 행위 만을 노출 시킴으로서 그 외 상태에 대한 캡슐화가 이루어진다. 26 | 27 | 구현체가 아닌 프로토콜에 의존적이면, 구현을 바꾸기가 쉬워진다. 인터페이스만 충족된다면, 사용되는 곳에서는 신경쓰지 않는다. 28 | 29 | 30 | 31 | ### 주의할 점 32 | 33 | 프로토콜의 구현을 바꾸는 건 쉽다는 장점이 있지만 프로토콜 자체를 바꾸는 일은 모든 구현체, 해당 프로토콜을 사용하는 객체, 테스트 코드에 영향을 주기 때문에 어려운 작업이 된다. 따라서 프로토콜을 설계할 때 적절한 권한(역할)을 부여해야 하여 변경을 최소화 해야 한다. 34 | 35 | extension을 통해 부분 기본 구현으로 좀더 유연한 개발이 가능해보인다. 36 | 37 | -------------------------------------------------------------------------------- /nyokki/Architecture/MVVM, Ribs, VIP 등 자신이 알고있는 아키텍쳐를 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### 용어 정리 2 | 3 | #### Entity 4 | 5 | 사전적 의미로는 ‘실체’, ‘존재’, ‘자주적인 것’, ‘본질’이다. 데이터베이스에서는 엔티티를 ‘실체’ 또는 ‘개체’라고 표현한다. 엔티티로 구성된 엔티티 집합이란 [정보](https://terms.naver.com/entry.nhn?docId=1140447&ref=y)의 세계에서는 의미 있는 정보의 단위 또는 우리가 관리하고자 하는 두 개 이상의 속성과 두 개 이상의 개체를 지닌 동질성의 의미를 가진 독립적인 집합이다. 6 | 7 | 출처: **[네이버 지식백과]** [엔티티](https://terms.naver.com/entry.naver?docId=1179872) [entity] (두산백과) 8 | 9 | #### Repository 10 | 11 | 애플리케이션 개발에 관련된 정보를 보관해 둔 [데이터베이스](https://terms.naver.com/entry.nhn?docId=842806&ref=y). 정의(定義) 정보, 설계 정보, [프로그램](https://terms.naver.com/entry.nhn?docId=833746&ref=y) 및 시험 결과 등의 [응용 프로그램](https://terms.naver.com/entry.nhn?docId=815270&ref=y) 개발에 대한 각 공정 과정에서 발생한 정보를 축적해서 공정간에 공용하거나 궤환되도록 컴퓨터 이용 [소프트웨어](https://terms.naver.com/entry.nhn?docId=837523&ref=y) 공정 툴이 지원된다. 12 | 13 | 출처: **[네이버 지식백과]** [리포지토리](https://terms.naver.com/entry.naver?docId=845827) [repository] (IT용어사전, 한국정보통신기술협회) 14 | 15 | 16 | 17 | # 아키텍처란? 18 | 19 | ### 아키텍처에 대한 기본 요구 사항 20 | 21 | + 시스템 구성 및 동작 원리를 나타내고 있다. 22 | + 시스템 구성 요소에 대해 설계 및 구현을 지원하는 수준으로 자세히 기술된다. 23 | + 구성 요소 간의 관계 및 시스템 외부 환경과외 관계가 묘사된다. 24 | 25 | ---------> **서비스의 동작 원리를 나타낸다.** 26 | 27 | 28 | 29 | ### 좋은 아키텍처의 요소 30 | 31 | 1. Distribution 32 | 33 | 각 객체들의 역할이 분명한가? 34 | 35 | 한 객체는 하나의 역할만 수행하도록 해서, 프로그램의 복잡도를 낮추는가? 36 | 37 | 2. Testability 38 | 39 | 테스트가 가능한가? 40 | 41 | 3. Ease of use 42 | 43 | 사용하기 편리하고(길이가 짧고 가독성이 좋은 코드), 유지보수 비용이 적은가? 44 | 45 | 46 | 47 | # MVVM 48 | 49 | MVVM은 Model, View, ViewModel을 나타낸다. 50 | 51 | ### Model 52 | 53 | 데이터 구조를 정의하고 ViewModel에게 결과를 알려준다. 54 | 55 | Model은 View와 이어지지 않는다. 56 | 57 | 58 | 59 | 데이터 모델, 비지니스 로직 등이 포함되어 있다. (Model, Repository, Service) 60 | 61 | 모델은 데이터의 CRUD(Create, Read, Update, Delete)에 대한 함수와 코드가 작성되어 있으며 62 | 63 | 이는 ViewModel에 의해서 시작되고 작업을 마치면 ViewModel에게 알려준다. 64 | 65 | ### View 66 | 67 | ViewController에 작성하며 view는 사용자와 상호작용이 직접적으로 일어나는 곳이다. 68 | 69 | 이벤트가 일어나면 ViewModel에게 알려주며 ViewModel은 이 요청에 대한 결과 데이터를 보여준다. 70 | 71 | ### ViewModel 72 | 73 | View와 Model 사이를 연결해준다. 74 | 75 | View를 나타내주기 위한 로직을 처리하며 View는 ViewModel에 의존한다. 76 | 77 | ViewModel은 사용자와 상호작용에 대한 이벤트를 View가 보내주면 그에 맞는 이벤트를 처리하여 Model에게 알려주며 Model은 이를 반영한 데이터를 다시 ViewModel에게 알려주고 이 결과를 View에게 전달하여 View에 나타나게 되는 것이다. 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 참고 87 | 88 | https://gwangyonglee.tistory.com/49 89 | 90 | https://42kchoi.tistory.com/292 91 | 92 | https://jiyeonlab.tistory.com/38 93 | 94 | https://youtu.be/M58LqynqQHc 95 | 96 | 97 | 98 | 클린코드 클린 아키텍처 99 | 100 | https://www.youtube.com/watch?v=KUEe1tc2CbE -------------------------------------------------------------------------------- /nyokki/Architecture/README.md: -------------------------------------------------------------------------------- 1 | ## Architecture 2 | - [x] MVVM, Ribs, VIP 등 자신이 알고있는 아키텍쳐를 설명하시오. 3 | - [x] 의존성 주입에 대하여 설명하시오. 4 | 5 | -------------------------------------------------------------------------------- /nyokki/Architecture/의존성 주입에 대하여 설명하시오.md: -------------------------------------------------------------------------------- 1 | ## Dependency Injection(DI): 의존성 주입 2 | 3 | ### 의존성 주입이란? 4 | 5 | 표준을 정의할 수 있고, 정의된 표준을 바탕으로 같은 설계를 하게 해주는 것 6 | 7 | #### 장점 8 | 9 | 1. 재사용성을 높여준다. 10 | 2. 테스트하기 좋다. 11 | 3. 코드를 단순화 시켜준다. 12 | 4. 종속적이던 코드의 수도 줄여준다. 13 | 5. 사용 목적을 파악하기 쉽다. 코드의 가독성이 높아진다. 14 | 6. 종속성이 감소한다. 구성 요소의 종속성이 감소하면 변경에 민감하지 않다. 15 | 7. 결합도를 낮추면서 유연성과 확장성은 향상사킨다. 16 | 8. 객체 간의 의존 관계를 설정할 수 있다. 17 | 9. 객체 간의 의존관계를 없애거나 줄일 수 있다. 18 | 19 | 20 | 21 | 그럼 의존성은 무엇이고 주입은 무엇일까 ? 22 | 23 | 24 | 25 | ### 의존성이란? 26 | 27 | 의존 관계를 가지는 상황에 대한 이해를 하면 좋은데 28 | 29 | 만일 A클래스를 B클래스의 인스턴스로 만들고 이 인스턴스로 B클래스 내부에 작업을 하게 된다면 30 | 31 | B클래스는 자연스럽게 A클래스에 대한 의존 관계가 생기게 된다. 32 | 33 | 34 | 35 | ### 주입이란? 36 | 37 | 내부가 아니라 외부에서 객체를 생성해서 넣어주는 것을 주입이라고 한다. 38 | 39 | B클래스 내부에 A클래스의 인스턴스를 생성하는 것이 아닌 40 | 41 | A클래스를 사용할 공간을 비워두고 B클래스의 인스턴스를 생성할 때(외부) 42 | 43 | A클래스를 넣어주는 것을 주입이라고 한다. 44 | 45 | 46 | 47 | ### 의존성과 주입을 합친 의존성 주입을 다시 살펴보면 ....? 48 | 49 | 내부에 만든 변수를 외부에서 넣어주게 하면 의존성 주입이 된다. 50 | 51 | > B클래스 내부에 A클래스의 인스턴스를 생성하는 것이 아닌 52 | > 53 | > A클래스를 사용할 공간을 비워두고 B클래스의 인스턴스를 생성할 때(외부) 54 | > 55 | > A클래스를 넣어주는 것 56 | 57 | 위 예시는 클래스 생성이었지만 함수를 이용해서 외부에서 넣거나 할 수 있다. 58 | 59 | #### 하지만 의존성을 주입하는 것만으로 의존성 주입이라고 하지 않는다. 60 | 61 | 62 | 63 | ### 의존성 분리란? 64 | 65 | 의존성 주입은 의존성을 분리시켜 사용한다. 66 | 67 | 의존성 분리는 의존관계 역전의 원칙으로 의존관계를 분리시킨다. 68 | 69 | > #### 의존관계 역전 원칙이란? 70 | > 71 | > 객체 지향 프로그래밍에서 의존관계 역전 원칙은 소프트웨어 모듈들을 분리하는 특정 형식을 지칭한다. 이 원칙에 따르면 상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 역전 시킴으로써 상위 계층이 하위 계층의 구현으로 부터 독립되게 할 수 있따. 72 | > 73 | > 1. 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 74 | > 2. 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다. 75 | > 76 | > 출처: https://ko.wikipedia.org/wiki/의존관계_역전_원칙 77 | 78 | 상위 모듈이 하위 모듈을 의존하게 되는 상황에서 이를 반전시켜 하위 계층의 구현으로 부터 독립하게 된다. ... 어떻게 하지 ? 79 | 80 | Interface를 이용하는 것인데, iOS에서는 이를 protocol로 이용한다. 81 | 82 | --->의존관계를 독립 시킨다. 83 | 84 | 85 | 86 | ### IOC(Inversion Of Control): 제어의 역전 87 | 88 | 프로그래머가 작성한 프로그램이 라이브러리의 흐름 제어를 받게 되는 디자인 패턴 89 | 90 | + 프로그램 제어권을 프레임워크가 가져가는 것 91 | + 개발자는 비지니스 로직에만 신경쓰면 됨 92 | + 개발자가 annotation, xml 등을 통해 설정 해 놓으면 Container가 알아서 처리 93 | + SOLID 원칭 중 S를 지킬 수 있게 됨(?) 94 | 95 | ------> 보완할 필요가 있음 96 | 97 | 98 | 99 | ## 의존성 주입 3가지 방법 100 | 101 | ### 1. Constructor Injection(생성자 주입) 102 | 103 | ```swift 104 | protocol Eatable { 105 | var calorie: Int { get } 106 | } 107 | 108 | struct Noodle: Eatable { 109 | var calorie: Int { 110 | return 250 111 | } 112 | } 113 | 114 | struct Restaurant { 115 | let food: Eatable 116 | 117 | init(food: Eatable) { 118 | self.food = food 119 | } 120 | } 121 | 122 | let restaurant = Restaurant(food: Noodle()) 123 | ``` 124 | 125 | ### 2. Property Injection 126 | 127 | ```swift 128 | protocol Eatable { 129 | var calorie: Int { get } 130 | } 131 | 132 | struct Noodle: Eatable { 133 | var calorie: Int { 134 | return 250 135 | } 136 | } 137 | 138 | struct Restaurant { 139 | var food: Eatable? 140 | } 141 | 142 | var restaurant = Restaurant() 143 | restaurant.food = Noodle() 144 | ``` 145 | 146 | ### 3. Method Injection 147 | 148 | ```swift 149 | protocol Eatable { 150 | var calorie: Int { get } 151 | } 152 | 153 | struct Noodle: Eatable { 154 | var calorie: Int { 155 | return 250 156 | } 157 | } 158 | 159 | class Restaurant { 160 | var food: Eatable? 161 | 162 | func setUp(food: Eatable) { 163 | self.food = food 164 | } 165 | } 166 | 167 | var restaurant = Restaurant() 168 | restaurant.setUp(food: Noodle()) 169 | ``` 170 | 171 | 172 | 173 | 174 | 175 | 참고 176 | 177 | https://lena-chamna.netlify.app/post/dependency_injection/ 178 | 179 | https://medium.com/@jang.wangsu/di-dependency-injection-이란-1b12fdefec4f 180 | 181 | https://eunjin3786.tistory.com/115 182 | 183 | -------------------------------------------------------------------------------- /nyokki/Autolayout/Intrinsic Size에 대해서 설명하시오.md: -------------------------------------------------------------------------------- 1 | ## Intrinsic Size 2 | 3 | 컨텐츠의 본질적인 크기 4 | 5 | Auto Layout은 기본적으로 뷰의 위치와 크기를 모두 정의하도록 Constraint를 구성해야 한다. 하지만 특정 뷰에서는 Content에 따라 고유한 크기를 갖는다. 따라서 이 경우에는 크기를 지정하지 않아도 오류 없이 뷰가 구성이 된다. 6 | 7 | 뷰마다 지원하는 Intrinsic content Size가 차이가 있다. 8 | 9 | | | **Intrinsic Contet Size Height** | **Intrinsic Contet Size Height** | 10 | | :------------------------------------------: | :------------------------------: | :------------------------------: | 11 | | **UIView** | X | X | 12 | | **UISlider** | O | X | 13 | | **UILabel, UIButton, UISwitch, UITextField** | O | O | 14 | | **TextView, ImageView** | Content에 따라 변화함 | | 15 | 16 | 17 | 18 | 19 | 20 | 참고 21 | 22 | https://babbab2.tistory.com/135 23 | 24 | https://velog.io/@wonhee010/Intrinsic-Content-Size 25 | 26 | https://developer.apple.com/documentation/uikit/uiview/1622600-intrinsiccontentsize 27 | 28 | https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/AnatomyofaConstraint.html#//apple_ref/doc/uid/TP40010853-CH9-SW21 -------------------------------------------------------------------------------- /nyokki/Autolayout/Left Constraint 와 Leading Constraint 의 차이점을 설명하시오..md: -------------------------------------------------------------------------------- 1 | Left는 사용자가 바로보는 뷰의 기준에서 왼쪽을 의미하고 2 | 3 | Leading은 뷰의 왼쪽이 아니라 글자가 시작하는 방향을 가리킨다. (아랍어를 사용하는 국가의 경우에는 Leading Constraints를 설정하면 오른쪽에 뷰가 생성된다.) 4 | 5 | 6 | 7 | Trailing과 Right도 동일한 개념이다. 8 | 9 | 10 | 11 | 참고 12 | 13 | https://milyo-codingstories.tistory.com/53 -------------------------------------------------------------------------------- /nyokki/Autolayout/README.md: -------------------------------------------------------------------------------- 1 | ## Autolayout 2 | - [x] 오토레이아웃을 코드로 작성하는 방법은 무엇인가? (3가지) 3 | - [x] hugging, resistance에 대해서 설명하시오. 4 | - [x] Intrinsic Size에 대해서 설명하시오. 5 | - [x] 스토리보드를 이용했을때의 장단점을 설명하시오. 6 | - [x] Safearea에 대해서 설명하시오. 7 | - [x] Left Constraint 와 Leading Constraint 의 차이점을 설명하시오. 8 | -------------------------------------------------------------------------------- /nyokki/Autolayout/Safearea에 대해서 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## Safe Area 2 | 3 | safe area 전에는 top/bottom layout guide가 존재했다. 4 | 5 | 하지만 아이폰의 변화(노치)에 따라 left/right의 마진이 필요했으며 이로 인해 Safe Area가 생겨났다. 6 | 7 | 8 | 9 | ViewController 생성시에 Default로 Safe Area가 설정되어 있다. 10 | 11 | 12 | 13 | SafeArea를 사용하지 않고 싶다면 Constraints의 기준을 Safe Area에서 Superview로 바꿔주면되고 14 | 15 | 아예 사용하고 싶지 않다면 Use Safe Area Layout Guides의 체크를 꺼주면 된다. 16 | 17 | 18 | 19 | 참고 20 | 21 | https://babbab2.tistory.com/134?category=932180 -------------------------------------------------------------------------------- /nyokki/Autolayout/hugging, resistance에 대해서 설명하시오..md: -------------------------------------------------------------------------------- 1 | 컨스트레인트 우선순위 2 | 3 | 1) Hugging priority 4 | 5 | 우선순위가 높으면 나의 크기 유지. 우선순위 낮으면 크기 늘어남 (늘어난다 = 당겨진다 = 커진다) 6 | 7 | 2) Compression Resistance priority 8 | 9 | 우선순위가 높으면 나의 크기 유지. 우선순위 낮으면 크기 작아짐 (밀린다 = 찌그러진다 = 작아진다) 10 | 11 | 두 개의 뷰가 존재한다고 가정했을 때, 12 | 13 | 만일 두 뷰 사이에서 공간이 남아서 어느 한 뷰가 당겨져야할 경우에 Hugging priority가 더 높은 쪽이 본인의 뷰를 보존하고(허깅하고, 안으로 끌어안기) 다른 뷰가 넓어진다. 14 | 15 | 또 다른 경우에, 두 뷰 사이에 공간이 없을 경우 Compression Resistance가 더 높은 쪽이 본인의 뷰를 보존하고(저항하고, 밖으로 밀어내고) 다른 뷰를 작게 만든다. 16 | 17 | 18 | 19 | 20 | 21 | 참고 22 | 23 | https://eunjin3786.tistory.com/43 -------------------------------------------------------------------------------- /nyokki/Autolayout/스토리보드를 이용했을때의 장단점을 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## Storyboard의 장단점 2 | 3 | ### 장점 4 | 5 | - **빠른 초기화** - 뷰를 만드는데 오래걸리지 않는다 6 | - **시각화** - 앱의 흐름을 한눈에 볼 수 있다 7 | - **낮은 진입장벽** 8 | 9 | ### 단점 10 | 11 | - **생산성** - 앱이 점점 커지고 스토리보드 로딩시간 길어진다 12 | - **가독성** - 스토리보드가 방대하면 읽기도 어려워지고 난잡해보일 수 있다 13 | - **협업 어려움** - 다수의 인원이 수정을 하게되면 **Merge Conflict 처리가 큰 어려움**으로 작용한다 14 | - **재사용성** - 스토리보드로 만든 뷰는 재사용하기가 어렵다 15 | 16 | 17 | 18 | 참고 19 | 20 | https://minjunkweon.github.io/why-should-we-dont-use-storyboard/ -------------------------------------------------------------------------------- /nyokki/Autolayout/오토레이아웃을 코드로 작성하는 방법은 무엇인가? (3가지).md: -------------------------------------------------------------------------------- 1 | ### Layout Anchors 2 | 3 | 앵커를 통해서 뷰를 배치하는 방법이다. 4 | 5 | `NSLayoutAnchor`는 제한요소를 만들기 위한 유틸리티 클래스로 사용하기 쉬운 인터페이스를 제공하여 다양한 제약 요소들을 생성할 수 있다. 6 | 7 | 이때 오토레이아웃과 오토리사이징레이아웃마스크가 충돌하지 않도록 false로 설정해야한다. 8 | 9 | 10 | 11 | ### NSLayoutConstraint Class 12 | 13 | `NSLayoutConstraint`를 사용하여 각 매개변수에 대한 값을 지정하여 하나씩 작성하여 사용한다. 14 | 15 | 추천하지 않는다. 16 | 17 | ### Visual Format Language 18 | 19 | 문자열을 이용해서 제약 요소값들을 생성하는 방식이다. 20 | 21 | + 비주얼 포맷을 사용하면 여러 제약 요소를 한번에 만들 수 있다. 22 | + 모든 필요한 제약요소가 다 만들어지는 것이 아닌 제한적인 제약요소들만 만들어진다. 23 | 24 | 예시 25 | 26 | ```swift 27 | let views = ["myView": myView] 28 | let formatString = "|-[myView]-|" 29 | let constraints = NSLayoutConstraint.constraintsWithVisualFormat(formatString, 30 | options: .AlignAllTop, 31 | metrics: nil, 32 | views: views) 33 | NSLayoutConstraint.activateConstraints(constraints) 34 | ``` 35 | 36 | 37 | 38 | 참고 39 | 40 | [Visual Format Language](https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html#//apple_ref/doc/uid/TP40010853-CH27-SW1) 41 | 42 | https://soooprmx.com/autolayout%EC%9D%84-%EC%BD%94%EB%93%9C%EB%A1%9C-%EC%A0%95%EC%9D%98%ED%95%98%EA%B8%B0-swift/ -------------------------------------------------------------------------------- /nyokki/Functional Programming/README.md: -------------------------------------------------------------------------------- 1 | ## Functional Programming 2 | - [ ] 함수형 프로그래밍이 무엇인지 설명하시오. 3 | - [ ] 고차 함수가 무엇인지 설명하시오. 4 | - [ ] Swift Standard Library의 map, filter, reduce, compactMap, flatMap에 대하여 설명하시오. 5 | -------------------------------------------------------------------------------- /nyokki/Functional Programming/Swift Standard Library의 map, filter, reduce, compactMap, flatMap에 대하여 설명하시오.md: -------------------------------------------------------------------------------- 1 | ## map 2 | 3 | Map 함수는 컨테이너 내부의 기존 데이터를 변형하여 새로운 컨테이너를 생성한다. 4 | 5 | 기존의 배열의 각 아이템을 새롭게 매핑해서 새로운 배열을 리턴하는 함수이다. 매핑하는 방식은 개발자가 원하는 로직을 클로저로 만든다. 6 | 7 | ```swift 8 | let numbers: [Int] = [0, 1, 2, 3, 4] 9 | var doubledNums; [Int] = numbers.map({(number: Int) -> Int in 10 | return number * 2}) 11 | ``` 12 | 13 | 14 | 15 | ## filter 16 | 17 | filter함수는 컨테이너 내부의 값을 걸러서 새로운 컨테이너로 추출한다. 18 | 19 | ```swift 20 | let numbers: [Int] = [0, 1, 2, 3, 4] 21 | var doubledNums; [Int] = numbers.filter({(number: Int) -> Bool in 22 | return number % 2 == 0 }) 23 | ``` 24 | 25 | 26 | 27 | ## reduce 28 | 29 | reduce함수는 컨테이너 내부의 콘텐츠를 하나로 통합합니다. 30 | 31 | ```swift 32 | let numbers: [Int] = [0, 1, 2, 3, 4] 33 | // 0은 초기값 34 | var doubledNums; [Int] = numbers.reduce(0, {(first: Int, second: Int) -> Int in 35 | return first + second }) 36 | var doubledNums; [Int] = numbers.reduce(0) { $0 + $1 } 37 | ``` 38 | 39 | 40 | 41 | ## flapMap 42 | 43 | 3가지 기능 44 | 45 | 1. nil이 아닌 결과들을 가지는 배열을 리턴 -> **compactMap 사용할 것** 46 | 2. 주어진 Sequence내의 요소들을 하나의 배열로써 리턴 47 | 3. 주어진 Optional이 nil이 아닌지 판단후 unwrapping하여 closure 파라미터로 전달. 48 | 49 | ```swift 50 | let optionalArray: [Int?] = [1, 2, 3, 4, nil] 51 | // Optinal Array : [Optional(1), Optional(2), Optional(3), Optional(4), nil] 52 | 53 | let flatMappedArray = optionalArray.flatMap { $0 } 54 | // flatMapped Array : [1, 2, 3, 4] 55 | 56 | 57 | 58 | let nestedArray = [[1, 2, 3], [4, 5, 6], [7, 8, 9]] 59 | let flatMappedNestedArray = nestedArray.flatMap { $0 } 60 | // flatMapped Nested Array : [1, 2, 3, 4, 5, 6, 7, 8, 9] 61 | 62 | let optional: Int? = 8 63 | let value = optional.flatMap { $0 > 0 ? $0 : -$0 } 64 | // value : Optional(8) 65 | ``` 66 | 67 | 68 | 69 | #### CompactMap 70 | 71 | ```swift 72 | let optionalArray: [Int?] = [1, 2, 3, 4, nil] 73 | // Optinal Array : [Optional(1), Optional(2), Optional(3), Optional(4), nil] 74 | 75 | /* 76 | * flatMap() vs compactMap() 77 | */ 78 | 79 | let flatMappedArray = optionalArray.flatMap { $0 } 80 | // flatMapped Array : [1, 2, 3, 4] 81 | 82 | let compactMappedArray = optionalArray.compactMap { $0 } 83 | // compactMapped Array : [1, 2, 3, 4] 84 | ``` 85 | 86 | flatmap의 첫번째 기능과 동일하다. 87 | 88 | 89 | 90 | map과 flatmap의 차이 91 | 92 | ```swift 93 | func map(_ transform: (Wrapped) throws -> U) rethrows -> U? 94 | func flatMap(_ transform: (Wrapped) throws -> U?) rethrows -> U? 95 | ``` 96 | 97 | Wrapped 과정에서 flatMap은 Optional안에 값이 있다면 추출해서 진행하고 map은 그렇지 않다. 98 | 99 | 이 차이점 때문에 flatMap은 Optional에서 Chaining이 가능하고 map은 불가능하다. 100 | 101 | 102 | 103 | ## forEach 104 | 105 | 106 | 107 | 108 | 109 | 참고 110 | 111 | https://yagom.github.io/swift_basic/contents/22_higher_order_function/ 112 | 113 | https://zeddios.tistory.com/448 114 | 115 | https://ontheswift.tistory.com/22 -------------------------------------------------------------------------------- /nyokki/Functional Programming/고차 함수가 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | ## 고차 함수란? 2 | 3 | 함수를 파라미터로 받거나 함수를 리턴하는 함수를 고차함수라고 한다. 4 | 5 | Swift에서는 Foundation 라이브러리에서 filter, map, reduce를 지원한다. 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 참고 14 | 15 | https://hyunndyblog.tistory.com/163 -------------------------------------------------------------------------------- /nyokki/Functional Programming/함수형 프로그래밍이 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | ## 함수형 프로그래밍이란? 2 | 3 | + 프로그램이 상태의 변화 없이 데이터 처리를 수학적 함수 계산으로 취급하고자 하는 프로그래밍 4 | + 값이나 상태의 변화보다는 함수 자체의 응용을 중요하게 여긴다. 5 | + 코드 이해와 실행 결과의 관점에서, 순수하게 함수에 전달된 인자 값만 결과에 영향을 주기 때문에 상태 값을 갖지 않고 순수하게 함수만으로 동작한다. 6 | + 어떤 상황에서 프로그램을 실행하더라도 일정하게 같은 결과를 도출할 수 있다. 7 | + 프로그램 동작 과정에서 상태가 변하지 않으면 함수 호출이 각각 상호 간섭 이 실행되므로 병렬처리를 할 때 부작용이 거의 없다는 장점이 있다. 8 | + 필요한 만큼 함수를 나누어 처리할 수 있도록 스케일업을 할 수 있기 때문에 대규모 병렬처리에 큰 강점을 가진다. 9 | 10 | 11 | 12 | 함수형 프로그래밍의 특징으로는 함수를 일급 객체로 다룬다는 점이다. 13 | 14 | 15 | 16 | ### 일급 객체의 조건 17 | 18 | + 전달인자로 전달할 수 있다. 19 | + 동적 프로퍼티 할당이 가능하다. 20 | + 변수나 데이터 구조 안에 담을 수 있다. 21 | + 반환 값으로 사용할 수 있다. 22 | + 할당할 때 사용된 이름과 관계없이 고유한 객체로 구별가능하다. 23 | 24 | 25 | 26 | ### 함수형 프로그래밍의 장점 27 | 28 | + 여러 가지 연산 처리 작업이 동시에 일어나는 프로그램을 짜기 쉽다. 29 | + 멀티코어 혹은 여러 연산 프로세서를 사용하는 시스템에서 효율적인 프로그램을 만들기 쉽다. 30 | + 상태변화에 따른 부작용에서 자유로워지므로 순수하게 기능 구현에 초점을 맞춰 설계가 가능하다. 31 | 32 | 33 | 34 | 참고 35 | 36 | https://borabong.tistory.com/5 37 | 38 | 추가 참고자료 39 | 40 | https://youtu.be/jVG5jvOzu9Y (함수형 프로그래밍이 뭔가요? - 얄팍한 코딩사전) 41 | 42 | https://youtu.be/HZkqMiwT-5A (함수형 프로그래밍이 뭐하는 건가요? - 곰튀김 님) 43 | 44 | https://youtu.be/cXi_CmZuBgg (Functional Reactive Programming 패러다임 - 곰튀김 님) 45 | -------------------------------------------------------------------------------- /nyokki/Swift/Anyobject에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | #### Any 2 | 3 | Any는 함수타입을 포함하여 모든 타입(기본 타입(String, Int, Double ...), 구조체, 열거형, 커스텀 클래스, g함수 타입, 옵셔널 타입)의 인스턴스를 나타낼 수 있습니다. 4 | 5 | ```swift 6 | var anyArr : [Any] = [1,"hi",true, 1.0] 7 | ``` 8 | 9 | 위와 같이 any로 타입을 지정하게 되면 여러 자료형을 한번에 넣을 수 있다. 10 | 11 | 정확하게는, 구조체로 구현된 값타입은 모두 들어올 수 있다. (구조체로 구현된 값타입만 들어올 수 있는 것이 아니라 class로 구현된 것도 들어 갈 수 있다. ) 12 | 13 | 14 | 15 | 단점은 저장된 타입의 메모리 구조를 알 수 없기 때문에 타입 메서드를 사용하거나 타입 속성을 사용하기 위해서는 항상 타입캐스팅(다운캐스팅)을 해서 사용해야 한다. 16 | 17 | #### AnyObject 18 | 19 | AnyObject는 클래스의 인스턴스만 담을 수 있는 타입이다. AnyObject는 모든 클래스가 암시적으로 준수하는 프로토콜이라고 정의되어 있다. 따라서 AnyObject는 모든 클래스 타입의 인스턴스를 나타낼 수 있습니다. 하지만 구조체나 열거형의 인스턴스 타입은 담을 수 없다. 20 | 21 | AnyObject 또한 인스턴스 메서드나 프로퍼티를 사용하기 위해서는 항상 타입 캐스팅(다운캐스팅)을 해주어야 한다. 22 | 23 | 24 | 25 | + 사용 예시 26 | 27 | ```swift 28 | for (index, item) in array.enumerated() { 29 | // (0, 5) 30 | // (1, "안녕") 31 | // (2, 3.5) 32 | // ... 33 | 34 | switch item { 35 | case is Int: // item is Int 36 | print("Index - \(index): 정수입니다.") 37 | case let num as Double: // let num = item as Double 38 | print("Index - \(index): 소수 \(num)입니다.") 39 | case is String: // item is String 40 | print("Index - \(index): 문자열입니다.") 41 | case let person as Person: // let person = item as Person 42 | print("Index - \(index): 사람입니다.") 43 | print("이름은 \(person.name)입니다.") 44 | print("나이는 \(person.age)입니다.") 45 | case is (String) -> String: // item is (String) -> String 46 | print("Index - \(index): 클로저 타입입니다.") 47 | default: 48 | print("Index - \(index): 그 이외의 타입입니다.") 49 | } 50 | } 51 | ``` 52 | 53 | 54 | 55 | Any 또는 AnyObject는 언제 선택해서 사용하는가? 56 | 57 | references를 작업하는 동안에는 AnyObjects를 사용하고 (*클래스의 인스턴스만 사용할 수 있기 때문에*) 58 | 59 | 값 타입을 작업할 때는 Any를 사용하는 것이 좋지만 사용을 피하는 것이 좋다. 60 | 61 | 62 | 63 | 참고 64 | 65 | https://medium.com/flawless-app-stories/any-anyobject-in-ios-803515bd95a6 66 | 67 | https://zeddios.tistory.com/213 68 | 69 | https://developer.apple.com/documentation/swift/anyobject 70 | 71 | -------------------------------------------------------------------------------- /nyokki/Swift/Codable에 대하여 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## Codable 2 | 3 | 자신을 변환하거나 외부표현으로 변환할 수 있는 타입 4 | 5 | 6 | 7 | JSON과 같은 외부 데이터를 우리가 만들 애플리케이션에서 사용하기 편하도록 객체에 맵핑하기 위해 사용한다. 8 | 9 | + Decodable: 자신을 외부표현에서 디코딩할 수 있는 타입(자신 <- 외부표현) 10 | + Encodable: 자신을 외부표현으로 인코딩할 수 있는 타입(자신 -> 외부표현) 11 | 12 | 13 | 14 | Codable은 프로토콜이며 class, struct, enum에 채택할 수 있다. 15 | 16 | 17 | 18 | 이때 Codable처리할 때, 스네이크표현법을 카멜표현법으로 바꾸거나 JSON에 있는 이름과 다른 이름을 사용하고 싶다면 CodingKey를 따로 정의 하면 된다. 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 참고 27 | 28 | https://adora-y.tistory.com/entry/iOS-Codable%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC 29 | 30 | https://zeddios.tistory.com/373 31 | 32 | https://shark-sea.kr/entry/Swift-Codable-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0 -------------------------------------------------------------------------------- /nyokki/Swift/Convenience init에 대해 설명하시오. .md: -------------------------------------------------------------------------------- 1 | # Initialization (초기화) 2 | 3 | ### 생성자란?(Initializer) 4 | 5 | 구조체, 클래스, 열거형에 대한 인스턴스를 생성할 때 **저장 속성**에 대한 초기값을 설정해야 한다. 6 | 7 | > Why? 8 | > 9 | > 초기값이 설정되어 있지 않으면 저장 속성을 저장하기 위한 고유의 데이터 저장 공간이 생기는데 이때 어떠한 값도 들어 있지 않다면 오류가 발생하기 때문이다. 10 | > 11 | > (열거형의 경우 메모리 공간이 필요한 저장 속성은 선언할 수 없다.) 12 | 13 | *Q) 그럼 계산 속성은 초기화를 안해줘도 되는가?* 14 | 15 | *A) YES* --> 계산 속성은 메서드로 취급 16 | 17 | 18 | 19 | 초기화 메서드는 함수이다. ```init()```이라는 메서드를 사용한다. 메서드는 func를 앞에 붙혀줘야 하는거 아닌가 싶지만 스위프트의 약속으로 ```init()```만 구현해주면 된다. 20 | 21 | #### ```init()```을 따로 하지 않아도 되는 경우 22 | 23 | 1. 구조체의 경우 --> ```init()``` + 멤버와이즈 이니셜라이저 제공 24 | 25 | 2. 클래스에서 모든 저장 속성의 초기화가 존재하는 경우 26 | 27 | ```swift 28 | // 저장 속성의 초기값이 있는 경우 init()을 구현하지 않아도 된다. (자동 생성) 29 | class Aclass { 30 | let a = 3 31 | let b = 4 32 | 33 | //init() { } ---> 생략 34 | } 35 | 36 | let a = Aclass() 37 | // 38 | class Aclass { 39 | let a : Int 40 | let b : Int 41 | var c : Int { 42 | return a + b 43 | } 44 | 45 | init(a: Int, b: Int) { 46 | self.a = a 47 | self.b = b 48 | } 49 | } 50 | 51 | let a = Aclass(a: 3, b: 4) 52 | print(a.c) // 7 53 | ``` 54 | 55 | 56 | 57 | # Designated init(지정 생성자) 58 | 59 | ```init()``` 형태를 가지는 생성자를 지정 생성자라고 한다. 60 | 61 | 지정 생성자는 모든 저장 속성을 초기화해야 한다. 모든 생성자는 오버로딩이 가능하다. 62 | 63 | > 오버로딩이란? 64 | > 65 | > 동일한 함수명을 가지고 편의와 목적을 위해 파라미터의 다양한 형태로 생성하는 것 66 | > 67 | > 단, 오버로딩의 경우에도 모든 저장 속성을 초기화해야 한다는 원칙은 변하지 않는다. 68 | 69 | image-20210902192032082 70 | 71 | # Convenience init (편의 생성자) 72 | 73 | 지정 생성자보다 적은 파라미터를 가지고 편리하게 생성하기 위한 생성자이다. 74 | 75 | **편의**라는 말이 붙은 것처럼 초기화를 편리하게 하기 위함이 목적이다. 모든 속성을 초기화할 필요가 없다. 76 | 77 | 지정 초기화 메서드를 오버로딩할 수 있으나 편의 생성자로 만드는 것이 개발자의 실수를 줄일 수 있는 방법이다. 78 | 79 | 80 | 81 | 다만, 편의 생성자는 지정생성자에게 의존하기 때문에 편의 생성자 내부에는 82 | 83 | 반드시 자기 단계의 지정생성자를 호출하는 코드가 존재해야 한다. 이때 지정생성자를 이미 호출하는 다른 편의 생성자를 호출해도 가능하다. 84 | 85 | 86 | 87 | 다른 목적은 상속을 할 경우에 서브클래스에서 override를 하지 못하는 목적이 있다.(원칙) 88 | 89 | ../_images/initializerDelegation01_2x.png 90 | 91 | ```swift 92 | class Bird { 93 | var name: String 94 | var age: Int 95 | 96 | init(name: String, age: Int) { 97 | self.name = name 98 | self.age = age 99 | } 100 | 101 | convenience init() { 102 | self.init(name: "새", age: 1) 103 | } 104 | } 105 | 106 | let aBird = Bird(name: "새", age: 1) 107 | let bBird = Bird() 108 | 109 | // 동일한 결과이다. 110 | ``` 111 | 112 | 113 | 114 | # 상속과 생성자 115 | 116 | ### 지정 생성자의 상속 117 | 118 | 생성자는 기본적으로 상속되지 않고 재정의가 원칙이다. 119 | 120 | ```swift 121 | class Vehicle { 122 | var numberOfWheels = 0 123 | var description: String { 124 | return "\(numberOfWheels) wheel(s)" 125 | } 126 | } 127 | 128 | let vehicle = Vehicle() 129 | print("Vehicle: \(vehicle.description)") 130 | // Vehicle: 0 wheel(s) 131 | 132 | class Bicycle: Vehicle { 133 | override init() { 134 | super.init() 135 | numberOfWheels = 2 136 | } 137 | } 138 | 139 | class Hoverboard: Vehicle { 140 | var color: String 141 | init(color: String) { 142 | self.color = color 143 | // super.init() implicitly called here 144 | } 145 | override var description: String { 146 | return "\(super.description) in a beautiful \(color)" 147 | } 148 | } 149 | 150 | let hoverboard = Hoverboard(color: "silver") 151 | print("Hoverboard: \(hoverboard.description)") 152 | // Hoverboard: 0 wheel(s) in a beautiful silver 153 | 154 | ``` 155 | 156 | ### 편의 생성자의 상속 157 | 158 | 편의 생성자는 재정의가 불가한 것이 원칙이다. 159 | 160 | 161 | 162 | 참고 163 | 164 | https://zeddios.tistory.com/141 165 | 166 | https://docs.swift.org/swift-book/LanguageGuide/Initialization.html 167 | 168 | -------------------------------------------------------------------------------- /nyokki/Swift/Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오..md: -------------------------------------------------------------------------------- 1 | 델리게이트의 사전적 정의는 위임(자)이며 2 | 3 | Protocol을 이용해서 권한을 위임하고 일을 처리하는 방식의 디자인 패턴이다. 4 | 5 | 6 | 7 | 가장 대표적으로는 테이블뷰, 테이블뷰 데이터소스의 델리게이트를 활용하는 것이 대표적이다. 8 | 9 | 10 | 11 | ```swift 12 | struct Cookie { 13 | var size : Int = 5 14 | var hasAChocolateChips : Bool = true 15 | } 16 | 17 | class Bakery { 18 | var delegate : BakeryDelegate? 19 | 20 | func makeCookie() { 21 | var cookie = Cookie() 22 | cookie.size = 10 23 | cookie.hasAChocolateChips = false 24 | 25 | delegate?.cookieWasBaked(cookie) 26 | } 27 | } 28 | 29 | protocol BakeryDelegate { 30 | func cookieWasBaked(_ cookie : Cookie) 31 | } 32 | 33 | class BakeryShop : BakeryDelegate { 34 | func cookieWasBaked(_ cookie: Cookie) { 35 | print("쿠키가 나왔습니다. 쿠키의 크기는 \(cookie.size)입니다.") 36 | } 37 | } 38 | 39 | let shop = BakeryShop() 40 | let bakery = Bakery() 41 | 42 | bakery.delegate = shop 43 | 44 | bakery.makeCookie() 45 | 46 | ``` 47 | 48 | -------------------------------------------------------------------------------- /nyokki/Swift/Delegates와 Notification 방식의 차이점에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | 델리게이트는 지정된 객체가 해야하는 메소드들의 원형을 프로토콜 형태로 정해놓은 디자인 패턴으로 2 | 3 | 커뮤니케이션 과정에서 제 3의 객체가 필요없고 로직의 흐름이 따라가기 쉽다는 장점이 있는데 코드가 길어지고 많은 객체들에게 이벤트를 알려주는 것이 비효율 적이라는 단점이 있다. 4 | 5 | 6 | 7 | 노티피케이션은 노티피케이션 센터라는 싱글턴 객체를 통해 이벤트의 발생을 옵저버를 등록한 객체들에게 post하는 방식으로 사용되는데 8 | 9 | 다수의 객체들에게 동시에 이벤트 발생을 알려줄 수 있다는 장점이 있으나 10 | 11 | key값으로 노티피케이션의 이름과 유저인포를 서로 맞추기 때문에 컴파일시 구독이 잘 되고 있는지에 대해 확인하기 어려워 추적하기 쉽지 않을 수 있다. 12 | 13 | Post이후에는 정보를 받을 수 없다. 14 | 15 | 16 | 17 | 델리게이트 패턴은 코드가 읽기 쉽고 추적이 쉬워 많은 부분에서 사용하기 편할 것이라 생각이 들지만 18 | 19 | 로그인 상태 변화와 같은 동시 다발적으로 뷰 객체들에게 이벤트를 알려줘야하는 경우에는 notification이 더 용이하다고 생각한다. 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 참고 28 | 29 | https://prod.velog.io/@hayeon/Delegates%EC%99%80-Notification-%EB%B0%A9%EC%8B%9D%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%97%90-%EB%8C%80%ED%95%B4-%EC%84%A4%EB%AA%85%ED%95%98%EC%8B%9C%EC%98%A4 -------------------------------------------------------------------------------- /nyokki/Swift/Extension에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | # Extension 2 | 3 | 익스텐션을 이용해 클래스, 구조체, 열거형, 프로토콜 타입에 기능(메서드)을 추가할 수 있다. 4 | 5 | 익스텐션으로 다음을 할 수 있다. 6 | 7 | + 인스턴스 연산 프로퍼티와 타입 연산 프로퍼티의 추가(저장 프로퍼티는 불가능) 8 | 9 | + 인스턴스 메소드와 타입 메소드 추가 10 | 11 | + 새로운 이니셜라이저 제공 12 | 13 | + 클래스의 경우에는 **편의 생성자만 추가 가능**, 지정 생성자와 소멸자는 반드시 베이스 클래스에 구현 14 | + 값타입의 경우 예외적으로 **저장속성에 기본값/생성자를 정의를 하지 않은 경우에만** extension에 생성자를 구현할 수 있다. 기본적으로 생성자는 본체에 생성해야 한다. 15 | 16 | + 서브스크립트 정의 17 | 18 | + [중첩 타입](https://jusung.gitbook.io/the-swift-language-guide/language-guide/19-nested-types)의 선언과 사용 19 | 20 | + 중첩 타입이란? 21 | 22 | 예) 클래스 내부에 클래스, 클래스 내부에 구조체, 구조체 내부에 클래스, 클래스 내부에 열거형 등등의 구현하는 것 23 | 24 | + 특정 프로토콜을 따르는 타입 만들기 25 | 26 | 27 | 28 | ### 언제 사용할까? 29 | 30 | String, Int와 같은 기본 타입의 경우 구조체이고 내부에 접근할 수 없기 때문에 확장을 사용하여 기본 타입에 필요한 기능들을 추가하여 사용할 수 있다. (소급 모델링 - retroactive modeling) 31 | 32 | 33 | 34 | #### 주의할 점⭐️ 35 | 36 | 익스텐션에 구현한 메서드를 상속하여 override하는 것은 불가능하다. (but, 익스텐션에 추가한 메서드에 @objc 키워드를 붙이면 가능은 하다. --> Objective-C방식의 구현) 37 | 38 | 39 | 40 | 참고 41 | 42 | https://jusung.gitbook.io/the-swift-language-guide/language-guide/20-extensions 43 | 44 | 45 | 46 | -------------------------------------------------------------------------------- /nyokki/Swift/Generic에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## Generic 2 | 3 | ### 사용하는 이유 4 | 5 | Generic 코드를 사용하면 사용자가 정의한 요구사항에 따라 모든 타입에서 작동할 수 있는 유연하고 재사용 가능한 함수와 타입을 작성할 수 있다. 6 | 7 | 중복 코드를 피하고 더 명확하고 추상적인 방법으로 표현할 수 있다. 8 | 9 | 스위프트에서 Array, Set, Dictionary에서 들어가는 타입이 제네릭 타입으로 이미 사용하고 있다. 10 | 11 | 12 | 13 | ### 사용하는 방법 14 | 15 | 사용하는 방법은 생성하는 구조체, 클래스, 열거형, 함수 등에서 제네릭 타입을 사용하고 싶다면 생성하고 싶은 클래스(예를 들어)명 뒤에 앵글브라켓 안에 플레이스홀더 형태로 어떤 것이든 입력하면 된다. 관습적으로는 T를 많이 사용한다. 16 | 17 | 파라미터는 여러 개가 들어갈 수 있으며 콤마 뒤에 넣으면 되는데 제네릭 타입을 썼다고 해서 Int, String과 같은 타입을 못쓰는 것이 아니고 같이 사용할 수 있다. 18 | 19 | 20 | 21 | ### 타입제약 22 | 23 | 스위프트에서 Array, Set, Dictionary의 타입은 hashable해야 한다. 이렇게 제네릭 타입이지만 제네릭 타입에 제약을 걸 수 있는데, where 절을 사용하여 제약을 할 수 있다. 24 | 25 | 타입 제약은 제네릭 타입이 특정 타입에 한정되거나 특정 프로토콜을 따르는 타입만 사용할 수 있도록 제약을 해야하는 상황에서 사용한다. 26 | 27 | 타입제약(where 절의 조건으로 사용하는 제약)은 클래스 타입 또는 프로토콜로만 가능하다. (구조체, 열거형 등의 타입은 타입제약이 불가능하다.) 28 | 29 | 30 | 31 | 참고 32 | 33 | https://zeddios.tistory.com/226 34 | 35 | https://the-brain-of-sic2.tistory.com/11 -------------------------------------------------------------------------------- /nyokki/Swift/Hashable이 무엇이고, Equatable을 왜 상속해야 하는지 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### 사전지식 2 | 3 | Hash란? 4 | 5 | 해시 함수는 임의이 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수이다. 해시 함수에 의해 얻어지는 값은 해시 값, 해시 코드, 해시 체크섬 또는 간단하게 해시라고 한다. 그 용도 중 하나는 해시 테이블이라는 자료구조에 사용되며, **매우 빠른 데이터 검색을 위한 컴퓨터 소프트웨어에 널리 사용된다.** 해시 함수는 큰 파일에서 중복되는 레코드를 찾을 수 있기 때문에 데이터베이스 검색이나 테이블 검색의 속도를 가속할 수 있다. 6 | 7 | 8 | 9 | ### Hashable Protocol 10 | 11 | 정의: 정수 해시 값을 생성하는 Hasher에 의해 해시 값을 hash할 수 있는 타입 12 | 13 | 즉 이 프로토콜을 채택한 타입은 유일한 값(해시값)으로 구분될 수 있다는 것이다. 14 | 15 | ```swift 16 | protocol Hashable: Equatable { 17 | var hashValue: Int { get } 18 | func hash(into hasher: inout Hasher) 19 | } 20 | ``` 21 | 22 | 23 | 24 | **Hashable**은 **Equatable protocol**을 상속받고 있다. 25 | 26 | ```swift 27 | protocol Equatable { 28 | static func == (lhs: Self, rhs: Self) -> Bool 29 | } 30 | ``` 31 | 32 | 33 | 34 | 해시 값은 고유값이어야 하기 때문에 고유값인지 식별해줄 수있는 **==** 함수가 필요하다. 일반적으로 Int, String, Double 등 Apple에서 제공하는 다양한 기본 연산자들은 Hashable 타입을 이미 상속받고 있기 때문에 자연스럽게 ==연산자를 사용할 수 있었던 것이다. 35 | 36 | 37 | 38 | - set 또는 dictionary의 key로 hashable을 준수하는 모든 타입을 사용할 수 있다. 39 | 40 | - swift에서 dictionary는 Dictionary 형태로 쓰인다. 41 | 42 | - 이때 유일한 제약사항은 Key Type이 반드시 해시가능한 타입이어야 한다(Hashable) 43 | 44 | 딕셔너리의 키는 중복이 되지 않는다. Set 역시 중복된 값을 담을 수 없다. 45 | 46 | - 즉, **그 자체로 유일하게 표현이 가능한 방법을 제공해야한다는 뜻** 이다. 47 | 48 | - swift의 기본타입(String, Int, Double…)은 기본적으로 해시가능한 것들로 dictionary의 key type으로 사용가능하다. 49 | 50 | - 또한 swift의 enum(열거형) 또한 해시 가능하다. 51 | 52 | 53 | 54 | 사용할 때 ? 55 | 56 | 개발하다 보면 커스텀으로 자료형을 구현하게 된다. 이때 struct이나 enum을 선언할 때 이 자료형들을 딕셔너리의 키나 set의 원소로 사용하기 위해서는 struct의 모든 프로퍼티와 enum의 연관값들은 모두 hashable해야한다. 57 | 58 | 59 | 60 | ### Equatable 61 | 62 | Equatable은 값의 비교가 가능함을 보장해주는 프로토콜이다. 이 프로토콜을 채택한 타입들은 ==연산자나 !=연산자를 사용해 값을 비교할 수 있다. Array에서 contain(_:)메소드를 사용할 수 있는 것도 Array가 Equatable 프로토콜을 채택하고 있기 때문이다. 63 | 64 | 65 | 66 | #### Hashable이 Equatable를 상속해야하는 이유? 67 | 68 | Hashable은 해시값을 가질 수 있다는 것으로 해시값만 존재하는 것이다. 69 | 70 | 이때 두 값, 인스턴스를 비교하기 위해서는 Equatable 상속이 필요하다. 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 참고 93 | 94 | https://zeddios.tistory.com/498 95 | 96 | https://www.zehye.kr/swift/2020/07/22/swift_hashable/ 97 | 98 | -------------------------------------------------------------------------------- /nyokki/Swift/KVO 동작 방식에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### KVO(Key-Value Observing) 2 | 3 | ##### 특정 키의 값의 변화를 감지하기 위한 기능 4 | 5 | 모델 객체의 어떤 값이 변경되었을 경우 이를 UI에 반영하기 위해서 컨트롤러는 모델 객체에 observing을 도입하여 델리게이트에 특정 메시지를 보내 처리할 수 있도록 하는 것 6 | 7 | 8 | 9 | 즉, 변수에 코드를 붙여 변수가 변경될 때마다 코드가 실행되도락 하는 방법을 의미한다. Didset, willset과 유사한데 KVO는 타입 정의 바깥에서 observe를 추가한다는 점이 다르다. KVO는 스위프트 코드로는 그리 좋지않다. 그 이유는 Object-c런타임에 의존하고 있기 때문이다. 그래서 NSObject를 상속받기 위해 @objc를 반드시 붙여줘야 한다. 10 | 11 | 12 | 13 | Example 14 | 15 | ```swift 16 | class SomeClass: NSObject { 17 | @objc dynamic var value: String = "" 18 | } 19 | 20 | let someObject = SomeClass() 21 | 22 | someObject.observe(\.value) { (object, change) in 23 | print("SomeClass object value changed to \(object.value)") 24 | } 25 | 26 | someObject.value = "test" // TEST 27 | ``` 28 | 29 | 30 | 31 | 참고 32 | 33 | https://www.zehye.kr/ios/2020/03/19/11iOS_KVO/ 34 | 35 | https://velog.io/@delmasong/KVOKey-Value-Observing -------------------------------------------------------------------------------- /nyokki/Swift/MVC 구조에 대해 블록 그림을 그리고, 각 역할과 흐름을 설명하시오..md: -------------------------------------------------------------------------------- 1 | MVC 패턴은 디자인 패턴 중 하나이다. 2 | 3 | 4 | 5 | Model, View, Controller이다. 6 | 7 | 8 | 9 | 애플에서 제안하는 CocoaMVC는 다음과 같다. 10 | 11 | ![img](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Ffb216aab-dc8d-4c1f-8e20-f00646162986%2F_2020-12-19__4.28.27.png?table=block&id=271845ca-c3c1-4d32-86d4-8a6c3c909103&spaceId=db563daf-5411-44cb-bd70-ae019abb9ad4&width=2510&userId=05b4c7b1-db96-4d31-9334-fe128d7f702a&cache=v2) 12 | 13 | Model 14 | 15 | + 애플리케이션에서 사용할 데이터들을 관리 16 | 17 | View 18 | 19 | + UI를 표현 및 관리 20 | 21 | Controller 22 | 23 | + View와 Model의 다리역할 24 | + View에서 들어오는 입력을 Model이 반영하고 Model의 변화를 View에 갱신함 25 | 26 | 27 | 28 | 하지만 ViewController가 강하게 연결되어 있어 View Controller가 거의 모든 일을 수행함 29 | 30 | View와 Model이 직접적으로 연관되어 있다. 따라서 오류가 생겨났을 경우 디버그가 쉽지 않고, 재사용성이 떨어진다. 31 | 32 | 33 | 34 | 참고 35 | 36 | https://www.notion.so/MVC-e1b9d0bf28984f77940abe22e283c375 37 | 38 | -------------------------------------------------------------------------------- /nyokki/Swift/Optional 이란 무엇인지 설명하시오..md: -------------------------------------------------------------------------------- 1 | # Optional이란? 2 | 3 | 옵셔널은 타입 뒤에 ?를 붙이면 해당 변수는 Optional 변수가 되는데 4 | 5 | Optional은 enum이다. 값이 존재한다면 case .some() 으로, 6 | 7 | 값이 없다면 case .none 으로 되는데 8 | 9 | nil은 실제 값이 없는 것이 아니고 "값이 없음을 의미한다."라고 한 단계 쌓여있는 상태이다. 10 | 11 | 다시 말해 nil은 **값이 없음을 표현하는 키워드**이다. 12 | 13 | 14 | 15 | ## 사용하는 이유는? 16 | 17 | 메모리 공간이 형성이 됐는데 만약 값이 없다면 에러가 발생한다. 이를 방지하기 위해서 옵셔널 타입을 사용하는 것인데 에러가 나지 않도록 임시적인 타입을 담아두는 개념이다. 따라서 String과 String?는 다른 타입이다. 18 | 19 | 옵셔널 값을 사용하기 위해서는 한번 Unwrapping 과정을 거쳐야 한다. 20 | 21 | 22 | 23 | ### Wrapping 24 | 25 | 옵셔널 변수들은 현재의 값이 존재하는 것인지 nil인 것인지 wrap 되어 있어서 모른다. 그렇기 때문에 wrap된 상태에서는 value값이 있는지 없는지 관계없이 value가 바로 출력되지 않고 Optional("hello")와 같이 출력된다. 26 | 27 | 28 | 29 | ### Unwrapping 30 | 31 | 1. Forced Unwrapping 32 | 33 | 바로 value의 값을 출력하기 위해서는 변수 뒤에 !를 붙이면 value값이 바로 나온다. 다만 값이 있다고 확신하는 경우에만 사용하는 것이 좋다. 그렇지 않으면 런타입 에러가 발생한다. 34 | 35 | 2. ```if something != nil { print(something!) } ``` 사용 36 | 37 | If 문을 사용해서 nil이 아님을 확인 후에 강제 추출 38 | 39 | 3. Optional Binding 40 | 41 | 옵셔널 바인딩을 사용하면 느낌표 없이 Optional 타입의 변수 값을 출력할 수 있어서 더 안전한 형태로 값을 얻을 수 있다. 42 | 43 | + if let, guard let 44 | 45 | ```swift 46 | if let 변수명 = Optional 변수 { 47 | // 임시 변수에 Optional 변수의 value값이 할당된다면 스코프의 코드를 실행한다. 48 | } 49 | ``` 50 | 51 | 4. Nil-Coalescing(닐 코얼레싱) 52 | 53 | 옵셔널 표현식 뒤에 기본값을 제시하여 옵셔널의 가능성을 없애는 방식이다. 54 | 55 | ```something ?? "내 이름"``` 56 | 57 | 58 | 59 | #### as, as? as! 60 | 61 | + 타입 캐스팅 - 해당 타입인지 확인하는 것이 타입캐스팅 62 | 63 | 업 캐스팅 : as 64 | 65 | 다운캐스팅 : as?, as! 66 | 67 | ​ as? - 뒤 타입이 맞는지 확인하고 맞으면 바인딩 틀리면 nil 68 | ​ as! - 강제로 타입변환 시도, 변환이 안맞으면 크래쉬 발생 69 | 70 | #### try!, try? 71 | 72 | + try? 73 | 에러가 발생할 수 있다. 핸들링 해라 74 | 트라이 해봐서 괜찮으면 바인딩하고 안되면 nil 75 | + try! 76 | 강제로 트라이해라 77 | 78 | try의 원래 목적은 에러가 발생할 때 핸들링해주는 것을 기회로 주겠다는 의미이고 정식으로 사용하기 위해서는 try는 무조건 do-catch 문법에 사용되며 오류 체크를 하기위함이다. 79 | 80 | 81 | 82 | ## Optional Chaining 83 | 84 | 옵셔널 타입으로 선언된 값에 접근하여, 프로퍼티, 메서드를 사용할 때, 접근연산자(.) 앞에 물음표(?)를 붙여야 한다. 85 | 86 | 해당 값이 옵셔널의 가능성을 내포한다는 의미이고 87 | 88 | 결과는 항상 옵셔널 타입으로 리턴이 된다. 89 | 90 | 옵셔널 체이닝 과정 중에 하나라도 nil을 return 한다면 이어지는 표현식은 평가하지 않고 nil을 return한다. 91 | 92 | 93 | 94 | ```instance?.method?()?.value``` 95 | 96 | --> instance가 옵셔널이다. method가 없을 수 있으며 함수의 retrun값이 없을 수 있다. 97 | 98 | 99 | 100 | ```dictionay?["something"]?.value``` 101 | 102 | --> 딕셔너리가 없을 수 있으며, 딕셔너리 결과값이 없을 수 있다. 103 | 104 | 105 | 106 | ```instance?.method()``` 107 | 108 | --> 인스턴스가 옵셔널이면 메서드가 실행이 될까? 109 | 110 | case 1. 리턴값이 없는 함수의 경우 111 | 112 | + 인스턴스가 nil이 아니면 --> 메서드 실행 113 | + 인스턴스가 nil이면 --> nil 반환 114 | 115 | case 2. 리턴값이 있는 함수 116 | 117 | + 인스턴스가 nil이 아니면 --> 옵셔널 타입으로 반환됨 118 | + 인스턴스가 nil이면 --> nil 반환 119 | 120 | 참고 121 | 122 | https://velog.io/@sossont/iOS-%EC%96%B4%ED%94%8C-%EB%A7%8C%EB%93%A4%EA%B8%B0-Swift-Optional 123 | 124 | http://monibu1548.github.io/2018/05/12/swift-optional/ 125 | 126 | 127 | 128 | -------------------------------------------------------------------------------- /nyokki/Swift/README.md: -------------------------------------------------------------------------------- 1 | ## Swift 2 | - [x] struct와 class와 enum의 차이를 설명하시오. 3 | - [x] class의 성능을 향상 시킬수 있는 방법들을 나열해보시오. 4 | - [x] Convenience init에 대해 설명하시오. 5 | - [x] Anyobject에 대해 설명하시오. 6 | - [x] Optional 이란 무엇인지 설명하시오. 7 | - [x] Struct 가 무엇이고 어떻게 사용하는지 설명하시오. 8 | - [x] Subscripts에 대해 설명하시오. 9 | - [x] instance 메서드와 class 메서드의 차이점을 설명하시오. 10 | - [x] Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오. 11 | - [x] Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오. 12 | - [x] KVO 동작 방식에 대해 설명하시오. 13 | - [x] Delegates와 Notification 방식의 차이점에 대해 설명하시오. 14 | - [x] 멀티 쓰레드로 동작하는 앱을 작성하고 싶을 때 고려할 수 있는 방식들을 설명하시오. 15 | - [x] MVC 구조에 대해 블록 그림을 그리고, 각 역할과 흐름을 설명하시오. 16 | - [x] 프로토콜이란 무엇인지 설명하시오. 17 | - [x] Hashable이 무엇이고, Equatable을 왜 상속해야 하는지 설명하시오. 18 | - [x] mutating 키워드에 대해 설명하시오. 19 | - [x] 탈출 클로저에 대하여 설명하시오. 20 | - [x] Extension에 대해 설명하시오. 21 | - [x] 접근 제어자의 종류엔 어떤게 있는지 설명하시오 22 | - [x] defer란 무엇인지 설명하시오. 23 | - [x] defer가 호출되는 순서는 어떻게 되고, defer가 호출되지 않는 경우를 설명하시오. 24 | - [x] property wrapper에 대해서 설명하시오. 25 | - [x] Generic에 대해 설명하시오. 26 | - [x] Result타입에 대해 설명하시오. 27 | - [x] Codable에 대하여 설명하시오. 28 | -------------------------------------------------------------------------------- /nyokki/Swift/Result타입에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## Result 2 | 3 | Result타입은 스위프트 표준 라이브러리에 도입되어 있다. Result 타입은 비동기 API와 같은 복잡한 코드에서 에러를 보다 간단하고 명확하게 처리할 수 있게 도와준다. 4 | 5 | Result 타입은 success와 failure 두 가지 case가 존재하는 enum이다. 둘 다 제네릭을 사용하여 구현되므로 개발자가 정한 타입의 연관값을 가질 수 있다. 다만 failure의 연관값은 swift의 error 타입을 채택한 타입이어야 한다. 6 | 7 | 8 | 9 | 이때 에러를 throw하고 싶다면 Result타입에서 제공하는 get()메서드가 있다. 이 메서드는 성공한 값이 있으면 반환하고 그렇지 않으면 error를 throw하는 메서드이다. 10 | 11 | 12 | 13 | 참고 14 | 15 | https://tech.burt.pe.kr/swift/what-new/swift-5.0/result-type 16 | 17 | https://hryang.tistory.com/21 -------------------------------------------------------------------------------- /nyokki/Swift/Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### 싱글턴패턴 2 | 3 | 특정 용도로 객체를 하나만 생성하여 공용으로 사용하고 싶을 때 사용하는 디자인 패턴 4 | 5 | #### 사용하는 이유 6 | 7 | + 데이터 공유 (여러 객체에서 공용으로 객체를 사용할 때 ) 8 | 9 | + 메모리 절약 10 | 11 | #### Example 12 | 13 | ```swift 14 | class UserInfo { 15 | static let shared = LoginInfo() 16 | 17 | var id: String? 18 | var password: String? 19 | var name: String? 20 | 21 | private init() { } 22 | } 23 | ``` 24 | 25 | 앱 내에서 반복적으로 사용되는 유저 데이터를 저장 26 | 27 | 매번 인스턴스를 만들거나 매개변수를 통해서 참조할 필요 없이 UserInfo.shared와 같이 접근 28 | 29 | 새로운 인스턴스가 생성되는 것을 막기 위해 private init()사용 30 | 31 | 32 | 33 | 사용자 기본 설정과 같은 단일 데이터 저장소를 사용하거나 34 | 35 | 앱이 실행하는 동안 앱을 제어하는 객체로 사용될 때, 36 | 37 | 알림을 통해(Notification) 다른 객체 간에 정보 전달을 할 때 사용된다. -------------------------------------------------------------------------------- /nyokki/Swift/Struct 가 무엇이고 어떻게 사용하는지 설명하시오..md: -------------------------------------------------------------------------------- 1 | # 구조체(Struct) 2 | 3 | 하나 이상의 변수를 묶어서 새로운 자료형을 정의하는 도구이다. 4 | 5 | 구조체는 값타입이며 스택 메모리에 저장된다. 스택에 저장되기 때문에 메모리 관리를 하지 않아도 된다. 6 | 7 | 8 | 9 | 구조체는 초기화 메소드를 직접 만들지 않아도 기본으로 멤버와이즈 이니셜라이저라는 이름으로 생성되며 10 | 11 | 소멸자는 존재하지 않는다. 12 | 13 | 14 | 15 | 사용하기 위해서는 내부에 프로퍼티와 메소드를 구현할 수 있으며 16 | 17 | 내부 프로퍼티를 변경하는 함수를 사용하기 위해서는 앞에 mutating 키워드를 붙여주면 된다. 18 | 19 | 20 | 21 | ## 사용하는 경우 22 | 23 | + 연관된 간단한 값의 집합을 캡슐화하는 것만이 목적인 경우 24 | 25 | + 캡슐화한 값을 참조하는 것보다 복사하는 것이 적합한 경우 26 | 27 | + 구조체에 저장된 프로퍼티가 값 타입이며 참조하는 것보다 복사하는 것이 적합한 경우 28 | 29 | + 다른 타입으로부터 상속받거나 자신을 상속할 필요가 없는 경우 30 | 31 | -------------------------------------------------------------------------------- /nyokki/Swift/Subscripts에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### 서브스크립트 2 | 3 | 1. 서브스크립트는 class, struct, enum에서 콜렉션 등의 멤버 요소에 쉽게 접근하기 위한 방법이다. 4 | 2. 서브스크립트는 메서드이다. 5 | 6 | 7 | 8 | 인스턴스의 이름 뒤에 대괄호로 감싼 index 값을 써줌으로써 인스턴스 내부 컬렉션 멤버의 특정 값에 접근할 수 있다. 9 | 10 | + 서브스크립트를 사용하지 않을 경우 접근 11 | 12 | ```swift 13 | class ExampleClass { 14 | var Array = [1, 2, 3, 4, 5] 15 | } 16 | 17 | let ex = ExampleClass() 18 | ex.Array[1] 19 | ``` 20 | 21 | + 서브스크립트를 사용할 경우 접근 22 | 23 | ```swift 24 | class SubscriptClass { 25 | var Array = [1, 2, 3, 4, 5] 26 | 27 | subscript (index: Int) -> Int { 28 | get { 29 | return Array[index] 30 | } 31 | set { 32 | Array[index] = newValue 33 | } 34 | } 35 | } 36 | 37 | let sc = SubscriptClass() 38 | sc[1] 39 | ``` 40 | 41 | 42 | 43 | 서브스크립트의 get블록은 필수 구현 사항이다. get만 구현하면 read-only 계산 속성이 된다. 44 | 45 | set블록은 선택사항이고 기본 파라미터 newValue가 제공된다. 46 | 47 | 48 | 49 | 만일 타입 서브스크립트로 구현하고 싶은 경우에는 메서드 앞에 static 또는 class(only class의 경우, 상속시 재정의 가능) 키워드를 붙여주면 된다. 50 | 51 | 52 | 53 | 54 | 55 | 참고 56 | 57 | https://icksw.tistory.com/21 58 | 59 | -------------------------------------------------------------------------------- /nyokki/Swift/class의 성능을 향상 시킬수 있는 방법들을 나열해보시오. .md: -------------------------------------------------------------------------------- 1 | 참고 2 | 3 | https://icksw.tistory.com/256 4 | 5 | https://hiddenviewer.tistory.com/253 6 | 7 | https://corykim0829.github.io/swift/Understanding-Swift-Performance/# 8 | 9 | 10 | 11 | 다이나믹 디스패치 12 | 13 | 간접 호출/접근 횟수마다 일정량의 런타임 오버헤드 비용을 증가시킨다. 14 | 15 | 16 | 17 | override가 필요없는 속성 선언에는 final키워드를 사용하며 이렇게 하면 컴파일러가 디스패치의 간접호출/접건을 생략할 수 있다. 18 | 19 | 20 | 21 | Private 키워드는 현재 파일에서만 선언이 노출되도록 제한을 하는데 이는 컴파일러가 간접 호출들을 제거한다. 22 | 23 | -------------------------------------------------------------------------------- /nyokki/Swift/defer가 호출되는 순서는 어떻게 되고, defer가 호출되지 않는 경우를 설명하시오.md: -------------------------------------------------------------------------------- 1 | ## defer 호출 순서 2 | 3 | defer문을 만나면 순차적으로 스택에 저장되고 스코프 종료 후 하나씩 pop해서 실행하기에 마지막 defer문이 가장 먼저 실행된다. defer문을 만나기 전에 종료되면 스택에 저장 될 수 없음으로 당연하게도 스코프 종료 후에도 defer문은 실행 되지 않는다 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 참고 12 | 13 | https://www.notion.so/defer-51013342c2b44b329995bc4841989cba 14 | 15 | https://www.notion.so/defer-defer-94b30eecec244821bb360a9e5cb501e3 -------------------------------------------------------------------------------- /nyokki/Swift/defer란 무엇인지 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## defer란? 2 | 3 | 자신이 속해있는 코드블럭의 scope를 빠져나가기 직전에 실행되는 구문이다. 4 | 5 | 이때 scope를 빠져나가는 것은 정상 종료 뿐 아니라 에러를 만나 비정상 종료도 포함한다. 어떤 종료를 하던지 스코프를 빠져나가기 직전에 defer문 내부의 코드를 실행하고 종료한다. 6 | 7 | 8 | 9 | 참고 10 | 11 | https://jusung.gitbook.io/the-swift-language-guide/language-guide/25-access-control 12 | 13 | https://github.com/Sueaty/iOS-Interview-KR/blob/main/Swift/Defer.md -------------------------------------------------------------------------------- /nyokki/Swift/instance 메서드와 class 메서드의 차이점을 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### 인스턴스 메소드 2 | 3 | 클래스 , 구조체, 열거형 등에서 각각의 인스턴스가 특정 작업을 실행하는 기능을 캡슐화하기 위해 인스턴스 메소드를 사용한다. 4 | 5 | 메서드이기 때문에 인스턴스에 메모리 공간이 할당되어 있지 않다. 6 | 7 | 메서드 접근 시에서는 인스턴스 이름으로 접근해야 한다. ```instance.Method()``` 8 | 9 | 10 | 11 | 메서드를 실행하면 스택에 스택프레임을 만들고 인스턴스의 데이터를 사용해서 12 | 13 | 해당 메서드의 코드가 있는 주소로 가서 코드를 실행한다. 14 | 15 | 함수와 문법이 동일하나 특정 타입 내부에 구현하므로 반드시 인스턴스가 생성되어야만 메소드 사용 가능하다. 16 | 17 | 18 | 19 | ### 타입 메소드 20 | 21 | 사용하는 이유? 해당 타입에 해당하는 보편적인 경우 22 | 23 | ```swift 24 | Int.random(in: 0...200) 25 | ``` 26 | 27 | 메서드 접근 시에는 타입 이름으로 접근해야 한다. ```Type.Method()``` 28 | 29 | 30 | 31 | 클래스를 위한 타입 메소드는 func 앞에 static 혹은 class 키워드를 작성하여 사용하고, 구조체와 열거형을 위한 타입 메소드는 앞에 static 키워드를 작성한다. 32 | 33 | > static과 class의 차이 34 | > 35 | > + static은 상속시 재정의가 불가능 36 | > + class는 상속시 재정의가 가능 37 | 38 | 메서드이기 때문에 인스턴스에 메모리 공간이 할당되어 있지 않다. 39 | 40 | 41 | 42 | 43 | 44 | 참고 45 | 46 | https://www.notion.so/instance-class-0caa78cdbd1e43e2a66e3061369d1e25 47 | 48 | http://minsone.github.io/mac/ios/swift-methods-summary 49 | -------------------------------------------------------------------------------- /nyokki/Swift/mutating 키워드에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | # mutating func 2 | 3 | 구조체와 열거형은 값타입이다. 4 | 5 | 기본적으로 값타입의 프로퍼티들은 해당 인스턴스 메소드 내에서 수정할 수 없다. 6 | 7 | > 값타입의 프로퍼티는 고유의 데이터를 가진 속성이기 때문이다. 8 | 9 | 그러나 특정 메소드 내에서 구조체 또는 열거형 프로퍼티를 수정해야 하는 경우, mutating 키워드를 가지고 해당 메소드의 동작을 변경하도록 선택할 수 있다. 10 | 11 | 그런 다음 메소드는 메소드 내에서 프로퍼티를 변경할 수 있으며 메소드가 끝나면 변경된 내용이 원래 구조체에 다시 기록된다. 12 | 13 | ```swift 14 | struct Point { 15 | var x = 0.0, y = 0.0 16 | mutating func moveBy(x deltaX: Double, y deltaY: Double) { 17 | x += deltaX 18 | y += deltaY 19 | } 20 | } 21 | var somePoint = Point(x: 1.0, y: 1.0) 22 | somePoint.moveBy(x: 2.0, y: 3.0) 23 | print("\(somePoint.x), \(somePoint.y)") 24 | //3, 4 25 | ``` 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 참고 34 | 35 | https://velog.io/@wonhee010/mutating 36 | 37 | https://zeddios.tistory.com/258 38 | 39 | https://docs.swift.org/swift-book/LanguageGuide/Functions.html#ID173 -------------------------------------------------------------------------------- /nyokki/Swift/property wrapper에 대해서 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## Property Wrappers 2 | 3 | 프로퍼티 래퍼는 프로퍼티가 저장되는 방식을 관리하는 코드와 프로퍼티를 정의하는 코드를 미리 작성하여 중복되는 코드를 생략하는 재사용성을 높히는 방식이다. 4 | 5 | 6 | 7 | 프로퍼티 래퍼의 생성 방법은 구조체, 클래스, enum 등을 만들고 그 앞에 @propertyWrapper라고 명시를 해준다. 실제로 저장값은 wrappedValue로 정의하고 추가로 제공하고 싶은 정보가 있다면 projectedValue를 정의하면 된다. 8 | 9 | 이 프로퍼티래퍼를 사용하는 방법은 프로퍼티를 정의하고 **@프로퍼티래퍼명**으로 attribute를 붙인다. 그러면 이 프로퍼티가 get/set이 일어날 때마다 property wrapper의 getter/setter 코드가 실행된다. 10 | 11 | 12 | 13 | 14 | 15 | 참고 16 | 17 | https://wlaxhrl.tistory.com/90 18 | 19 | https://zeddios.tistory.com/1221 20 | 21 | https://docs.swift.org/swift-book/LanguageGuide/Properties.html -------------------------------------------------------------------------------- /nyokki/Swift/struct와 class와 enum의 차이를 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## **Reference types & Value types** 2 | 3 | 클래스는 레퍼런스 타입(참조타입)이고 구조체와 열거형은 value type(값타입)이다. 4 | 5 | 참조타입은 한 클래스 타입 객체를 다른 객체에 할당했을 때, 두 객체는 같은 인스턴스를 가리킨다. 그리고 하나를 수정하면 다른 하나도 수정이 되는 형태이다. 6 | 7 | 반면에 구조체와 열거형은 할당할 때마다 새로운 복사본을 만들어낸다. 8 | 9 | ## Mutability 10 | 11 | 구조체와 열거형이 벨류타입이기 때문에 만일 구조체를 상수로 만들게 되면 모든 인스턴스는 수정이 불가능하다. 그 안에 있는 프로퍼티가 수정되는 것이 불가능하다. 12 | 13 | ```swift 14 | struct Cat { 15 | var name:String 16 | } 17 | let cat1 = Cat(name: "Kitty") 18 | cat1.name = "Oscar" 19 | // error: cannot assign to property 20 | 21 | ``` 22 | 23 | 반면에 클래스는 상수로 할당되었음에도, 그 참조는 수정 불가능하지만 프로퍼티는 문제없이 수정이 가능하다. -> 인스턴스에 힙에 저장된 클래스의 주소를 저장하기 때문이다. 24 | 25 | ```swift 26 | class Cat { 27 | var name:String? 28 | } 29 | let cat1 = Cat() 30 | cat1.name = "Oscar" 31 | // Working fine 32 | ``` 33 | 34 | 게다가 구조체는 변수로 인스턴스를 생성해도, 그 자신의 프로퍼티를 수정하는 것이 불가능하다. 대신에 이를 가능하게 하려면 mutating 키워드를 써야한다. 35 | 36 | ```swift 37 | struct Cat { 38 | private var vaccinated:Bool 39 | init() { 40 | self.init() 41 | } 42 | // Will not work without mutating keyword 43 | mutating func vaccinate() { 44 | self.vaccinated = true 45 | } 46 | } 47 | var cat1 = Cat() 48 | cat1.vaccinate() 49 | 50 | ``` 51 | 52 | ## Deinitializer 53 | 54 | 벨류타입과 참조타입 둘다 초기화 메소드를 가지고 있지만, deinit 메소드는 벨류타입에 존재하지 않는다. 레퍼런스 카운팅에 영향이 없기 때문에??? 55 | 56 | ```swift 57 | struct Cat { 58 | var name:String 59 | deinit { 60 | } 61 | } 62 | // Compiler Error : Deinitializers may only be declared within a class 63 | ``` 64 | 65 | ## Generated init 66 | 67 | 초기화 메소드는 오직 구조체에서만 선택적으로 가능하다. (클래스는 필수) -> 자동으로 멤버와이즈 메소드를 제공한다. 68 | 69 | ```swift 70 | struct Cat { 71 | var name:String 72 | var age:Int 73 | } 74 | let cat1 = Cat(name: "Lucy", age: 3) 75 | ``` 76 | 77 | ## Inheritance 78 | 79 | 오직 클래스만 상속 할 수 있다. 80 | 81 | ## Stored properties 82 | 83 | 구조체와 클래스와 달리, 열거형은 저장 프로퍼티를 가질 수 없다. 84 | 85 | ```swift 86 | enum Pet { 87 | 88 | var name:String 89 | // error: enums must not contain stored properties 90 | } 91 | ``` 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | ## 정리 100 | 101 | #### 클래스 102 | 103 | + 프로퍼티와 메소드를 가질 수 있는 컨테이너 타입을 정의하기 위한 용도 104 | + 일반적으로 단일 상속 가능 105 | + 참조타입 106 | + iOS 프레임워크는 대부분의 큰 뼈대는 클래스로 구성 107 | + Extension 가능 108 | 109 | #### 구조체 110 | 111 | + 프로퍼티와 메소드 정의 가능 112 | + 상속 불가능 113 | + Extension 가능 114 | + 값 타입 115 | + Swift의 큰 뼈대는 구조체 116 | 117 | #### 열거형 118 | 119 | + 상속 불가 120 | + 값 타입 121 | + 유사한 종류의 여러 값을 한 곳에 모아 정의 한 것 122 | + 열거형 자체가 하나의 데이터 타입 123 | + Extension 가능 124 | + Stored property 불가능 125 | 126 | + Computed Property example 127 | 128 | ````swift 129 | enum ApiError { 130 | case NoInternetConnection 131 | case AuthenticationFail 132 | case ResponseTimeOut 133 | var errorMsg: String { 134 | switch self { 135 | case .NoInternetConnection: 136 | return “Internet connection has problem!” 137 | 138 | case .AuthenticationFail: 139 | return “Error has Authentication fail!” 140 | 141 | case .ResponseTimeOut: 142 | return “Too longggggg :P” 143 | } 144 | } 145 | } 146 | ```` 147 | 148 | -------------------------------------------------------------------------------- /nyokki/Swift/멀티 쓰레드로 동작하는 앱을 작성하고 싶을 때 고려할 수 있는 방식들을 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### 1. GCD / Operation 2 | 3 | + GCD(Grand Central Dispatch) 4 | 5 | 함수를 사용한 작업(메소드, 블럭) 6 | 7 | DispatchQueue와 같다고 생각하면 된다. 8 | 9 | + Operation(NSOperation) 10 | 11 | 데이터와 기능을 캡슐화하고 작업의 시작과 정지 Qos등 직접적으로 관리할 수 있음(애플에서는 지양) 12 | 13 | ### 2. Async / Sync 14 | 15 | + Async(비동기) 16 | 17 | 작업의 요청을 하고 응답을 기다리지 않은 채 다음 작업으로 넘긴다. 18 | 19 | + Sync(동기) 20 | 21 | 작업의 요청을 하고 응답이 올 때까지 다른 작업으로 넘기지 않고 응답이 오면 다음 작업으로 넘긴다. 22 | 23 | ### 3. Serial / Concurrent 24 | 25 | + Serial 26 | 27 | 등록된 작업을 한번에 하니씩 차례대로 처리 하는 직렬 Queue 28 | 29 | 메인큐에서 시리얼로 작업하며 작업을 하나의 스레드에서 진행하고 30 | 31 | 순서가 중요한 작업의 경우 시리얼로 작업한다. 32 | 33 | + Concurrent 34 | 35 | 등록된 작업을 한번에 하니씩 차례대로 처리 하지 않고 여러 작업을 동시에 작업하는 병렬 Queue 36 | 37 | 글로벌 큐에 경우 Concurrent로 작업하며 분산시킨 작업을 여러 개의 스레드에서 작업하며 각각 독립적이지만 여러 개의 작업을 처리할 때 사용한다. 38 | 39 | 4. Main/Global 40 | 41 | 앱 실행시 시스템에서 기본적으로 2개의 Queue를 만들어 주는데, 그것이 Main Queue와 Global Queue이다. 42 | 43 | + Main Queue 44 | 45 | 메인 스레드에서 사용 되는 Serial Queue. 모든 UI 처리는 메인 스레드에서 처리를 해야 한다. 46 | 47 | + Global Queue 48 | 49 | 편의상 사용할 수 있게 만들어 놓은 Concurrent Queue. 처리 우선 순위를 위한 QoS 파라미터를 제공하며 작업 완료의 순서는 정할 수 없지만 우선적으로 일을 처리하게 할 수 있다. 우선적으로 일을 처리한다는 뜻은 쓰레드의 할당을 늘린다는 의미이다. 50 | 51 | + Custom Queue 52 | 53 | Global Queue에서 수행되는 임의로 지정한 Queue. Serial/Concurrent 모두 가능하나 보통 Serial로 작업 수행. Main과 구분 해서 사용이 필요할 경우 사용 한다. 54 | 55 | ### 동시성 프로그래밍의 문제점 56 | 57 | #### 경쟁 상황 58 | 59 | + Thread-safe하지 않음 60 | 61 | 멀티 쓰레드의 환경에서 같은 시점에 여러 개의 쓰레드에서 하나의 메모리에 동시 접근하는 문제를 말한다. 이를 Thread-Safe하지 않는다고 하며 경쟁상황(Race Condition)이라고도 표현을 한다. 62 | 63 | #### 교착상태(DeadLock) 64 | 65 | 멀티 쓰레드의 환경에서, 베타적인 메모리 사용(서로 잠그고 점유하려고 하는 것)으로 메서드의 작업이 종료 되지 못하고 일이 진행이 안되는 문제 66 | 67 | 68 | 69 | 참고 70 | 71 | https://www.notion.so/868ec584a6d14851a5c6d74ec4c1c791 72 | 73 | https://www.notion.so/286e419e66484f92ad188649b788a7fd 74 | 75 | https://velog.io/@sossont/Swift-GCD%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC -------------------------------------------------------------------------------- /nyokki/Swift/접근 제어자의 종류엔 어떤게 있는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | 사전지식 2 | 3 | + 모듈 4 | 5 | 하나의 프레임워크로 import 키워드를 통해서 추가되는 외부의 코드를 모두 모듈이라고 한다.(UIKit, Foundation) 6 | 7 | + 소스파일 8 | 9 | swift파일로 추가하여 코드를 작성한 파일(?) 10 | 11 | + 은닉화 12 | 13 | 클래스의 프로퍼티를 private으로 만들어 클래스 밖에서 접근할 수 없도록 하는 것 14 | 15 | 16 | 17 | ## Access Control(접근 제어) 18 | 19 | 접근 제어는 다른 소스파일 및 모듈의 코드에서 코드의 일부에 대한 엑세스를 제한하는 것이다. 20 | 21 | 클래스, 구조체, 열거형, 프로퍼티, 메소드, 이니셜라이저, 서브스크립트에 대해 특정 접근 레벨을 지정할 수 있다. 22 | 23 | 24 | 25 | ### 사용하는 이유 26 | 27 | 코드의 영역을 분리시켜서 효율적 관리가 가능하게 된다. 28 | 29 | 컴파일러가 해당 변수가 어느 범위에서만 쓰이는 지를 인지 가능하게 하여 컴파일 시간이 감소한다. 30 | 31 | 애플에서 자신들이 원하는 코드를 감출 수 있다. 32 | 33 | 34 | 35 | ### Access Levels(접근레벨) 36 | 37 | - `Open` & `Public` : Open과 Public 접근자 모두 선언한 모듈이 아닌 다른 모듈에서 사용 가능하다. 38 | 39 | 두 접근자의 차이점은 40 | 41 | Open은 다른 모듈에서 재정의와 상속이 가능하지만 42 | 43 | Public 접근자로 선언된 것은 다른 모듈에서는 재정의와 상속이 불가능하다. 44 | 45 | - `Internal` : 디폴트 접근레벨로 아무 접근레벨을 선언하지 않으면 `Internal`로 간주된다. `Internal`레벨로 선언되면 같은 모듈에서만 사용 가능하다. 46 | 47 | - `File-private` : 특정 엔티티를 선언한 같은 파일 안에서만 사용 가능하다. 48 | 49 | - `Private` : 특정 엔티티가 선언된 괄호({}) 안에서만, 같은 scope 내에서만 사용 가능하다. -> Extension으로만 사용 가능하다. 50 | 51 | 52 | 53 | ### 상속 관계 주의점 54 | 55 | + 상속해서 만든 하위 클래스는 상위 클래스보다 더 높은 접근 수준 설정이 안된다. 56 | 57 | ```swift 58 | public class A { 59 | fileprivate func aMethod() { } 60 | } 61 | 62 | open class B: A { // 불가능 63 | override internal func aMethod() { 64 | super.aMethod() 65 | } 66 | } 67 | ``` 68 | 69 | 70 | 71 | + 동일 모듈에서 정의한 클래스의 상위 멤버에 접근 가능하면, 접근 수준을 올려서 재정의가 가능하다. (fileprivate -> internal로 재정의 가능) 72 | 73 | ```swift 74 | public class A { 75 | fileprivate func aMethod() { } 76 | } 77 | 78 | internal class B: A { 79 | override internal func aMethod() { // 가능 80 | super.aMethod() 81 | } 82 | } 83 | ``` 84 | 85 | 86 | 87 | ### extension의 접근 수준 88 | 89 | 확장시에는 본체의 타입과 동일한 접근 수준을 유지 한다. 확장의 멤버는 본체의 멤버와 동일 취급을 한다. 90 | 91 | 92 | 93 | ### getter/setter의 접근 제어 94 | 95 | 읽기의 수준보다 쓰기의 수준이 더 높을 수 없다. 쓰기는 데이터를 바꾸는 동작이기 때문에 읽기 보다 더 높은 위험성을 가지기 때문이다. 96 | 97 | ```swift 98 | class SomeClass { 99 | private(set) var someValue = 1 100 | } 101 | 102 | // 읽기는 internal이지만 쓰기는 private이 되는 변수이다. 다시 말해, 읽는 것은 가능하지만 직접적으로 쓰는 것은 불가능하다. 103 | ``` 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 참고 112 | 113 | https://www.notion.so/bb039b0999764622b66b8c90df2ec1f7 114 | 115 | https://zeddios.tistory.com/383 116 | 117 | https://jusung.gitbook.io/the-swift-language-guide/language-guide/25-access-control -------------------------------------------------------------------------------- /nyokki/Swift/탈출 클로저에 대하여 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## 탈출 클로저(escaping Closure) 2 | 3 | 클로저를 함수의 파라미터로 넣을 수 있는데, 원칙적으로는 함수의 실행이 끝나면 파라미터로 쓰이는 클로저도 제거가 된다. 하지만 ```@escaping```키워드를 붙힌 클로저는 제거되지 않고 함수 밖(함수가 끝나고)에서 실행되는 클로저를 escaping closure라 한다. 4 | 5 | 예를 들어, 내부에서 사용한 클로저를 외부 변수에 저장하거나 비동기로 실행되거나 completionHandler로 사용되는 클로저에 사용된다. 6 | 7 | 8 | 9 | 함수의 파라미터 라이프사이클을 보면 파라미터는 함수가 실행되면 생성되었다가 실행이 끝나면 자동으로 제거가 된다. 함수가 실행되면서 클로저를 생성하는데 탈출 클로저가 아니라면 이 클로저를 실행할 코드가 사라진다. 따라서 탈출 클로저로 선언하면 해당 클로저를 실행할 때까지 이 클로저를 삭제하지 않고 클로저가 실행하게 되면 그 이후에 이 클로저가 삭제된다. 10 | 11 | 12 | 13 | 따라서 클로저의 실행흐름이 함수의 실행흐름을 벗어나더라도 에러 없이 실행할 수 있는 것이다. 14 | 15 | 16 | 17 | `@escaping`이 붙어 있어도 다음과 같이 non-escaping 클로저를 인자로 넣을 수 있다. 반대로 escaping 클로저를 `@escaping` 없이 사용할 수 없다. escaping, non-escaping 클로저를 나눠서 사용하는 이유는 컴파일러의 퍼포먼스와 최적화 때문이다. 18 | 19 | non-escaping 클로저는 컴파일러가 클로저의 실행이 언제 종료되는지 알기 때문에, 때에 따라 클로저에서 사용하는 특정 객체에 대한 retain, release 등의 처리를 생략해 객체의 라이프싸이클(life-cycle)을 효율적으로 관리할 수 있다. 20 | 21 | 22 | 23 | 참고 24 | 25 | https://jusung.gitbook.io/the-swift-language-guide/language-guide/20-extensions 26 | 27 | https://jusung.github.io/Escaping-Closure/ 28 | 29 | -------------------------------------------------------------------------------- /nyokki/Swift/프로토콜이란 무엇인지 설명하시오..md: -------------------------------------------------------------------------------- 1 | # 프로토콜이란? 2 | 3 | 특정 역할을 하기 위한 메소드, 프로퍼티, 기타 요구사항 등의 청사진 4 | 5 | 6 | 7 | 자격증이라고 생각하면 편하다. 만일 어떤 사람이 심폐 소생술 자격증을 취득했다고 하면 그 사람은 심폐 소생술을 할 수 있는 사람이다. 8 | 9 | 어떤 객체가 특정 프로토콜을 채택(취득)했다는 것은 특정 프로토콜 내부의 메서드(행동)들을 할 수 있다는 것을 의미한다. 또한 한 사람이 여러 자격증을 취득할 수 있듯이, 프로토콜도 다중 채택이 가능하다. 10 | 11 | 12 | 13 | ## 프로토콜의 사용 14 | 15 | + 구조체, 클래스, 열거형은 프로토콜을 채택하여 특정 기능을 실행하기 위한 프로토콜의 요구사항을 실제로 구현할 수 있다. 16 | + 프로토콜은 정의를 하고 제시를 할 뿐 스스로 기능을 구현하지는 않는다. 17 | + 하나의 **타입**으로 사용되기 때문에 타입이 쓰이는 모든 곳에 프로토콜을 사용할 수 있다. 18 | + 함수, 메소드, init의 파라미터 타입 혹은 리턴 타입 19 | + 상수, 변수, 프로퍼티의 타입으로 할당 가능 20 | + 배열, 딕셔너리의 원소 타입 21 | 22 | ##### -------> *스위프트는 프로토콜을 "일급객체"로 취급한다.* 23 | 24 | 25 | 26 | ## Property Requirments 27 | 28 | 프로토콜에서는 프로퍼티가 29 | 30 | 1. 저장프로퍼티인지 연산프로퍼티인지 명시하지 않는다. 31 | 2. 그 대신, 이름과 타입 그리고 get, set 키워드를 이용해 읽기/쓰기, 읽기 여부를 명시한다. 32 | 3. 프로퍼티는 항상 var로 선언해야 한다. 33 | 4. 타입프로퍼티 구현 가능하다. 34 | 35 | 36 | 37 | 프로토콜은 최소한의 요구 사항이기 때문에 어떤 곳에 채택을 하여 구현을 할 때, 38 | 39 | get only 프로퍼티를 get, set을 모두 충족하는 프로퍼티로 구현이 가능하다. (최소한의 요구 사항만 맞추면 되기 때문에 그 이상을 하는 것은 가능하다. 하지만 읽기/쓰기 프로퍼티에서 read-only 프로퍼티로 구현하는 것은 불가능하다.) 40 | 41 | Read-only 프로퍼티인 경우에는 var를 let으로 변경하는 것도 가능하다. 42 | 43 | ## Method Requirements 44 | 45 | 프로토콜에서는 인스턴스 메소드와 타입 메소드를 정의할 수 있다. 하지만 메소드 파라미터의 기본값은 프로토콜 안에서 사용할 수 없다. 46 | 47 | + mutating 키워드 48 | 49 | 메소드 앞에 mutating 키워드를 붙이는 것은 구조체에만 특정 짓는 것이 아니고 구조체/클래스 모두 사용할 수 있는 메서드인데 구조체/열거형에도 사용 가능하도록 내부 저장 프로퍼티 변경 메서드를 요구하는 것이다. 50 | 51 | ## Initializer Requirements 52 | 53 | : 프로토콜에서는 이니셜라이저도 정의할 수 있다. 54 | 55 | + 실패 가능한 이니셜라이저도 선언할 수 있다. ``` init?(), init!()``` 56 | 57 | 실패 가능한 프로토콜을 구현할 때에 구현 불가능한 이니셜라이저로 구현해도 된다. 58 | 59 | - 특정 프로토콜의 required 이니셜라이저를 구현하고, SuperClass의 이니셜라이저를 SubClass에 상속하는 경우 **SubClass의 이니셜라이저 앞에 required 키워드와 override 키워드를 붙여줘야 한다.** (필수적으로 구현해야하는 최소한의 요구사항이기 때문에) 60 | 61 | + 예외 62 | 63 | 구조체라면 필수 생성자라는 것이 없기 때문에 required 키워드를 안붙여도 된다. 64 | 65 | 클래스 앞에 final 키워드를 붙인다면 상속을 하지 않는다는 의미이기 때문에 required 키워드를 붙이지 않아도 된다. 66 | 67 | ## Subscript Requirements 68 | 69 | + subscript 가능하다. 최소 읽기 서브스크립트 요구할 수 있고, 읽기/쓰기 모두 요구하는 것도 가능하다. 70 | 71 | 72 | 73 | ## Protocol is Type 74 | 75 | 스위프트에서 프로토콜을 일급객체로 취급하기 때문에 프로토콜은 타입으로써 사용될 수 있다. 변수에 할당할 수도 있고, 함수의 파라미터, 리턴값으로도 프로토콜타입을 사용할 수 있다. 76 | 77 | 만일, 프로토콜을 채택한 클래스의 인스턴스를 생성하고 나서, 그 인스턴스의 타입을 채택한 프로토콜로 한다면 오류가 나지 않는다. 하지만 해당 인스턴스는 프로토콜 내부 요구사항(메서드, 프로퍼티 등)만 사용할 수 있다. 78 | 79 | 80 | 81 | **장점** 82 | 83 | + 해당 프로토콜을 채택한 객체들을 하나의 데이터 묶음으로 저장 할 수 있다. 84 | + 함수의 파라미터/리턴타입으로 사용이 가능하다. 85 | + is/as 연산자 사용이 가능하다. ---> 프로토콜 준수성 검사 86 | 87 | 88 | 89 | ## protocol SomeProtocol : AnyObject { } 90 | 91 | AnyObject는 프로토콜이기 때문에 다른 프로토콜에서 상속 받을 수 있으며, 92 | 93 | 이 프로토콜은 클래스 전용 프로토콜이 된다. -> 구조체에서는 사용할 수 없게 됨 94 | 95 | 96 | 97 | ## Optional Protocol 98 | 99 | 프로토콜의 요구사항을 선택적으로 채택할 수 있도록 구현하기 위해서는 100 | 101 | 프로토콜을 Objective-C에서 읽을 수 있는 코드로 바꿔줘야 한다. 102 | 103 | 옵셔널은 @objc에서 지원하는 기능이기 때문이고 프로퍼티 앞에 @objc 키워드를 붙여줘야 하고 104 | 105 | 해당 프로퍼티 혹은 func를 optional로 하기 위해서는 106 | 107 | ```@objc optional var something``` 혹은 ```@objc optional func doSomething```과 108 | 109 | 같은 형태로 만들어주어야 한다. 110 | 111 | 다만, @objc 프로토콜을 선언한다면 클래스 전용 프로토콜이기 때문에 구조체/열거형에서는 채택할 수 없다. 112 | 113 | 114 | 115 | ## Extension Protocol 116 | 117 | 프로토콜의 익스텐션을 사용하면 메서드의 기본 구현을 할 수 있다. 이 방법을 사용하면 중복되는 코드를 줄일 수 있다. 118 | 119 | ```swift 120 | protocol CanRun { 121 | func run() 122 | } 123 | 124 | extension CanRun { 125 | func run() { 126 | print("나는 달릴 수 있다.") 127 | } 128 | } 129 | 130 | class Runner: CanRun {} 131 | let runner = Runner() 132 | runner.run() 133 | // 나는 달릴 수 있다. 134 | 135 | class Runner2: CanRun { 136 | func run() { 137 | print("나는 더 빨리 달릴 수 있다.") 138 | } 139 | } 140 | 141 | let runner2 = Runner2() 142 | runner2.run() 143 | // 나는 더 빨리 달릴 수 있다. 144 | ``` 145 | 146 | #### 주의할 점 147 | 148 | 확장에서 기본 구현을 제공하는 메서드는 해당 프로토콜을 채택해서 필수적으로 구현하지 않아도 된다. 다만 채택한 곳 내부에서 메서드를 구현을 할 경우에는 기본 구현이 아닌 직접 구현한 것을 우선순위로 한다. 149 | 150 | 151 | 152 | ### 프로토콜 익스텐션 조건 추가 153 | 154 | 프로토콜 익스텐션에 where절을 이용해서 해당 조건을 만족할 경우에만 프로토콜 확장을 적용하는 방식이다. 155 | 156 | ```swift 157 | protocol CanRun { 158 | func run() 159 | } 160 | 161 | protocol CanJump { 162 | func jump() 163 | } 164 | 165 | extension CanRun where Self: CanJump{ 166 | //Self는 타입(클래스, 구조체, 열거형 등) 자기 사진을 의미. 167 | //self는 인스턴스 자기 자신을 의미. 168 | func run() { 169 | print("나는 달릴 수 있다.") 170 | } 171 | func jump() { 172 | print("나는 달리면서 뛸 수 있다.") 173 | } 174 | } 175 | 176 | class Runner: CanRun { 177 | func run() { 178 | //구현해야 한다. 179 | } 180 | } 181 | 182 | class JumperAndRunner: CanJump, CanRun { 183 | // extension에 구현된 기본값으로 사용 가능하기 때문에 구현하지 않아도 된다. 184 | } 185 | ``` 186 | 187 | 188 | 189 | ## Protocol-Oriented Programming(프로토콜 지향 프로그래밍) 190 | 191 | 객체 지향 프로그래밍의 장점은 상속이 된다는 점이다. 192 | 193 | 단점은 하나의 클래스만, 즉 다중 상속이 불가능하다는 점이다. 또한 상위 클래스의 메모리 구조를 따라갈 수 밖에 없고 필요하지 않은 프로퍼티와 메서드까지 상속이 된다. 상속은 구조체, 열거형에서는 불가능하고 오직 클래스에서만 가능하는 단점이 있다. 194 | 195 | 196 | 197 | 반면 프로토콜은 198 | 199 | 구조체, 열거형, 클래스 모두 사용이 가능하고, 다중 채택이 가능하다. 200 | 201 | 메모리 구조에 대한 특정 요구사항이 없으며 모든 요구 사항을 받아드리지 않아도 되는 ```@optional```이 존재한다. 202 | 203 | 프로토콜은 타입으로 사용이 가능하기 때문에 활용성이 올라가고 재사용성을 높일 수 있다. 204 | 205 | 206 | 207 | 208 | 209 | 참고 210 | 211 | https://medium.com/@jgj455/%EC%98%A4%EB%8A%98%EC%9D%98-swift-%EC%83%81%EC%8B%9D-protocol-f18c82571dad 212 | 213 | https://kimgaeun.tistory.com/8 -------------------------------------------------------------------------------- /nyokki/iOS/ Foundation Kit은 무엇이고 포함되어 있는 클래스들은 어떤 것이 있는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # Foundation 2 | 3 | 프로그램의 중심을 담당하는 프레임워크이다. 사실 가장 기본적인 `원시 데이터 타입`(String, Int, Double)부터가 `Foundation`에 포함되어있기 때문에, 프레임워크를 상속하지 않으면 아무것도 할 수 없다고 봐도 무방하다. 4 | 5 | `Foundation` 내에 포함된 클래스들은 앞에 `NS`가 붙으며 주로 사용하는 기능들은 다음과 같다. 6 | 7 | ### 기본 8 | 9 | `Number, Data, String`: 원시 데이터 타입 사용 10 | `Collection`: Array, Dictionary, Set 등과 같은 컬렉션 타입 사용 11 | `Date and Time`: 날짜와 시간을 계산하거나 비교하는 작업 12 | `Unit and Measurement`: 물리적 차원을 숫자로 표현 및 관련 단위 간 변환 기능 13 | `Data Formatting`: 숫자, 날짜, 측정값 등을 문자열로 변환 또는 반대 작업 14 | `Filter and Sorting`: 컬렉션의 요소를 검사하거나 정렬하는 작업 15 | 16 | ### 애플리케이션 지원 17 | 18 | `Resources`: 애플리케이션의 에셋과 번들 데이터에 접근 지원 19 | `Notification`: 정보를 퍼뜨리거나 받아들이기는 기능 지원 20 | `App Extension`: 확장 애플리케이션과의 상호작용 지원 21 | `Error and Exceptions`: API와의 상호작용에서 발생할 수 있는 문제 상황에 대처할 수 있는 기능 지원 22 | 23 | ### 파일 및 데이터 관리 24 | 25 | `File System`: 파일 또는 폴더를 생성하고 읽고 쓰는 기능 관리 26 | `Archives and Serialization`: 속성 목록, JSON, 바이너리 파일들을 객체로 변환 또는 반대 작업 관리 27 | `iCloud`: 사용자의 iCloud 계정을 이용해 데이터를 동기화하는 작업 관리 28 | 29 | ### 네트워킹 30 | 31 | `URL Loading System`: 표준 인터넷 프로토콜을 통해 URL과 상호작용하고 서버와 통신하는 작업 32 | `Bonjour`: 로컬 네트워크를 위한 작업 33 | 34 | ​ 35 | 36 | #### 추가 37 | 38 | Foundation은 코코아 프레임워크 계층구조에서 Core Service에 들어가 있고 UIKit은 가장 위인 Cocoa Touch 계층에 있다. 39 | 40 | ![img](https://media.vlpt.us/post-images/wan088/04203e00-bff7-11e9-aaf8-abce3fc63ae8/image.png) 41 | 42 | #### Cocoa Touch 계층 43 | 44 | 하위 계층의 프레임워크를 사용하여 애플리케이션을 직접 구현하는 프레임워크 45 | `UIKit`, `GameKit`, `MapKit` 46 | 47 | #### Media 계층 48 | 49 | 상위 계층인 코코아 터치 계층에 그래픽 관련 서비스나 멀티미디어 관련 서비스를 제공 50 | `Core Graphics`, `Core Text`, `Core Audio`, `Core Animation`, `AVFoundation` 51 | 52 | #### Core Service 계층 53 | 54 | 문자열 처리, 데이터 집합 관리, 네트워크, 주소록 관리, 환경 설정 등 핵심적인 서비스들을 제공 55 | 또한 GPS, 나침반, 가속도 센서나 자이로스코프 센서와 같이 디바이스의 하드웨어 특성에 기반한 서비스도 제공 56 | `Foundation`, `Core Foundation`, `Core Location`, `Core Motion`, `Core Animation`, `Core Data` 57 | 58 | #### Core OS 계층 59 | 60 | 커널, 파일 시스템, 네트워크, 보안, 전원 관리, 디바이스 드라이버 등이 포함 61 | iOS가 운영 체제로서 기능을 하기 위한 핵심적인 영역 -------------------------------------------------------------------------------- /nyokki/iOS/@Main에 대해서 설명하시오..md: -------------------------------------------------------------------------------- 1 | Type Method 2 | 3 | # main() 4 | 5 | > 앱의 최상위 레벨의 entry point를 제공한다. 6 | 7 | ## Declaration 8 | 9 | ```swift 10 | @MainActor static func main() 11 | ``` 12 | 13 | [`UIApplicationDelegate`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate) 은 UIKit app의 메인 entry point로서 역할을 할 수 있도록 main 메소드를 실행한다. 시스템은 앱을 시작하기 위해 이 매소드를 호출하고 절대로 사용자나 개발자가 직접 이 메서드를 호출하지 않는다. @main 어트리뷰트로 표시된 앱에서 정확히 하나의 entry point를 갖는 것이다. 14 | 15 | 16 | 17 | 1. main 함수는 Xcode에서 제공된 함수이며 UIKit의 [`UIApplicationMain(_:_:_:_:)`](https://developer.apple.com/documentation/uikit/1622933-uiapplicationmain)을 호출한다. 18 | 19 | 2. [`UIApplicationMain(_:_:_:_:)`](https://developer.apple.com/documentation/uikit/1622933-uiapplicationmain)는 UIApplication 객체를 만들고 앱 델리게이트를 만든다. 20 | 3. UIKit은 메인 스토리보드나 nib 파일로부터 앱의 디폴드 인터페이스를 만든다. 21 | 4. UIKit은 앱 델리게이트의 [`UIApplicationMain(_:_:_:_:)`](https://developer.apple.com/documentation/uikit/1622933-uiapplicationmain)를 호출한다. 22 | 5. UIKit은 앱의 델리게이트와 뷰 컨트롤러가 추가적인 메소드를 부를수 있는 restoration 상태를 수행한다. 23 | 6. UIKit은 앱 델리게이트의 [`application(_:didFinishLaunchingWithOptions:)`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622921-application)메소드를 호출한다. 24 | 25 | 초기화가 끝나면 시스템은 씬 델리게이트와 앱 델리게이트를 이용하여 앱의 생명주기를 관리하고 UI를 표시한다. 26 | 27 | 28 | 29 | Xcode 12부터 적용됨 30 | 31 | 진입 포인트 마킹 32 | 33 | 34 | 35 | 참고 36 | 37 | https://developer.apple.com/documentation/uikit/uiapplicationdelegate/3656306-main 38 | 39 | -------------------------------------------------------------------------------- /nyokki/iOS/App Bundle의 구조와 역할에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | # App Bundle 2 | 3 | + 실행 가능한 코드와 관련 리소스를 한 공간에 묶는 디렉토리 모음 4 | 5 | 애플리케이션 번들은 애플리케이션이 성공적으로 작동하는데 필요한 모든 것을 저장한다. 6 | 7 | ### 애플리케이션 번들에 들어가는 파일 8 | 9 | + Info.plist : Information Property list의 줄임말로 응용프로그램에 대한 구성 정보가 들어가 있는 구조화된 파일. 시스템은 이 파일의 존재 여부에 따라 애플리케이션 및 관련 파일에 대한 관련 정보를 식별(필수) 10 | 11 | + 실행파일(Executable): 모든 응용프로그램에는 실행 가능한 파일이 있어야한다. 이 파일에는 애플리케이션 entry point와 애플리케이션 타겟에 정적으로 연결된 모든 코드가 포함되어 있다. (필수) 12 | 13 | + 리소스파일: 위에서 말한 애플리케이션 실행 파일 밖에 있는 데이터 파일들을 의미한다. 일반적으로 이미지, 아이콘, 소리, nib 파일, 문자열 파일 등으로 구성된다. 14 | 15 | + 다른 지원 파일: iOS 애플리케이션 번들에는 custom data resource를 포함하는 것이 가능하지만 사용자 정의 프레임워크 또는 플러그인은 포함될 수 없다. 16 | 17 | ### iOS App Bundle 의 구조 18 | 19 | image-20210805211332122 20 | 21 | + **MyApp(필수)** 22 | 23 | 애플리케이션 코드를 포함하는 실행 파일(Executable) 24 | 25 | 실제 앱 이름에서 .app 확장자를 뗀 것이다. 번들 구조에서 반드시 있어야 한다. 26 | 27 | + **애플리케이션 아이콘(필수/권장)** 28 | 29 | + **Info.plist(필수)** 30 | 31 | 번들 ID, 버전 번호와 같은 애플리케이션에 대한 구성 정보가 포함되어 있음 32 | 33 | + Launch image(권장) 34 | 35 | 위 이미지에서는 Default.png를 의미한다. 36 | 37 | 애플리케이션이 window와 인터페이스를 로드할 때까지 launch이미지 중 하나를 임시 배경으로 사용한다. 이를 사용하지 않으면 검은 배경이 표시된다. 38 | 39 | + MainWindow.nib 40 | 41 | 런타임시 앱을 로드할 기본 인터페이스 객체를 포함하고 있다. 보통 Window 객체와 App Delegate, scene delegate 객체의 인스턴스가 포함된다. 42 | 43 | + Setting.bundle 44 | 45 | 앱의 specific preferences를 포함하는 특별한 타입의 플러그인이다. 46 | 47 | + 커스텀 리소스 파일 48 | 49 | 로컬화 되지 않은 리소스는 최상위 디렉토리에 배치되고 로컬 리소스는 애플리케이션 번들의 언어별 하위 디렉토리에 배치된다. 리소스는 nib파일, 이미지, 사운드 파일, 설정파일, 등등 애플리케이션에 필요한 기타 커스텀 데이터 파일로 구성된다. 50 | 51 | 52 | 53 | 출처 54 | 55 | https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1 56 | 57 | 58 | 59 | 참고 60 | 61 | https://sihyungyou.github.io/iOS-app-bundle/ 62 | 63 | -------------------------------------------------------------------------------- /nyokki/iOS/App thinning에 대해서 설명하시오.md: -------------------------------------------------------------------------------- 1 | 출처 : https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f 2 | 3 | 앱 시닝이란 무엇일까? 4 | 5 | 단어 그대로 해석을 하면 앱을 얇게(thin)하게 한다는 의미로 해석된다. 얇게 ...? 6 | 7 | 이에 대한 출처는 WWDC 15에서 확인할 수 있었습니다. 8 | 9 | "App Thinning in Xcode" 10 | 11 | 12 | 13 | # 앱 시닝이란? 14 | 15 | 앱 시닝이란 16 | 17 | > App Store와 운영 체제는 최소 설치 공간으로 사용자의 특정 디바이스 및 운영 체제 버전의 기능에 맞게 조정하여 iOS, tvOS 및 watchOS 앱 설치를 최적화하는 기술 18 | 19 | 을 의미합니다. 이를 통해 최소한의 디스크 사용과 빠른 다운로드 속도를 제공할 수 있습니다. 앱 시닝은 슬라이싱(slicing), 비트코드(bitcode), 주문형 리소스(on-demand resource)가 있습니다. 20 | 21 | 22 | 23 | ### 슬라이싱(slicing)이란? 24 | 25 | 앱이 지원하는 여러 디바이스에 대해 그에 맞는 각각 App variant 번들을 생성하고 제공하는 프로세스입니다. variant에는 타겟 장치 및 운영 체제 버전에 필요한 리소스와 실행이 가능한(해당 버전이나 디바이스에서) 아키텍처를 갖고 있습니다. 개발자가 App store connect에 모든 버전의 앱을 업로드하면, 앱 스토어에서 App이 지원하는 디바이스와 운영 체제 버전을 기반으로 하는 서로 다른 variants를 만들고 제공합니다. asset catalog를 이용해야 이유는 앱스토어가 각 variants에 맞는 이미지, GPU 리소스, 적합한 데이터를 고르기 위해서 입니다. 그리고 사용자가 그 variants 중에서 가장 알맞은 app variant을 다운로드 받는 것입니다. 26 | 27 | img 28 | 29 | ### 비트코드(bitcode)란? 30 | 31 | 비트코드는 기계언어로 번역되기 이전 단계의 Intermediate Representation을 말합니다. 짧게 표현하자면 컴파일된 프로그램의 중간 표현입니다. 현재 iOS에서는 비트코드가 default이나 option이고 watchOS와 tvOS의 경우는 비트코드가 필수입니다. 비트코드를 사용하여 업로드를 하면 애플이 애플리케이션을 다시 컴파일하여 앱 바이너리(app binary)를 생성합니다. 비트코드를 사용하지 않으면, 모든 경우의 디바이스 경우에 따라 바이너리로 생성하여 합쳐져서 fat binary라는 것이 업로드되지만, 비트코드를 사용하면 필요 경우에 따라 재컴파일하게 되므로 여기에서 최적화할 수 있습니다. 32 | 33 | 34 | 35 | ### 주문형 리소스(on-demand resource)란? 36 | 37 | 쉽게 말해서, 필요할 때 다운로드 받는다는 것입니다. 앱스토어는 주문형 리소스에 따라 slice하여 앱의 variants를 더욱 최적화시킵니다. 예를 든다면 사용자가 게임을 합니다. 현재 레벨보다 상위레벨은 필요하지 않으므로 갖고 있을 필요가 없습니다. 사용자의 레벨이 필요할 때 다운로드 받는 것입니다. 또한 인앱 구매를 예로 들 수 있습니다. 사용자의 선택에 따라 다운로드를 받는 것입니다. 38 | 39 | 40 | 41 | img 42 | 43 | 44 | 45 | 참조 46 | 47 | https://ttuk-ttak.tistory.com/42 48 | 49 | https://zeddios.tistory.com/655 -------------------------------------------------------------------------------- /nyokki/iOS/App의 Not running, Inactive, Active, Background, Suspended에 대해 설명하시오. .md: -------------------------------------------------------------------------------- 1 | App States 2 | 3 | 1. Not Running 4 | 5 | 앱이 실행되지 않았거나 완전히 종료되었을 때 상태 6 | 7 | 2. In-Active 8 | 9 | 앱이 실행되면서 foreground에 진입하지만 어떠한 이벤트도 받지 않는 상태 10 | 11 | 백그라운드에서 포그라운드로 진입할때의 상태 12 | 13 | 포그라운드에서 백그라운드로 진입할때의 상태 14 | 15 | 3. Active 16 | 17 | 앱이 실행 중이며 foreground에 있고 이벤트를 받고 있는 상태 18 | 19 | 4. Background 20 | 21 | 앱이 백그라운드에 있으며 다른 앱으로 전환되었거나 홈버튼을 눌러 밖으로 나갔을 때의 상태 22 | 23 | 5. Suspended 24 | 25 | 백그라운드에서 특별한 작업이 없을 경우 전환되는 상태 26 | 27 | -------------------------------------------------------------------------------- /nyokki/iOS/Delegate란 무언인가 설명하고, retain 되는지 안되는지 그 이유를 함께 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## Delegate 2 | 3 | 델리게이션을 이해하기 위해서는 프로토콜을 먼저 이해해야한다. 프로토콜은 특정 작업 혹은 기능들을 구현하기 위한 메소드, 프로퍼티 그리고 기타 다른 요구사항들의 청사진이다. 4 | 5 | 조금 쉽게 말하자면 해당 이름에 걸맞는 기능을 하기 위해서 구현해야 하는 것들의 리스트이다. 6 | 7 | 8 | 9 | 그럼 델리게이션이랑 프로토콜이랑 무슨 상관이 있는 걸까? 10 | 11 | 이 델리게이션을 프로토콜로 만들기 때문이다. 델리게이션은 사전상의 의미로 "위임하다."라는 뜻이다. 사전 뜻 그대로 원하는 class, enum, struct에 프로토콜을 채택하여 해야 할 일들을 위임시킨다는 것이다. 12 | 13 | Delegate 패턴에는 protocol, sender, receiver가 있으며 14 | 15 | protocol : 해야할 일의 목록 16 | 17 | sender : 일을 시키는 객체 18 | 19 | receiver: 일을 하는 객체 20 | 21 | 22 | 23 | ### Retain Cycle 24 | 25 | 참조하는 값은 메모리의 Heap이라는 영역에 해당된다. 26 | 27 | Heap이라는 영역에 메모리가 저장되기 위해선 공간이 필요한데 바로 그 공간을 레퍼런스가 바라보고 있는 것이다. 28 | 29 | img 30 | 31 | 여기서 Retain은 위 사진처럼 레퍼런스를 이용하여 인스턴스를 만들때 생겨난다. 32 | retain은 ARC에서 참조값을 +1해준다. 참고로 반대는 release로 참조값을 -1해준다. 33 | 34 | img 35 | 36 | Retain이 필요한 이유는 메모리 누수를 방지하기 위해서 필요하다. 37 | 38 | 이 방법은 연결 상태 Strong, Weak , unowned으로 각각 상황에 따라 약하게 연결할지 강하게 연결할지 결정하는 것이다. 39 | 40 | 이때 델리게이트는 프로토콜이기 때문에 retain이 발생하지 않는 것일까? 41 | 42 | 델리게이트를 형성하는 것은 해당 프로토콜을 채택한 객체에게 위임을 하는 것이기 때문에 어떤 객체가 델리게이트를 하게 된다면 참조값이 증가한다. 만일 서로가 서로의 대리자가 되어 참조한다면 둘의 참조값이 증가하였기 때문에 두 클래스 모두 해제가 된다고 해도 서로 참조값은 0이 되지 않고 메모리 누수가 생기게 된다. 43 | 44 | 클래스에서 프로토콜을 채택할 때에는 Class-only-Protocol이라는 프로토콜을 만들어주어야 하고 이는 클래스 타입으로 만들어지기 때문에 Retain된다. 45 | 46 | 47 | 48 | 참조 49 | 50 | https://jwonylee.github.io/iOSInterviewquestions/Delegate-retain 51 | 52 | -------------------------------------------------------------------------------- /nyokki/iOS/Frame, Bounds.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout : single 3 | title : Frame과 Bounds 4 | --- 5 | 6 | # Frame과 Bounds의 차이 7 | 8 | Frame과 Bounds는 UIView의 instance property로 둘 다 CGRect이다. 9 | 10 | 여기서 CGRect을 간단히 설명하자면 구조체로서 구조체 변수로 CGPoint, CGSize를 갖고 있다. 따라서 자신의 위치(CGPoint)를 갖는 가로와 세로 길이가 존재(CGSize)하는 사각형이다. 여기서 CGPoint는 사각형기준 왼쪽 위의 점을 기준으로 하며 (0, 0) 기준으로 양의 방향은 x축 오른쪽, y축 아래쪽이다. 11 | 12 | 그렇다면 차이는 무엇일까? 13 | 14 | App 개발자 문서에는 다음과 같이 나와있다. 15 | 16 | 17 | 18 | Bounds: **자기 자신의 좌표계**에서 해당 view의 위치와 크기를 나타내는 사각형 19 | 20 | image-20210605175638277 21 | 22 | Frame: **Superview(상위뷰)** 의 좌표계에서 해당 view의 위치와 크기를 나타내는 사각형 23 | 24 | 25 | 26 | 여기서 드는 의문점은 27 | 28 | 1. 자기 자신의 좌표계란 무엇인가? 29 | 2. 상위뷰를 기준으로 위치와 크기를 나타낸다고 했는데 그 위치를 나타내는 값의 크기는 상위뷰의 크기와 상관이 없는가 그와 유사하게 크기 또한 상대적인 수치인가 절대적인 수치인가? 30 | 31 | XCode에서 살펴보자. 32 | 33 | ```swift 34 | import UIKit 35 | 36 | class ViewController: UIViewController { 37 | 38 | var superView = UIView() 39 | var subView = UIView() 40 | 41 | override func viewDidLoad() { 42 | super.viewDidLoad() 43 | 44 | view.backgroundColor = .red 45 | superView.frame = CGRect(x: 25, y: 25, width: 25, height: 25) 46 | superView.backgroundColor = .yellow 47 | 48 | subView.frame = CGRect(x: 25, y: 25, width: 50, height: 50) 49 | subView.backgroundColor = .green 50 | 51 | view.addSubview(superView) 52 | superView.addSubview(subView) 53 | } 54 | } 55 | ``` 56 | 57 | 58 | 59 | 위 코드로 알게 된 점은 2번 질문에 관한 것인데 수치는 절대적인 값이다. 만일 view 보다 yellow인 superView의 Size가 더 크다면 화면을 넘어가게 된다. (여기서 화면의 크기는 iPhone 11기준 width: 414, height: 819) 60 | 61 | 이번에는 bound에 대한 실험을 해보자. 62 | 63 | ```swift 64 | override func viewDidLoad() { 65 | super.viewDidLoad() 66 | 67 | view.backgroundColor = .red 68 | 69 | yelloewView.backgroundColor = .yellow 70 | greenView.backgroundColor = .green 71 | blackView.backgroundColor = .black 72 | 73 | yelloewView.frame = CGRect(x: 50, y: 50, width: 200, height: 200) 74 | greenView.frame = CGRect(x: 100, y: 100, width: 100, height: 100) 75 | blackView.frame = CGRect(x: 200, y: 200, width: 50, height: 50) 76 | 77 | // view.addSubview(superView) 78 | // view.addSubview(subView) 79 | 80 | view.addSubview(yelloewView) 81 | yelloewView.addSubview(greenView) 82 | view.addSubview(blackView) 83 | 84 | 85 | UIViewPropertyAnimator(duration: 3, curve: .easeOut) { 86 | self.yelloewView.bounds.origin = CGPoint(x: 50, y: 50) // 87 | self.greenView.bounds.origin = CGPoint(x: -100, y: -100) //yellowView에 영향을 받음 88 | // self.view.bounds.origin = CGPoint(x: -80, y: -80) 89 | } .startAnimation() 90 | 91 | 92 | 93 | print("yelloewView bound의 x, y 좌표 : \(yelloewView.bounds.origin.x), \(yelloewView.bounds.origin.y)") //yelloewView bound의 x, y 좌표 : 50.0, 50.0 94 | print("greenView bound의 x, y 좌표 : \(greenView.bounds.origin.x), \(greenView.bounds.origin.y)") //greenView bound의 x, y 좌표 : -100.0, -100.0 95 | 96 | } 97 | 98 | ``` 99 | 100 | 101 | 102 | 자기 자신의 좌표계를 사용한다고 해서 superView의 영향을 받지 않는다고 생각했다. 하지만 yellowView의 bound를 바꾸니 그 subView인 greenView가 영향을 받아 움직였다. 마치 greenView의 point는 핀으로 꽂혀있고 yellowView의 point가 (0, 0)에서 (50, 50)으로 바뀌어서 yellowView의 point가 (0, 0)이던 시점의 point를 찾아가는 것처럼 보인다. 이때 blackView는 View의 subView이므로 yellowView bound에는 영향을 받지 않는다. 103 | 104 | 105 | 106 | -------------------------------------------------------------------------------- /nyokki/iOS/GCD API 동작 방식과 필요성에 대해 설명하시오. .md: -------------------------------------------------------------------------------- 1 | GCD 필요성 2 | 3 | 멀티 코어 프로세서 시스템에 대한 응용 프로그램 지원을 최적화하기 위해 Apple에서 개발한 기술로 스레드 관리와 실행에 대한 책임을 어플리케이션 레벨에서 운영체제 레벨로 넘겨버렸다. 4 | 5 | 작업 단위는 Block(swift에선 클로저)이라 불리며 DispatchQueue가 이 Block들을 관리합니다. 6 | 7 | 애플에서는 쓰래드 클래스 대신 GCD 사용을 권장하고 있다. 8 | 9 | ##### GCD 의 장점 10 | 11 | - reduces the memory penalty for storing thread stacks in the app’s memory space. 12 | 앱의 저장 공간에 스레드 스택을 저장하기 위한 메모리 패널티를 줄여준다. 13 | - eliminates the code needed to create and configure your threads. 14 | 스레드를 만들고 구성하는데 필요한 코드를 제거해준다. 15 | - eliminates the code needed to manage and schedule work on threads. 16 | 스레드에서 작업을 관리하고 스케쥴링하는데 필요한 코드를 제거한다. 17 | - simplifies the code 18 | 코드가 간소화된다. 19 | 20 | 21 | 22 | GCD API 동작 방식 : https://developer.apple.com/documentation/dispatch 23 | 24 | ## DispatchQueue 25 | 26 | - GCD는 앱이 블록 객체 형태로 작업을 전송할 수 있는 FIFO 대기열(Queue)을 제공하고 관리한다. 27 | - Queue에 전달된 작업은 시스템이 전적으로 관리하는 스레드 풀(a pool of threads)에서 실행된다. 28 | - DispatchQueue는 2개의 타입( Serial / Concurrent )으로 구분되며 둘 모두 FIFO 순서로 처리한다. 29 | - 앱을 실행하면 시스템이 자동으로 메인스레드 위에서 동작하는 Main 큐(Serial Queue)를 만들어서 작업을 수행하고, 그 외에 추가적으로 여러 개의 Global 큐(Cuncurrent Queue)를 만들어서 큐를 관리한다. 30 | - 각 작업은 동기(sync) 방식과 비동기(async) 방식으로 실행 가능하지만 Main 큐에서는 async 만 사용 가능 31 | 32 | ### Serial / Concurrent 33 | 34 | Serial Queue: 하나의 다른 쓰레드만 생성하여 작업들을 해당 쓰레드로만 보내는 큐. 순서가 중요한 작업을 수행할 때 사용 35 | 36 | Concurrent Queue: 여러 개의 쓰레드를 생성하여 각각에 맞는 쓰레드에 작업을 보내는 큐. 37 | 38 | 39 | 40 | ### Main & Global 41 | 42 | + Main 43 | 44 | + UI와 관련된 작업은 모두 main queue를 통해서 수행하며 Serial Queue에 해당된다. 45 | 46 | + main쓰레드를 의미하며 메인쓰레드는 메인큐와 같다. 47 | 48 | + MainQueue를 sync메소드로 동작시키면 Dead Lock 상태에 빠진다. async 사용해야 한다. 49 | 50 | ```swift 51 | DispatchQueue.main.async{ } 52 | ``` 53 | 54 | 필요한 이유는? 55 | 56 | + Global 57 | 58 | + UI를 제외한 작업에서 사용하며 Concurrent Queue에 해당 -> 여러 개의 쓰레드를 사용한다. 59 | 60 | + sync와 async 메소드 모두 사용 가능하다. 61 | 62 | + QoS(서비스의 품질)에 따라서 종류가 여러 개(6종류)이다. 63 | 64 | + QoS클래스를 지정하여 우선순위 설정이 가능하다. 65 | 66 | + QoS가 높을 수록 많은 숫자의 쓰레드를 사용하게 된다. -> 작업 속도가 올라감(하지만 절대적으로 먼저 끝난다는 것은 아님, 작업에 따라 다름) 67 | 68 | ```swift 69 | DispatchQueue.global().async{ } 70 | DispatchQueue.global(qos: .utility).async{ } 71 | ``` 72 | 73 | + Custom(프라이빗 큐) 74 | 75 | + 기본적으로 직렬 큐이다. 하지만 Concurrent 설정도 가능하다. 76 | 77 | ```swift 78 | DispatchQueue(label: "customeSerial") 79 | DispatchQueue(label: "someQueue", attributes: .concurrent) 80 | ``` 81 | 82 | 83 | 84 | ### QoS(Quality of Service) 85 | 86 | 시스템은 QoS 정보를 통해 스케쥴링, CPU 및 I/O 처리량, 타이머 대기 시간 등의 우선 순위를 조정 87 | 총 6개의 QoS 클래스가 있으며 4개의 주요 유형와 다른 2 개의 특수 유형으로 구분 가능 88 | [낮은순] unspecified -> background -> utility -> default -> userInitiated -> userInteractive [높은순] 89 | 90 | 91 | 92 | 참고 93 | 94 | https://jinshine.github.io/2018/07/09/iOS/GCD(Grand%20Central%20Dispatch)/ -------------------------------------------------------------------------------- /nyokki/iOS/Global DispatchQueue 의 Qos 에는 어떤 종류가 있는지, 각각 어떤 의미인지 설명하시오. .md: -------------------------------------------------------------------------------- 1 | 참고 2 | 3 | https://developer.apple.com/documentation/dispatch/dispatchqueue/2300077-global 4 | 5 | https://developer.apple.com/documentation/dispatch/dispatchqos/qosclass 6 | 7 | Global dispatch queue는 concurrent queues이다. 8 | 9 | 하나 이상의 task를 실행하지만 task는 큐에 추가된 순서대로 계속 시작된다.(FIFO) 10 | 11 | Global dispatch queue는 QoS를 파라미터로 받는데 QoS를 지정함으로써 중요도를 표시하고 시스템이 우선순위를 정하여 이에 따라 스케줄링을 정한다. task가 순서대로 서비스를 받지만 누가 먼저 끝날지, 어떤 task에 더 많은 에너지를 쏟을지는 QoS에 달려있다. 12 | 13 | QoS는 다음과 같은 것들이 있다. 14 | 15 | ### Choosing a Quality of Service Class 16 | 17 | **User-interactive** : main thread에서 작업, 사용자 인터페이스(UI) 새로고침 또는 애니메이션 수행과 같이 사용자와 상호작용 하는 작업입니다. 작업이 신속하게 수행되지 않으면, UI가 중단된 상태로 표시될 수 있습니다. 반응성(responsiveness)과 성능(performance)에 중점을 둡니다. 18 | 19 | Duration of work to be performed(수행해야될 작업의 기간?) - 순식간에 끝난다.(Work is virtually instantaneous.) 20 | 21 | 22 | 23 | **User-initiated** : 사용자가 시작한 작업이며, 저장된 문서를 열거나, 사용자 인터페이스에서 무언가를 클릭할 때 작업을 수행하는 것과 같은 즉각적인 결과가 필요합니다. 사용자 상호작용을 계속하려면 작업이 필요합니다. (The work is required in order to continue user interaction) 반응성과 성능에 중점을 둡니다. 24 | 25 | Duration of work to be performed : 거의 순식간이며, 몇 초 또는 그 이하입니다. 26 | 27 | 28 | 29 | **Utility** : 작업을 완료하는 데 약간의 시간이 걸릴 수 있으며, 데이터 다운로드 또는 import와 같은 **즉각적인 결과가 필요하지 않습니다**. 유틸리티 작업에는 일반적으로 사용자가 볼 수 있는 progress bar가 있습니다. 반응성, 성능 및 에너지 효율성 간에 **균형을 유지하는 데 중점**을 둡니다. 30 | 31 | Duration of work to be performed : 작업은 몇초에서 몇분정도가 걸립니다. 32 | 33 | 34 | 35 | **Background** : 백그라운드에서 작동하며, indexing, 동기화 및 백업과 같이 **사용자가 볼 수 없는 작업**. 에너지 효율성에 중점을 둡니다. 36 | 37 | Duration of work to be performed : 작업은 분(minutes) 또는 시간(hour)과 같은 상당한 시간(significant time)이 걸립니다. 38 | 39 | 40 | 41 | ### Special Quality of Service Classes 42 | 43 | **Default** : 이 QoS의 priority level은 user-initiated와 utility사이에 있습니다. 이 QoS는 개발자가 작업을 분류하는데 사용하기 위한 것이 아닙니다. QoS정보가 할당되지 않은 작업은 Default로 처리되며 GCD global queue는 이 level(default)에서 실행됩니다. 44 | 45 | 46 | 47 | **Unspecified** : 이는 QoS정보가 없음을 나타내며, 환경 QoS(environmental QoS)를 추론해야 한다는 단서를 시스템에 제공합니다. 쓰레드가 기존(legacy) API를 사용하는 경우, Unspecified QoS를 사용할 수 있으며, 이 경우 쓰레드가 QoS를 벗어날 수 있습니다. (기존 API .. ?) 48 | 49 | 50 | 51 | # 추가할 사항 52 | DispatchQueue.global(qos: .userInteractive).async{} 53 | and 54 | 55 | DispatchQueue.main.async{} 56 | 57 | 의 차이점 58 | -------------------------------------------------------------------------------- /nyokki/iOS/NSCache와 딕셔너리로 캐시를 구성했을때의 차이를 설명하시오..md: -------------------------------------------------------------------------------- 1 | 사전지식 2 | 3 | 캐시란? 4 | 5 | 캐시는 애플리케이션의 성능을 크게 향상시킬 수 있는 객체 또는 데이터 모음이다. 6 | 캐시를 사용함으로써 계산 비용이 많이 들 수 있는 일시적인 데이터와 함께 자주 접근하는 객체를 저장할 수 있다. 7 | 캐싱된 객체를 다시 사용하면 해당 값을 다시 계산할 필요가 없기 때문에 성능상의 이점을 얻을 수 있다. 8 | 9 | 10 | 11 | 하지만 대용량 데이터를 캐싱할 때는 다른 애플리케이션을 위한 RAM이 남아 있지 않을 정도로 많은 객체를 캐시할 수 있는데, 이 용량을 확보하기 위해 애플리케이션을 종료할 수 있다. 12 | 13 | 14 | 15 | iOS에서는 캐싱을 위한 NSCache 객체를 제공하여 생성 비용이 많은 객체를 임시로 저장할 수 있다. 16 | 17 | 18 | 19 | NSCache를 이용하여 image 등의 다량의 데이터를 효율적으로 처리한다. 20 | 21 | 22 | 23 | NSCache는 메모리 관리 문제를 해결하면서 캐시할 항목을 위한 저장 컨테이너이다. 24 | 25 | 1. NSCache는 메모리 관리가 기본적으로 제공된다. 26 | 다른 앱에서 메모리를 더 사용하려고 하면 캐시되어 있던 데이터를 지우고 메모리를 해제한다. 27 | 2. NSCache는 Thread-safe하다. 28 | 캐시 데이터를 읽고 쓰고 지울때마다 따로 lock을 해줄 필요가 없다. 29 | 3. NSDictionary는 Key 값을 copy 하지만 NSCache는 retain 카운트만 증가시킨다. 30 | 복사를 지원하지 않는 객체까지 포용한다. 31 | 32 | ???? 33 | 34 | 35 | 36 | NSCache클래스와 NSDictionary 클래스는 매우 유사하며 둘 다 key-value 쌍을 보유한다. 37 | 38 | 그러나 NSCache는 반응 캐시(Reactive Cache)로, 메모리를 사용할 수 있을 때 주어진 데이터를 적극적으로 캐시하고 만약 메모리가 부족하면 다른 애플리케이션을 위한 메모리를 확보하기 위해 일부 요소를 자동으로 삭제한다. 삭제된 항목은 필요할 경우 다시 계산해야하는 추가적인 컴퓨팅 시간이 걸린다. 39 | 40 | 41 | 42 | NSCache는 캐시된 요소의 갯수를 제한하고 캐시에 있는 모든 요소의 총 Cost를 제한하는 두 가지 유용한 제한 기능을 제공한다. 43 | 44 | ```swift 45 | let cache: NSCache = NSCache() 46 | cache.countLimit = // 허용하는 key의 개수 47 | cache.totalCostLimit = // cost 합계의 최댓값 48 | ``` 49 | 50 | 51 | 52 | NSDictionary에 비해 NSCache가 지닌 장점은 시스템 메모리가 꽉차면 자동으로 캐시의 메모리가 정리된다는 것 53 | 54 | NSCache는 최근에 가장 적게 사용된 객체를 먼저 정리해준다. 55 | 56 | NSCache는 키를 복사하지 않고 리테인한다. 57 | 58 | NSDictionary는 스레드에 안전하지 않고 NSCache는 스레드에 안전하다. 59 | 60 | 61 | 62 | 63 | 64 | 참고 65 | 66 | https://gaki2745.github.io/swift/2019/10/10/Swift-Basic-08/ 67 | 68 | https://junyng.tistory.com/41 69 | 70 | NSCachefh image cache 구현 : https://ontheswift.tistory.com/24 71 | 72 | 딕셔너리 캐싱 : https://aroundck.tistory.com/4717 73 | 74 | -------------------------------------------------------------------------------- /nyokki/iOS/NSOperationQueue 와 GCD Queue 의 차이점을 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## 사전 지식 2 | 3 | ### 비동기 처리가 필요한 이유 4 | 5 | 작업이 오래 걸리는 작업이 생겨나게 되고(특히 네트워크 작업) 이를 잘 처리하기 위한 방법이 필요하다. 6 | 7 | 8 | 9 | 메인 쓰레드에서는 1초에 60번 화면을 다시 그려야하는 역할도 하기 때문에 너무 오래 걸리는 작업들을 시키면 안된다. 10 | 11 | 따라서 다른 쓰레드로 분산처리를 해야하는데, 분산처리를 어떻게 하는지에 대한 코딩 방법을 비동기 처리/ 동시성 프로그래밍이라고 한다. 12 | 13 | 14 | 15 | iOS에서는 작업(Task)를 "대기행렬(Queue)"에 보내기만 하면 iOS가 알아서 여러 쓰레드로 나눠서 분산처리를 한다. 16 | 17 | 18 | 19 | 소프트웨어적인 Thread 20 | 21 | Thread 1 -> Main 쓰레드라고 부른다. 22 | 23 | 24 | 25 | 26 | 27 | ### Async/Synce 28 | 29 | #### KVO(Key-Value Observing) 30 | 31 | - 객체 프로퍼티의 변경사항을 다른 객체에게 알리기 위해 사용하는 코코아 프로그래밍 패턴 32 | - Model과 View와 같이 논리적으로 분리된 파트 간의 변경사항을 전달하는데 유용함 33 | - NSObject를 상속한 클래스에서만 KVO를 사용할 수 있음 34 | - 참고 : https://zeddios.tistory.com/1220 35 | 36 | #### Serial/Concurrent 37 | 38 | - Serial : 39 | Serial queues(private dispatch queus)는 큐에 추가된 순서대로 한번에 하나의 task 실행 40 | 직렬 방식 41 | 현재 실행 중인 task는 dispatch queues에서 관리하는 고유한 스레드에서 실행된다. 42 | 필요한 만큼 사용가능 하며, 각 큐는 다른 모든 큐와 관련하여 동시에 작동한다. -> 만약 serial queue 4개 작성시 각 큐는 한번에 하나의 task만 실행하지만 최대 4개의 task가 각 큐에서 동시에 실행된다. 43 | + Main dispatch queue 44 | main 쓰레드에서 task를 실행하는 전역적으로 사용 가능한 serial queue 45 | 이 큐는 앱의 실행 루프( run time loop?)와 함께 작동하여 큐에 있는 task의 실행을 실행루프에 연결된 다른 이벤트 소스의 실행과 얽힌다. main 스레드에서 실행되므로 main queue는 종종 앱의 주요 동기화 지점으로 사용된다. 46 | - Concurrent: 47 | Concurrent queues(global dispatch queue)는 동시에 하나 이상의 task를 실행하지만 task는 큐에 추가된 순서대로 계속 시작된다. 48 | 특정 시점에서 실행되는 정확한 task의 수는 가변적이며 시스템 조건에 따라 다르다. 49 | iOS 5 이상에서는 큐 타입으로 DISPATCH_QUEUE_CONCURRENT를 지정하여 사용자가 동시에 dispatch queue를 생성할 수 있다. 50 | 앱에 사용할 사전에 정의된 global concurrent queues가 4개 있다. 51 | 52 | #### QoS(Quality of Service) 53 | 54 | 이 class는 DispatchQueue에서 수행할 작업을 분류한다. 55 | 중요도를 표시하고 시스템이 우선순위를 정하여 이에 따라 스케쥴링을 정한다. 우선순위가 높은 작업이 더 빨리 수행되고, 리소스가 많으므로 일반적으로 우선순위가 높은 작업이 우선순위가 낮은 작업보다 더 많은 에너지가 필요하다. -> 앱이 responsive하며 에너지 효율에 대한 보장을 해준다. 56 | 57 | 추가 참고: https://zeddios.tistory.com/521 58 | 59 | #### API 60 | 61 | #### Operation 62 | 63 | Single task와 관련된 코드와 데이터를 나타내는 추상 클래스 64 | 65 | GCD를 기반으로 여러가지 기능을 추가한 추상 클래스라고 생각 (예를 들어 dispatchqueue에서 작업한 코드를 취소할 방법이 없지만 이를 하기 위해서 operation을 사용한다.) 66 | 67 | 기능 68 | 69 | 1. 데이터와 기능을 캡슐화했기 때문에 재사용이 가능하다. 70 | 2. 해당 작업의 실행 상태(실행, 정지, 대기 등)를 알 수 있고 이를 통해 operation들을 취소 혹은 순서 지정이 가능하다.(왜냐하면 Operation은 OperationQueue에 들어가기 전까지 실행되지 않기 때문이다.) 71 | 72 | https://developer.apple.com/documentation/foundation/operation 73 | 74 | https://tong94.tistory.com/17 75 | 76 | 77 | 78 | 쓰레드 활용법 : GCD(Grand Central Dispatch), NSOperation 79 | 80 | GCD는 순정 C API이다. 반면 NSOperationQueue는 object-C객체이다. 따라서 NSOperationQueue가 조금 더 무겁다. NSOperationQueue, Operation(swift3부터 NSOperation -> Operation으로 변경)을 사용하는 이점은 다음과 같다. 81 | 82 | 1. 작업 취소 83 | Operation Queue를 사용하면 취소는 간단히 할 수 있다. 이미 시작한 작업은 취소하지 못할지라도 작업이 실행하지 않게는 할 수 있다. 반면 GCD 큐는 이미 스케쥴된 블록을 취소할 수 있는 방법이 없다. 84 | 2. 의존 작업 85 | 다른 작업이 성공적으로 수행된 후에 실행할 수 있게 하는 작업 계층을 만들 수 있다. 86 | 3. 작업 프로퍼티 키-값 관찰 87 | KVO를 통해 작업이 취소되었는지 알 수 있는 isCancelled, 작업이 끝났는지 확인하는 isFinished 같은 것들이 있다. 이를 통해 GCD보다 세세하게 제어할 수 있다. 88 | 4. 작업 우선순위 89 | 각 작업은 QoS가 있다. 작업들 간의 우선순위를 설정한다. GCD는 이를 하기 위한 직접적인 방법이 없으며 큐 우선순위는 가지지만 개별 블록이 아닌 전체 큐에 대해 우선순위를 설정한다. 90 | 5. 작업의 재사용 91 | NSBlockOpertaion 같은 NSOperation의 하위 클래스 중 하나를 사용하는 것이 아니라면 스스로 자신의 하위 클래스를 생성해야한다. 이러한 코드는 코드 내에서 재사용할 수 있다. 92 | 93 | 참고 : https://blog.naver.com/PostView.nhn?blogId=horajjan&logNo=220888295104&redirect=Dlog&widgetTypeCall=true 94 | 95 | ## NSOperationQueue 96 | 97 | - operation의 실행을 관리하는 큐 98 | - 준비 상태, 상호 운용 종속성, 우선 순위 등을 기반으로 실행한다. 99 | - 우선 순위가 같을 경우 먼저 큐에 들어 온 순서대로 처리 100 | - 큐에 한번 들어가면 작업이 완료되었다고 보고 할 때까지 대기열에 남아 있음 101 | - NSOperation의 finished가 true 일때 102 | - NSOperation의 작업 실행 과정 103 | `ready → executing → finished` 104 | state는 암묵적으로 해당 키패스에 KVO 통지를 하게됨. 이에 대응하는 프로퍼티가 true 반환 105 | - 작업 취소 106 | - 개체가 대기열에 남아 있지만 최대한 빨리 작업을 중지해야한다고 알림 107 | - 현재 작업이 실행 중일 경우 작업 개체의 state가 취소 상태를 확인하고 수행 중인 작업을 중지한 다음 완료됨으로 표시함 108 | - **KVO을 사용해 작업 진행 사항 감시 가능** 109 | 110 | ## Grand Central DispatchQueue(GCD) = DispatchQueue 111 | 112 | * iOS에서 제공하는 쉽고 편한 멀티 스레딩 처리를 위한 API 113 | * 개발자가 실행할 테스크를 생성하고 DispatchQueue에 추가하면 GCD는 테스크에 맞는 스레드를 자동으로 생성해서 실행하고 작업이 종료되면 해당 스레드를 제거 114 | * 앱의 기본 스레드 또는 백그라운드 스레드에서 작업을 serial 또는 concurrent 방식으로 관리하는 개체 115 | * First In First Out 방식으로 동작한다. 따라서 queues에 추가하는 테스크는 항상 추가된 순서대로 시작된다. 116 | * 앱 실행시 시스템에서 기본적으로 2개의 Queue를 만들어 준다. 117 | 1. Main Queue: 메인 스레드(UI 스레드)에서 사용 되는 Serial Queue로 모든 UI 처리는 메인 스레드에서 처리를 해야한다. 118 | 2. Global Queue: 편의상 사용할수 있게 만들어 놓은 Concurrent Queue로 Global Queue는 처리 우선 순위를 위한 qos(Quality of service) 파라미터 제공하여 병렬적으로 동시에 처리를 하기때문에 작업 완료의 순서는 정할수 없지만 우선적으로 일을 처리하게 할수 있다. 119 | 120 | | | 차이점 | 121 | | -------------- | ------------------------------------------------------------ | 122 | | GCD | 작업이 복잡하지 않고 간단하게 처리하거나 특정 유형의 시스템 이벤트를 비동기적으로 처리할 때 적합하다. (예를 들면 타이머, 프로세스 등의 관련 이벤트)

오버헤드가 있지만 사용하기 매우 간편 | 123 | | OperationQueue | 비동기적으로 실행되어야 하는 작업을 객체 지향적인 방법으로 사용하는 데 적합하다.

KVO(key Value Observing)를 사용해 작업 진행 상황을 감시하는 방법이 필요할 때도 적합하다.
동시에 실행할 수 있는 Operation의 최대 수를 지정할 수 있다.

Operation을 일시 중지, 다시 시작 및 취소를 할 수 있습니다. | 124 | 125 | 126 | 127 | 128 | 129 | 참고 130 | 131 | https://zeddios.tistory.com/513 132 | -------------------------------------------------------------------------------- /nyokki/iOS/NotificationCenter 동작 방식과 활용 방안에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | NotificationCenter의 동작방식 2 | 3 | "특정 객체가 NotificationCenter에 등록된 event를 발생(post)시키면 NotificationCenter가 이 정보를 흩뿌려주고(broadCasting) 해당 event를 처리할 것이라고 등록된 observer들이 Event에 대한 행동을 취하는 것이 NotificationCenter 동작 방식이다." 4 | 5 | 6 | 7 | img 8 | 9 | NotificationCenter는 델리게이트 패턴과 함께 어플리케이션 내에서 객체가 서로 상호작용할 수 있는 방법 중 하나이다. 10 | 11 | 12 | 13 | 사용 절차는 다음과 같다. 14 | 15 | 이벤트가 발생할 객체에 NotificationCenter를 등록시킨다. 16 | 17 | Event에 대한 행동을 취해줄 객체에 observer를 등록시킨다. 18 | 19 | ## 활용방안 추가 할것 20 | -------------------------------------------------------------------------------- /nyokki/iOS/OS 앱을 만들고, User Interface를 구성하는 데 필수적인 프레임워크 이름은 무엇인가?.md: -------------------------------------------------------------------------------- 1 | ### Cocoa Touch 2 | 3 | 코코아 터치 프레임워크란 iOS 개발 환경을 구축하기 위한 최상위 프레임워크다. 4 | 5 | 참고코 코코아 프레임워크는 macOS 개발 환경을 위한 프레임 워크다. iOS는 터치기반의 디바이스라 코코아 터치 프레임워크라는 이름을 갖게 된 것 같다. 6 | 7 | ![img](https://media.vlpt.us/post-images/wan088/f559c1e0-bfef-11e9-9a74-2157d61cdf8e/1110.png) 8 | 9 | ## UIKit 10 | 11 | 사용자 인터페이스를 관리하고 이벤트를 처리하는게 주 목적인 프레임워크다. 12 | 13 | 14 | 15 | UIViewController, UIView, UIAlertController 등 앞에 UI가 붙는 클래스들을 사용하려면 반드시 UIKit을 상속해야 한다. 16 | 17 | UIKit은 Foundation을 상속받고 있기 때문에 UIKit을 import하는 것은 Foundation 프레임워크를 import한 결과를 가져온다. 18 | 19 | -------------------------------------------------------------------------------- /nyokki/iOS/README.md: -------------------------------------------------------------------------------- 1 | ## iOS 2 | 3 | - [x] Bounds 와 Frame 의 차이점을 설명하시오. 4 | 5 | - [x] 실제 디바이스가 없을 경우 개발 환경에서 할 수 있는 것과 없는 것을 설명하시오. 6 | 7 | - [ ] 앱의 콘텐츠나 데이터 자체를 저장/보관하는 특별한 객체를 무엇이라고 하는가? 8 | 9 | - [x] 앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체를 무엇이라고 하는가? 10 | 11 | - [x] App thinning에 대해서 설명하시오. 12 | 13 | 14 | 15 | - [x] 앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가? 16 | 17 | - [x] @Main에 대해서 설명하시오. 18 | 19 | - [x] 앱이 foreground에 있을 때와 background에 있을 때 어떤 제약사항이 있나요? 20 | 21 | - [x] 상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오. 22 | 23 | - [x] 앱이 In-Active 상태가 되는 시나리오를 설명하시오. 24 | 25 | - [x] scene delegate에 대해 설명하시오. 26 | 27 | - [x] UIApplication 객체의 컨트롤러 역할은 어디에 구현해야 하는가? 28 | 29 | - [x] App의 Not running, Inactive, Active, Background, Suspended에 대해 설명하시오. 30 | 31 | 32 | 33 | - [x] NSOperationQueue 와 GCD Queue 의 차이점을 설명하시오. 34 | 35 | - [x] GCD API 동작 방식과 필요성에 대해 설명하시오. 36 | 37 | - [x] Global DispatchQueue 의 Qos 에는 어떤 종류가 있는지, 각각 어떤 의미인지 설명하시오. 38 | 39 | - [x] iOS 앱을 만들고, User Interface를 구성하는 데 필수적인 프레임워크 이름은 무엇인가? 40 | 41 | - [x] Foundation Kit은 무엇이고 포함되어 있는 클래스들은 어떤 것이 있는지 설명하시오. 42 | 43 | - [x] Delegate란 무언인가 설명하고, retain 되는지 안되는지 그 이유를 함께 설명하시오. 44 | 45 | - [x] NotificationCenter 동작 방식과 활용 방안에 대해 설명하시오. 46 | 47 | - [x] UIKit 클래스들을 다룰 때 꼭 처리해야하는 애플리케이션 쓰레드 이름은 무엇인가? 48 | 49 | - [x] App Bundle의 구조와 역할에 대해 설명하시오. 50 | 51 | - [x] 모든 View Controller 객체의 상위 클래스는 무엇이고 그 역할은 무엇인가? 52 | 53 | - [x] 자신만의 Custom View를 만들려면 어떻게 해야하는지 설명하시오. 54 | 55 | - [x] View 객체에 대해 설명하시오. 56 | 57 | - [x] UIView 에서 Layer 객체는 무엇이고 어떤 역할을 담당하는지 설명하시오. 58 | 59 | - [x] UIWindow 객체의 역할은 무엇인가? 60 | 61 | - [x] UINavigationController 의 역할이 무엇인지 설명하시오. 62 | 63 | - [x] TableView를 동작 방식과 화면에 Cell을 출력하기 위해 최소한 구현해야 하는 DataSource 메서드를 설명하시오. 64 | 65 | - [x] 하나의 View Controller 코드에서 여러 TableView Controller 역할을 해야 할 경우 어떻게 구분해서 구현해야 하는지 설명하시오. 66 | 67 | - [x] setNeedsLayout와 setNeedsDisplay의 차이에 대해 설명하시오. 68 | 69 | 70 | 71 | - [x] NSCache와 딕셔너리로 캐시를 구성했을때의 차이를 설명하시오. 72 | 73 | - [x] URLSession에 대해서 설명하시오. 74 | 75 | - [x] prepareForReuse에 대해서 설명하시오. 76 | 77 | - [x] 다크모드를 지원하는 방법에 대해 설명하시오. 78 | 79 | -------------------------------------------------------------------------------- /nyokki/iOS/TableView를 동작 방식과 화면에 Cell을 출력하기 위해 최소한 구현해야 하는 DataSource 메서드를 설명하시오. .md: -------------------------------------------------------------------------------- 1 | ## TableView 2 | 3 | 테이블뷰 델리게이트 프로토콜에는 필수 구현 메소드는 없으며 테이블뷰 섹션 헤더, 푸터 구성, 셀 삭제 및 재정렬, 테이블 행에서 스와이프 기능 등의 기능을 관리한다. 4 | 5 | 테이블뷰 데이터소스 개체는 테이블뷰 데이터소스 프로토콜을 준수하며 다음 두 필수 구현 메소드가 있다. 6 | 7 | ```swift 8 | func tableView(UITableView, cellForRowAt: IndexPath) -> UITableViewCell 9 | 테이블뷰의 특정 위치에 삽입할 셀에 대한 데이터 소스를 요청합니다. 10 | func tableView(UITableView, numberOfRowsInSection: Int) -> Int 11 | 테이블뷰의 지정된 섹션에 있는 행 수를 반환하도록 데이터 소스에 지시합니다. 12 | ``` 13 | 14 | 15 | 16 | 동작방식 17 | 18 | 1. 테이블뷰의 dequeueReusableCell(withIdentifier:for:) 메소드를 호출해서 셀 객체를 검색한다. 19 | 2. 셀을 구성한다. 20 | 3. 셀을 테이블뷰로 반환한다. 21 | 22 | 테이블뷰는 테이블의 각 행에 대해 셀을 만들지 않는다. 23 | 24 | 25 | 26 | 의문점 27 | 28 | 갑자기 궁금해서 알아본 view, awakeFromNib 호출 타이밍 29 | 30 | **호출 순서** 31 | 32 | **1. loadView** 33 | 34 | **2. viewDidLoad** 35 | 36 | **3. awakeFromNib** 37 | 38 | **4. viewWillAppear** 39 | 40 | **5. ViewDidAppear** 41 | 42 | 43 | 44 | 출처 : https://memohg.tistory.com/58 45 | 46 | 47 | 48 | Prefetch(tableviewdelegate)와 관련된 참고 자료 49 | 50 | 10개의 셀을 미리 받아오고 serial로 작업한다 51 | 52 | concurrent로 했다가 cpu에 부담이 간다고 하여 수정 53 | 54 | https://jinnify.tistory.com/58 55 | 56 | 57 | 58 | -------------------------------------------------------------------------------- /nyokki/iOS/UIApplication 객체의 컨트롤러 역할은 어디에 구현해야 하는가?.md: -------------------------------------------------------------------------------- 1 | 참고 2 | 3 | https://jinshine.github.io/2018/05/28/iOS/%EC%95%B1%EC%9D%98%20%EC%83%9D%EB%AA%85%EC%A3%BC%EA%B8%B0(App%20Life%20Cycle)%EC%99%80%20%EC%95%B1%EC%9D%98%20%EA%B5%AC%EC%A1%B0(App%20Structure)/ 4 | 5 | https://zeddios.tistory.com/811 6 | 7 | -------------------------------------------------------------------------------- /nyokki/iOS/UIKit 클래스들을 다룰 때 꼭 처리해야하는 애플리케이션 쓰레드 이름은 무엇인가?.md: -------------------------------------------------------------------------------- 1 | UIApplication -> UIWindow -> UIViewController -> UIView -> UISubView 2 | 3 | 4 | 5 | UIKit과 관련된 클래스들은 Main Thread에서 다뤄져야한다. 6 | 7 | 그 이유는 다음과 같다. 8 | 9 | 1. UIKit은 Thread-Safe하지 않기 때문이다. 10 | UIKit은 nonatomic이며 ..거대한 프레임워크라 thread-safe하게 하는 것이 불가능하며..이를 가능하게 하려면 모두 atomic, NSLock 등의 처리를 해야하며 성능의 이슈를 발생..... 그렇구나 11 | 이를 한번에 처리하려면 UIKit이 MainThread에서 Synchronously하게 작동하면 해결된다. 12 | 2. ...... ?? 13 | 14 | 위 부분 참고 https://medium.com/remember/%EC%99%9C-ui-%EC%B2%98%EB%A6%AC%EB%A5%BC-main-thread%EC%97%90%EC%84%9C-%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98-5b2ba268f4eb 15 | 16 | 17 | 18 | View가 비동기적으로 작동하게 되면 제각각의 순서로 뷰가 로드, 업데이트되면서 어떤 스레드에서는 뷰를 삭제했는데 다른 스레드에서 삭제한 뷰를 사용하는 등의 문제가 발생할 수 있다. 19 | 20 | -------------------------------------------------------------------------------- /nyokki/iOS/UINavigationController 의 역할이 무엇인지 설명하시오. .md: -------------------------------------------------------------------------------- 1 | # UINavigationController 2 | 3 | ``class UINavigationController: UIViewController`` 4 | 5 | UINavigationController는 하나의 뷰 컨트롤러가 아닌 여러 개의 뷰 컨트롤러의 계층을 만들고 관리해 주는 컨테이너 뷰 컨트롤러이다. 6 | 7 | 이때 UINavigationBar는 UINavigationController에 의해 제어가 된다. 화면의 순서는 stack이 관리하지만, 사용자가 이 스택을 조종하기 위한 인터페이스로 UINavigationBar가 있다. 8 | 9 | ### 주요 역할 10 | 11 | + 컨텐츠 뷰 컨트롤러(테이블뷰, 콜렉션뷰 등등)를 보여주고, 네비게이션 바 혹은 툴바와 같은 사용자 정의 뷰 두 가지를 보여주는 역할 12 | + 사용자의 액션에 응답하며, 새로운 콘텐츠 뷰 컨트롤러를 스택에 쌓거나 스택에서 뷰 컨트롤러를 제가하는 역할 13 | + 스택에 있는 각 뷰 컨트롤러는 앱의 데이터를 보여주는 역할 14 | 15 | 16 | 17 | 네비게이션 뷰 컨트롤러는 컨텐츠 뷰컨트롤러를 관리하는데 스택구조로 담아 놓는다. 18 | 19 | 가장 아래쪽에 있는 것을 루트뷰 컨트롤러가 되며 가장 위에 있는 화면을 탑 뷰 컨트롤러가 된다. 20 | 21 | 네비게이션 컨트롤러에는 뷰 간의 화면 전환을 하는 다양한 메소드들이 있다. 22 | 23 | 24 | 25 | 네비게이션 바와 툴바에 관해서는 네비게이션 컨트롤러가 UINavigationBar 객체의 delegate가 될 수 있다. 26 | 27 | -------------------------------------------------------------------------------- /nyokki/iOS/UIView 에서 Layer 객체는 무엇이고 어떤 역할을 담당하는지 설명하시오..md: -------------------------------------------------------------------------------- 1 | https://developer.apple.com/documentation/uikit/uiview/1622626-layerclass 2 | 3 | ## Layer 4 | 5 | 렌더링(렌더링이란 컴퓨터 프로그램을 사용하여 하나의 영상, 뷰를 만드는 것)에 사용되는 뷰의 코어 애니메이션 레이어이다. 6 | 7 | 8 | 9 | ### CALayer 10 | 11 | CALayer는 Core Animation API가 제공하는 요소중 하나로 UIView가 가지고 있는 속성이다 12 | 13 | UIView의 역할 ( 1. 화면 표시, 2. 터치 이벤트, 3. subview) 중 화면표시하는 작업을 직접 처리하지 않고 Core Animation에 위임하여 처리한다. 14 | 15 | 에니메이션, View 형태 변환등을 처리할 수 있다 16 | 17 | ![img](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fb442b25d-d7f6-4575-ac1d-6b15cc0b6381%2F996A474D5AD598E32A.png?table=block&id=a99bcab4-9df7-4611-b4fd-e389cd09872e&spaceId=e97e973e-163f-4521-9046-b2b23e28de41&width=840&userId=05b4c7b1-db96-4d31-9334-fe128d7f702a&cache=v2) 18 | 19 | -------------------------------------------------------------------------------- /nyokki/iOS/UIWindow 객체의 역할은 무엇인가?.md: -------------------------------------------------------------------------------- 1 | # UIWindow 2 | 3 | post-thumbnail 4 | 5 | UIWindow 클래스는 앱 UI의 배경(액자)에 해당한다. 윈도우는 UI를 표시하고 상호작용을 할 수 있는 영역을 제공한다. 6 | 7 | + UIWindow는 UIView 클래스의 서브클래스이다. 8 | + 사용자는 UIWindow 객체를 직접 보거나 상호작용을 할 수 없다. 9 | + 프로그램으로 생성할 수 있지만, 일반적인 경우 사용자 인터페이스를 디자인할 때 인터페이스 빌더에 의해 자동으로 생성된다. 10 | + Application은 하나의 window와 여러 개의 view들로 이루어져 있다. 각 Window는 앱의 다른 View와 독립적이다. 11 | 12 | # window란 13 | 14 | window란 UIWindow의 인스턴스이며 여러 개의 보이지 않는 view들 까지도 포함하는 container 역할을 하는데 최상위 container이다. 15 | 16 | Window는 보이지 않으며 앱 종료시에만 사라지게 된다. 17 | 18 | ### 역할 19 | 20 | + 앱의 시각적 콘텐츠를 담는다. 21 | 22 | + 뷰들과 다른 애플리케이션 객체들에게 터치 이벤트를 전달하는 중요한 역할을 한다. 23 | 24 | + 뷰 컨트롤러들과 협력한다. 25 | 26 | 윈도우는 이벤트를 처리하고 앱 동작에 기본적인 많은 작업을 수행하기 위에 뷰컨트롤러와 함께 작동한다. UIKit은 대부분 window 관련 상호 작용을 처리하고 많은 앱 동작을 구현하는데 필요한 다른 객체와 함께 작동한다. 27 | 28 | 29 | 30 | ### 참고 31 | 32 | https://developer.apple.com/documentation/uikit/uiwindow 33 | 34 | https://zeddios.tistory.com/283 35 | 36 | -------------------------------------------------------------------------------- /nyokki/iOS/URLSession에 대해서 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### 사전 지식 2 | 3 | 참고 : https://jeong-pro.tistory.com/80 4 | 5 | 쿠키와 세션 6 | 7 | 쿠키와 세션이 있는 이유는 무엇일까? 8 | 9 | HTTP는 클라이언트가 요청(request)을 서버에 보내고, 서버는 클라이언트에게 적절한 응답(response)을 주고 연결을 끊는 특성이 있다. 10 | 11 | 이 가장 큰 장점은 서버 리소스 낭비가 줄어든다는 것이지만 12 | 13 | 통신할 때마다 새로 커넥션을 만들기 때문에 클라이언트에게는 상태를 유지하기 위해 통신할 때마다 어떤 절차를 거쳐야한다는 단점이 생긴다. 14 | 15 | 16 | 17 | ### 쿠키 18 | 19 | 쿠키는 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일이다. 20 | 21 | 쿠키에는 이름, 값, 만료 날짜/시간(쿠기 저장기간), 경로 정보 등이 들어있다. 22 | 23 | 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 요청할 때 참조된다. 24 | 25 | 쿠키는 서버측에서 만료 날짜/시간을 지정하여 정해진 시간 동안 데이터를 유지할 수 있다.(일정 시간 동안 로그인 상태가 유지된다.) 26 | 27 | 28 | 29 | 세션쿠키(Session Cookie)와 지속쿠키(Persistent Cookie) 30 | 31 | 만료 날짜/시간을 지정하지 않으면, '메모리에 있는 동안' 계속 유효하다고 판단하도록 세션 쿠키에 저장되고, 만료 날짜/시간을 지정하면 프로세스가 종료되더라도(메모리에서 사라지더라도) 특정 만료날짜/시간까지 유효하므로 지속 쿠키에 저장된다. 32 | 33 | 세션쿠키는 브라우저 메모리에 저장되므로 브라우저가 종료되면 쿠키는 사라지게 되고 34 | 35 | 지속쿠키는 파일로 저장되므로 브라우저가 종료되어도 쿠키는 남아있게 된다. 36 | 37 | 38 | 39 | ### 세션 40 | 41 | 서버에 클라이언트의 상태 정보를 저장하는 기술로 논리적인 연결을 세션이라고 한다. 42 | 43 | 웹 서버에 클라이언트에 대한 정보를 저장하고 클라이언트에게는 클라이언트를 구분할 수 있는 ID를 부여하는데 이것을 세션ID라고 한다. 44 | 45 | 세션 프로세스 46 | 47 | + 클라이언트가 서버에 요청했을 때, 필요에 따라 세션에 클라이언트에 대한 데이터를 저장하고 세션 아이디 응답을 통해 발급해준다. 48 | + 클라이언트는 발급받은 세션 아이디를 쿠키로 저장한다. 49 | + 클라이언트는 다시 서버에 요청할 때, 세션 아이디를 서버에 전달하여 상태 정보를 서버가 활용할 수 있도록 해준다. 50 | 51 | 52 | 53 | 결과적으로 세션을 통해 클라이언트의 정보는 서버에 두고 세션 아이디를 이용해서 인증받고 정보를 이용하는 방식 54 | 55 | + 세션 사용 사례 56 | + 로그인 정보 유지 57 | 58 | 59 | 60 | ## HTTP 이해하기(+HTTPS) 61 | 62 | 1. 하이퍼 텍스트 63 | 64 | 하이퍼 링크를 통해 한 문서에서 다른 문서로 즉시 접근할 수 있는 비선형적 텍스트. 인터넷과 결합하여 HTML의 주된 구성요소가 되었다. 기존의 문서가 순차적이면서 서열형 구조라면, 하이퍼텍스트는 링크에 따라 그 차례가 바뀌는 임의적이면서 나열형인 구조를 가진다. 65 | 66 | 2. HTML 67 | 68 | 인터넷 서비스의 하나인 월드 와이드 웹을 통해 볼 수 있는 문서를 만들 때 사용하는 웹 언어의 한 종류이다. 특히 하이퍼텍스트를 작성하기 위해 개발되었으며, 인터넷에서 웹을 통해 접근되는 대부분의 웹 페이지들은 HTML로 작성된다. 69 | 70 | 3. 프로토콜 71 | 72 | 정보기기 사이(컴퓨터와 컴퓨터, 컴퓨터와 단말기 사이 등)에서 정보교환이 필요한 경우 이를 원활하게 하기 위하여 정한 여러 가지 통신 규칙과 방법에 대한 약속 즉, 통신의 규칙, 규약을 의미한다. 73 | 74 | 4. URL 75 | 76 | Uniform Resource Locator, 네트워크 상에서 자원이 어디에 있는지를 알려주기 위한 규약, URL은 웹 사이트 주소 뿐만 아니라 컴퓨터 네트워크 상의 자원을 모두 나타낼 수 있다. 그 주소에 접속하려면 해당 URL에 맞는 프로토콜을 알아야 하고, 그와 동일한 프로토콜로 접속해야 한다. 77 | 78 | ---> &q, &lat, &lot 이런건가..? 79 | 80 | ### HTTP 개요 81 | 82 | HTTP는 HyperText Transfer Protocol의 약자로, 월드와이드웹 상에서 정보를 주고 받을 수 있는 프로토콜이다. 주로 HTML을 주고받는 데 쓰이며, 하이퍼텍스트 문서를 전달하기 위한 규약이라고 할 수 있다. 83 | 84 | 85 | 86 | HTTP는 클라이언트와 서버 사이에 이루어지는 **요청/응답(request/response) 프로토콜**이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로 부터 웹페이지(HTML)나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 나타나는 것이다. 87 | 88 | http://, https://로 시작하는 URL이 HTTP 프로토콜로 통신하겠다는 선언이다. 89 | 90 | 91 | 92 | ### HTTP의 요청(request)와 응답(response) 93 | 94 | HTTP는 클라이언트-서버 사이에 이루어지는 요청/응답 프로토콜이라고 했다. 그렇다면 HTTP는 어떻게 요청하고 응답할까? HTTP는 요청과 응답을 위해 클라이언트-서버 간의 요청 메세지와 응답 메세지를 주고 받는다. 메세지는 규칙과 구조가 정해져있다. 95 | 96 | http2 97 | 98 | 위키피디아의 예시인 요청 메세지이다. 99 | 100 | ```html 101 | GET /restapi/v1.0 HTTP/1.1 102 | Accept: application/json 103 | Authorization: Bearer UExBMDFUMDRQV1MwMnzpdvtYYNWMSJ7CL8h0zM6q6a9ntw 104 | ``` 105 | 106 | 첫 줄의 요청 라인은 GET/restapi/v1.0 HTTP/1.1은 요청방식/요청URI/HTTP버전 으로 구성되어 있다. GET은 요청 메서드이다. 이 메서드에 따라 서버에 요청하는 성격이 달라진다. 107 | 108 | 다음은 응답 메세지이다. 109 | 110 | ```html 111 | HTTP/1.1 200 OK // 상태 라인 112 | Date: Mon, 23 May 2005 22:38:34 GMT // 헤더 시작 113 | Content-Type: text/html; charset=UTF-8 114 | Content-Encoding: UTF-8 115 | Content-Length: 138 116 | Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT 117 | Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) 118 | ETag: "3f80f-1b6-3e1cb03b" 119 | Accept-Ranges: bytes 120 | Connection: close // 헤더 끝 121 | // 공백 122 | // 바디 시작 123 | 124 | An Example Page 125 | 126 | 127 | Hello World, this is a very simple HTML document. 128 | 129 | // 바디 끝 130 | ``` 131 | 132 | 첫 줄을 살펴보면, HTTP/1.1 200 OK 는 HTTP버전/ 상태 코드/ 응답이유 로 구성되어 있으며, 200은 상태 코드이다. 133 | 134 | 135 | 136 | ### HTTP 요청 메서드 137 | 138 | - **GET**: 특정한 리소스를 가져오도록 요청. 데이터를 가져올 때만 사용해야함 139 | - **POST**: 서버로 데이터를 전송(추가, 작성 등). 요청 본문의 유형은 Content-Type 헤더로 나타냄 140 | - **PUT**: 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체 (서버의 데이터를 갱신, 작성 등) 141 | - **DELETE**: 지정한 리소스를 삭제 (서버의 데이터를 삭제) 142 | - **HEAD**: 서버 리소스의 헤더를 요청 143 | - **OPTIONS**: 리소스가 지원하고 있는(서버에서 사용하는) 메서드를 알려줌 144 | - **PATCH**: 리소스의 부분적인 수정 145 | - **CONNECT**: 요청한 리소스에 대해 양방향 연결을 시작. 터널을 열기 위해서 사용될 수 있음 146 | 147 | #### CRUD 148 | 149 | CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말이다. 위의 HTTP 메서드에서는 POST, GET, PUT, DELETE가 각각 CRUD 기능 역할을 한다.. 150 | 151 | - Create: POST/PUT 152 | - Read: GET 153 | - Update: PUT 154 | - Delete: DELETE 155 | 156 | ### 상태 코드 157 | 158 | 클라이언트가 서버에 요청 메세지를 보내고, 서버는 클라이언트에게 응답 메세지를 보내는데, 이때 응답 내용에 따른 **상태 코드**를 보내게 된다. 상태 코드는 그 종류가 매우 많아서 포스팅에서 다루기보다는 링크를 올려두는 것이 좋을 것 같군요. 159 | 160 | 모든 HTTP 응답 코드는 5개의 클래스(분류)로 구분됩니다. 상태 코드의 첫 번째 숫자는 응답의 클래스를 정의합니다. 마지막 두 자리는 클래스나 분류 역할을 하지 않습니다. 첫자리에 대한 5가지 값들은 다음과 같습니다. 161 | 162 | - **1xx (정보)**: 요청을 받았으며 프로세스를 계속한다 163 | - **2xx (성공)**: 요청을 성공적으로 받았으며 인식했고 수용하였다 164 | - **3xx (리다이렉션)**: 요청 완료를 위해 추가 작업 조치가 필요하다 165 | - **4xx (클라이언트 오류)**: 요청의 문법이 잘못되었거나 요청을 처리할 수 없다 166 | - **5xx (서버 오류)**: 서버가 명백히 유효한 요청에 대해 충족을 실패했다 167 | 168 | 169 | 170 | ### Content-Type이란? 171 | 172 | https://juyoung-1008.tistory.com/4 173 | 174 | 175 | 176 | 출처 177 | 178 | https://odong-tree.github.io/cs/2021/01/18/http/ 179 | 180 | 참고 181 | 182 | https://goddaehee.tistory.com/169 183 | 184 | Restful API 185 | 186 | https://wayhome25.github.io/etc/2017/11/26/restful-api-designing-guidelines/ 187 | 188 | 189 | 190 | 191 | 192 | ## URLSession이란? 193 | 194 | URLSession은 iOS에서 제공하는 HTTP를 이용한 네트워킹을 통해 데이터를 주고받을 수 있게 도와주는 API를 제공해주는 클래스이다. URLSession은 Thread-Safety하기 때문에 어떤 스레드에서든 자유롭게 Session과 Task를 생성할 수 있다. 195 | 196 | 197 | 198 | URLSession은 비동기 처리 방식으로 작동하도록 애플이 설계를 해놓았다. 199 | 200 | 201 | 202 | URLSession은 URLSessionConfiguration을 통해 생성할 수 있다. 이렇게 생성된 URLSession을 통해 한 개 이상의 URLSessionTask를 생성할 수 있으며, 이 URLSessionTask를 통해 실제로 서버와 통신을 할 수 있다. 203 | 204 | 205 | 206 | #### URLSessionConfiguration 207 | 208 | + Default: 기본적인 네트워킹 정책을 사용한다.(?) 209 | + Ephemeral: 쿠키와 캐시를 저장하지 않을 때 사용한다. (어떤 경우가 있을까?) 210 | + Background: 앱이 background에 있을 때 컨텐츠를 다운로드 혹은 업로드 할 때 사용한다. 211 | 212 | 213 | 214 | #### URLSessionTask 215 | 216 | - URLSessionDataTask : 데이터를 받는 작업 수행 시 사용한다. background 세션에 대한 지원을 하지 않는다. 217 | - URLSessionUploadTask : 데이터 업로드 시 사용 218 | - URLSessionDownloadTask : 데이터 다운로드 시 사용 219 | 220 | 221 | 222 | 223 | 224 | -------------------------------------------------------------------------------- /nyokki/iOS/View 객체에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | ## UIView 2 | 3 | 뷰 객체는 사용자에게 컨텐츠를 보여주고 인터렉션에 대해서 다룬다. 4 | 5 | 뷰 객체는 응용 프로그램이 사용자와 상호작용하는 주요 방법이기 때문에 여러 책임(?)들이 있다. 6 | 7 | 1. 드로잉(사각형 그리기, 배경 그리기) 및 애니메이션 8 | 2. 레이아웃 및 서브뷰 관리 9 | 서브뷰의 크기와 위치 조정 가능(frame) 10 | 오토레이아웃을 사용하여 뷰 계층 구조의 변경에 대한 응답으로 뷰의 크기를 조정하고 위치를 변경하는 것을 정의 11 | 3. 이벤트 처리 12 | 뷰는 UIResponder의 하위 클래스이며 터치 및 기타 이벤트에 대한 응답할 수 있다. 13 | 제스처 처리에 대한 gestureRecognizer을 설치할 수 있다. 14 | 15 | 모든 처리는 메인 쓰레딩에서 처리한다. 16 | 17 | 18 | 19 | 공식 문서 : https://developer.apple.com/documentation/uikit/uiview 20 | 21 | 22 | 23 | 참고 24 | 25 | https://haningya.tistory.com/217 26 | 27 | view의 형성 과정 : https://velog.io/@yongchul/iOSView%EC%9D%98-%ED%98%95%EC%84%B1%EA%B3%BC%EC%A0%95 28 | 29 | rootViewController를 바꿔야하는 상황과 하는 방법 :https://mtsparrow.blogspot.com/2018/08/rootviewcontroller.html 30 | 31 | window, view, ViewController : https://velog.io/@ellyheetov/Window-View-%EA%B7%B8%EB%A6%AC%EA%B3%A0-View-Controller -------------------------------------------------------------------------------- /nyokki/iOS/app이 foreground와 background에 있을 때 제약.md: -------------------------------------------------------------------------------- 1 | # iOS Background Mode 2 | 3 | https://medium.com/cashwalk/ios-background-mode-9bf921f1c55b 4 | 5 | img 6 | 7 | ### 1. Not Running 8 | 9 | - App을 실행하지 않은 상태로, App이 실행되기 전 상태 또는 실행되었지만 System에 의해 종료된 상태 10 | 11 | ### 2. Foreground 12 | 13 | - App이 실행되어 사용자에게 보여지고 있는 상태 14 | - 오직 하나의 App만 Foreground 상태를 가지고 inActive와 Active의 두 가지 상태로 나뉘어짐 15 | - InActive: Foregound 상태에서 전화가 오거나, 잠금상태, 멀티태스킹(Split?) 스크린에서는 InActive 상태 16 | - Active: inActive가 아닌 상태 17 | 18 | ### 3. Background 19 | 20 | - Foregound 상태에서 HomeScreen으로 이동한 상태 21 | 22 | - Background 상태로 전환되기 전에 호출된 Task가 끝나지 않은 경우 Background 상태에서도 여전히 실행됨 23 | - Background 상태로 전환된 후 호출된 Task는 App이 Foreground 상태로 전환된 후에 실행됨 24 | 25 | ### 4. Suspend 26 | 27 | - App이 Background 상태로 전환된 후 더 이상 작업을 수행하지 않으면 System에서 App을 Suspend 상태로 변경 28 | - App은 여전히 메모리에 존재하며 Suspend 상태가 될 당시의 상태를 저장하고 있지만, CPU나 배터리를 소모하지 않음 29 | - Suspend 상태의 App은 Foreground 상태의 App을 위해 메모리 부족 등의 이유로 System에 의해 언제든지 종료. 이후 App을 실행하면 이전 상태의 화면은 나오지 않고 App이 재시작됩니다. 30 | 31 | 32 | 33 | ##### Background 제약사항 34 | 35 | - 사용자 이벤트를 받기 어려움 36 | - 공유 시스템 리소스 해제, 이미지 객체 참조 해제 등 메모리 제한 37 | - 특정 유형의 앱만 백그라운드에서 실행 가능함 38 | 39 | - 가능한 작은 메모리 공간을 사용해야 함 (시스템 리소스 해제, 메모리에서 해제 후 데이터를 디스크에 작성) 40 | - priority에 의해 백그라운드 태스크는 포그라운드 태스크보다 더 낮은 자원 할당 41 | - 포 그라운드는 메모리 및 기타 시스템 리소스보다 우선 순위를 가지며 시스템은 이러한 리소스를 사용할 수 있도록 필요에 따라 백그라운드 앱을 종료 42 | 43 | 44 | 45 | 46 | 47 | ##### 참고 48 | 49 | https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/about_the_background_execution_sequence 50 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds.xcodeproj/project.xcworkspace/contents.xcworkspacedata: -------------------------------------------------------------------------------- 1 | 2 | 4 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds.xcodeproj/project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | IDEDidComputeMac32BitWarning 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/AppDelegate.swift: -------------------------------------------------------------------------------- 1 | // 2 | // AppDelegate.swift 3 | // frame & bounds 4 | // 5 | // Created by Sh Hong on 2021/06/05. 6 | // 7 | 8 | import UIKit 9 | 10 | @main 11 | class AppDelegate: UIResponder, UIApplicationDelegate { 12 | 13 | 14 | 15 | func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { 16 | // Override point for customization after application launch. 17 | return true 18 | } 19 | 20 | // MARK: UISceneSession Lifecycle 21 | 22 | func application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration { 23 | // Called when a new scene session is being created. 24 | // Use this method to select a configuration to create the new scene with. 25 | return UISceneConfiguration(name: "Default Configuration", sessionRole: connectingSceneSession.role) 26 | } 27 | 28 | func application(_ application: UIApplication, didDiscardSceneSessions sceneSessions: Set) { 29 | // Called when the user discards a scene session. 30 | // If any sessions were discarded while the application was not running, this will be called shortly after application:didFinishLaunchingWithOptions. 31 | // Use this method to release any resources that were specific to the discarded scenes, as they will not return. 32 | } 33 | 34 | 35 | } 36 | 37 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/Assets.xcassets/AccentColor.colorset/Contents.json: -------------------------------------------------------------------------------- 1 | { 2 | "colors" : [ 3 | { 4 | "idiom" : "universal" 5 | } 6 | ], 7 | "info" : { 8 | "author" : "xcode", 9 | "version" : 1 10 | } 11 | } 12 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/Assets.xcassets/AppIcon.appiconset/Contents.json: -------------------------------------------------------------------------------- 1 | { 2 | "images" : [ 3 | { 4 | "idiom" : "iphone", 5 | "scale" : "2x", 6 | "size" : "20x20" 7 | }, 8 | { 9 | "idiom" : "iphone", 10 | "scale" : "3x", 11 | "size" : "20x20" 12 | }, 13 | { 14 | "idiom" : "iphone", 15 | "scale" : "2x", 16 | "size" : "29x29" 17 | }, 18 | { 19 | "idiom" : "iphone", 20 | "scale" : "3x", 21 | "size" : "29x29" 22 | }, 23 | { 24 | "idiom" : "iphone", 25 | "scale" : "2x", 26 | "size" : "40x40" 27 | }, 28 | { 29 | "idiom" : "iphone", 30 | "scale" : "3x", 31 | "size" : "40x40" 32 | }, 33 | { 34 | "idiom" : "iphone", 35 | "scale" : "2x", 36 | "size" : "60x60" 37 | }, 38 | { 39 | "idiom" : "iphone", 40 | "scale" : "3x", 41 | "size" : "60x60" 42 | }, 43 | { 44 | "idiom" : "ipad", 45 | "scale" : "1x", 46 | "size" : "20x20" 47 | }, 48 | { 49 | "idiom" : "ipad", 50 | "scale" : "2x", 51 | "size" : "20x20" 52 | }, 53 | { 54 | "idiom" : "ipad", 55 | "scale" : "1x", 56 | "size" : "29x29" 57 | }, 58 | { 59 | "idiom" : "ipad", 60 | "scale" : "2x", 61 | "size" : "29x29" 62 | }, 63 | { 64 | "idiom" : "ipad", 65 | "scale" : "1x", 66 | "size" : "40x40" 67 | }, 68 | { 69 | "idiom" : "ipad", 70 | "scale" : "2x", 71 | "size" : "40x40" 72 | }, 73 | { 74 | "idiom" : "ipad", 75 | "scale" : "1x", 76 | "size" : "76x76" 77 | }, 78 | { 79 | "idiom" : "ipad", 80 | "scale" : "2x", 81 | "size" : "76x76" 82 | }, 83 | { 84 | "idiom" : "ipad", 85 | "scale" : "2x", 86 | "size" : "83.5x83.5" 87 | }, 88 | { 89 | "idiom" : "ios-marketing", 90 | "scale" : "1x", 91 | "size" : "1024x1024" 92 | } 93 | ], 94 | "info" : { 95 | "author" : "xcode", 96 | "version" : 1 97 | } 98 | } 99 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/Assets.xcassets/Contents.json: -------------------------------------------------------------------------------- 1 | { 2 | "info" : { 3 | "author" : "xcode", 4 | "version" : 1 5 | } 6 | } 7 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/Base.lproj/LaunchScreen.storyboard: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/Base.lproj/Main.storyboard: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/Info.plist: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | CFBundleDevelopmentRegion 6 | $(DEVELOPMENT_LANGUAGE) 7 | CFBundleExecutable 8 | $(EXECUTABLE_NAME) 9 | CFBundleIdentifier 10 | $(PRODUCT_BUNDLE_IDENTIFIER) 11 | CFBundleInfoDictionaryVersion 12 | 6.0 13 | CFBundleName 14 | $(PRODUCT_NAME) 15 | CFBundlePackageType 16 | $(PRODUCT_BUNDLE_PACKAGE_TYPE) 17 | CFBundleShortVersionString 18 | 1.0 19 | CFBundleVersion 20 | 1 21 | LSRequiresIPhoneOS 22 | 23 | UIApplicationSceneManifest 24 | 25 | UIApplicationSupportsMultipleScenes 26 | 27 | UISceneConfigurations 28 | 29 | UIWindowSceneSessionRoleApplication 30 | 31 | 32 | UISceneConfigurationName 33 | Default Configuration 34 | UISceneDelegateClassName 35 | $(PRODUCT_MODULE_NAME).SceneDelegate 36 | UISceneStoryboardFile 37 | Main 38 | 39 | 40 | 41 | 42 | UIApplicationSupportsIndirectInputEvents 43 | 44 | UILaunchStoryboardName 45 | LaunchScreen 46 | UIMainStoryboardFile 47 | Main 48 | UIRequiredDeviceCapabilities 49 | 50 | armv7 51 | 52 | UISupportedInterfaceOrientations 53 | 54 | UIInterfaceOrientationPortrait 55 | UIInterfaceOrientationLandscapeLeft 56 | UIInterfaceOrientationLandscapeRight 57 | 58 | UISupportedInterfaceOrientations~ipad 59 | 60 | UIInterfaceOrientationPortrait 61 | UIInterfaceOrientationPortraitUpsideDown 62 | UIInterfaceOrientationLandscapeLeft 63 | UIInterfaceOrientationLandscapeRight 64 | 65 | 66 | 67 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/SceneDelegate.swift: -------------------------------------------------------------------------------- 1 | // 2 | // SceneDelegate.swift 3 | // frame & bounds 4 | // 5 | // Created by Sh Hong on 2021/06/05. 6 | // 7 | 8 | import UIKit 9 | 10 | class SceneDelegate: UIResponder, UIWindowSceneDelegate { 11 | 12 | var window: UIWindow? 13 | 14 | 15 | func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { 16 | // Use this method to optionally configure and attach the UIWindow `window` to the provided UIWindowScene `scene`. 17 | // If using a storyboard, the `window` property will automatically be initialized and attached to the scene. 18 | // This delegate does not imply the connecting scene or session are new (see `application:configurationForConnectingSceneSession` instead). 19 | guard let _ = (scene as? UIWindowScene) else { return } 20 | } 21 | 22 | func sceneDidDisconnect(_ scene: UIScene) { 23 | // Called as the scene is being released by the system. 24 | // This occurs shortly after the scene enters the background, or when its session is discarded. 25 | // Release any resources associated with this scene that can be re-created the next time the scene connects. 26 | // The scene may re-connect later, as its session was not necessarily discarded (see `application:didDiscardSceneSessions` instead). 27 | } 28 | 29 | func sceneDidBecomeActive(_ scene: UIScene) { 30 | // Called when the scene has moved from an inactive state to an active state. 31 | // Use this method to restart any tasks that were paused (or not yet started) when the scene was inactive. 32 | } 33 | 34 | func sceneWillResignActive(_ scene: UIScene) { 35 | // Called when the scene will move from an active state to an inactive state. 36 | // This may occur due to temporary interruptions (ex. an incoming phone call). 37 | } 38 | 39 | func sceneWillEnterForeground(_ scene: UIScene) { 40 | // Called as the scene transitions from the background to the foreground. 41 | // Use this method to undo the changes made on entering the background. 42 | } 43 | 44 | func sceneDidEnterBackground(_ scene: UIScene) { 45 | // Called as the scene transitions from the foreground to the background. 46 | // Use this method to save data, release shared resources, and store enough scene-specific state information 47 | // to restore the scene back to its current state. 48 | } 49 | 50 | 51 | } 52 | 53 | -------------------------------------------------------------------------------- /nyokki/iOS/frame & bounds/frame & bounds/ViewController.swift: -------------------------------------------------------------------------------- 1 | // 2 | // ViewController.swift 3 | // frame & bounds 4 | // 5 | // Created by Sh Hong on 2021/06/05. 6 | // 7 | 8 | import UIKit 9 | 10 | class ViewController: UIViewController { 11 | 12 | var yelloewView = UIView() 13 | var greenView = UIView() 14 | var blackView = UIView() 15 | 16 | override func viewDidLoad() { 17 | super.viewDidLoad() 18 | 19 | view.backgroundColor = .red 20 | 21 | yelloewView.backgroundColor = .yellow 22 | greenView.backgroundColor = .green 23 | blackView.backgroundColor = .black 24 | 25 | yelloewView.frame = CGRect(x: 50, y: 50, width: 200, height: 200) 26 | greenView.frame = CGRect(x: 100, y: 100, width: 100, height: 100) 27 | blackView.frame = CGRect(x: 200, y: 200, width: 50, height: 50) 28 | 29 | UIViewPropertyAnimator(duration: 3, curve: .easeOut) { 30 | self.yelloewView.bounds.origin = CGPoint(x: -50, y: -50) // 31 | // self.greenView.bounds.origin = CGPoint(x: -100, y: -100) //yellowView에 영향을 받음 32 | // self.view.bounds.origin = CGPoint(x: -80, y: -80) 33 | // self.yelloewView.frame.size = CGSize(width: 150, height: 250) 34 | // self.greenView.bounds.size = CGSize(width: 100, height: 200) 35 | } .startAnimation() 36 | 37 | 38 | // view.addSubview(superView) 39 | // view.addSubview(subView) 40 | 41 | view.addSubview(yelloewView) 42 | yelloewView.addSubview(greenView) 43 | view.addSubview(blackView) 44 | 45 | print("yelloewView bound의 x, y 좌표 : \(yelloewView.bounds.origin.x), \(yelloewView.bounds.origin.y)") 46 | print("greenView bound의 x, y 좌표 : \(greenView.bounds.origin.x), \(greenView.bounds.origin.y)") 47 | 48 | } 49 | 50 | 51 | 52 | } 53 | 54 | -------------------------------------------------------------------------------- /nyokki/iOS/prepareForReuse에 대해서 설명하시오..md: -------------------------------------------------------------------------------- 1 | ### prepareForReuse가 존재하는 이유 2 | 3 | 테이블뷰에서 성능을 위해 테이블뷰 셀을 reuse한다. 4 | 5 | 사라지는 셀을 큐로 들어가고 하단 셀을 보여주기 위해 dequeue하여 reuse하는데 6 | 7 | 이때 재사용되는 셀의 경우 초기화를 하거나 수정을 하지 않으면 재사용되기 전의 셀의 상태나 레이아웃 등이 그대로 남아있다. 8 | 9 | 그래서 이를 수정하기 위한 메소드이다. 10 | 11 | ```swift 12 | override func prepareForReuse() { 13 | super.prepareForReuse() 14 | //이 내부 안에 해당 셀 클래스 파일에 연결된 아울렛 변수들의 값을 모두 nil 및 초기값으로 초기화를 한다. 15 | //이때 text가 있다면 이를 초기화하는 것뿐만 아니라 constraints등도 cellForRowAt에서 재설정해야 한다. 16 | } 17 | ``` 18 | 19 | 이때 필요하다면 setNeedsLayout() 혹은 layoutIfNeeded() 메소드를 호출하여 보완하는 것이 좋다. 20 | 21 | 22 | 23 | 참고 24 | 25 | https://g-y-e-o-m.tistory.com/134 26 | 27 | -------------------------------------------------------------------------------- /nyokki/iOS/scene delegate에 대해 설명하시오..md: -------------------------------------------------------------------------------- 1 | # SceneDelegate 2 | 3 | - ### 사전 지식 4 | 5 | > app Switcher란 홈버튼 더블클릭, 인디케이터바를 위로 스와이프 해서 나오는 화면을 말합니다. 6 | 7 | SceneDelegate는 Xcode 11부터 iOS 앱 프로젝트 템플릿으로 자동 추가가 되었는데, iOS13 이상에서는 씬 델리게이트가 앱 델리게이트의 일부 역할을 담당하게 되었고 window 대신에 scene이라는 개념으로 대체가 되었다. 8 | 9 | scene에는 UI의 한 인스턴스를 표시하는데 필요한 windows와 view controller가 있다. 10 | 11 | ## scene이 생김으로서 장점? 12 | 13 | 기존에는 앱 하나(iPad)에 윈도우 하나를 가지고 있었지만 이제 앱에서 여러 개의 scene이 있을 수 있게 되었으며 이를 통해 멀티 윈도우 앱을 빌드할 수 있게 되었다. 14 | 15 | 예전에는 한 앱을 동시에 키는 것이 불가능 하였다. (Split View 와 다른가?? -> 관련 [자료1](https://eunjin3786.tistory.com/162), [자료2](https://developer.apple.com/documentation/uikit/app_and_environment/scenes/supporting_multiple_windows_on_ipad)) 16 | 17 | ## SceneDelegate의 역할 18 | 19 | 앱의 라이프 사이클을 관리하는 역할을 하게 되었다. 20 | 21 | img 22 | 23 | ### Scene-Based Life-Cycle 24 | 25 | + Unattaced State 26 | + 유저나 시스템이 앱의 새로운 씬을 요청하면 UIKit은 그 씬을 만들고 그것을 unattaced state로 둔다. 27 | + 유저가 요청한 씬은 foreground로 이동한다. 28 | + 시스템이 요청한 씬은 background로 이동해서 그 이벤트를 처리한다. (위치 처리 과정 대한 작업은 백그라운드에서 씬을 시작해도 된다.) 29 | 30 | + Foreground 31 | + Inactive: 앱이 실행 중인 상태이나 이벤트를 받지는 않음. Active 상태로 넘어가기 전에 앱은 반드시 거치는 상태. 알림 같은 특정 알림창이 화면을 덮어서 앱이 event를 받지 못하는 상태 32 | + Active: 앱이 실행 중이고 이벤트를 받을 수 있는 상태. Foreground 앱의 일반적인 상태 33 | + Background 34 | + 앱 사용 중에 다른 앱을 실행하거나 홈 화면으로 나갔을 때 상태. 백그라운드에서 동작하는 코드를 추가하면 suspended 상태로 넘어가지 않고 백그라운드 상태를 유지. 처음부터 background 상태로 실행되는 앱은 inactive 대신 background 상태로 진입. 음악을 실행하고 홈 화면으로 나가도 음악이 나오는 상태 35 | + Suspended 36 | + 앱이 background 상태에서 추가적인 작업을 하지 않으면 곧바로 suspended 상태로 진입. 앱을 다시 실행할 경우 빠른 실행을 위해 메모리에는 올라가 있음. 메모리가 부족한 상황이 되면 iOS는 suspended 상태에 있는 앱들을 메모리에서 해제 37 | 38 | 39 | 40 | **scene (_ : willConnectTo : options :)** 41 | 42 | 가장 중요한 기능은 입니다. scene이 앱에 추가될 때 호출됩니다. 43 | 44 | **sceneDidDisconnect(_:)** 45 | 46 | scene의 연결이 해제될 때 호출됩니다. 연결은 다시 연결될 수도 있습니다. 47 | 48 | **sceneDidBecomeActive(_:)** 49 | 50 | app switcher에서 선택되는 등 scene과 상호작용이 시작될 때 호출됩니다. 51 | 52 | **sceneWillResignActive(_:)** 53 | 54 | 사용자가 scene과의 상호작용을 중지할 때 호출됩니다. (다른 화면으로의 전환이 예입니다.) 55 | 56 | **sceneWillEnterForeground(_:)** 57 | 58 | scene이 포그라운드로 진입할 때 호출됩니다. 59 | 60 | **sceneDidEnterBackground(_:)** 61 | 62 | scene이 백그라운드로 진입할때 호출됩니다. 63 | 64 | 65 | 66 | ## 추가 67 | 68 | ### AppDelegate.swift 파일 69 | 70 | + UILifeCycle은 이제 SceneDelegate.swift 파일이 한다. 71 | + Session LifeCycle에 대한 역할이 추가 되었다. 72 | + Scene Session이 생성되거나 삭제될 때 AppDelegate에 알리는 메서드 추가 73 | + Scene Session은 앱에서 생성한 모든 scene의 정보를 관리함 74 | + 앱의 중요한 데이터 초기화 75 | + 앱의 scene 환경 설정 76 | + 앱 밖에서 발생한 알림(배터리 부족, 다운로드 완료 등)에 대응 77 | + 특정한 scene, view, view controller에 한정하지 않고 앱 자체 타겟 이벤트에 대응 78 | + 푸쉬 알림 서비스 같은 실행 시 요구되는 서비스 등록 79 | 80 | 81 | 82 | **참고** 83 | https://lena-chamna.netlify.app/post/appdelegate_and_scenedelegate/#AppDelegate%EC%99%80-SceneDelegate 84 | 85 | https://www.youtube.com/watch?v=fvF2K8mi-Bc 86 | 87 | -------------------------------------------------------------------------------- /nyokki/iOS/setNeedsLayout와 setNeedsDisplay의 차이에 대해 설명하시오. .md: -------------------------------------------------------------------------------- 1 | 참고: https://velog.io/@zeke/difference-between-setNeedsLayoutsetNeedsDisplay 2 | 3 | 참고 진짜: https://zeddios.tistory.com/359 4 | 레이아웃 미스테리 : https://medium.com/mj-studio/%EB%B2%88%EC%97%AD-ios-%EB%A0%88%EC%9D%B4%EC%95%84%EC%9B%83%EC%9D%98-%EB%AF%B8%EC%8A%A4%ED%84%B0%EB%A6%AC%EB%A5%BC-%ED%8C%8C%ED%97%A4%EC%B9%98%EB%8B%A4-2cfa99e942f9 5 | 6 | 7 | 사전 지식 8 | 9 | #### main run loop 10 | 11 | (참고 자료: 12 | 13 | https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html, 14 | 15 | https://babbab2.tistory.com/68) 16 | 17 | 기기에서 앱 아이콘을 터치하게 되면 @main을 찾아 UIApplication, AppDelegate, SceneDelegate 객체를 생성한다. 그리고 main run loop가 실행된다. main run loop는 터치이벤트, 위치의 변화, 디바이스의 회전 등의 각종 이벤트들을 처리하게 된다. 이러한 처리 과정은 각 이벤트들에 알맞는 핸들러를 찾아 그들에게 처리 권한을 위임하며 진행된다. 18 | 19 | 이렇게발생한 이벤트들을 모두 처리하고 권한이 다시 main run loop로 돌아오는 시점을 update cycle이라고 한다. 20 | 21 | ![img](https://media.vlpt.us/images/zeke/post/8fec2313-8bb2-46a0-9e1e-7771629d3870/9936863F5ACA0D5C06.png) 22 | 23 | 아이폰은 1초에 60번을 그린다(60Hz)-> 무한 반복문이 계속 도는 것 (화면 주사율) 24 | 25 | Update Cycle은 1/60초 주기마다 화면을 다시 그린다. 26 | 27 | Main Run Loop는 필요한 일처리를 하는 CPU이고 3.5GHz인 경우 1초에 35억번의 일처리를 한다는 뜻이다. 28 | 29 | 화면을 다시 그리는 일은 1번 쓰레드가 한다.(Main Thread) 30 | 31 | 32 | 33 | main run loop에서 이벤트가 처리되는 과정에서 크기나 위치가 이동하는 애니메이션과 같은 layout이나 position값을 바꾸는 핸들러가 실행될 때가 있는데, 이러한 변화는 즉각적으로 반영되는 것이 아니다. 34 | 35 | 시스템은 이런 변화하는 view를 체크하고 모든 핸들러가 종료된 후에 main run loop로 권한이 돌아오는 update cycle 시점에 view들의 값을 바꿔주어 position이나 layout의 변화를 적용시킨다. 36 | 37 | post-thumbnail 38 | 39 | Q. layout과 draw의 차이는? 40 | 41 | A. 42 | 43 | + Layout : 뷰의 크기와 위치 44 | + draw : 뷰의 CGrect을 그리는 것 45 | 46 | 참고자료 : https://itpeace.tistory.com/44 47 | 48 | 49 | 50 | ### setNeedsLayout 51 | 52 | setNeedsLayout()은 UIView의 인스턴스 메소드이다. 53 | 54 | ##### 정의: receiver(수신자)의 현재 레이아웃을 무효화하고, 다음 업데이트 주기 동안 레이아웃 업데이트를 트리거한다. 55 | 56 | 57 | 58 | 이 메소드는 즉각적인 업데이트를 강제하지 않지만, 다음 업데이트 주기를 기다리기 때문에 View를 업데이트하기 전에 여러 View의 레이아웃을 무효화하는데 사용할 수 있다. 이와 같은 행위로 모든 레이아웃 업데이트를 하나의 업데이트 주기에 통합할 수 있고 한번에 처리할 수 있기 때문에 일반적으로 성능향상에 도움이 된다. 59 | 60 | 61 | 62 | setNeedsLayout()을 호출하면 내부적으로 layoutSubView()를 호출해서 다음 업데이트 주기 때 모든 레이아웃을 업데이트 해준다. 63 | 64 | layoutSubView()는 하위 View의 크기와 위치를 결정하기 위해 설정한 constraints를 사용한다. 65 | 66 | 67 | 68 | ### setNeedsDisplay 69 | 70 | 이 메소드는 다음 드로잉 사이클동안 View를 업데이트해야 함을 시스템에 알린다. View를 업데이트하기 위해 다음 드로잉 사이클때 까지 기다리기 때문에 여러 View에서 이 메소드를 호출하여 동시에 업데이트할 수 있다. View의 내용이 변경되면 해당 변경사항을 직접 다시 그리지 않고 대신 setNeedsDisplay메소드를 사용하여 View를 무효화한다. 그리고 시스템은 드로잉 작업을 하기 전에 현재 실행루프가 끝날 때까지 대기한다. 71 | 72 | 73 | 74 | 이때 View를 업데이트하는 것은(그리는 것) draw메소드를 통해서 View업데이트를 한다. 75 | 76 | draw메소드는 재정의 할 필요가 없고 직접 호출하면 안되며 setNeedsDisplay()메소드를 호출해야 한다. 77 | 78 | 79 | 80 | -------------------------------------------------------------------------------- /nyokki/iOS/다크모드를 지원하는 방법에 대해 설명하시오. .md: -------------------------------------------------------------------------------- 1 | iOS 13 이상을 사용하는 기기에서 다크모드를 사용할 수 있게 되었다. 2 | 3 | 다크모드를 사용할 때 가장 큰 문제는 디자인과 색상이다. 4 | 5 | 6 | 7 | 다크 모드의 여부에 따라서 앱의 색상을 달리해야하는 어려움이 있다. 이를 위하 애플에서는 Semantic colors라는 것을 제공한다. 8 | 9 | 직역하면 "의미적 색채"의 뜻을 가지고 있는데 이는 앱이 다크 모드에 들어가면 시스템이 알아서 색상을 바꿔주는 것이다. 10 | 11 | Semantic colors를 사용하기 위해서는 .systemcolor를 사용하면 된다. 12 | 13 | 14 | 15 | 커스텀 색상 만들기 16 | 17 | 커스텀 색상을 만들기 위해서는 먼저 다크모드의 여부를 판별하여 대상 객체의 색상을 변경해주어야 한다. 18 | 19 | 이는 20 | 21 | ```swift 22 | UITraitCollection.userInterfaceStyle 23 | ``` 24 | 25 | 이라는 속성을 가지고 편별할 수 있으며 26 | 27 | UITraitCollection.userInterfaceStyle == .dark 조건이 다크모드이다. 28 | 29 | ##### example 30 | 31 | ```swift 32 | let COLOR_BRANDI_PRIMARY: UIColor = { 33 | if #available(iOS 13, *) { 34 | return UIColor { (UITraitCollection: UITraitCollection) -> UIColor in 35 | if UITraitCollection.userInterfaceStyle == .dark { 36 | // Return color for Dark Mode 37 | return UIColor.rgb(red: 255, green: 100, blue: 92) 38 | } else { 39 | // Return color for Light Mode 40 | return UIColor.rgb(red: 255, green: 76, blue: 66) 41 | } 42 | } 43 | } else { 44 | // Return fallback color for iOS 12 and lower 45 | return UIColor.rgb(red: 255, green: 76, blue: 66) 46 | } 47 | }() 48 | ``` 49 | 50 | 51 | 52 | 53 | 54 | -------------------------------------------------------------------------------- /nyokki/iOS/모든 View Controller 객체의 상위 클래스는 무엇이고 그 역할은 무엇인가?.md: -------------------------------------------------------------------------------- 1 | 모든 View Controller 객체의 상위 클래스는 UIViewController이다. 2 | 3 | UIViewController는 UIResponder를 상속하고 있다. 4 | 5 | viewController의 주요 임무는 다음과 같다. 6 | 7 | + 데이터 변화에 따른 view 컨텐츠를 업데이트 8 | + view와 사용자 상호 작용에 응답(UIResponder) 9 | + view를 리사이징하고 전체적인 인터페이스의 레이아웃 관리 10 | + 앱 내에서 다른 객체와의 상호작용, 조정 11 | 12 | 13 | 14 | 참고 15 | 16 | https://melod-it.gitbook.io/sagwa/app-frameworks/uikit/view-controllers/uiviewcontroller -------------------------------------------------------------------------------- /nyokki/iOS/상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오..md: -------------------------------------------------------------------------------- 1 | # UIApplicationDelegate 2 | 3 | > 앱 내에서 shared behaviors를 관리하는 메소드의 집합 4 | 5 | 6 | 7 | 앱 델리게이트 객체는 앱의 shared behaviors를 관리한다. 앱 델리게이트는 앱의 가장 루트 객체이고 UIApplication과 함께 시스템에서 interations를 관리한다. UIApplication 객체와 유사하게, UIKit은 앱 델리게이트 객체를 앱의 lauch cycle 초기에 생성하고 항상 나타나게 한다. 8 | 9 | 앱 델리게이트 객체는 다음 업무를 관리하는데 사용한다. 10 | 11 | - Initializing your app’s central data structures. 12 | 앱의 중앙 데이터 구조의 초기화 13 | - Configuring your app’s scenes. 14 | 앱 scenes의 구성 15 | - Responding to notifications originating from outside the app, such as low-memory warnings, download completion notifications, and more. 16 | Low-memory warning, download completion noti와 같은 앱 바깥에서 오는 노티피케이션에 응답한다. 17 | - Responding to events that target the app itself, and are not specific to your app’s scenes, views, or view controllers. 18 | 앱의 scenes, 뷰, 뷰 컨트롤러와 관련이 없는 그 앱 자체를 타겟으로 하는 이벤트에 응답을 한다(??) 19 | - Registering for any required services at launch time, such as Apple Push Notification service. 20 | Apple Push 노티피케이션과 같은 시작 지점에 어떤 필수적인 서비스를 등록한다. 21 | 22 | 더 많은 정보는 [Responding to the Launch of Your App](https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app) 을 참고한다. 23 | 24 | 앱 델리게이트 클래스는 아래의 델리게이트 메소드 구현을 포함한다. 25 | 26 | ```swift 27 | //애플리케이션이 실행된 직후 사용자의 화면에 보여지기 직전에 호출 28 | func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool 29 | 30 | //애플리케이션이 최초 실행될 때 호출되는 메소드 31 | func application(_ application: UIApplication, willFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool 32 | //애플리케이션이 InActive 상태로 전환되기 직전에 호출 33 | func applicationWillResignActive(_ application: UIApplication) 34 | 35 | //애플리케이션이 백그라운드 상태로 전환된 직후 호출 36 | func applicationDidEnterBackground(_ application: UIApplication) 37 | 38 | //애플리케이션이 Active 상태가 되기 직전, 화면에 보여지기 직전에 호출 39 | func applicationWillEnterForeground(_ application: UIApplication) 40 | 41 | //애플리케이션이 Active 상태로 전환된 직후 호출 42 | func applicationDidBecomeActive(_ application: UIApplication) 43 | 44 | //애플리케이션이 종료되기 직전에 호출 45 | func applicationWillTerminate(_ application: UIApplication) 46 | ``` 47 | 48 | 위 메소드들은 UIApplication 객체가 앱 델리게이트와 상호작용을 하게된다. App state가 변하는 동안 UIApplication 앱이 응답할 기회를 주면서 객체는 이에 대응되는 델리게이트 메소드를 호출한다. UIApplication 객체가 해당 작업을 처리하므로 이러한 메소드를 호출하기 위해 별다른 작업을 수행하지 않아도 된다. 49 | 50 | img 51 | 52 | ### App State 53 | 54 | - **Not Running** : 실행되지 않았거나, 시스템에 의해 종료된 상태 55 | - **Inactive** : 실행 중이지만 이벤트를 받고있지 않은 상태. 예를들어, 앱 실행 중 미리알림 또는 일정 얼럿이 화면에 덮여서 앱이 실질적으로 이벤트는 받지 못하는 상태 등 56 | - **Active** : 어플리케이션이 실질적으로 활동하고 있는 상태. 57 | - **Background** : 백그라운드 상태에서 동작을 하고 있는 상태. 예를 들어 백그라운드에서 음악을 실행하거나, 걸어온 길을 트래킹 하는 등의 행동이 돌아감. 58 | - **suspend** : 백그라운드 상태에서 활동을 멈춘 상태. 빠른 재실행을 위하여 메모리에 적재된 상태지만 실질적으로 동작하고 있지는 않음. 메모리가 부족할때 시스템이 강제종료 함 59 | 60 | 61 | 62 | ### Life-Cycle Management in iOS 12 and Earlier 63 | 64 | iOS 12 이하에서는 앱 델리게이트가 앱의 주요 생명 주기를 관리하였다. 이후 버전에서는 씬 델리게이트가 생명 주기를 관리한다. 65 | 66 | 67 | https://ios-development.tistory.com/53 68 | 69 | https://lena-chamna.netlify.app/post/appdelegate_and_scenedelegate/#AppDelegate와-SceneDelegate 70 | 71 | 72 | 참고 73 | 74 | https://developer.apple.com/documentation/uikit/uiapplicationdelegate 75 | 76 | https://velog.io/@delmasong/App-Delegate 77 | -------------------------------------------------------------------------------- /nyokki/iOS/실제 디바이스가 없는 개발 환경에서 할 수 있는 것과 없는 것.md: -------------------------------------------------------------------------------- 1 | 공식 문서 : https://help.apple.com/simulator/mac/11.0/#/devb0244142d 2 | 3 | 4 | 5 | # 시뮬레이션된 장치와 물리적 장치의 차이점 6 | 7 | ### 시뮬레이터 장점 8 | 9 | * 변경 결과를 신속하게 확인하고 오류를 디버그하고 테스트를 실행할 수 있도록 하는 앱의 신속한 프로토타이핑 및 개발을 위한 훌륭한 도구 10 | 11 | ### 차이점 12 | 13 | #### 일반적인 차이점 14 | 15 | * 프로레싱, 그래픽, 네트워크의 정확한 결과를 얻으려면 실제 장치에서 테스트 해야한다. 16 | 17 | 시뮬레이터는 CPU, 메모리 및 네트워크 연결을 포함한 컴퓨터 리소스를 사용하여 Mac에서 실행되는 앱이다. 결과적으로 시뮬레이터는 앱의 성능, 메모리 사용량 및 네트워킹 속도에 대한 정확한 테스트가 아니다. 18 | 19 | * 실제 결과가 필요한 경우 실제 장치에서 사용자가 테스트를 해야한다. 20 | 21 | 포인터와 키보드 같은 사용자 상호 작용은 iOS 및 watchOS에서 손가락을 사용하거나 tvOS에서 사용되는 포커스 기반 모델과는 다르다. 22 | 23 | #### 디스플레이 차이점 24 | 25 | * 실제 장치와 맥의 해상도 또는 포인트당 픽셀은 다를 수 있다. 26 | * 맥 화면의 색 영역이 다를 수 있기 때문에 실제 디바이스와 색상이 정확하지 않을 수 있다. 27 | 28 | #### 시스템 차이점 29 | 30 | * 시뮬레이터는 백그라운드 앱, iOS 11 이상, tvOS 11 이상, watchOS 4 이상의 프로세스는 일시 중단하지만, 31 | 일시 중단된 프로세스는 디버거에서 재개할 수 있다.(디버거에서 resume할 수 있다는 것은 무슨 뜻일까?) 32 | * 시뮬레이터는 HFS+ 및 APFS 형식 볼륨에서 파일 시스템을 대소문자를 구분한다.(?????) 33 | 34 | #### 하드웨어 차이점 35 | 36 | 시뮬레이터에서 지원하지 않는 하드웨어 37 | 38 | - 주변 광 센서(Ambient Light Sensor) 39 | - 오디오 입력(하드웨어 > Siri를 선택하여 Siri를 사용하는 경우 제외) 40 | - 기압계 41 | - 블루투스 42 | - 카메라 43 | - 모션 지원(가속도계 및 자이로스코프) 44 | - 근접 센서(Proximity Sensor) 45 | 46 | #### API 차이점 47 | 48 | 시뮬레이터에서 지원하지 않은 프레임워크 49 | 50 | - ARKit 51 | - External Accessory 52 | - HomeKit 53 | - IOSurface 54 | - Media Player 55 | - Message UI 56 | 57 | 시뮬레이터에서 사용할 수 없는 API 기능 58 | 59 | - Apple 푸시 알림 수신 및 전송(Xcode 11.4 이후 가능) 60 | - UIBackgroundModes 키 61 | - UIKit의 UIVideoEditorController클래스 62 | - 핸드오프 지원 63 | 64 | [Metal]: https://zeddios.tistory.com/932 65 | 66 | , MetalKit, Metal Performance Shaders 프레임워크는 stubs으로만 제공된다. 이 프레임워크들의 함수 호출은 효과가 없다. 67 | 68 | #### Metal 차이 69 | 70 | 시뮬레이터는 앱 개발에 사용할 수 있는 Metal implementation을 갖고 있다. 71 | 72 | -------------------------------------------------------------------------------- /nyokki/iOS/앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체를 무엇이라고 하는가?.md: -------------------------------------------------------------------------------- 1 | # View Controller 2 | 3 | > Manage your interface using view controllers and facilitate navigation around your app's content. 4 | 5 | 뷰컨트롤러를 사용하여 인터페이스를 관리하고 앱의 콘텐츠의 네비게이션에 이용한다. 라는 의미로 해석이 됩니다. 6 | 7 | 여기서 나오는 인터페이스의 용어는 정확히 무슨 의미일까요? 8 | 9 | > Interface 10 | > 11 | > 사람([사용자](https://ko.wikipedia.org/wiki/사용자_(컴퓨팅)))과 사물 또는 시스템, 특히 [기계](https://ko.wikipedia.org/wiki/기계), [컴퓨터 프로그램](https://ko.wikipedia.org/wiki/컴퓨터_프로그램) 등 사이에서 의사소통을 할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체를 뜻한다. 12 | > 13 | > (출처 : https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9A%A9%EC%9E%90_%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4) 14 | 15 | UIKit 앱의 인터페이스를 관리하기 위해 뷰 컨트롤러를 사용합니다. 하나의 뷰 컨트롤러는 단독 루트 뷰를 관리하는데, 이 루트 뷰에는 여러 개의 서브뷰를 가질 수 있습니다. 루트 뷰와 서브뷰들 간의 계층 구조와 사용자 상호작용은 필요에 의해 다른 객체와 조직화하는 뷰 컨트롤러에 의해 관리됩니다. 16 | 17 | img 18 | 19 | 모든 앱은 최소한 한개의 뷰컨트롤러를 가지고 있으며, 뷰 컨트롤러의 콘텐츠들은 메인 window에 채우게 됩니다. 20 | 21 | 만약에 앱이 한번에 화면에 모든 컨텐츠를 띄울 수 없다면, 컨텐츠의 각각을 관리하는 여러 개의 뷰 컨트롤러를 사용합니다. 22 | 23 | 24 | 25 | Container view controller는 자신의 루트 뷰안에 다른 뷰 컨트롤러들의 컨텐츠를 embed합니다. (뷰 컨트롤러의 종류에는 ViewController, Navigation Controller, TableView Controller, TabBar Controller, Split ViewController, CollectionView Controller...가 있습니다.) 26 | 27 | image-20210726145708694 28 | 29 | (위와 같은 구조도 가능합니다.) 30 | 31 | 32 | 33 | Container view controller는 독특한 인터페이스를 만들거나 네비게이션을 편리하게 하기 위해서 자식 뷰 컨트롤러의 콘텐츠를 커스텀 뷰들과 섞어서 표현할 수 있습니다. 예를 들어, UINavigationController 객체는 네비게이션 바와 자식 뷰 컨트롤러의 스택을 관리합니다. 그리고 그 스택에 자식 뷰 컨트롤러에 API를 추가하거나 제거를 하게 해줍니다. 34 | 35 | 36 | 37 | UIKit은 컨텐츠의 특정 타입들을 관리하고 네비게이션을 위한 다양한 standard한 뷰 컨트롤러(테이블VC, 네비게이션 VC, 콜렉션 VC 등등)들을 제공합니다. 앱 개발할 때 커스텀 컨텐츠를 표현하는 뷰 컨트롤러를 정의할 수도 있고, 새로운 네비게이션 로직을 실행하는 커스텀 컨테이너 뷰 컨트롤러를 정의할 수도 있습니다. 38 | 39 | 40 | 41 | # Displaying and Managing Views with a View Controller 42 | 43 | > Build a view controller in storyboards, configure it with custom views, and fill those views with your app’s data. 44 | 45 | MVC 디자인 패턴에서, 뷰 컨트롤러는 스크린위에 정보를 나타내는 뷰 객체와 앱의 컨텐츠를 저장하는 데이터 객체 사이에 있는 것이 딱 맞습니다. 특히, 뷰 컨트롤러는 뷰 계층구조를 관리하고 뷰를 최신으로 업데이트 된 상태를 유지하기 위한 상태 정보를 관리합니다. 모든 UIKit 앱은 컨텐츠를 표현하기 위에 뷰 컨트롤러에 매우 의존적이며 뷰와 UI와 관련된 로직을 관리하기 위한 커스텀 뷰 컨트롤러를 자주 정의하게 될 것입니다. 46 | 47 | 48 | 49 | 대부분 커스텀 뷰 컨트롤러는 content view controller로 만들게 될 것입니다. content view controller란 이에 속한 모든 뷰들을 소유하고 뷰 간의 상호 작용을 관리하는 뷰 컨트롤러를 말합니다. 앱의 컨텐츠를 화면에 띄우고 뷰에 데이터를 입력하고 가져오는 것을 관리하는 뷰 컨트롤러 객체를 사용하세요. 50 | 51 | ![An illustration of the relationship between a view controller, its views, and the data objects from your app.](https://docs-assets.developer.apple.com/published/ce55b56d59/da0603c5-2aac-4a8a-8537-99eca6617ab1.png) 52 | 53 | 컨텐츠 뷰 컨트롤러와는 반대로, 컨테이너 뷰 컨트롤러는 뷰 계층 안에 있는 다른 뷰 컨트롤러의 컨텐츠와 협력(?)합니다. UINavigationController는 컨테이너 뷰 컨트롤러의 한 예시입니다. 컨테이너 뷰컨트롤러가 어떻게 실행되는 지에 대해 알기 위해서는 [Implementing a Custom Container View Controller](https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/ImplementingaContainerViewController.html#//apple_ref/doc/uid/TP40007457-CH11-SW12) 를 확인하세요. 54 | 55 | 56 | 57 | 컨텐츠 뷰 컨트롤러를 정의하기 위해서는 UIViewController를 상속을 먼저 받아야합니다. 만약에 인터페이스가 테이블 뷰이거나 콜렉션뷰라면 UITableViewController, UICollectionViewController를 상속받으세요. 58 | 59 | 60 | 61 | 출처 62 | 63 | https://developer.apple.com/documentation/uikit/view_controllers 64 | 65 | https://developer.apple.com/documentation/uikit/view_controllers/displaying_and_managing_views_with_a_view_controller 66 | 67 | 68 | 69 | 70 | 71 | -------------------------------------------------------------------------------- /nyokki/iOS/앱의 콘텐츠나 데이터 자체를 저장:보관하는 특별한 객체를 무엇이라고 하는가?.md: -------------------------------------------------------------------------------- 1 | # 아카이브(Archive) 2 | 3 | 사전적 의미: 데이터를 보관해두는 것. "기록보관소", "기록보관소에 보관하다." 4 | 5 | 6 | 7 | ## 아카이브-NSCoding 8 | 9 | * 객체 아카이브는 객체 그래프를 따라 객체의 데이터 내용을 저장하는 방식 10 | 11 | * 객체 그래프란 객체들의 참조 관계를 나타낸 모습이다. 12 | 13 | * 가변 객체나 다중참조 관계를 원래대로 복원해야하는 경우 NSCoding 프로토콜을 사용한다. 14 | 15 | * NSCoding 프로토콜의 메소드는 16 | 17 | ```swift 18 | func encode(with aCoder: NSCoder) 19 | required init?(coder aDecoder: NSCoder) 20 | ``` 21 | 22 | 두 가지 메소드만 있다. 23 | 24 | 25 | 26 | ### 아카이빙 27 | 28 | * iOS에서 모델 객체를 저장하는 방법 중 하나이며 가장 흔한 방법 29 | * **아카이빙** : 객체의 아카이빙이란 그 객체의 프로퍼티를 모두 기록하고 파일 시스템에 그 내용을 저장한다는 뜻 30 | * **언아카이빙** : 아카이브한 데이터로 객체를 다시 만든다. 31 | 32 | 33 | 34 | UserDefault CoreData SQL -------------------------------------------------------------------------------- /nyokki/iOS/앱이 In-Active 상태가 되는 시나리오를 설명하시오..md: -------------------------------------------------------------------------------- 1 | iOS 애플리케이션은 5가지 상태에 있습니다. 2 | 3 | 4 | 5 | 1. Not Running 6 | 앱이 실행되지 않았거나 완전히 종료되었을 때 상태 7 | 2. In-Active 8 | 앱이 실행되면서 foreground에 진입하지만 어떠한 이벤트도 받지 않는 상태 9 | 백그라운드에서 포그라운드로 진입할때의 상태 10 | 포그라운드에서 백그라운드로 진입할때의 상태 11 | 3. Active 12 | 앱이 실행 중이며 foreground에 있고 이벤트를 받고 있는 상태 13 | 4. Background 14 | 앱이 백그라운드에 있으며 다른 앱으로 전환되었거나 홈버튼을 눌러 밖으로 나갔을 때의 상태 15 | 5. Suspended 16 | 백그라운드에서 특별한 작업이 없을 경우 전환되는 상태 17 | 18 | 19 | 20 | 이때 앱의 생명주기에 따라서 app delegate와 scene delegate에서 특정 메소드를 실행하게 합니다. 21 | 22 | 1. Not Running 23 | 1) **[application(_:willFinishLaunchingWithOptions:)](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623032-application)** 24 | 앱 실행을 준비하는 메소드 25 | 필요한 주요 객체들을 생성하고 앱 실행 준비가 끝나기 직전에 호출 26 | [앱 실행 옵션](https://developer.apple.com/documentation/uikit/uiapplication/launchoptionskey)에 따라서 설정을 달리 할 수 있다. 27 | (필요한 주요 객체들은 무엇일까?) 28 | 2) **[applicationDidFinishLaunching(_:)](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623053-applicationdidfinishlaunching)** 29 | 앱 실행을 위한 모든 준비가 끝난 후 화면이 사용자에게 보여지기 직전에 호출된다. 30 | 주로 초기화 코드를 이곳에 작정 31 | 3) **[applicationWillTerminate(_:)](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623111-applicationwillterminate)** 32 | 앱이 종료되기 직전에 호출된다. 33 | (하지만 메모리 확보를 위해 suspended 상태에서 앱의 종료나 백그라운드에서 사용자에 의한 종료시 혹은 오류로 인해 앱이 종료될 때에는 호출되지 않는다.) 34 | 2. In-Active 35 | 1. **[sceneWillEnterForeground(_:)](https://developer.apple.com/documentation/uikit/uiscenedelegate/3197918-scenewillenterforeground)** 36 | 앱이 백그라운드나 not running에서 foreground로 들어가기 직전에 호출된다. 37 | 비활성화 상태를 거쳐 acitve 상태가 된다. 38 | 2. **[sceneWillResignActive(_:)](https://developer.apple.com/documentation/uikit/uiscenedelegate/3197919-scenewillresignactive)** 39 | 이 메소드는 일시적인 중단이 생기면 UIKit이 호출한다. 예를 들어, 사용자가 게임을 하다가 일시정지를 하게되면 이 메소드가 호출된다. 40 | 3. Active 41 | 1. **[sceneDidBecomeActive](https://developer.apple.com/documentation/uikit/uiscenedelegate/3197915-scenedidbecomeactive)[(_:)](https://developer.apple.com/documentation/uikit/uiscenedelegate/3197915-scenedidbecomeactive)** 42 | 앱이 비활성상태에서 활성상태로 진입한 직후에 호출된다. 43 | 앱이 실제로 사용되기 전에 마지막으로 준비할 수 있는 코드를 작성할 수 있다. 44 | 4. Background 45 | 1. **[sceneDidBecomeActive](https://developer.apple.com/documentation/uikit/uiscenedelegate/3197915-scenedidbecomeactive)[(_:)](https://developer.apple.com/documentation/uikit/uiscenedelegate/3197915-scenedidbecomeactive)** 46 | 앱이 백그라운드 상태로 들어갔을 때 호출된다. 47 | Suspended 상태가 되기 전 중요한 데이터를 저장하는 등 종료하기 전에 필요한 작업을 한다. 48 | 5. Suspended 49 | 따로 호출되는 메소드는 없으며 백그라운드 상태에서 특별한 작업이 없을 때 이 상태가 된다. 50 | 51 | -------------------------------------------------------------------------------- /nyokki/iOS/앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가?.md: -------------------------------------------------------------------------------- 1 | 앱이 시작될 때, 앱을 담당하는 메인 런루프가 생성된다. 이벤트 처리(화면의 터치, 화면 돌리기 등)를 담당하며 어떤 함수를 실행시킬 것인지 선택하고 실행하는 역할이다. 2 | 3 | 함수 등의 실행 결과를 화면에 보여줘야 하며 화면을 다시 그리는 일이 필요할 때 화면을 다시 그리게 된다. 4 | 5 | 메인 쓰레드는 1초에 60번 화면을 다시 그려야하는 역할도 가지고 있다. (지시하는 위치) 그렇기 때문에 6 | 7 | 작업을 하는 시간이 오래 걸리게 되면(네트워크 작업) 1초에 60번 화면을 다시 그려야하는 역할도 하기 때문에 8 | 9 | 버벅이는 현상이 일어나게 된다. 다시 말에 시간이 오래 걸리는 작업을 하고 다음 작업으로 넘어갈 때, 그 찰나에 화면을 다시 10 | 11 | 그리기 때문에 버벅이는 것이다. 12 | 13 | 14 | 15 | When an app launches, it loads its main UI file, asks the app delegate to initialize the app's data structures, and restores any previous interface state. 16 | 17 | 1. The app is launched, either explicitly by the user or implicitly by the system. 18 | 2. The Xcode-provided `main` function calls UIKit's [`UIApplicationMain(_:_:_:_:)`](https://developer.apple.com/documentation/uikit/1622933-uiapplicationmain) function. 19 | 3. The [`UIApplicationMain(_:_:_:_:)`](https://developer.apple.com/documentation/uikit/1622933-uiapplicationmain) function creates the [`UIApplication`](https://developer.apple.com/documentation/uikit/uiapplication) object and your app delegate. 20 | 4. UIKit loads your app's default interface from the main storyboard or nib file. 21 | 5. UIKit calls your app delegate's [`application(_:willFinishLaunchingWithOptions:)`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623032-application) method. 22 | 6. UIKit performs state restoration, which calls additional methods of your app delegate and view controllers. 23 | 7. UIKit calls your app delegate's [`application(_:didFinishLaunchingWithOptions:)`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622921-application) method . 24 | 25 | img 26 | 27 | 28 | 29 | # UIApplicationMain(_: _: _: _:) 30 | 31 | Creates the application object and the application delegate and sets up the event cycle. 32 | 33 | ## Declaration 34 | 35 | ```swift 36 | func UIApplicationMain(_ argc: Int32, 37 | _ argv: UnsafeMutablePointer?>, 38 | _ principalClassName: String?, 39 | _ delegateClassName: String?) -> Int32 40 | ``` 41 | 42 | \- **argc** : argv의 개수. 대게 main에 해당하는 파라미터입니다. 43 | 44 | \- **argv** : argument의 변수 목록. 대게 main에 해당하는 파라미터입니다. 45 | 46 | (C언어에서 main 함수는 프로그램의 진입점이다. int argc는 정보의 갯수를 의미하고 char argv[ ]는 메인함수에 전달되는 실질적인 정보로 문자열의 배열을 의미한다.) 47 | 48 | \- **principalClassName** : 49 | 50 | [UIApplication]: https://developer.apple.com/documentation/uikit/uiapplication 51 | 52 | 클래스 또는 하위 클래스의 이름입니다. nil을 지정하면, UIApplication으로 가정됩니다. 53 | 54 | \- **delegateClassName** : application delegate가 인스턴스화 되는 클래스 이름입니다. principalClassName이 UIApplication의 하위클래스를 지정하는 경우, 하위 클래스를 delegate로 지정 할 수 있습니다. 하위클래스 인스턴스는 앱의 delegate 메세지를 받습니다. 앱의 기본 nib파일에서 delegate 객체를 로드하는 경우, nil을 지정합니다. 55 | 56 | # UIApplication 57 | 58 | > The centralized point of control and coordination for apps running in iOS. 59 | > 60 | > (iOS에서 앱을 구동하는데 control하고 조정하는 중앙 지점?) 61 | 62 | UIApplicationMain에 의해 생성되는 객체는 UIApplication 객체입니다. iOS앱은 UIApplication이라는 클래스의 객체입니다. 프로젝트의 main 함수는 기본적으로 UIApplication 클래스의 인스턴스를 만들어서 GUI를 사용하기 위한 runloop를 돌려주는 작업을 수행한다. 그 이후 앱 내에서 일어나는 모든 처리는 UIApplication 객체가 관리하게 된다. 63 | 64 | 65 | 66 | 출처 67 | 68 | https://developer.apple.com/documentation/uikit/1622933-uiapplicationmain 69 | 70 | https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app/about_the_app_launch_sequence 71 | -------------------------------------------------------------------------------- /nyokki/iOS/자신만의 Custom View를 만들려면 어떻게 해야하는지 설명하시오..md: -------------------------------------------------------------------------------- 1 | 1. xib 2 | 3 | Xib란 Xcode Interface Builder의 약자로 Nib파일을 XML형식으로 변환한 파일이다. 4 | 5 | XML 형식이라 소스코드를 좀더 알아보기 편하다 ..? 6 | 7 | Xib파일을 빌드하면 Nib으로 컴파일되고 그 파일이 배포되는 식이다. 8 | 9 | 10 | 11 | 사용하는 법 12 | 13 | Xib파일과 swift파일을 각각 만든다. 14 | 15 | xib의 커스텀 클래스를 만든 swift파일로 지정한다. 16 | 17 | Owner 설정 -> 이벤트를 받는 주최 설정(??) 18 | 19 | 20 | 21 | 22 | 23 | 1. only 코드 24 | 25 | Xib 파일이 필요없고 swift파일만 있으면 된다. 26 | 27 | -------------------------------------------------------------------------------- /nyokki/iOS/하나의 View Controller 코드에서 여러 TableView Controller 역할을 해야 할 경우 어떻게 구분해서 구현해야 하는지 설명하시오..md: -------------------------------------------------------------------------------- 1 | 참고자료: https://zeddios.tistory.com/169 2 | 3 | 4 | 5 | 1. IBOutlet 연결, Delegate, DataSource extension 6 | 2. Delegate 위임 7 | 3. DataSource 메소드 구현 8 | 4. 각 테이블의 다른 내용 넣기 9 | + 구분하는 법 10 | 1. tableView이름으로 구분 11 | 2. tag사용 12 | 13 | -------------------------------------------------------------------------------- /nyokki/네트워크/REST API.md: -------------------------------------------------------------------------------- 1 | ### API(Application Programming Interface)란? 2 | 3 | API란 상호 간의 정보를 교환하기 위한 Interface이다. 그렇기 때문에 룰과 약속이 존재한다. 요청 방식에 대한 약속으로 어떤 주소로 무엇을 요청하며 그 결과를 어떻게 주는지에 대한 약속을 정의한 것이다. 4 | 5 | 이때 상호 간의 약속을 하는 것이기 때문에 본인만 아는 형식으로 하는 것은 다른 개발자와 소통의 어려움과 많은 부작용이 생겨날 수 밖에 없다. 실제로 많은 어려움을 겪은 후에 요청 방식에 대한 약속을 정했다. 6 | 7 | # REST API 8 | 9 | 많은 혼란을 겪은 후에 개선을 해왔고 현재에는 REST한 형식의 API를 사용하자 라고 약속을 했다. 10 | 11 | 1. 명사형으로 작성하자. 등등 12 | 13 | 14 | 15 | # iOS 네트워킹 16 | 17 | 만드는 순서 18 | 19 | 1. URL 20 | 21 | 2. URLSession (브라우저를 킨다.) 22 | 23 | 통신을 자유롭게 하기 위해서 애플이 만들어 놓은 객체 24 | 25 | 3. dataTask (url을 입력한다.) 26 | 27 | 일거리를 던져주는 행위 28 | 29 | 4. 시작(resume) (엔터) 30 | 31 | 위 단계를 거치면 Swift에서 HTTP 형식으로 변환을 해주어서 서버에 전송을 하게 된다. 32 | 33 | 서버가 요청사항을 받으면 해당 데이터를 JSON 형태로 보내주게 된다. 34 | 35 | 받은 JSON데이터를 앱에서 사용하는 Class/Struct로 변환하여서 사용한다. 36 | 37 | 38 | 39 | Session은 기간, 시간이라는 뜻을 갖고 있다. 40 | 41 | 브라우저에서 Session의 의미는 일정 시간 동안 브라우저로 부터 들어오는 연결상태를 유지하는 혹은 연결상태를 의미한다. 42 | 43 | 브라우저 하나의 탭이라고 생각하면 된다. 구글탭, 넷플릭스 탭, 유튜브 탭 등 44 | 45 | 46 | 47 | Parse -> 파싱은 분석한다는 뜻이다. JSON Parsing이란 JSON을 분석한다는 의미가 된다. 48 | 49 | -------------------------------------------------------------------------------- /nyokki/네트워크/네트워크 통신.md: -------------------------------------------------------------------------------- 1 | # TCP/IP 프로토콜 2 | 3 | 우리 사용하는 스마트폰은 인터넷 연결이 끊기면 생활이 아주 불편하다. 그럼 우리가 유용하게 사용하고 있는 이 인터넷과 연결. 네트워킹은 어떻게 이루어질까? 4 | 5 | 우리가 인터넷에서 받아오는 정보는 사실 다른 외부 컴퓨터에 접근하여 정보를 받아오거나 저장하는 일을 한다. 이때 컴퓨터/스마트폰은 클라이언트(고객)라고 칭하고 정보가 있는 컴퓨터를 서버라고 한다. 6 | 7 | 그럼 둘이 어떻게 연결이 될까? 인터넷에 연결하는 방법은 다양한 프로토콜로 존재한다. 이를 통합해서 부르는 것을 TCP/IP라고 부른다. 여기서 프로토콜은 약속을 의미한다. 서로 연결하고 정보를 교환하기 위한 약속. 8 | 9 | 우리가 중점적으로 알아야하는 프로토콜은 HTTP 프로토콜이다. 10 | 11 | # 요청과 응답의 방식(우편 주고 받기) 12 | 13 | 현재 인터넷의 모든 것은 HTTP로 이루어져있다. 14 | 15 | 앱 개발을 하는 상황에서 애플리케이션에서 HTTP는 리퀘스트라고 한다. 서버와 통신을 하는 것은 편지/우편을 주고 받는 것과 유사하다. 편지를 쓰거나 문서를 보낼 때 우편에 작성하는 양식과 약속이 정해져 있듯이 정보를 요청하거나 서버에서 앱에 정보를 줄 때도 이 양식을 갖춰서 전송을 하게 된다. 16 | 17 | 애플리케이션에 편지지인 HTTP를 작성하고 이를 OS에서 받게된다. OS의 트랜스포트에서 TCP로 바꾸는데 받은 HTTP를 조각내고 전송한 곳(카카오톡, 음악 앱, 사진 앱 등)의 표시를 하는 PORT를 붙힌다. 그리고 우편 주소를 적은 IP를 붙여준다. 18 | 19 | 이를 LAN에서 받아 한번 더 감싼 뒤 서버로 보낸다. 이렇게 4개의 계층으로 이루어져있다. 20 | 21 | 22 | 23 | 정리하면 HTTP는 데이터를 어떻게 주고 받을지에 대한 약속이며 요청과 응답이 이루어진다. 24 | 25 | TCP에서는 주고 받을 상태 확인과 검증을 하고 어떤 앱과 통신하는지를 밝히는 PORT를 붙인다. 그리고 인터넷에서 주고 받는 주소(경로)를 즉, IP 주소를 작성해준다. 26 | 27 | 서버에서 이 요청을 받으면 역순으로 포장과 우편을 풀어서 내용을 확인하게 되며 서버에서 앱으로 정보를 전달할 때에도 동일한 4계층의 단계를 거치게 된다. 28 | 29 | # HTTP(Hyper Text Transfer Protocol) 30 | 31 | 하이퍼 문서를 전송하는 것에서 시작을 한 것을 HTTP 프로토콜이라고 한다. 역사의 시작은 문서를 보내는 것에서 시작을 했지만 지금은 이미지/영상/음성/파일/JSON 등 모든 형태의 데이터를 전송하는 것이 가능하다. 따라서 하이퍼 텍스트라고 칭하는 것이다. 32 | 33 | 앱 개발자가 해줘야하는 일은 앱이 올바른 형식으로 정보를 요청하고 받아오는 작업을 하는 것이다. 올바른 형식이란 요청 메세지를 HTTP에 맞춰 올바르게 리퀘스트 하는 것이다. 34 | 35 | 요청인 리퀘퀘스트는 Query라고 하고 응답인 Response는 data가 온다. 36 | 37 | ## HTTP의 구조 38 | 39 | 한번 더 말하자면 HTTP 메세지 형태는 데이터를 어떻게 주고 받을지에 대한 약속을 말한다. 40 | 41 | 메세지의 형식은 가장 위에서 부터 시작라인/헤더/ 공 백 / 바디 순으로 되어있다. 42 | 43 | #### HTTP 요청 / 응답 메세지 44 | 45 | img 46 | 47 | 1. 시작 라인 48 | 49 | + 요청 메세지의 경우 50 | 51 | 시작 라인에는 HTTP 메소드, 주소, HTTP 버전 순으로 되어있다. 52 | 53 | + 응답 메세지의 경우 54 | 55 | HTTP 버전, 상태코드, 문구가 들어오는데 문구에는 상태코드에 대한 내용이다. 56 | 57 | 2. 헤더 58 | 59 | 부가 정보가 들어간다. 실제로 필요한 정보는 바디에 들어있다. (요청/응답 메세지 동일) 60 | 61 | 3. 공백라인 62 | 63 | 정말 말 그대로 공백으로 되어있다. (요청/응답 메세지 동일) 64 | 65 | 4. 바디 66 | 67 | 바디에는 실제로 전송할 데이터(JSON/ 이미지/ 영상/ HTML 문서 등)가 들어있다. (요청/응답 메세지 동일) 68 | 69 | ### HTTP 메소드 70 | 71 | 가장 잘 알아야하는 것은 GET, POST, PUT, PATCH, DELETE 이다. 72 | 73 | GET은 조회하는 것으로 카카오톡의 경우 현재까지 왔던 데이터를 불러오는 메소드이다. 74 | 75 | POST는 카카오톡에 메세지를 보내거나 댓글을 달거나 게시글을 작성할 때, 쇼핑을 해서 주문을 넣을 때 사용하는 메소드이다. 76 | 77 | PUT은 데이터를 대체하거나 없으면 생성하는 것으로 게시글을 수정할 때 사용하는 메소드이다. 78 | 79 | PATCH는 주로 PUT을 사용하지만 부분 변경을 할 경우 PATCH를 사용한다. 80 | 81 | DELETE는 말그대로 삭제하는데 사용하는 메소드이다. 82 | 83 | #### CRUD 84 | 85 | CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말이다. 위의 HTTP 메서드에서는 POST, GET, PUT, DELETE가 각각 CRUD 기능 역할을 한다. 86 | 87 | - Create: POST/PUT 88 | - Read: GET 89 | - Update: PUT 90 | - Delete: DELETE 91 | 92 | ### 상태 코드 93 | 94 | 클라이언트가 서버에 요청 메세지를 보내고, 서버는 클라이언트에게 응답 메세지를 보내는데, 이때 응답 내용에 따른 **상태 코드**를 보내게 된다. 95 | 96 | 모든 HTTP 응답 코드는 5개의 클래스(분류)로 구분된다. 상태 코드의 첫 번째 숫자는 응답의 클래스를 정의합니다. 마지막 두 자리는 클래스나 분류 역할을 하지 않는다. 첫 자리에 대한 5가지 값들은 다음과 같다. 97 | 98 | - 1xx (정보): 요청을 받았으며 프로세스를 계속한다 99 | - **2xx (성공)**: 요청을 성공적으로 받았으며 인식했고 수용하였다 100 | - 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다 101 | - **4xx (클라이언트 오류, 내가 잘못함)**: 요청의 문법이 잘못되었거나 요청을 처리할 수 없다 -> 잘못된 요청 102 | - **5xx (서버 오류, 서버가 잘못함)**: 서버가 명백히 유효한 요청에 대해 충족을 실패했다 -> 서버 내부의 문제 103 | 104 | ### Request(요청) 데이터의 형태 105 | 106 | 일반적으로 GET 메소드 일때 query는 물음표 뒤에 있으며 쿼리 파라미터가 존재하여 key=value의 형태로 작성되며 &로 추가 요청(쿼리)가 가능하다. 주로 요청 메세지에서 스타트라인, 즉 상태라인, 요청라인에 쿼리 파라미터를 함께 보낸다. 물론 바디에 붙여서 보기도 한다. 107 | 108 | > 예시 109 | > 110 | > https://shopping.naver.com/hotdeal/p/luckto/index.naver?id=3303424&cat=958&sort=rcnt 111 | > 112 | > ?id=3303424&cat=958&sort=rcnt 113 | > 114 | > id(key)=3303424(value) 115 | > 116 | > cat(key)=948(value) 117 | > 118 | > sort(key)=rcnt(value) 119 | 120 | GET 메소드일 경우 쿼리 파라미터를 통한 데이터 전송을 하며 POST/PUT/PATCH 메소드를 사용하는 경우, 즉 회원가입, 게시글 작성, 게시글 업데이트(수정)할 경우에는 메세지 바디를 통해 데이터를 전송한다. 121 | 122 | ### Response(응답) 데이터의 형태 123 | 124 | 만일 GET 요청을 하고 서버에서 데이터를 전송해주면 대부분 JSON 형태의 데이터를 보내준다. 125 | 126 | 127 | 128 | -------------------------------------------------------------------------------- /nyokki/라이브러리/요약.md: -------------------------------------------------------------------------------- 1 | Kingfisher 2 | 3 | 이미지 캐싱 라이브러리 4 | 5 | 비동기적 처리가 디폴트 6 | 7 | 8 | 9 | Lottie -iOS 10 | 11 | JSON 기반의 Adobe After Effects 애니메이션 구문을 분석하여 화면에 애니메이션을 렌더링해주는 라이브러리이다. 12 | 13 | -------------------------------------------------------------------------------- /supersupremekim/ARC/ARC란 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🚨 ARC란 무엇인지 설명하시오 2 | 3 | 4 | 5 | ### 프로그램 작동시에 cpu가 필요한 것들을 올려놓는 memory에는 필요한 것만 올려놓는 것이 좋다. 6 | 7 | ### 그래서 memory 관리를 해야하는데, stack에 쌓이는 자료들은 메모리에서 자동으로 제거되기 때문에 특별한 관리를 해주지 않아도 된다. heap에 쌓이는 데이터들은 그렇지가 않아서 특별한 관리가 필요하다. 8 | 9 | ### Arc, 즉 auto reference counting이란 어떤 객체를 참조할 때마다 자동으로 카운트를 늘려주고, 그 카운트가 0이 되면 자동으로 메모리에서 해당 객체를 해제하는 방식을 의미한다. -------------------------------------------------------------------------------- /supersupremekim/ARC/README.md: -------------------------------------------------------------------------------- 1 | ## ARC 2 | - [x] ARC란 무엇인지 설명하시오. 3 | - [x] Retain Count 방식에 대해 설명하시오. 4 | - [x] Strong 과 Weak 참조 방식에 대해 설명하시오. 5 | - [x] 순환 참조에 대하여 설명하시오. 6 | - [x] 강한 순환 참조 (Strong Reference Cycle) 는 어떤 경우에 발생하는지 설명하시오. 7 | -------------------------------------------------------------------------------- /supersupremekim/ARC/Retain Count 방식에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🚨 Retain Count 방식에 대해 설명하시오 2 | 3 | 4 | 5 | ### ARC 이전 MRC 에서 참조횟수를 세는 방식이다. 객체를 참조할 때 retain count가 증가할 때마다 retain함수를 써주고, retain count가 감소되는 시점에 release 메소드를 써주며 메모리를 관리한다. 6 | 7 | -------------------------------------------------------------------------------- /supersupremekim/ARC/Strong 과 Weak 참조 방식에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🚨 Strong 과 Weak 참조 방식에 대해 설명하시오 2 | 3 | 4 | 5 | ### strong 강한 참조 - 해당 인스턴스의 소유권을 가진다. 자신이 참조하는 인스턴스의 retain count를 증가시키고, 참조가 종료되는 시점에 release 된다. 선언할 때 아무것도 적지 않으면 default 값으로 strong이 된다. 레퍼런스 카운트를 증가시켜 자동으로 메모리 해제되는 것을 방지할 때 쓰인다. 6 | 7 | 8 | 9 | ### Weak 약한 참조 - 해당 인스턴스의 소유권을 가지지 않고, 주소값만 가지고 있는 포인터 개념이다. 자신이 참조하는 인스턴스의 retain count를 증가시키지 않는다. release도 발생하지 않는다. 인스턴스가 메모리에서 해제될 경우 자동으로 레퍼런스가 nil로 초기화된다. Weak 속성을 사용하는 객체는, 해당 객체가 nil일수도 있기 때문에 항상 optional 타입 이어야 한다. 메모리 누수를 방지하기 위해 사용된다. 10 | 11 | 12 | 13 | ### Unowned (미소유, 약한 참조) - 해당 인스턴스의 소유권을 가지지 않는다. 자신이 참조하는 인스턴스의 retain count를 증가시키지 않는다. nil이 될 수 없기 때문에 optional로 선언되어서는 안된다. 그러므로 app이 crash될 수 있기 때문에 객체의 라이프사이클이 명확할 경우 사용한다. 14 | 15 | 16 | 17 | ### weak와 unowned의 차이 - weak은 객체를 계속 추적하면서 객체가 사라지면 nil이 된다. 그래서 앱이 crash나지 않는다. 하지만 unowned는 객체가 사라지면 메모리의 빈공간을 참조하고 있는 형태가 되기 때문에, unowned는 사라지지 않을거라고 보장되는 객체에만 설정해야 한다. 18 | 19 | -------------------------------------------------------------------------------- /supersupremekim/ARC/강한 순환 참조 (Strong Reference Cycle) 는 어떤 경우에 발생하는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🚨 강한 순환 참조 (Strong Reference Cycle) 는 어떤 경우에 발생하는지 설명하시오 2 | 3 | 4 | 5 | ### 예를 들면, 두 class 인스턴스의 속성이 서로를 강한 참조하고 있는데, 두 인스턴스가 메모리에서 해제되는 시점에서도, 두 인스턴스의 속성이 강한 참조를 할 때 증가한 reference count는 계속 유지되기 때문에 강한 순환 참조가 발생한다. 6 | 7 | ### 이런 경우 class의 강한참조가 발생하는 속성을 한쪽의 class에서 만이라도 weak로 바꾸면 한쪽의 클래스의 인스턴스가 nil이 될 때 참조하고 있는 속성도 함께 메모리에서 해제되기 때문에 두 인스턴스 모두 메모리에서 해제된다. -------------------------------------------------------------------------------- /supersupremekim/ARC/순환 참조에 대하여 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🚨 순환 참조에 대하여 설명하시오. 2 | 3 | ### 클래스 인스턴스의 reference count가 0이 되는 시점을 절대 얻지 못하는 상황. 4 | 5 | ### 두 인스턴스가 서로를 붙잡고 있는 상황이라 메모리에서 해제될 수 없는 상황으로 누수가 발생하고 있는 상황. 6 | 7 | -------------------------------------------------------------------------------- /supersupremekim/Architecture/MVVM, Ribs, VIP 등 자신이 알고있는 아키텍쳐를 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🏗 MVVM, Ribs, VIP 등 자신이 알고있는 아키텍쳐를 설명하시오 2 | 3 | ### MVVM 아키텍쳐는 Model과 View 그리고 ViewModel로 이루어진 아키텍쳐이다. Model에서는 어플리케이션 내에서 필요한 타입의 데이터를 갖고 있고, 비즈니스 로직을 다뤄서 데이터를 가공하여 viewmodel에 제공한다. viewModel은 view와 바인드 되어 있고 특정 로직에 따라 표현해야 하는 ui 요소를 본따고 있으며, model로부터 받은 데이터를 View에 표시하기 적합한 형태로 변형하여 View에 넘겨주고, view는 해당 내용을 그린다. 하지만 일방통행만은 아니다. view는 model과는 직접적으로 소통하지 않지만, 주로 user event를 viewmodel에 넘겨주기도 하면서 양방향으로 소통한다. 4 | 5 | ### mvvm의 장점은 view controller가 길어지지 않는다는 점과 각 파트가 나눠져있어서 가독성이 뛰어나다는 점, 그리고 에러가 생기면 에러가 생긴 단계에서만 수정을 하면 된다는 장점과, unit test를 하기 적합하다는 장점, 그리고 rxswift를 적용하기에 적합하다는 장점이 있다. 6 | 7 | ### MVC 아키텍쳐는 Model과 View와 Controller로 이뤄져 있는 아키텍쳐이다. 8 | 9 | ### model은 data와 logic을 갖고 있고 view는 user interaction을 담당하며 controller는 view와 model의 중재자 역할을 한다. view가 user interaction을 받는 상황부터 설명하면, interaction을 받았을 때 controller에 input event를 전달하고 받은 내용을 바탕으로 model에 요청을 보내면 model에서 비즈니스 로직을 처리해서 필요한 데이터를 다시 controller에 보낸다. 컨트롤러는 해당 데이터를 뷰에 그리기에 적합한 type으로 바꿔서 view에 그리게 한다. 10 | 11 | ### Coordinator 는 화면 전환과 관련된 일을 하는 객체 coordinator가 각 뷰 컨트롤러에 주입되어 화면 전환 역할을 담당하는 디자인 패턴이다. coordinator 프로토콜을 채택한 coordintor 클래스 객체에서 각종 화면 전환과 관련된 메소드를 구현해놓고 사용한다. 또한 보통 뷰컨트롤러들의 instance화를 간편하게 하기 위해서 관련 프로토콜을 정의하고 타입 메소드로 뷰컨트롤러의 인스턴스화를 담당하는 메소드를 정의해놓고 사용한다. 12 | -------------------------------------------------------------------------------- /supersupremekim/Architecture/README.md: -------------------------------------------------------------------------------- 1 | ## Architecture 2 | - [ ] MVVM, Ribs, VIP 등 자신이 알고있는 아키텍쳐를 설명하시오. 3 | - [ ] 의존성 주입에 대하여 설명하시오. 4 | 5 | -------------------------------------------------------------------------------- /supersupremekim/Architecture/의존성 주입에 대하여 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🏗 의존성 주입에 대하여 설명하시오 2 | 3 | 4 | 5 | ### 의존성 주입은 하나의 객체가 다른 객체의 의존성을 제공하는 기술이다. 의존성이란 서비스로 사용할 수 있는 객체이다. 예를 들면, model에서 비즈니스를 처리하는 메소드가 있고, 해당 로직을 위해서는 어떤 인스턴스들이 필요하다고 할 때, 그 인스턴스들을 메소드가 찾게 하는 것이 아닌, 메소드를 사용할 때마다 주입해주는 것이다. 이렇게 의존성 주입을 하면 코드 재사용을 용이하게 하는 것과, 리팩토링을 할 때 용이하다는 점, 작게는 dummy data 로 앱 사용을 test 해볼 수 있다는 점이 있다. -------------------------------------------------------------------------------- /supersupremekim/Autolayout/Intrinsic Size에 대해서 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 👨‍🎨 Intrinsic Size에 대해서 설명하시오 2 | 3 | 4 | 5 | ### 컨텐츠의 본질적인 크기. UILabel이나 UIButton, UITextField와 같이 텍스트를 뷰 안에 갖는 ui 요소들의 경우에는 텍스트의 크기나 폰트, 길이에 따라 자체적인 Width와 Height를 갖는 것을 Instrinsic Size라 한다. 이런 뷰들의 경우에는, 최소한의 위치 autolayout만 정해줘도 자체적인 크기가 있기 때문에, 뷰에 그리기에 충분한 정보가 있어서 오토 레이아웃 에러가 나지 않는다. -------------------------------------------------------------------------------- /supersupremekim/Autolayout/Left Constraint 와 Leading Constraint 의 차이점을 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 👨‍🎨 Left Constraint 와 Leading Constraint 의 차이점을 설명하시오 2 | 3 | 4 | 5 | ### left constraint는 superview와의 오른쪽 간격을 의미하고, leading은 sibling view 와의 왼쪽 정렬을 의미한다. 6 | 7 | -------------------------------------------------------------------------------- /supersupremekim/Autolayout/README.md: -------------------------------------------------------------------------------- 1 | - [x] 오토레이아웃을 코드로 작성하는 방법은 무엇인가? (3가지) 2 | - [x] hugging, resistance에 대해서 설명하시오. 3 | - [x] Intrinsic Size에 대해서 설명하시오. 4 | - [x] 스토리보드를 이용했을때의 장단점을 설명하시오. 5 | - [x] Safearea에 대해서 설명하시오. 6 | - [x] Left Constraint 와 Leading Constraint 의 차이점을 설명하시오. 7 | -------------------------------------------------------------------------------- /supersupremekim/Autolayout/Safearea에 대해서 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 👨‍🎨 Safearea에 대해서 설명하시오. 2 | 3 | ### 최근 아이폰들의 디스플레이의 경우에 상 하단 라운드 영역을 포함하고 있다. 상단 라운드 영역의 경우에 노치에 카메라나 스피커도 있고 센서나 중요한 부품들이 위치하고 있어서 컨텐츠가 잘리거나 컨텐츠를 보여주기에 적합하지 않을 수 있다. 그래서 컨텐츠가 안정적으로 보여질 수 있는 영역인 safe area를 갖고 있다. -------------------------------------------------------------------------------- /supersupremekim/Autolayout/hugging, resistance에 대해서 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 👨‍🎨 hugging, resistance에 대해서 설명하시오. 2 | 3 | 4 | 5 | ### hugging은 작아질 수 있다는 것으로 해석할 수 있어서, 다수의 뷰가 있다면, hugging priority가 높은쪽이 줄어든다. 6 | 7 | ### resistance는 반대로 최소 크기에 대한 제한으로, 즉 커질 수 있다라고 해석할 수 있고, 어떤 뷰의 constraint 보다 resistance의 priority가 높으면, constraint를 무시하고 resistance만큼 커진다. -------------------------------------------------------------------------------- /supersupremekim/Autolayout/스토리보드를 이용했을때의 장단점을 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 👨‍🎨 스토리보드를 이용했을때의 장단점을 설명하시오 2 | 3 | 4 | 5 | ### 스토리 보드를 이용했을 때의 장점은, 세그웨이를 잇거나 유아이 네비게이션 컨트롤러의 루트 뷰컨트롤러를 드래그로 잇는 등 직관적으로 개발을 할 수 있다는 점과, 런을 하지 않고도 개발하고 있는 뷰의 레이아웃을 볼 수 있다는 점, 런을 하지 않고도 바로바로 오토레이아웃 에러를 볼 수 있다는 점이다. 6 | 7 | 8 | 9 | ### 단점은 빌드가 오래걸린다는 점, 협업 merge할때 conflict가 많다는 점, 상황상 위치가 겹치는 ui 요소들이 있을 때 드래그해서 끌고오기 번거롭다는 점이 있다. -------------------------------------------------------------------------------- /supersupremekim/Autolayout/오토레이아웃을 코드로 작성하는 방법은 무엇인가.md: -------------------------------------------------------------------------------- 1 | # 👨‍🎨 오토레이아웃을 코드로 작성하는 방법은 무엇인가? (3가지) 2 | 3 | 4 | 5 | ### 가장 많이 사용되는 것은 Anchor를 통해서 구현하는 것이다. 어떤 ui 요소의 centerXAnchor, heightAnchor 등에 constraint를 줘서 해당 constraint를 활성화시켜 사용한다. 6 | 7 | 8 | 9 | ### 두번째 방법은 NSLayoutConstraint 의 매개변수를 활용해서 작성하는 방법이다. 10 | 11 | ### 여기에는 item, attribute, relatedBy 등 파라미터에 아규먼트를 넘겨줘서 사용한다. 12 | 13 | 14 | 15 | ### 세번째는 Visual Format Language를 통해 구현하는 것이다. 16 | 17 | ### 이 방식은 매개변수로 값을 넘기지 않고, 특정한 기호 문자열을 활용해서 오토레이아웃을 구현한다. -------------------------------------------------------------------------------- /supersupremekim/Functional Programming/README.md: -------------------------------------------------------------------------------- 1 | - [x] 함수형 프로그래밍이 무엇인지 설명하시오. 2 | - [x] 고차 함수가 무엇인지 설명하시오. 3 | - [x] Swift Standard Library의 map, filter, reduce, compactMap, flatMap에 대하여 설명하시오. 4 | -------------------------------------------------------------------------------- /supersupremekim/Functional Programming/Swift Standard Library의 map, filter, reduce, compactMap, flatMap에 대하여 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🧑‍💻 Swift Standard Library의 map, filter, reduce, compactMap, flatMap에 대하여 설명하시오 2 | 3 | 4 | 5 | map - 어떤 array의 요소를 인자로 받아 인자를 변경하고 변경 값을 리턴하는데, 그 요소들을 종합하여 새로운 배열을 만드는 함수를 인자로 받는 고차 함수. 6 | 7 | filter - 어떤 array의 요소를 인자로 받아서 인자의 어떤 속성을 특정 값과 비교해서 bool 값을 리턴하는 함수를 filter로 전달하는데, 이 때 true를 리턴한 인자만으로 새로운 배열을 만드는 고차 함수. 8 | 9 | reduce - 초깃값을 설정하고 , array의 두 요소를 파라미터로 받아 더한 값을 초깃값과 더하고, 이 값이 초깃값이 되며 요소들을 더해나가는 함수를 받는 고차함수. 10 | 11 | compactMap - map을 실행할 때, array의 요소 중 nil이 return 된 요소를 제외한 요소들로 새로운 배열을 만드는 고차함수. 12 | 13 | flatMap - array의 요소들이 또 squence를 이루고 있을 때, squence들을 flat하게 만들어 array를 일차원 array로 만드는 고차함수. -------------------------------------------------------------------------------- /supersupremekim/Functional Programming/고차 함수가 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🧑‍💻 고차 함수가 무엇인지 설명하시오 2 | 3 | 4 | 5 | ### swift에서 함수는 1급시민으로 취급되기 때문에 다른 함수의 인자로, 반환값으로 전달될 수 있다. 6 | 7 | ### 고차함수는 이러한 형식으로 인자로 함수를 받거나, 결과를 함수로 반환하는 함수를 말한다. 8 | 9 | ### 대표적인 고차함수로는 map, filter, reduce가 있다. -------------------------------------------------------------------------------- /supersupremekim/Functional Programming/함수형 프로그래밍이 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🧑‍💻 함수형 프로그래밍이 무엇인지 설명하시오 2 | 3 | 값으로 저장될 수 있고, 인자, return 값으로 돌려받을 수 있는, 함수가 1급 시민인 언어를 함수형 프로그래밍이라고 한다. 4 | 5 | more to search -------------------------------------------------------------------------------- /supersupremekim/Swift/Anyobject에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Anyobject에 대해 설명하시오 2 | 3 | 4 | 5 | 6 | 7 | ### Any 가 모든 오브젝트라면, AnyObject는 Any안에 포함된 것. 8 | 9 | ### AnyObject는 모든 클래스 타입의 인스턴스가 암시적으로 준수하는 프로토콜이다. 10 | 11 | ### any의 배열은 배열 안에 여러 기본 타입의 인스턴스들을 넣을 수 있지만, anyobject는 아니다. 왜냐하면 Int, string, bool, float, double 등의 기본 타입들은 구조체로 구현되어 있기 때문이다. 12 | 13 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Codable에 대하여 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Codable에 대하여 설명하시오 2 | 3 | ### 어떤 타입이 codable을 채택하게 되면 이 타입은 decodable과 encodable 모두 가능하게 되는 프로토콜이다. 4 | 5 | ### 어떤 data타입의 인스턴스를 swift 개발에서 활용할 수 있는 커스텀 타입의 인스턴스로 변환할 때, decodable을 채택한 커스텀 타입을 활용한다. 많이 활용하는 경우는 decodable을 채택한 타입을 만들어 JSON Decoder를 활용해서 데이터를 원하는 타입의 오브젝트로 변환하는 경우이다. 6 | 7 | ### 중요한 점은 codinkeys를 활용하지 않으면, 프로퍼티의 이름들을 json에 있는 속성들의 이름과 동일하게 설정해놓아야 한다는 것이다. 8 | 9 | 10 | 11 | ### encodable은 반대로, 스위프트 오브젝트를 data type의 오브젝트로 변환할 수 있게하는 프로토콜이다. 이 것도 역시 마찬가지도 JSONEncoder를 활용하면 json형태로 만들 수 있으며, 이렇게 변환된 data는 .utf8 형식을 활용하면 string 형태로 확인할 수 있다. 12 | 13 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Convinience init에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Convinience init에 대해 설명하시오 2 | 3 | 4 | 5 | - ### 보조 이니셜라이져 6 | 7 | ### 클래스의 기본 이니셜라이져를 도와주는 역할 8 | 9 | 10 | 11 | 12 | 13 | - ### convinience init은 같은 클래스에서 다른 이니셜라이져를 호출해야만 한다. 14 | 15 | 16 | 17 | ### 사용하는 방식은 convinience init 안에 있는 기본 이니셜라이저 호출 부에서 디폴트로 값을 정해 놓을 속성들의 값은 미리 적어두고, 값을 새로 주입 받을 속성에 대해서만 convinience init으로부터 주입 받는 방식으로 사용된다. convinience init 블록 안에서 self.init()을 작성하고, convinience init으로 새로 주입 받을 값을 self init안에 주입한다. 18 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오 2 | 3 | 4 | 5 | ### Delegate 패턴은, 주로 뷰컨트롤러간의 통신에 활용한다. 예를 들어, 어떤 인스턴스에서 네트워크 통신을 한다고 해보자. 이 네트워크 통신이 완료되면, 다른 뷰컨트롤러에서 해당 정보와 함께 ui를 업데이트 해야한다. 이 경우, 네트워크 통신을 하는 인스턴스에서 네트워크 통신이 다 되면, 통신결과를 protocol에 선언해 둔 메소드의 파라미터로 넘겨주며 대리자, 즉 UI를 업데이트 해야하는 뷰 컨트롤러가 protocol 메소드를 실행하게 하는 것이다. -------------------------------------------------------------------------------- /supersupremekim/Swift/Delegates와 Notification 방식의 차이점에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Delegates와 Notification 방식의 차이점에 대해 설명하시오 2 | 3 | ## delegate는 대리자에게 프토토콜로 해야하는 일을 정의하고, 해당 프로토콜을 채택한 객체가 정해놓은 시점에 정해놓은 해야하는 일을 하는 것이다. 해당 일을 처리하는 데 필요한 정보도 프로토콜 메소드의 파라미터로 넘겨주며 Delegate 는 대부분 객체와 또다른 객체 간의 1:1 소통을 할 때 주로 쓰인다. - 비동기로 수정하기 4 | 5 | 6 | 7 | ## Notification은 설정해놓은 시점에 한 객체에서 다른 객체들로 이름을 정해놓은 어떤 메시지를 보내는 것이다. 노티피케이션 센터에서 옵저버를 추가해놓은 모든 객체는 이 메시지를 들으며, selector에서 설정해놓은 메소드가 작동하게 된다. 이 객체는 싱글턴으로 동작하며, 객체들이 1 대 다수의 소통을 할 때 주로 쓰인다. 때문에 남용하게 되면, 이 메시지를 어느 객체들이 받는 가에 대해서 혼란을 초래할 수 있다. 8 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Extension에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Extension에 대해 설명하시오 2 | 3 | 4 | 5 | extension은 기존의 클래스, 구조체, 열거형, 프로토콜 타입에 새로운 기능을 추가하는 것이다. 실제 사용을 할 때, Int나 Double, Date 같은 기본 타입을 extension으로 구현해 새로운 매소드나 computed property를 추가해서 필요한 기능을 추가하기도 한다. 하지만 기존 기능들을 오버라이딩 할 수는 없고 stored property는 추가할 수 없다. -------------------------------------------------------------------------------- /supersupremekim/Swift/Generic에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Generic에 대해 설명하시오 2 | 3 | 4 | ### generic의 목적은, 일단 일반적인 상황에서 코드를 작성해서 이후 코드를 실제 사용할 때, 어떤 타입에도 유연하게 대응하는 코드를 구현하기 위함이다. 제네릭으로 구현된 코드는 재사용하기도 쉽고, 코드의 중복을 줄일 수 있다. 5 | 6 | ### 제네릭을 구현할 때는 보통, 메소드나 커스텀 타입을 정의할 때 주로 쓰는데, 메소드의 경우 구체적인 실제 타입을 써주는 대신에 플레이스 홀더 T를 추가하는 방식으로 제네릭을 이용하여 함수를 구현하고, 실제 이 함수를 호출하는 때에 구체적인 타입의 인스턴스를 넘겨준다. 제네릭 타입의 경우에도 정의부에는 플래이스 홀더를 써서, 이 플래이스 홀더가 어떤 타입이라는 것만 명시하고, 실제 해당 타입의 인스턴스를 생성할 때 구체적인 타입을 정해준다. 제네릭를 쓸 때, 메소드나 클래스에서 제네릭을 쓸 경우, 제네릭 타입의 제약을 걸어줄 수도 있다. 7 | 8 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Hashable이 무엇이고, Equatable을 왜 상속해야 하는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Hashable이 무엇이고, Equatable을 왜 상속해야 하는지 설명하시오 2 | 3 | 4 | 5 | ### hashable은 set, dictionary의 key와 같이 임의의 자료형을 정수의 값으로 변환하여 각각의 인스턴스를 정수값을 통해 접근할 수 있도록 한다. Equatable을 프로토콜을 준수해야 하는 이유는, hashable을 통해서 변환된 정수 값을 바탕으로 인스턴스를 비교하여 찾아야 하기 때문이다. 6 | 7 | ### Hashable 프로토콜을 준수하는 모든 타입의 인스턴스는 hashValue라는 정수형 프로퍼티를 갖고 있고, 이값은 각각의 인스턴스를 식별하는 값이 된다. 8 | 9 | ### 해시값은 프로그램 실행마다 같은 값을 보장하지 않는다. -------------------------------------------------------------------------------- /supersupremekim/Swift/KVO 동작 방식에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 KVO 동작 방식에 대해 설명하시오 2 | 3 | 4 | 5 | ## 특정 키의 값 변화를 감지하기 위한 기능 6 | 7 | 8 | 9 | #### 프로퍼티에 @objc dynamic 키워드를 붙여서 해당 프로퍼티가 변경될 때마다 코드가 실행되도록 하는 방식. 10 | 11 | #### willset didSet과 유사한 개념이며 , 클래스 정의 부 밖에서 인스턴스에 observe 키워드를 활용하여 사용한다. -------------------------------------------------------------------------------- /supersupremekim/Swift/MVC 구조에 대해 블록 그림을 그리고, 각 역할과 흐름을 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 MVC 구조에 대해 블록 그림을 그리고, 각 역할과 흐름을 설명하시오 2 | 3 | ![image-20210818221535211](/Users/kimdonghwan/Library/Application Support/typora-user-images/image-20210818221535211.png) 4 | 5 | 6 | 7 | ### 뷰와 모델은 직접 소통하지 않고, 컨트롤러가 둘의 중간에서 둘의 매개체 역할을 한다. 모델은 데이터를 보관하고, 비즈니스 로직을 처리하며 처리한 데이터를 컨트롤러에 보내면 뷰컨트롤러는 뷰에 해당 내용을 그리고, 뷰는 유저와 인터렉션을 해 이것을 다시 컨트롤러에 보내면 해당 이벤트에 대한 처리 요청을 모델에게 하는 방식으로 작동한다. 8 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Optional 이란 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Optional 이란 무엇인지 설명하시오 2 | 3 | 4 | 5 | ### Optional - 스위프트의 특성 중 안전성을 담보해주는 기능. 값이 있을 수도 없을 수도 있음을 나타내는 표현이다. 옵셔널과 옵셔널이 아닌 타입을 철저히 다른 타입으로 인식하기 때문에 컴파일할 때 오류를 걸러낼 수 있다. 예를 들어서 앱이 실행되다가 네트워킹 등 수 많은 경우들에 의해서 값이 아직 들어오지 않은 인스턴스로 다른 작업을 하는 코드를 만나면 앱이 실행 중지된다. 이러한 경우, 옵셔널 바인딩 기능을 사용해서 앱이 실행 중지되는 것을 방지할 수 있다. 추가로 optional은 값이 있는 경우와 없는 경우 nil을 나타내는 enum 타입이어서, switch 문으로 옵셔널 값을 분기하여 데이터를 활용할 수 있다. 6 | -------------------------------------------------------------------------------- /supersupremekim/Swift/README.md: -------------------------------------------------------------------------------- 1 | - [x] struct와 class와 enum의 차이를 설명하시오. 2 | - [x] class의 성능을 향상 시킬수 있는 방법들을 나열해보시오. 3 | - [x] Convinience init에 대해 설명하시오. 4 | - [x] Anyobject에 대해 설명하시오. 5 | - [x] Optional 이란 무엇인지 설명하시오. 6 | - [x] Struct 가 무엇이고 어떻게 사용하는지 설명하시오. 7 | - [x] Subscripts에 대해 설명하시오. 8 | - [x] instance 메서드와 class 메서드의 차이점을 설명하시오. 9 | - [x] Delegate 패턴을 활용하는 경우를 예를 들어 설명하시오. 10 | - [x] Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오. 11 | - [x] KVO 동작 방식에 대해 설명하시오. 12 | - [x] Delegates와 Notification 방식의 차이점에 대해 설명하시오. 13 | - [x] 멀티 쓰레드로 동작하는 앱을 작성하고 싶을 때 고려할 수 있는 방식들을 설명하시오. 14 | - [x] MVC 구조에 대해 블록 그림을 그리고, 각 역할과 흐름을 설명하시오. 15 | - [x] 프로토콜이란 무엇인지 설명하시오. 16 | - [x] Hashable이 무엇이고, Equatable을 왜 상속해야 하는지 설명하시오. 17 | - [x] mutating 키워드에 대해 설명하시오. 18 | - [x] 탈출 클로저에 대하여 설명하시오. 19 | - [x] Extension에 대해 설명하시오. 20 | - [x] 접근 제어자의 종류엔 어떤게 있는지 설명하시오 21 | - [x] defer란 무엇인지 설명하시오. 22 | - [x] defer가 호출되는 순서는 어떻게 되고, defer가 호출되지 않는 경우를 설명하시오. 23 | - [x] property wrapper에 대해서 설명하시오. 24 | - [x] Generic에 대해 설명하시오. 25 | - [x] Result타입에 대해 설명하시오. 26 | - [x] Codable에 대하여 설명하시오. 27 | 28 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Result타입에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Result타입에 대해 설명하시오. 2 | 3 | ### 성공 혹은 실패에 대한 정보를 담는 타입이다. 특히 네트워크 통신에 실패한 경우, Error 프로토콜를 채택한 열거형을 정의해서, 오류 case를 failure 키워드와 함께 컴플리션 함수의 파라미터로 전달하는 방식으로 쓴다. 4 | 5 | ### 컴플리션 핸들러를 활용하는 함수부에서는 보통, switch를 활용하여 success와 failure로 분기하고, 연관값을 받아 각각의 로직을 처리한다. 6 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Singleton 패턴을 활용하는 경우를 예를 들어 설명하시오 2 | 3 | 4 | 5 | ### Singleton 패턴은 그리고 앱 내에서 하나의 객체만 있으면 되고, 그 객체가 여기저기서 불리며 일을 할 필요가 있을 때 구현한다. 그리고, 여기저기 불려다니면서 생기는 그 객체의 내부 프로퍼티의 변경사항을 모두 공유할 수도 있다. 주로 클래스 안에서 static 변수 혹은 상수로 shared를 선언해 놓고, 클래스 자기자신의 객체를 대입하는 형태로 기본 셋팅을 한다. 실제 예를 들어서, Todo 앱을 만든다고 하자. 이런 경우, 앱 내의 여러 뷰컨트롤러에서 할 일의 목록을 추가하고 수정할 것이다. 이런 경우, 모든 뷰컨트롤러마다 인스턴스를 만들어서 작업하는 것은 비효율적이다. 그런 경우 TodoManager의 static 상수인 shared를 통해서 싱글턴 패턴을 통해 원하는 작업을 실행하면서 다음 할 일의 id를 바꿔주며, 그 id를 싱글턴 패턴을 사용하는 곳에서 모두 공유할 수 있다. -------------------------------------------------------------------------------- /supersupremekim/Swift/Struct 가 무엇이고 어떻게 사용하는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Struct 가 무엇이고 어떻게 사용하는지 설명하시오 2 | 3 | ### 클래스와 함께 데이터를 용도에 맞게 묶어 표현하고자 할 때 사용되는 것이다. 다만 struct의 인스턴스는 값 타입이어서, 선언 정의 후 인스턴스의 속성을 바꾸기 위해서는 변수로 선언해야 한다. struct는 상속성이 없는 것이 특징이고, 구조체 안에 값이 바뀔 때마다 구조체가 파괴되었다가 다시 만들어지는 방식으로 작동하기 때문에 구조체 안에 있는 메소드가 구조체의 속성을 변경할 때는 메서드 앞에 mutating 키워드를 붙여줘야 한다. 4 | -------------------------------------------------------------------------------- /supersupremekim/Swift/Subscripts에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 Subscripts에 대해 설명하시오 2 | 3 | 4 | 5 | ### 대괄호와 그 안의 값을 넣어서 해당 인덱스나 키의 값을 가져올 때 활용하는 것. 6 | 7 | ### 서브스크립트구현할 때는 subscript 키워드를 사용하여 정의하고, 읽고 쓰거나 쓰기만 가능하게 구현할 수 있으며, 자신이 가지는 시퀀스나 컬렉션 등의 요소를 반환하고 설정할 때 주로 사용된다. 필요에 따라 복수의 서브 스크립트도 구현할 수 있고 static키워드를 붙여서 타입 서브스크립트로도 정의할 수 있다. -------------------------------------------------------------------------------- /supersupremekim/Swift/class의 성능을 향상 시킬수 있는 방법들을 나열해보시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 class의 성능을 향상 시킬수 있는 방법들을 나열해보시오 2 | 3 | 4 | 5 | 성능 영향 요소 - allocation, reference counting, method dispatch 6 | 7 | Stack - 단순 구조, 메모리 할당 해제 편리. 단순 구조 - O(1) 으로 속도 빠름 8 | 9 | Struct, enum, tuple 10 | 11 | 12 | 13 | Heap - 복잡 구조, heap영역에서 사용하지 않는 블록을 찾아 메모리 할당. 여러 스레드가 동시에 힙에 메모리를 할당할 수 있기 떄문에 무결성 보호 해야함. 14 | 15 | 16 | 17 | 18 | 19 | -> stack 비용 적고, 속도 빠름 20 | 21 | 복사된 인스턴스마다 기존 인스턴스와 구분되어져 stack에 저장되기 때문에 내부 값 변경해도 원래 값에 영향을 주지 않음. Reference count도 사용하지 않음 22 | 23 | 24 | 25 | -> class 26 | 27 | stack에는 reference 주소값을 할당하고, 실질적인 데이터는 heap에 할당. class, function 28 | 29 | 어떤 클래스의 인스턴스를 생성하고 복사하면 stack에 있는 주소값이 복사되기 때문에 주소값을 넘겨받은 인스턴스들은 모두 같은 값을 가리키게 됨. 30 | 31 | 32 | 33 | ### 성능 향상 - heap allocation 피하기 - 딕셔너리를 만들 때 string 대신에 structure를 쓴다 , heap 영역의 메모리 해제 - structure라도 reference semantics를 따르는 타입의 프로퍼티를 가지면 reference counting은 발생한다. 구조체의 레퍼런스 개수가 많으면 오버헤드가 늘어나기 때문에 class 보다 reference counting이 많이 발생한다. 레퍼런스 카운팅 줄이기 - 구조체 안에 string을 structure나 enum등 값 타입으로 바꾼다. 34 | 35 | -------------------------------------------------------------------------------- /supersupremekim/Swift/defer가 호출되는 순서는 어떻게 되고, defer가 호출되지 않는 경우를 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 defer가 호출되는 순서는 어떻게 되고, defer가 호출되지 않는 경우를 설명하시오 2 | 3 | 4 | 5 | ### 다수로 선언된 defer의 호출 순서는 선언이 되어있는 역순이다. 6 | 7 | 8 | 9 | ### 호출되지 않는 경우는 throw 함수가 실행 중간에 오류를 던져서 해당 defer까지 실행되지 않는 경우, 10 | 11 | ### 함수 안의 Guard 문에서 조건에 맞지 않아 함수가 리턴되었을 때, defer까지 실행되지 않는 경우. 12 | 13 | ### 즉, 코드 진행 범위 안에 들어온 defer까지만 호출되고 진행이 멈춘 후에 선언된 defer는 호출되지 않는다. 14 | 15 | -------------------------------------------------------------------------------- /supersupremekim/Swift/defer란 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 defer란 무엇인지 설명하시오. 2 | 3 | 4 | 5 | ### defer - 현재 스코프를 벗어나기 직전에 꼭 실행되는 코드 블록을 작성해줄 수 있는 기능. 이러한 특징 때문에 오류처리를 할 때 유용하게 쓰일 수 있다. 예를 들어, 함수 내에서 파일을 열어 사용하다가 오류가 발생하여 코드가 블록을 빠져나가더라도, 파일을 정상적으로 닫아 메모리에서 해제될 수 있도록 할 수 있다. defer문 내부에는 break, return과 같이 코드 블록을 빠져나갈 수 있는 코드 또는 오류를 던지는 코드는 작성하면 안된다. 6 | 7 | ### defer 여러 개가 같은 레벨에서 블록 내부에 속해있다면 선언 된 역순으로 실행되며, 함수 중간에 에러 등으로 종료된다면 이후에 있는 defer문은 실행되지 않는다. 8 | -------------------------------------------------------------------------------- /supersupremekim/Swift/instance 메서드와 class 메서드의 차이점을 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 instance 메서드와 class 메서드의 차이점을 설명하시오 2 | 3 | 4 | 5 | ### 인스턴스 메소드 - 인스턴스에 속하는 함수. 반드시 인스턴스가 생성되어야만 메소드 사용 가능. 6 | 7 | 8 | 9 | ### 클래스 메소드 - 타입 메소드의 일종으로, 인스턴스를 생성하지 않고 사용 가능하며 메소드 이름 앞에 class 키워드를 사용하여 표기한다. Static 메소드는 서브 클래스에서 override할 수 없지만, class 메소드는 오버라이드 할 수 있다. 10 | -------------------------------------------------------------------------------- /supersupremekim/Swift/mutating 키워드에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 mutating 키워드에 대해 설명하시오 2 | 3 | 4 | 5 | ## Struct 나 enum 같은 값 타입 인스턴스들은 immutable하다. immutable의 뜻은 무언가 변화가 일어나면 전에 것이 파괴되고 새로운 것이 생겨난 다는 것이다. 만약, 값 타입 인스턴스 안의 메소드로 self의 어떤 속성을 변경하고자 한다면, 해당 메소드 앞에 mutating을 붙여줘야 새로운 값을 담은 객체가 새롭게 생겨난다. 반면 class의 method는 이 점에 대해서는 신경을 쓸 필요가 없다. 6 | -------------------------------------------------------------------------------- /supersupremekim/Swift/property wrapper에 대해서 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 property wrapper에 대해서 설명하시오 2 | 3 | 4 | 5 | ### Property wrapper는 어떤 타입 안에 중복되는 로직이 있다면 그 로직을 정의하는 타입을 만들어 코드를 dry하게 하는 것이다. 6 | 7 | ### 선언하는 방식은, @propertyWrapper키워드를 프로퍼티를 가질 수 있는 타입 앞에 붙이고 (class, struct, enum) 이 타입 안에 wrapped value를 선언 정의한다. 사용할 때는 변수 선언부 앞에 해당 키워드를 적어준다. -------------------------------------------------------------------------------- /supersupremekim/Swift/struct와 class와 enum의 차이를 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 struct와 class와 enum의 차이를 설명하시오 2 | 3 | 4 | 5 | 클래스는 참조타입으로, 같은 클래스의 인스턴스를 대입할 때마다, 주소가 복사되어 주소는 스택에 쌓이지만, 주소 값이 레퍼런싱하는 곳은 같다. 6 | 7 | 하지만 structure와 enum은 값 타입으로 복사될 때마다, 값이 복사된다. 8 | 9 | 10 | 동일한 클래스의 인스턴스의 주소 값이 복사된 여러 변수들이 있을 때, 인스턴스 간 단 하나의 주소를 공유하기 때문에, 하나의 변수를 통해 클래스에 접근해서 값을 바꿔도, 다른 변수로 해당 클래스 데이터에 접근하면 같은 값을 출력한다. 반대로 값 타입 인스턴스들은 각각의 값을 따로 가지기 때문에 어떤 인스턴스의 값을 바꿔도 다른 인스턴스의 속성에는 영향을 미치지 못한다. 11 | 12 | 13 | 추가로 enum은 스토어드 프로퍼티가 올 수 없다는 점과, class와 구조체의 가장 큰 차이점은 상속의 가능성 여부다. 14 | -------------------------------------------------------------------------------- /supersupremekim/Swift/멀티 쓰레드로 동작하는 앱을 작성하고 싶을 때 고려할 수 있는 방식들을 설며.md: -------------------------------------------------------------------------------- 1 | # 🐥 멀티 쓰레드로 동작하는 앱을 작성하고 싶을 때 고려할 수 있는 방식들을 설명하시오 2 | 3 | 4 | 5 | ### GCD 멀티코어 하드웨어에서 시스템이 관리하는 큐에 작업을 넣어서 코드를 병렬적으로 실행시키는 것. 6 | 7 | 8 | 9 | ### Dispatch queue - 작업을 블록 객체 형태로 dispatchqueue에 넣는다. Global queue에서는 qos를 설정해서, 해당 작업의 우선순위를 설정할 수 있다. 10 | 11 | ### NSOperation - Operation 12 | 13 | ### Operation 객체를 queue에 넣어서 비동기적으로 실행할 수 있다. -------------------------------------------------------------------------------- /supersupremekim/Swift/접근 제어자의 종류엔 어떤게 있는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 접근 제어자의 종류엔 어떤게 있는지 설명하시오 2 | 3 | ### 객체지향 프로그래밍에서 캡슐화와 은닉화를 구현하기 위한 기능. 4 | 5 | ### 제어 강도의 순서로 나열하면 다음과 같다. private, fileprivate, internal, public, open. 6 | 7 | ### 기본 접근 제어 레벨, 즉, 변수나 상수, 메소드 앞에 아무것도 붙이지 않는다면 internal로 설정이 되어서 같은 프로젝트 안에 있다면 앱 모듈 안에서는 어디서나 접근이 가능하다. 하지만, fileprivate으로 설정된 것은 같은 파일 안에서만 접근이 가능하고, private은 structure나 class의 중괄호 안에서만 접근이 가능하다. 보통 상황에서는 위 세 개의 접근 제어자를 쓰지만, 라이브러리나 프레임워크에서는 public이나, open을 흔히 볼 수 있다. public은 모듈을 뛰어넘어서 접근할 수 있는 것이고, open은 클래스와 클래스의 멤버에서만 사용할 수 있는데 public 보다 더 개방된 접근이며 class가 상속되거나 함수가 overriding 될 수도 있는 것이다. 8 | 9 | ### 규칙은, 상위 요소보다 하위 요소가 더 개방된 접근 수준을 가질 수 없다는 것이다. 10 | 11 | ### 어떠한 클래스 내부의 속성이 읽기는 가능하게 하고, 쓰기만 제한하려면 private (set) 과 같이 쓸 수 있다. 12 | 13 | ### 코드를 안전하게 사용하기 위해서는 기본적으로 private으로 설정하고, 그 다음 필요하다면 접근 제어 강도를 낮추는 것이 좋다. 14 | -------------------------------------------------------------------------------- /supersupremekim/Swift/탈출 클로저에 대하여 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 탈출 클로저에 대하여 설명하시오 2 | 3 | ### 함수의 전달인자로 전달한 클로저가 함수 종료 후에 호출될 때 클로저가 함수를 탈출한다고 한다. 이러한 기능을 구현하고자 할 때, 클로저에 escaping 키워드를 붙여줌으로써 구현한다. 4 | 5 | ### 원래 함수로 전달된 파라미터들이나, 함수안에 선언 정의 된 변수 또는 상수들은 해당 함수가 반환되면 메모리에서 사라진다. 하지만, 함수의 인자로 전달된 탈출 클로저는 해당 함수가 반환된 이후에도, 메모리에서 사라지지 않고, 다른 어딘가로 가서 실행될 수 있다. 이러한 기능은 비동기 작업으로 함수가 종료되고 난 후 호출될 필요가 있는 클로저를 사용해야 할 때 쓰기 적절하다. 이 경우 해당 클로저 앞에 @escaping 키워드를 붙여줘야 한다. 탈출 클로저는 함수를 빠져나가 클래스를 왔다갔다도 할 수 있기 때문에, 클로저 내부에서 self를 쓰는 것은 클로저를 사용하는 클래스 주소 값을 복사해두는 것이고, 그렇기 때문에 weak키워드를 써서 메모리 누수에 유의해야 한다. 6 | -------------------------------------------------------------------------------- /supersupremekim/Swift/프로토콜이란 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🐥 프로토콜이란 무엇인지 설명하시오. 2 | 3 | 4 | ### 해당 클래스 또는 구조체나 열거형과 같은 타입이 특정 역할을 하기 위해서 가져야하는 속성이나 메소드 이니셜라이저, 즉 요구사항들을 정의해놓은 것. 프로토콜은 정의를 하고 제시를 할 뿐 프로토콜 자체는 스스로 기능을 구현하지는 않는다. 비슷한 성격을 가진 상속을 생각해봤을 때, 모든 속성과 메소드를 물려받는 다는 점에서 보면 자식 클래스와 부모 클래스의 관계가 너무 밀접해진다는 단점을 갖는다. 프로토콜 방식을 활용하면, 원하는 속성과 메소드만 골라 프로토콜을 정의하고 클래스에 주입하면서 경우에 따라 유연하게 활용할 수 있다. 5 | 6 | ### 프로퍼티의 속성이라면, 채택한 클래스나 구조체에서 반드시 구현해야 하는데 프로토콜에서 해당 속성이 읽기, 쓰기로 선언되어 있다면 클래스의 정의부에서도 읽기와 쓰기 둘다 가능하게 정의해 놓아야 하고, 프로토콜에서 읽기 기능만 명시되어 있는 경우엔, 클래스에서 속성을 읽기 쓰기 둘 다 가능하게 구현할 수 있다. 7 | 8 | ### 메서드의 경우, 프로토콜에서 함수 이름과, 파라미터만 명시해 놓고 실제 클래스에서 함수 기능부를 작성한다. 만약, 구조체가 채택하는 경우도 있으며 구조체 내부의 속성을 변경하는 메소드가 있다면 mutating 키워드를 프로토콜 메서드에 붙여줘야 한다. 9 | 10 | ### 프로토콜도 서로 상속될 수 있으며 class키워드를 프로토콜에 추가하면 클래스 전용 프로토콜도 정의할 수 있다. 또한 프로토콜 이름을 타입으로 갖는 변수 또는 상수에는 그 프로토콜을 준수하는 타입의 어떤 인스턴스라도 할당할 수 있다. 11 | -------------------------------------------------------------------------------- /supersupremekim/iOS/@Main에 대해서 설명하시오..md: -------------------------------------------------------------------------------- 1 | # 🍎 @Main에 대해서 설명하시오. 2 | 3 | 4 | 5 | Xcode 12부터 AppDelegate 파일 안, AppDelegate 클래스 위에 쓰여져 있는 것인데, 스위프트 프로그램의 진입 포인트를 마킹해 놓은 것이다. 6 | 7 | 8 | 9 | 앱이 시작되는 순간 @Main을 통해 UIApplicationMain 메소드가 호출되고, 이것이 응용프로그램 객체 UIApplication을 (앱의 life cycle 담당) 만든다. 또한 시스템은 AppDelegate클래스의 인스턴스(app delegate - 앱 내용이 그려질 창을 만듦)를 생성하고 이를 UIApplication 객체에 할당한다. 마지막으로 시스템은 앱을 실행한다. 10 | 11 | 12 | 13 | cf) 프로그램은 단 하나의 진입 포인트가 있어야만 한다. 14 | 15 | -------------------------------------------------------------------------------- /supersupremekim/iOS/App Bundle의 구조와 역할에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 App Bundle의 구조와 역할에 대해 설명하시오 2 | 3 | 4 | 5 | ### app bundle은 앱의 성공적인 작동에 필요한 모든 것을 저장한 것 6 | 7 | 8 | 9 | ### 필수 10 | 11 | - #### 어플리케이션 코드를 포함하는 실행 파일. 파일의 이름은 애플리케이션 이름에서 .app 확장자를 뺀 것과 같음 12 | 13 | - #### Info.plist. 번들 ID, 버전 번호 같은 애플리케이션에 대한 구성 정보가 포함되어 있음 14 | 15 | - #### Resource files. 실행 파일 외부에 있는 데이터 파일. 이미지, 아이콘, 사운드 파일 등으로 구성됨. 16 | 17 | - #### 아이콘 18 | 19 | ### 권장 20 | 21 | - #### Launch Images. 앱 초기 인터페이스 이미지. 22 | 23 | - #### MainWindow.nib. 프로그램 시작 시 로드할 기본 인터페이스 객체가 포함되어 있음. nil파일에는 기본 창 객체와 프로그램 delegate객체가의 인스턴스가 포함됨 24 | 25 | - #### Settings.bundle.설정 어플리케이션에 추가하려는 앱 별 환경 설정을 포함하는 특수 유형의 플러그인 26 | 27 | -------------------------------------------------------------------------------- /supersupremekim/iOS/App의 Not running, Inactive, Active, Background, Suspended에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 App의 Not running, Inactive, Active, Background, Suspended에 대해 설명하시오 2 | 3 | 4 | 5 | - ### Not running 6 | 7 | 앱을 키지 않았거나 종료한 상태 8 | 9 | - ### Inactive 10 | 11 | 앱의 상태변화시에 거치게 됨. 사용자 이벤트는 받지 않음 12 | 13 | - ### Background 14 | 15 | Suspended전의 상태. 앱이 보이지 않지만 뒤에서 돌아가고 있는 상태 16 | 17 | - ### Suspended 18 | 19 | 아무 코드도 실행하지 않고 시스템에서 임의로 리소스 해제 가능 20 | 21 | - ### Active 22 | 23 | 이벤트를 받고, 앱이 실행 중 24 | 25 | 26 | 27 | applicationWillResignActive 28 | 29 | 30 | 31 | applicationDidEnterBackground 32 | 33 | 34 | 35 | applicationWillEnterForeground 36 | 37 | 38 | 39 | applicationDidBecomeActive 40 | 41 | 42 | 43 | applicationWillTerminate 44 | 45 | 46 | 47 | willFinishLaunching 48 | 49 | 50 | 51 | didFinishLaunching 52 | 53 | - ### Active -> Background 54 | 55 | ### 홈키를 누르고 홈화면 이동 56 | 57 | ### 잠금 누름 58 | 59 | ### 앱에서 다른 앱 이동 60 | 61 | 62 | 63 | - ### Active -> InActive (background 아님) 64 | 65 | ### App Switcher 66 | 67 | ### 전화 올 때 68 | 69 | ### 문자 확대 70 | 71 | ### 상단 스크롤 해서 알림센터 보는 경우 72 | 73 | ### 제어센터 보는 경우 74 | 75 | 76 | 77 | -------------------------------------------------------------------------------- /supersupremekim/iOS/Delegate란 무언인가 설명하고, retain 되는지 안되는지 그 이유를 함께 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 Delegate란 무언인가 설명하고, retain 되는지 안되는지 그 이유를 함께 설명하시오 2 | 3 | 4 | 5 | ### Delegate란 일을 대신해주는 대리자의 개념으로 생각해볼 수 있다. Delegate pattern에서는 뷰컨트롤러간에 통신을 할 때, 대리자에게 필요한 정보를 제공하고 일을 위임하고, 대리자, 주로 뷰 컨트롤러는 정보를 받아서 해당 뷰컨트롤러에서 일을 처리한다. 할 일을 위임할 수 있어서 코드 재사용이 가능하고 delegate pattern에서는 기능이 하나의 뷰컨트롤러에 집중되는 것을 방지할 수 있다. 6 | 7 | 8 | 9 | #### Retain - 어떤 객체에 대한 메모리가 해제되지 않고 유지되어 누수가 생기는, 낭비가 되고있는 현상. 10 | 11 | 12 | 13 | ### Delegate 또한 객체간의 참조가 이뤄지기 때문에 retain이 된다. 14 | 15 | -------------------------------------------------------------------------------- /supersupremekim/iOS/Foundation Kit은 무엇이고 포함되어 있는 클래스들은 어떤 것이 있는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 Foundation Kit은 무엇이고 포함되어 있는 클래스들은 어떤 것이 있는지 설명하시오. 2 | 3 | 4 | 5 | ### 앱 기본 실행의 기본이 되는 필수적 data type과 컬렉션, os system service에 접근할 수 있게 하는 것. 6 | 7 | #### foundation으로 데이터 저장, 텍스트 처리, 시간과 날짜 계산이나 네트워킹 등을 작업을 할 수 있다. 8 | 9 | number(Int, float, double) 10 | 11 | data 12 | 13 | string 14 | 15 | array, dictionaries, sets 16 | 17 | Data formatting(convert numbers, dates, measurements to and from locale-aware string representation) -------------------------------------------------------------------------------- /supersupremekim/iOS/GCD API 동작 방식과 필요성에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 GCD API 동작 방식과 필요성에 대해 설명하시오 2 | 3 | 4 | 5 | 동작 방식 - DispatchQueue.main - main thread queue . 기본적으로 serial queue (직렬 큐)로 동작 6 | 7 | 8 | 9 | DispatchQueue.global - background thread queue 기본적으로 Concurrent Queue(병렬 큐)로 동작 10 | 11 | 둘다 큐라 큐에 추가된 순서대로 계속 시작됨 12 | 13 | QoS를 이용해 우선 순위를 정해줄 수 있음 -> 앱의 에너지 효율이 좋아짐 14 | 15 | 16 | 17 | userInteractive 18 | 19 | userInitiated 20 | 21 | default 22 | 23 | utility 24 | 25 | background 26 | 27 | unspecified 28 | 29 | 30 | 31 | 나만의 큐를 만들 수 도 있음 32 | 33 | DispatchQueue(label: "name") attribute .concurrent 지정 안해주면 그냥 Serial Queue가 됨 34 | 35 | 36 | 37 | 필요성 - 서버와 데이터 통신할 때 많이 쓰는데, 이 작업을 비동기로 처리하지 않고 동기 방식으로 차례대로 실행시킨다면, 통신 작업이 끝날 때까지 기다려야해서 앱이 멈춘다. 그래서 이러한 작업들을 GCD API를 활용하여 비동기 방식으로 처리한다. 작업 간 순서가 중요할 때 필요하다. 38 | 39 | -------------------------------------------------------------------------------- /supersupremekim/iOS/Global DispatchQueue 의 Qos 에는 어떤 종류가 있는지, 각각 어떤 의미인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 Global DispatchQueue 의 Qos 에는 어떤 종류가 있는지, 각각 어떤 의미인지 설명하시오. 2 | 3 | 4 | 5 | 1. ### userInteractive 6 | 7 | - main thread 에서 작업. ui 새로고침 또는 애니메이션 수행과 같이 사용자와 상호작용 8 | - 작업이 신속하게 수행되지 않으면 ui 중단 상태될 수 있음 9 | - 순식간에 끝난다 10 | 11 | 2. ### userInitiated 12 | 13 | - 사용자가 시작한 작업, 저장된 문서를 열거나, 사용자 인터페이스에서 무언갈를 클릭할 때 작업 수행처럼 즉각적인 결과 필요할 때 14 | - 사용자와 상호작용을 위해서는 작업이 필요함 15 | - 몇 초 그 이하 16 | 17 | 3. ### default 18 | 19 | - QoS정보 할당되지 않은 작업은 default에서 20 | 21 | 4. ### utility 22 | 23 | - 데이터 다운로드, import와 같은 즉각적 결과 필요하지 않음 24 | 25 | 5. ### background 26 | 27 | - background에서 작동, 동기화 및 백업 사용자가 볼 수 없는 작업 28 | - 상당한 시간이 걸림 -------------------------------------------------------------------------------- /supersupremekim/iOS/NSCache와 딕셔너리로 캐시를 구성했을때의 차이를 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 NSCache와 딕셔너리로 캐시를 구성했을때의 차이를 설명하시오 2 | 3 | 4 | 5 | ### NSCache - 메모리 캐싱에 주로 사용되는 클래스. Key value 형태의 데이터를 임시로 저장하는 데 사용할 수 있고 자원 부족시 삭제 대상이 된다. 6 | 7 | 8 | 9 | ### NSCache는 메모리 관리가 기본적으로 제공된다. 10 | 11 | ### 다른 앱에서 메모리를 더 사용하려고 하면 캐시되어 있던 데이터를 지우고 메모리를 해제한다. 12 | 13 | 14 | 15 | 16 | 17 | ### Cf) 메모리 캐시는 어플리케이션 메모리 영역의 일부분을 캐싱에 사용하는 것이다. 처리 속도가 빠르지만 저장 공간이 작다, 18 | 19 | ### 디스크 캐시는 데이터를 파일 형태로 디스크에 저장하는 것이다. 저장 공간은 크지 파일 입출력으로 인한 처리 속도는 상대적으로 느리다. -------------------------------------------------------------------------------- /supersupremekim/iOS/NSOperationQueue 와 GCD Queue 의 차이점을 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 NSOperationQueue 와 GCD Queue 의 차이점을 설명하시오 2 | 3 | 4 | 5 | ### **동기** 6 | 7 | - 코드가 "순차적"으로 실행되는 것. 8 | - 동기적으로 실행될 때 파일 입출력 등 시간이 오래 걸리는 작업이 진행된다면, 해당 코드에서 모든 작업이 끝날 때까지 기다렸다가 다음 코드를 실행한다. 9 | 10 | ### **비동기** 11 | 12 | - 코드가 순차적으로 실행되는 것을 보장하지 않는다. 비동기적으로 실행하는 코드가 있다면, 우선 다음 코드를 실행하고, 비동기 코드가 끝나면 콜백을 받아 실행한다. 13 | - 스레드는 로우 레벨의 툴이기 때문에 개발자가 직접 제어하는 것은 까다롭다. iOS에서는 스레드를 직접 만드는 대신에 앱에서는 특정 태스크만 정의하고 시스템이 스레드를 관리한다. 14 | 15 | 16 | 17 | ### GCD(Grand Central Dispatch) Queue - DispatchQueue 18 | 19 | - 앱의 기본 스레드 또는 백그라운드 스레드에서 작업 실행을 serial 또는 concurrent 방식으로 관리하는 개체 20 | - 개발자가 실행할 작업을 생성하고 Dispatch Queue에 추가하면 GCD는 작업에 맞는 스레드를 자동으로 생성해서 실행하고 작업이 종료되면 해당 스레드 제거 21 | - FIFO 22 | 23 | - 블록 형태의 태스크가 들어온다 24 | - Serial Queue(한번에 태스크 하나)와 Concurrent Queue(한번에 여러 태스크 처리)가 존재한다. 25 | - 시스템에 의해 관리되는 스레드 풀에서 태스크가 실행되나, 메인 큐를 제외하고 어떤 태스크가 어느 스레드에서 실행되는 지는 보장하지 않는다. 26 | - 동기적 / 비동기적으로 태스크를 처리할 수 있다. 27 | 28 | - 앱 실행시 시스템에서 2개의 Queue를 만들어준다. 29 | - Main queue 메인 스레드에서 사용되는 Serial queue로 모든 UI처리 30 | - Global Queue Concurrent Queue qos파라미터 제공. 병렬적으로 동시에 처리하기 때문에 작업 완료의 순서는 정할 수 없지만 우선적으로 일을 처리하게 할 수 있다. 31 | 32 | ### Async / sync (비동기 / 동기) 33 | 34 | - 동기sync - 하나의 작업이 끝날 때까지 기다림, 비동기 async - 기다리지 않음 35 | 36 | ### Serial/Concurrent 37 | 38 | - 한번에 실행하는 작업의 수 39 | 40 | 41 | 42 | ### NSOperation Queue 43 | 44 | - Obj-C기반으로 만들어진 API 45 | - 비교적 오버헤드가 있다 46 | - 다양한 작업들 가운데 의존성 추가, 재사용, 취소, 중지 가능 47 | 48 | 49 | 50 | # -> 답변 51 | 52 | GCD 53 | 54 | - 쉽고 편한 멀티 스레딩 처리를 위해 제공되는 api 55 | 56 | - 작업이 복잡하지 않고 간단하게 처리 57 | 58 | 59 | 60 | NSOperationQueue - 오버헤드 발생, 느리다. 시작되지 않은 작업을 취소할 수 있다. 61 | 62 | 동시에 실행할 수 있는 operation의 최대 수를 지정할 수 있음. 63 | 64 | -------------------------------------------------------------------------------- /supersupremekim/iOS/NotificationCenter 동작 방식과 활용 방안에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 NotificationCenter 동작 방식과 활용 방안에 대해 설명하시오 2 | 3 | 4 | 5 | 6 | 7 | ### Notification Center - 등록된 옵저버들에게 정보를 broadcast 해주는 메커니즘. 8 | 9 | 10 | 11 | ### 동작 방식 - 노티피케이션센터에서 Nsnotification에 이름을 붙여서 노티피케이션을 post하면, 해당 NSNotification의 옵저버로 등록되어 있는 클래스가 노티피케이션을 받고, selector에서 지정한 함수가 실행된다. 원하는 정보를 같이 보내기 위해서는 userInfo를 dictionary형식으로 전달한다. 12 | 13 | 14 | 15 | ### 활용 방안 - 백그라운드 작업의 결과, 비동기 작업의 결과 등 현재 작업의 흐름과 다른 흐름의 작업으로부터 이벤트를 받으려고 할 때 notification을 많이 활용한다. -------------------------------------------------------------------------------- /supersupremekim/iOS/README.md: -------------------------------------------------------------------------------- 1 | # iOS 2 | 3 | 4 | 5 | - [ ] Bounds 와 Frame 의 차이점을 설명하시오. 6 | - [ ] 실제 디바이스가 없을 경우 개발 환경에서 할 수 있는 것과 없는 것을 설명하시오. 7 | - [ ] 앱의 콘텐츠나 데이터 자체를 저장/보관하는 특별한 객체를 무엇이라고 하는가? 8 | - [x] 앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체를 무엇이라고 하는가? 9 | - [x] App thinning에 대해서 설명하시오. 10 | - [x] 앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가? 11 | - [x] @Main에 대해서 설명하시오. 12 | - [x] 앱이 foreground에 있을 때와 background에 있을 때 어떤 제약사항이 있나요? 13 | - [x] 상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오. 14 | - [x] 앱이 In-Active 상태가 되는 시나리오를 설명하시오. 15 | - [x] scene delegate에 대해 설명하시오. 16 | - [x] UIApplication 객체의 컨트롤러 역할은 어디에 구현해야 하는가? 17 | - [x] App의 Not running, Inactive, Active, Background, Suspended에 대해 설명하시오. 18 | - [x] NSOperationQueue 와 GCD Queue 의 차이점을 설명하시오. 19 | - [x] GCD API 동작 방식과 필요성에 대해 설명하시오. 20 | - [x] Global DispatchQueue 의 Qos 에는 어떤 종류가 있는지, 각각 어떤 의미인지 설명하시오. 21 | - [x] iOS 앱을 만들고, User Interface를 구성하는 데 필수적인 프레임워크 이름은 무엇인가? 22 | - [x] Foundation Kit은 무엇이고 포함되어 있는 클래스들은 어떤 것이 있는지 설명하시오. 23 | - [x] Delegate란 무언인가 설명하고, retain 되는지 안되는지 그 이유를 함께 설명하시오. 24 | - [x] NotificationCenter 동작 방식과 활용 방안에 대해 설명하시오. 25 | - [x] UIKit 클래스들을 다룰 때 꼭 처리해야하는 애플리케이션 쓰레드 이름은 무엇인가? 26 | - [x] App Bundle의 구조와 역할에 대해 설명하시오. 27 | - [x] 모든 View Controller 객체의 상위 클래스는 무엇이고 그 역할은 무엇인가? 28 | - [x] 자신만의 Custom View를 만들려면 어떻게 해야하는지 설명하시오. 29 | - [x] View 객체에 대해 설명하시오. 30 | - [x] UIView 에서 Layer 객체는 무엇이고 어떤 역할을 담당하는지 설명하시오. 31 | - [x] UIWindow 객체의 역할은 무엇인가? 32 | - [x] UINavigationController 의 역할이 무엇인지 설명하시오. 33 | - [x] TableView를 동작 방식과 화면에 Cell을 출력하기 위해 최소한 구현해야 하는 DataSource 메서드를 설명하시오. 34 | - [x] 하나의 View Controller 코드에서 여러 TableView Controller 역할을 해야 할 경우 어떻게 구분해서 구현해야 하는지 설명하시오. 35 | - [x] setNeedsLayout와 setNeedsDisplay의 차이에 대해 설명하시오. 36 | - [x] NSCache와 딕셔너리로 캐시를 구성했을때의 차이를 설명하시오. 37 | - [x] URLSession에 대해서 설명하시오. 38 | - [x] prepareForReuse에 대해서 설명하시오. 39 | - [x] 다크모드를 지원하는 방법에 대해 설명하시오. 40 | -------------------------------------------------------------------------------- /supersupremekim/iOS/SceneDelegate에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 SceneDelegate에 대해 설명하시오 2 | 3 | 4 | 5 | #### iOS 버전 13이후부터는 UI Lifecycle 역할을 맡게 되었다. 6 | 7 | #### Mutiple Window를 지원함에 따라서 프로세스는 하나지만 여러 개의 window에 대한 처리를 할 수 있다. 각 scene은 각자의 life 사이클을 갖고, 동시에 active일 수 있다. 8 | 9 | #### Appdelegate에는 Scene Session이 생성되거나 삭제될 때 AppDelegate에 알리는 메소드가 추가 되었다. 10 | 11 | #### scene의 상태에 따라 notification을 받는다. 12 | 13 | #### 메소드는 scene에 영향을 미치는 상태 변화에 응답한다. 14 | 15 | 16 | 17 | ### 메소드 18 | 19 | - scene(_:willConnectTo:options:) 20 | 21 | scene이 app에 추가됨 22 | 23 | - sceneDidDisconnect(_:) 24 | 25 | UIKit이 scene을 app에서 제거함 26 | 27 | - sceneDidBecomeActive(_:) 28 | 29 | scene이 active되어 사용자 이벤트를 받을 수 있음 30 | 31 | - sceneWillResignActive(_:) 32 | 33 | scene이 곧 active 상태에서 벗어나 사용자 이벤트를 받을 수 없음 34 | 35 | - sceneWillEnterForeground(_:) 36 | 37 | scene이 곧 foreground에 올라가 사용자에게 보여짐 38 | 39 | - sceneDidEnterBackground(_:) 40 | 41 | scene이 background로 들어감 -------------------------------------------------------------------------------- /supersupremekim/iOS/TableView를 동작 방식과 화면에 Cell을 출력하기 위해 최소한 구현해야 하는 DataSource 메서드를 ᄉ.md: -------------------------------------------------------------------------------- 1 | # 🍎 TableView를 동작 방식과 화면에 Cell을 출력하기 위해 최소한 구현해야 하는 DataSource 메서드를 설명하시오 2 | 3 | 4 | 5 | ### row의 갯수를 리턴하는 tableview numberOfRowInSection 메소드와, UITableviewcell을 리턴하는 tableview cellForRowAt 메소드가 필수 메소드이다. 6 | 7 | ### 두번째 cellForRowAt 메소드는 tableview 화면에 보여질 각 셀을 만들 때마다 호출되는데, tableview의 identifier에 맞는 reusable cell을 deque시켜서 cell을 구성하고 해당 cell을 리턴해주는 방식으로 진행된다. -------------------------------------------------------------------------------- /supersupremekim/iOS/UIApplication.md: -------------------------------------------------------------------------------- 1 | # 🍎 UIApplication 2 | 3 | ### 실행되고 있는 앱의 제어와 조정의 중심 포인트 4 | 5 | ### 앱이 시작될 때, 시스템은 UIApplicationMain메소드를 호출한다. 이 메소드는 싱글턴 UIApplication 객체를 생성한다. 6 | 7 | ### 사용자의 터치 등이 시스템에 의해 이벤트로 생성되는데, 이 이벤트를 UIApplication이 받아서 UIControl에 전달. 8 | 9 | ### UIApplication은 UIApplicationDelegate 프로토콜을 채택해 중요한 런타임 이벤트(앱 시작, 종료, 메모리 부족 등)을 델리게이트가 처리하게 한다. 10 | 11 | 12 | 13 | ### 델리게이트 - uiapplication의 인스턴스 프로퍼티. app object의 대리자. 14 | 15 | ### 모든 앱은 앱과 관련된 메시지에 응답하기 위해 app delegate 객체를 갖는다. 16 | -------------------------------------------------------------------------------- /supersupremekim/iOS/UIKit 클래스들을 다룰 때 꼭 처리해야하는 애플리케이션 쓰레드 이름은 무엇인가.md: -------------------------------------------------------------------------------- 1 | # 🍎 UIKit 클래스들을 다룰 때 꼭 처리해야하는 애플리케이션 쓰레드 이름은 무엇인가 2 | 3 | 4 | 5 | UIKit 클래스를 다룰 때는 앱의 main thread나 main dispatchQueue에서만 처리해야 한다. UIResponder를 상속한 클래스나 앱의 유저 인터렉션을 다룰 때 특히나 더 이 점에 유의해야 한다. -------------------------------------------------------------------------------- /supersupremekim/iOS/UINavigationController 의 역할이 무엇인지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 UINavigationController 의 역할이 무엇인지 설명하시오 2 | 3 | 4 | 5 | ### push된 컨텐츠 뷰 컨트롤러들을 네비게이션 스택에 쌓아두는 역할을 하고, 맨 위에 있는 뷰 컨트롤러가 화면에 띄워지게 된다. 뷰를 뺄 때는 pop으로 처리한다. 6 | 7 | 8 | 9 | ### 맨 위에 보이는 뷰컨트롤러 상단에는 뒤로 돌아갈 수 있는 back 버튼이나 여러 bar item을 둘 수 있는 네비게이션 바가 보이게 된다. -------------------------------------------------------------------------------- /supersupremekim/iOS/UIView 에서 Layer 객체는 무엇이고 어떤 역할을 담당하는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 UIView 에서 Layer 객체는 무엇이고 어떤 역할을 담당하는지 설명하시오 2 | 3 | 4 | 5 | ### CALayer는 CoreAnimation이 제공하는 요소 중 하나. 각 View마다 루트 layer는 하나씩 존재한다. 6 | 7 | 8 | 9 | ### 뷰위에 컨텐츠나 애니메이션을 그리는 작업은 view가 직접 처리하지 않고 core animation에 위임함. 그러면 CALayer가 뷰 위에 컨텐츠와 애니메이션을 그리는 작업을 담당하게 됨. 10 | 11 | 12 | 13 | ### 뷰에 속한 루트 layer를 통해 shadow와 cornerRadius 값을 설정할 수 있다. 또한 cornerRadius 값에 따라서 안의 컨텐츠가 짤리거나 하는 경우가 발생할 수 있는데, Bool type인 clipsToBounds를 설정하면 바뀐 뷰 테두리 영역에 의해 안에 있는 내용을 자를 것인가 보존할 것인가를 설정할 수 있다. -------------------------------------------------------------------------------- /supersupremekim/iOS/UIWindow 객체의 역할은 무엇인가.md: -------------------------------------------------------------------------------- 1 | # 🍎 UIWindow 객체의 역할은 무엇인가 2 | 3 | 4 | 5 | - ### 앱의 시각적 컨텐츠를 담는다 6 | 7 | - ### 터치 이벤트를 전달한다 8 | 9 | 10 | 11 | ### window - 뷰들을 담는 컨테이너 12 | 13 | #### 스크린에 표시되는 뷰의 계층 구조에서 최상위 뷰의 역할을 할 고정적인 객체의 역할을 한다. 14 | 15 | #### 단 하나의 window 객체만 생성하고, 이 객체를 통해서 rootviewcontroller를 설정할 수 있다. 16 | 17 | 18 | 19 | ### 스토리 보드를 쓰지 않는 경우, 메인 window를 직접 생성해야 한다. 방법은 window에 UIWindowScene을 직접 넣어줘야 한다. 20 | 21 | 구체적으로는 plist파일에 Application scene manifest의 하위 속성 중 Storyboard Name 항목을 삭제하고, Scene delegate 파일에서 앱을 런치할 때 실행되는 메소드인 제일 첫번째 메소드에서 windowScene을 생성하고 클래스의 옵셔널로 되어 있던 window 속성에 씬을 주입해주고, window에 root viewcontroller를 생성하여 설정하고 window?.makeKeyAndVisible() 을 작성해준다. 22 | 23 | -------------------------------------------------------------------------------- /supersupremekim/iOS/URLSession에 대해서 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 URLSession에 대해서 설명하시오 2 | 3 | 4 | 5 | ### url session은 네트워크 통신할 때, 요청을 보내고 받는 핵심 객체이다. 6 | 7 | ### UrlSessionConfiguration을 통해 크게 세 가지 유형의 url session을 생성한다. 8 | 9 | ### .default 기본, . ephemeral 쿠키나 캐시 저장 안함. background에서도 작업하는 session을 생성할 수 있음. 10 | 11 | 12 | 13 | 14 | 15 | ### 생성된 urlsession으로 url을 파라미터로 넘겨줘서 dataTask를 실행한다. 16 | 17 | -------------------------------------------------------------------------------- /supersupremekim/iOS/View 객체에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 View 객체에 대해 설명하시오 2 | 3 | 4 | 5 | ### 앱 화면에서 시각적으로 표시되는 UI들은 공통적으로 View를 갖고 있다. 6 | 7 | ### 화면의 직사각형 영역에 대한 컨텐츠를 관리한다. view는 부모 뷰와 하나 이상의 subview를 가질 수 있다. view는 frame이라는 CGRect 속성을 가지고 있고, 원점은 origin이고 크기는 size속성으로 접근한다. View 객체의 컨텐츠 조작은 메인 스레드에서 해야 한다. -------------------------------------------------------------------------------- /supersupremekim/iOS/appthinning.md: -------------------------------------------------------------------------------- 1 | # 🍎 AppThinning이란? 2 | 3 | 4 | 5 | ### AppThinning 6 | 7 | 사용자의 기기 환경에 맞게 앱의 설치를 최적화 하는 것. 8 | 9 | - slicing 10 | - bitcode 11 | - Ondemand resource 12 | 13 | 14 | 15 | ### slicing 16 | 17 | 서로 다른 디바이스와 운영체제 버전에 따라 다양한 앱 번들을 만들고 가장 적합한 앱 번들(IPA)을 전달하는 과정 18 | app bundle(컴파일된 앱에 모든 코드 및 리소스) 19 | 20 | 21 | ### BitCode 22 | 아직 기계코드도 아니고 swift도 아닌 중간단계의 코드. 23 | bitcode 즉, 중간 언어가 있어서 다양한 방식으로 다시 컴파일하는데 사용할 수 있다. 24 | 애플은 앱이 다운로드 되기 전에 디바이스에 맞게 앱을 최적화하여 바이너리를 새로 만들어 제공함. 25 | bitcode 사용하면 최신 컴파일러용으로 자동으로 앱을 컴파일하고, 특정 아키텍쳐에 맞게 최적화 한다. 26 | watchOs에서는 bitcode설정 필수. 27 | 28 | ### On-Demand Resource 29 | 지금 당장 필요하지 않은 데이터들을 요청할 때만 로드해줌. 30 | ODR은 앱스토어에 IPA와 별도로 저장되어 가지고 있다가 필요할 때마다 더 많은 컨텐츠를 디바이스에 저장함. 31 | 32 | -------------------------------------------------------------------------------- /supersupremekim/iOS/iOS 앱을 만들고, User Interface를 구성하는 데 필수적인 프레임워크 이름은 무엇인가.md: -------------------------------------------------------------------------------- 1 | # 🍎 iOS 앱을 만들고, User Interface를 구성하는 데 필수적인 프레임워크 이름은 무엇인가? 2 | 3 | 4 | 5 | ### UIKit 6 | 7 | UIKit 프레임워크는 사용자의 인터페이스를 관리한다. 주로 처리하는 사용자 이벤트로는 제스처 처리, 애니메이션, 이미지 처리, 텍스트 처리 등이있다. 테이블 뷰, 슬라이더, 버튼, 텍스트 필드, 얼럿 등 앱 화면을 구성하는 요소도 포함한다. 앞에 UI가 붙은 클래스들을 사용하려면 반드시 UIKit을 import해야한다. 8 | 9 | 10 | 11 | Cf) UIkit은 foundation을 포함한다 12 | 13 | Cf) iOS 앱을 만드는데 필요한 여러 개발도구를 포함하는 최상위 프레임 워크 - Cocoa Touch Framework 14 | 15 | -------------------------------------------------------------------------------- /supersupremekim/iOS/prepareForReuse에 대해서 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 prepareForReuse에 대해서 설명하시오 2 | 3 | 4 | 5 | 테이블 뷰의 델리게이트에서 재사용 셀을 재사용하려고 할 때 호출되는 메서드. 6 | 7 | 테이블 뷰의 셀이 재사용되기 때문에, 재사용 되는 셀의 컨텐츠가 다시 보이거나 하는 경우가 있을 수 있다. 8 | 9 | prepareForReuse 메소드는 기존의 요청을 취소하고, 재사용되어서 새로 나타나는 셀을 reset할 수 있다. 10 | 11 | -------------------------------------------------------------------------------- /supersupremekim/iOS/setNeedsLayout와 setNeedsDisplay의 차이에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 setNeedsLayout와 setNeedsDisplay의 차이에 대해 설명하시오 2 | 3 | 4 | 5 | ### 뷰의 실제 컨텐츠가 변경될 때 뷰를 다시 그려야함을 시스템에 알리는 것. 두가지의 메소드를 호출하여 이 작업을 수행 6 | 7 | 8 | 9 | ### setNeedsDisplay의 목표는 수정된 뷰가 있어서 draw메소드를 다음 드로우 주기에 호출하는 건데, 개발자가 직접 이 메소드를 호출하면 안돼서 setNeedsDisplay()를 통해서 시스템에서 자동으로 draw메소드를 다음 드로우 주기에 호출하게 하는 것. 10 | 11 | ### 컨텐츠를 그리는 메소드이다. 12 | 13 | 14 | 15 | ### setNeedsLayout의 목표는 layoutSubView를 호출해서 뷰의 레이아웃을 업데이트 하는 것이다. 하지만 개발자가 직접 호출할 수 없음. 대신 setNeedsLayout호출하면 다음 setNeedsLayout()내부적으로 layoutSubViews()호출해서 다음 업데이트 주기 때 모든 레이아웃 업데이트. 비동기 액티비티다. 하지만 즉시 업데이트하려면 layoutIfNeeded()를 호출한다. view의 크기나 autolayout 값 변경할 때 쓰이는 메소드이다. 16 | 17 | 18 | 19 | 대부분의 기본 유아이들은 해당 사항이 변경될 때마다 자동으로 두 메소드가 호출되지만, 커스텀으로 만든 uiview클래스 안에서는 명시적으로 호출되어야 업데이트 된다 20 | -------------------------------------------------------------------------------- /supersupremekim/iOS/다크모드를 지원하는 방법에 대해 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 다크모드를 지원하는 방법에 대해 설명하시오 2 | 3 | iOS 13이상에서 지원 4 | 5 | xcode에서 ui 요소의 컬러를 시스템 컬러나 레이블 컬러로 해놓을 경우, 자동으로 다크모드의 색을 지원함. 6 | 7 | 하지만 커스텀으로 컬러를 설정한 요소의 색도 다크모드로 하고 싶을 때, 새로운 컬러셋을 추가하고 appearance를 any, light, dark 각각을 추가해놓으면, 커스텀 컬러를 쓸 시에 각 모드에서 설정한 색으로 표시된다. 8 | -------------------------------------------------------------------------------- /supersupremekim/iOS/모든 View Controller 객체의 상위 클래스는 무엇이고 그 역할은 무엇인가.md: -------------------------------------------------------------------------------- 1 | # 🍎 모든 View Controller 객체의 상위 클래스는 무엇이고 그 역할은 무엇인가 2 | 3 | 4 | 5 | ### UIViewController 6 | 7 | ##### cf) UIResponder를 상속받음 8 | 9 | ### 역할 10 | 11 | - #### 데이터의 변경에 대해서 뷰 업데이트 12 | 13 | - #### 사용자와 상호작용 14 | 15 | - #### 레이아웃 관리 16 | 17 | - #### 여러 경우, 데이터와 view를 이어줌 -------------------------------------------------------------------------------- /supersupremekim/iOS/상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 상태 변화에 따라 다른 동작을 처리하기 위한 앱델리게이트 메서드들을 설명하시오. 2 | 3 | 4 | 5 | 1. func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: 6 | - 앱이 실행되고 사용자에의 화면에 보여지기 직전에 호출되는 메소드 7 | - launchOption 파라미터로 앱이 실행된 이유 (푸시 등)가 포함되어 실행 8 | 9 | 2. applicationDidBecomeActive(_ application: UIApplication) 10 | 11 | - 앱이 화면에 뜬 후 실행되는 메소드 12 | 13 | - 백그라운드에서 다시 포어그라운드로 올라온 후에도 실행됨 14 | 15 | 3. applicationWillResignActive(_ application: UIApplication) 16 | 17 | - 홈 버튼 탭. 백그라운드로 이동할 때 실행되는 메소드 18 | - 일시정지, 비활성화 구현 19 | 20 | 4. applicationDidEnterBackground(_ application: UIApplication) 21 | 22 | - 앱이 백그라운드 상태로 전환되고 호출 23 | 24 | - 앱이 백그라운드 실행 지원한다면, applicationWillTerminate 대신에 호출됨 25 | 26 | - 공유자원 해제, 사용자 저장 등의 로직 구현 27 | 28 | 5. applicationWillEnterForeground(_ application: UIApplication) 29 | 30 | - 앱이 다시 포어그라운드로 올라올 때 호출되는 메소드 31 | - API를 통해 앱 상태 갱신 때 사용 32 | 33 | 6. func applicationWillTerminate(_ application: UIApplication) 34 | - 앱이 종료되기 직전에 호출됨 -------------------------------------------------------------------------------- /supersupremekim/iOS/앱이 In-Active 상태가 되는 시나리오를 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 앱이 In-Active 상태가 되는 시나리오를 설명하시오. 2 | 3 | 4 | 5 | ### In-Active 상태 6 | 7 | - ###### 앱이 Foreground 상태이지만 이벤트를 받지 못하는 상태 8 | 9 | - ###### 다른 상태로 넘어가기 전에 앱은 반드시 이 상태를 거침 10 | 11 | 12 | 13 | 1. ### App Switcher로 전환될 때 14 | 15 | 2. ### 다른 앱 push 알림으로 이벤트 수신하지 못할 때 16 | 17 | 18 | 19 | 20 | 21 | 앱 실행 - not running -> Inactive -> Active 22 | 23 | To background - Active -> Inactive -> Background (- suspended) 24 | 25 | To Foreground - Background -> Inactive -> Active 26 | 27 | 앱 종료 - Background -> not running 28 | -------------------------------------------------------------------------------- /supersupremekim/iOS/앱이 foreground에 있을 때와 background에 있을 때 어떤 제약사항이 있나요?.md: -------------------------------------------------------------------------------- 1 | # 🍎 앱이 foreground에 있을 때와 background에 있을 때 어떤 제약사항이 있나요? 2 | 3 | 4 | 5 | ### foreground (active, inactive) 6 | 7 | - 사용자가 앱을 보고 있는 상황. 시스템 자원의 우선 순위가 높은 상황 8 | 9 | 10 | 11 | ### background 12 | 13 | - 앱이 사용자한테 보이지 않는 상태를 의미 14 | - 사용자에게 보이지는 않지만 계속 실행될 수 있음 ex) 음악 어플, 네비게이션 어플 15 | 16 | #### 제약사항 17 | 18 | - 적은 메모리 공간을 사용해야 함 19 | - 더 낮은 자원 할당 우선 순위 20 | - 필요에 따라 백그라운드 앱 종료 시킴 21 | - 사용자 이벤트 받기 어려움 22 | 23 | #### 추가 시간 부여 24 | 25 | Location Service, 외부 악세서리와 통신 (apple watch, homepods), 블루투스를 이용한 악세서리 사용, 앱 업데이트 진행, 푸시 알림 26 | 27 | 28 | 29 | ### 앱의 상태 30 | 31 | 1. Not running 32 | 33 | 앱이 실행되지 않았거나, 시스템에 의해 종료 34 | 35 | 2. Inactive 36 | 37 | Foreground 상태지만, 이벤트 받지 못함 38 | 39 | 3. Active 40 | 41 | foreground 상태이며 이벤트를 받음 42 | 43 | 4. Background 44 | 45 | 앱이 background에 있으며 코드를 실행하고 있음 46 | 47 | 5. Suspended 48 | 49 | background이며, 메모리에는 남아있으나 코드를 실행하고 있지 않음 50 | 51 | 각 상태의 메소드 안에서 구현하고 싶은 기능을 AppDelegate.swift에서 구현할 수 있음 -------------------------------------------------------------------------------- /supersupremekim/iOS/앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가?.md: -------------------------------------------------------------------------------- 1 | # 🍎앱이 시작할 때 main.c 에 있는 UIApplicationMain 함수에 의해서 생성되는 객체는 무엇인가? 2 | 3 | 4 | 5 | ### UIApplication 싱글턴 객체 6 | 7 | 모든 앱은 하나의 UIApplication 인스턴스가 있다. 8 | 9 | 유저의 아이폰에서 앱이 실행될 때, UIApplication이 실행되고 있는 어플리케이션 오브젝트에 해당된다. 10 | 11 | UIApplication을 통해 appdelegate에 접근할 수 있다. 12 | 13 | `let appDelegate = UIApplication.shared.delegate as! AppDelegate` -------------------------------------------------------------------------------- /supersupremekim/iOS/자신만의 Custom View를 만들려면 어떻게 해야하는지 설명하시오.md: -------------------------------------------------------------------------------- 1 | # 🍎 자신만의 Custom View를 만들려면 어떻게 해야하는지 설명하시오 2 | 3 | 4 | 5 | ### 1. Xib 사용하기 6 | 7 | #### 1. UIView를 상속하는 class 생성한다 8 | 9 | ##### cf)uiview는 두개의 필수 생성자가 있다. override init 코드로 뷰 만들 때 사용됨. Required init 스토리 보 드를 통해서 view 연결할 때 사용됨 10 | 11 | 12 | 13 | #### 2. Nib 파일 생성 후, nib파일의 이름으로 해당 nib 파일을 가져오는 내용을 포함한, 뷰를 로드 하는 메소드를 작성하고, init과 required init에서 이 메소드를 실행한다. 14 | 15 | 16 | 17 | 18 | 19 | ### 2. 코드로 만들기 20 | 21 | #### 코드로 뷰의 구성을 전부 작성. 22 | 23 | #### init(frame) 이 실행된다. 24 | 25 | #### 뷰컨트롤러에서 불러올 때는 해당 클래스의 인스턴스 만들고 addSubview 통해서 추가해줌 -------------------------------------------------------------------------------- /supersupremekim/iOS/하나의 View Controller 코드에서 여러 TableView Controller 역할을 해야 할 경우 어떻게 구분해서 구현해야 하느.md: -------------------------------------------------------------------------------- 1 | # 🍎 하나의 View Controller 코드에서 여러 TableView Controller 역할을 해야 할 경우 어떻게 구분해서 구현해야 하는지 설명하시오 2 | 3 | 4 | 5 | ### Tableview의 datasource 메소드 중 cellForRowAt 메소드에서 tableview의 종류로 구분하는 방법과, 6 | 7 | ### 각 tableView의 tag를 등록하여 구분하는 방법이 있다. -------------------------------------------------------------------------------- /supersupremekim/iOS/앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체를 무엇이라고 하는가?.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # 🍎 앱 화면의 콘텐츠를 표시하는 로직과 관리를 담당하는 객체를 무엇이라고 하는가? 4 | 5 | 6 | 7 | ### ViewController 8 | 9 | - 컨텐트 뷰컨트롤러 10 | - 컨테이너 뷰컨트롤러(기본으로 제공되는 container vc ex. 탭바컨트롤러, 네비게이션 뷰 컨트롤러, 페이지뷰컨트롤러 or 커스텀 컨테이너 뷰 컨트롤러) 11 | 12 | 13 | 14 | ### 역할 15 | 16 | 17 | 18 | 1. ##### 뷰 계층을 관리한다 19 | 20 | 뷰 컨트롤러는 루트뷰를 가지고 있어 그 위에 다른 뷰를 추가할 수 있다. 21 | 22 | 모든 서브 뷰를 관리하고, 아웃렛으로 서브 뷰에 대한 레퍼런스를 저장한다. 23 | 24 | 컨테이너는 서브 뷰의 컨텐트를 관리하지는 않고, 컨테이너 종류에 따라 서브뷰의 사이즈와 위치가 지정된다. 25 | 26 | 2. ##### 뷰와 데이터의 중계자 역할을 수행한다 27 | 28 | 데이터 관리에 있어서 뷰컨트롤러의 역할은 최소화 되어야한다. 29 | 30 | 3. ##### 리소스 관리 31 | 32 | UIKit이 더이상 필요없는 리소스를 정리하도록 요청한다. 33 | 34 | 4. ##### 유저 인터렉션 관리 35 | 36 | 뷰가 자신의 터치 이벤트를 뷰컨트롤러에 action메서드나 delegate로 전달 37 | 38 | 39 | 40 | ### 생명주기 41 | 42 | 1. ##### loadView 43 | 44 | Outlet 과 action들이 이 메소드에서 생성되고 연결됨 45 | 46 | override하지 않는 것이 좋음 47 | 48 | 2. ##### viewDidLoad 49 | 50 | outlet들이 메모리에 올라옴 51 | 52 | 사용자에게 화면이 보여지기 전 데이터를 배치하는 코드 작성 (ex. 네트워크 호출) 53 | 54 | vc 생에 오직 한 번만 호출 55 | 56 | 3. ##### viewWillAppear 57 | 58 | vc의 화면이 올라오고 난 후에 호출되는 메소드 59 | 60 | 애니메이션 실행, 비디오, 소리 재생, 데이터 업데이트 61 | 62 | 화면 전환으로 다시 돌아올 때마다 호출 63 | 64 | 4. ##### viewDidAppear 65 | 66 | 뷰가 데이터가 완전히 화면에 나타난 후 호출되는 메소드 67 | 68 | 5. ##### viewWillDisappear 69 | 70 | 다른 vc로 화면 전환 전, 해당 뷰가 화면에서 사라질 때 호출 71 | 72 | 6. ##### viewDidDisappear 73 | 74 | 해당 vc가 완전히 사라지고 나서 호출 75 | 두번째 뷰가 로드되고 willAppear가 호출된 다음에 첫번째 뷰가 진정으로 사라지게 되는 viewDidDisappear 호출됨 76 | 멈추어야 할 작업들을 작업들 작성 (ex. notification 해제) 77 | 78 | 7. ##### Deinit 79 | 80 | vc가 메모리에서 사라지기 전 호출 81 | 82 | arc에 의해 해지 불가능한 자원들을 해제하기 위해 override 83 | 84 | vc가 화면에서 사라지는 것이 메모리에서 해제되는 것이 아님 85 | 86 | 참고 - https://www.notion.so/467df350a438455785ccb86e6a551070, 87 | 88 | https://ahyeonlog.tistory.com/17, 89 | 90 | http://www.appleofeyes.com/role-view-controllers-xcode-엑스코드에서-뷰컨트롤러의-역할/ 91 | --------------------------------------------------------------------------------