:D

• Résumé
• Blog

iOS(adv)

Computer Science of iOS(adv)

💛 SwiftUI

VStack 🆚 LazyVStack

👉 VStack
　　👉 전체 데이터를 메모리에 담아두고 스크롤 할 때마다 보여줌
👉 LazyVStack
　　👉 데이터가 화면에 렌더링 되는 순간, 즉, 보여지는 순간 그려짐
👉 즉, 미리 화면을 다 그려놓고 보여주느냐, 렌더링 되는 순간에 그려주느냐의 차이

Property Wrapper in SwiftUI

👉 SwiftUI의 뷰에서 값을 수정 및 읽기가 가능하도록 돕는 역할
　　👉 Property Wrapper
　　　　👉 프로퍼티를 구현할 때 반복적으로 사용되는 패턴을 줄이기 위해 사용
　　　　👉 즉, 반복되는 로직들을 미리 정의하고 프로퍼티 자체에 연결하는 방식
　　　　👉 정의 시, wrappedValue를 반드시 필요로 하며, 연산 프로퍼티 형태로 반복되는 로직을 정의하면 됨
👉 몇 가지 개념
　　👉 @State
　　　　👉 String, Int와 같은 간단한 값을 저장하고 View의 현재 상태를 표시하기 위해 사용
　　👉 @ObservedObject
　　　　👉 View의 외부에 존재하는 데이터를 이용할 때 사용
　　　　👉 주로, ObservableObject & @Published와 같이 사용됨
　　　　　　👉 ObservableObject : 변경된 값을 방출(emit)하는 objectWillChange 퍼블리셔를 사용할 수 있도록 하는 프로토콜
　　👉 @Binding
　　　　👉 ChildView에서 ParentView의 값을 다루고 싶을 때 사용 (ChildView에서 사용됨)
　　　　👉 데이터를 직접 저장하지 않고, Parent의 데이터를 표시하거나 핸들링하게 됨 (ParentView에는 @State와 같은 데이터 존재)
　　👉 @Published
　　　　👉 변경이 발생하면 자동으로 알림을 발생 (Observable 객체들을 만듦으로써)
👉 @State 🆚 @ObservedObject
　　👉 @State
　　　　👉 View의 내부, 값 타입, 프레임워크 자체적 관리
　　　　👉 화면 내부에서만 사용이 되기 때문에 private으로 선언할 것
　　　　　　👉 ex) @State private var isDisabled = true
　　👉 @ObservedObject
　　　　👉 View의 외부(ex. ObservableObject 클래스), 참조 타입, 개발자가 직접 관리

UIHostingController

👉 UIViewController의 하위 클래스로, UIKit 기반의 프로젝트에 통합될 수 있도록 SwiftUI 뷰를 감싸는 역할을 수행함

UIViewRepresentable

👉 SwiftUI에서 UIView를 사용하기 위해 필요한 프로토콜
👉 UIViewRepresentable를 따르는 struct를 만들어 SwiftUI에서 바로 사용하면 되며, 해당 struct는 반드시 두 가지 메소드를 구현해야 함
　　👉 ex) struct RepresentableRedLabel: UIViewRepresentable { ~ }
👉 필수 구현 메소드 2가지
　　👉 func makeUIView(context: Context) -> UIKit에서의 타입 // SwiftUI에서 나타낼 뷰를 반환
　　👉 func updateUIView(_ uiView: UIKit에서의 타입, context: Context) // SwiftUI에서 업데이트가 발생할 때 실행

UIViewControllerRepresentable

👉 SwiftUI에서 UIViewController를 사용하기 위해 필요한 프로토콜
👉 UIViewControllerRepresentable 따르는 struct를 만들어 SwiftUI에서 바로 사용하면 되며, 해당 struct는 반드시 두 가지 메소드를 구현해야 함
　　👉 ex) struct RepresentableRedLabel: UIViewRepresentable { ~ }
👉 필수 구현 메소드 2가지
　　👉 func makeUIViewController(context: Context) -> some UIViewController // SwiftUI에서 나타낼 뷰 컨트롤러를 반환
　　👉 func updateUIViewController(_ uiViewController: some UIViewController, context: Context) // SwiftUI에서 업데이트가 발생할 때 실행

ViewModifier (프로토콜)

👉 기존에 생성한 뷰 또는 modifier를 다른 버전으로 만들기 위해 사용하는 개념
　　👉 modifier : 뷰에 modifier를 적용하여 새로운 뷰를 만들어 리턴하는 개념

SwiftUI some 의미 🔥

👉 반환 타입이 불투명한 반환 타입(역 제네릭 타입)이라는 것을 나타냄
　　👉 역 제네릭 : 함수 외부에서 어떤 타입을 다루는지 정확히 알 수 없지만, 내부에서는 정확히 알고 있음
👉 명확하지 않은 타입이 프로토콜 내에 정의되어 있고, 이 프로토콜을 함수 혹은 연산 프로퍼티의 반환 타입으로 가질 때 반환 타입을 불투명 타입으로 만들어 주기 위해 사용
👉 반환 타입이 어떤 타입일지 컴파일러 및 외부에선 모르겠지만, 함수 내부에서 어떤 타입을 반환하는지 명확하게 알고 있으니, 컴파일러에게 정해진 특정 타입만을 반환해 줄 것임을 알려주는 개념
👉 따라서, var body: some View { 내부 ~ } 의 함수 내부에서 내가 작성하는 코드에 따라 시시 각각 리턴 타입이 변경되지만, 따로 리턴 타입을 변경하지 않아도 되고 some View로 작성해도 되는 이유

Swift 제네릭

👉 타입에 의존하지 않는 범용적인 코드를 작성할 때 사용하는 개념
👉 중복을 피하고 코드를 유연하게 작성할 수 있음
👉 함수 내부에서 어떤 타입을 다루는지 알 수 없지만, 외부에서는 파악이 가능함
　　👉 ex) func load<T: Decodable>(_ filename: String) -> T { ~ }
　　　　👉 <T>의 의미는 따로 새로운 타입이 아니라 너도 이미 알고 있던, 원래 존재하는 타입이라는 것을 알려주기 위함
　　　　👉 <T: Decodable>을 통해 T에 대한 제약을 설정

제네릭 프로그래밍(Generic Programming)

👉 데이터 타입에 의존하지 않고, 하나의 값이 여러 다른 데이터 타입을 가질 수 있도록 하는 기술에 중점을 두는 프로그래밍 패러다임
✋ Generic Programming is a style of computer programming in which algorithms are written in terms of types to be specified-later that are then instantiated when needed for specific types provided as parameters

ForEach

👉 SwiftUI에서 ForEach를 사용하여 View를 반복할 수 있음
👉 Swift의 .forEach와는 약간 다른 개념
👉 ForEach id: .self 의미
　　👉 SwiftUI에서 배열의 각 요소를 고유하게 식별할 수 있도록 하기 위해 필요함

💛 ReactiveX

반응형 프로그래밍(Reactive Programming)

👉 데이터의 흐름과 전달에 관해 중점을 두는, 즉, 비동기적인 데이터 스트림을 이용한 프로그래밍 패러다임
✋ RxJava, RxSwift, etc

RxSwift 관련 요소 및 개념

👉 Observable
　　👉 Rx 코드의 기반이 되는 가장 중요한 요소
　　　　👉 Rx에서는 Observable = Observable Sequence = Sequence 모두 동일
　　👉 Observable<T> 형식
　　👉 T형태의 데이터 snapshot을 전달할 수 있는 일련의 이벤트를 비동기적으로 생성하는 기능을 가짐
　　　　👉 만약, <T>를 적지 않을 경우 타입추론을 하게 됨
　　👉 총 세 가지 유형(next, error, completed)의 이벤트를 생성 및 방출하며, 하나 이상의 옵저버가 실시간으로 어떠한 이벤트에 반응하게 됨
　　　　👉 onNext : Observable은 어떤 구성요소를 가지는 next 이벤트를 계속해서 방출할 수 있음
　　　　👉 onError : Observable은 error 이벤트를 방출하여 완전 종료될 수 있음
　　　　👉 onCompleted : Observable은 completed 이벤트를 방출하여 완전 종료될 수 있음
　　👉 ex)

Observable<Int>.of(1, 2, 3, 4, 5) // 단순 정의

Observable<Int>.of(1, 2, 3, 4, 5)
    .subscribe(onNext: {
        print($0)
    }) // 1 2 3 4 5

Observable.of(1, 2, 3)
    .subscribe({
        print($0)
    }) // next(1) next(2) next(3) completed

👉 Traits
　　👉 Observable에 대한 빌더 패턴 구현의 일종
　　👉 Trait이 만들어지면, asObservable()을 통해 다시 observable로 변환할 수 있음
　　👉 3가지 종류
　　　　👉 Single
　　　　　　👉 일련의 요소를 방출하는 대신 단일 요소 혹은 오류를 방출(onSuccess(onNext + onCompleted), onFailure)
　　　　　　👉 Observable을 asSingle() 메서드를 통해 Single로 변환할 수 있음
　　　　👉 Maybe
　　　　　　👉 일련의 요소를 방출하는 대신 단일 요소 혹은 오류를 방출하거나 아무 것도 방출하지 않음(onSuccess, onCompleted, onError)
　　　　　　👉 Observable을 asMaybe() 메서드를 통해 Maybe로 변환할 수 있음
　　　　👉 Completable
　　　　　　👉 일련의 요소를 방출하는 대신 오류를 방출하거나 아무 것도 방출하지 않음(onCompleted, onError)
　　　　　　👉 Observable을 Completable로 변환할 수 없음
👉 Operator
　　👉 Rx 코드 이벤트를 변환하고 처리하는 등 다양한 연산 관련 요소
👉 Scheduler
　　👉 Rx의 DispatchQueue
👉 Dispose
　　👉 수동적으로 subscribe를 종료하는 것
　　　　👉 subscribe() 메소드가 없으면 단순한 Observable 정의일 뿐, 아무런 역할을 수행하지 않으며, 이벤트를 방출하기 위해선 subscribe() 메소드가 필요
　　　　👉 But, Observable은 subscribe 이후 complete 또는 error 이벤트가 발생하기 전까지 계속 next 이벤트를 발생시킴
　　　　👉 이는 메모리 누수로 이어질 수 있기 때문에 Dispose 필요
　　　　👉 즉, Subscribe 이후에 Dispose를 하는 것이 Observable의 생명주기
　　👉 dispose() 메소드를 활용해 원하는 시점에 구독을 해지할 수 있음
　　　　👉 But, dispose() 메소드는 구독하는 것마다 별도로 관리를 해줘야하는 번거로움이 있음
　　　　👉 따라서, disposeBag과 disposed(by: )메소드를 활용한다면 여러 개의 구독을 한번에 해제할 수 있음
　　　　　　👉 subscribe가 반환하는 disposable이 disposeBag에 담기고 disposeBag이 해제될 때 disposable이 모두 해제되는 방식
　　　　　　👉 subscribe() 메서드는 기본적으로 disposable을 반환
　　　　　　👉 disposable은 메모리 관리를 도와주는 객체
👉 Subject
　　👉 Observable이자 Observer인 객체
　　👉 대표 종류
　　　　👉 PublishSubect
　　　　　　👉 빈 상태로 시작하여 새로운 값만을 구독자에게 방출, 구독자는 구독을 시작한 이후부터의 이벤트를 받음
　　　　👉 BehaviorSubject
　　　　　　👉 하나의 초기값을 가진 상태로 시작하여, 구독자는 구독하는 시점에서 과거에 갱신되었던 값들중 가장 최신값을 받음
　　　　👉 ReplaySubject
　　　　　　👉 버퍼를 두고 초기화하며, 버퍼 사이즈만큼의 값들을 유지하면서 새로운 구독자들에게 방출
　　　　　　👉 But, 버퍼는 메모리가 가지고 있기에, 큰 용량(이미지, 큰 배열)의 데이터를 버퍼로 갖게 한다면 메모리에 부하가 발생하기에 주의해야 함

RxCocoa

👉 Cocoa Framework와 Rx를 합친 라이브러리, Cocoa Framework에 Rx의 장점을 더해준 라이브러리

👉 Binder
　　👉 발신자(Observable)에서 수신자(Binder)로 단방향 데이터 스트림을 전송 (bind() 메소드를 활용)
　　　　👉 Binder는 Observer 역할만을 수행
　　👉 메인 스레드에서 실행되는 것을 보장
　　👉 UI Binding에 사용
　　👉 Error 이벤트를 무시함
　　👉 에러 이벤트를 받으면 실행이 종료되었는데, UI Binding에 사용되기에 UI 업데이트가 멈추는 일이 발생하는 것을 원치 않기 때문에 무시하도록 만들어짐
👉 Traits
　　👉 에러를 방출하지 않는 특별한 Observable
　　👉 모든 과정은 메인 스레드에서 이뤄짐
　　👉 스트림 공유가 가능
　　👉 대표 종류
　　　　👉 Signal (PublishSubject와 유사)
　　　　　　👉 구독한 이후에 발생하는 값 전달
　　　　　　👉 Observable을 asSignal()을 이용해 S로 변환 가능
　　　　👉 Driver (BehaviorSubject와 유사)
　　　　　　👉 초기값 or 최신값 replay
　　　　　　👉 Observable을 asDriver()을 이용해 D로 변환 가능

RxExtension

👉 Reactive에 원하는 기능이 구현되어 있지 않아 extension하여 활용하는 것

PublishRelay

👉 UI 이벤트 처리에 좀 더 특화된 것(클래스), onNext 이벤트만 존재 (onError, onCompleted X)
👉 PublishSubject의 wrapper로, 구독자는 구독을 시작한 이후부터의 이벤트를 받음

💛 Combine

Combine

👉 Publisher, Subscriber을 사용해서 비동기 이벤트를 처리할 수 있도록 애플에서 개발한 프레임워크
👉 RxSwift와의 차이점
　　👉 #1
　　　　👉 Combine의 Publisher : 값 타입, Output과 Error라는 두 개의 연관 Type을 가짐
　　　　👉 RxSwift의 Observable : 참조 타입, Element라는 하나의 타입만을 가짐 (Error X)
　　👉 #2
　　　　👉 제공하는 Operator의 차이가 있으며, Combine에는 주로 함수 앞에 try라는 명칭이 붙어있으며 에러를 핸들링 할 수 있는 기능이 있음
　　👉 #3
　　　　👉 PublishSubject <-> PassthroughSubject와 대응
　　　　👉 ReplaySubject <-> X
　　　　👉 BehaviorSubject <-> CurrentValueSubject와 대응
　　👉 #4
　　　　👉 Combine에는 DisposeBag이라는 것이 따로 존재하지 않음
　　　　👉 비슷한 기능 동작을 위해서는 AnyCancellable을 Set으로 선언하고 store() 메소드를 사용하는 방식으로 구현이 가능함

💛 Design Pattern

디자인 패턴 🆚 아키텍처 패턴 ✔️

👉 디자인 패턴
　　👉 특정 문맥에서 소프트웨어 디자인의 공통적인 발생 문제에 대해 재사용 가능한 해결책
　　👉 특정 유형의 문제를 해결하는 방법
　　👉 앱 성능 및 유지보수 등에 많은 영향을 끼치기에 중요한 개념
　　👉 효율적인 코드 작성, 해결 방안 도출, 인수인계 능률증가 등의 장점이 있음
👉 아키텍처 패턴
　　👉 프로그램 내에서 큰 구조로 구성되어 다른 구성요소들을 관리하는 역할
👋 아키텍처 패턴이 조금 더 넓은 범위에 속함

MVC 패턴 ✔️

👉 프로그램을 각각의 역할에 따라 Model, View, Controller로 나누어 설계한 디자인 패턴
👉 Model
　　👉 애플리케이션이 무엇을 할지 정의하는 파트
　　👉 앱의 데이터 및 비즈니스 로직을 가짐(DB, 변수 등)
👉 View
　　👉 사용자에게 어떤 것을 화면으로 보여주는 역할
　　👉 UI 요소
👉 Controller
　　👉 Model과 View의 다리 역할
👉 초기에 애플은 View와 Model의 상호 의존성을 없애고 Controller로 통제하려고 의도함
👉 View와 Controller가 너무 밀접하게 연결되어 있음
　　👉 Controller가 View life cycle을 너무 많이 관여하게 되어 View와 Controller를 분리하기 어려움
👉 Life Cycle 뿐만이 아닌 대부분의 코드(네트워크 요청 등)가 Controller에 밀집되어 크기가 커지고 내부 구조가 복잡해짐
👉 즉, 재사용성이 떨어지고, 유닛 테스트가 어려워짐
👉 따라서, MVC 패턴은 개발 시간면에서는 빨리 개발이 가능하지만, 프로젝트 규모가 커질수록 유지보수에 어려움이 있음
👉 즉, 개발 시간이 없을 때, 프로젝트 규모가 작을 때 사용하는 패턴

MVP 패턴

👉 프로그램을 각각의 역할에 따라 Model, View, Presenter로 나누어 설계한 디자인 패턴
👉 기존의 MVC에서 많은 역할을 맡고 있던 ViewController의 일을 Presenter에게 나누어 설계한 디자인 패턴
👉 즉, Controller 대신 Presenter 개념이 도입된 디자인 패턴
👉 Model
　　👉 애플리케이션이 무엇을 할지 정의하는 파트
　　👉 앱의 데이터 및 비즈니스 로직을 가짐(DB, 변수 등)
👉 View
　　👉 사용자에게 어떤 것을 화면으로 보여주는 역할
　　👉 UI 요소
👉 Presenter
　　👉 View(+ViewController)와 Model의 다리 역할
　　👉 일반적으로 View에서 수행된 사용자의 동작에 반응하여 Model에 변경을 요청하고, Model의 변경 사항을 기반으로 View에 업데이트를 요청하는 역할
　　　　👉 View에서 유저 액션을 Presenter에게 전송함
　　　　👉 전송받은 데이터를 Presenter에서 Model에게 업데이트를 요청함
　　　　👉 업데이트 후 Model에서 Presenter에게 변경사항 알려줌
　　　　👉 변경사항을 기반으로 Presenter에서 View로 UI 업데이트를 요청함
　　　　👉 Model과 View는 반드시 Presenter을 거쳐서 알 수 있으며 직접적으로 서로를 알 수 없음
👉 MVP 패턴의 View는 life cycle과 아무 연관이 없고, 어떠한 레이아웃 코드도 Presenter에 안 담겨있음
　　👉 즉, MVP 패턴의 View는 쉽게 mocking 될 수 있음
　　　　👉 mocking : Unit Test에서 쓰이는 기술로, 실제와 똑같은 fake 버전을 만들어 내는 테스트 기술
👉 대부분 책임을 Presenter와 Model이 가지고 있으며 View는 역할이 많이 없음
👉 View와 Model이 완전히 분리가 되기 때문에 독립적으로 테스트 가능
👉 따라서, MVP 패턴은 Testability가 좋으며 많은 양의 코드를 가진다는 특징이 있음
👉 But, Presenter는 View들에 대한 참조를 직접 프로토콜 형태로 가지고 변경사항을 반영함
👉 Presenter가 View에 대한 변경사항을 결정하기 때문에 Presenter가 View에 대해 어느 정도 알고 있어야 함
👉 이에 따라, 하나의 Presenter를 통해 유연하게 여러 다른 View를 구성하는 것이 어려워 짐
👉 즉, Presenter와 View가 보이지 않는 연관성을 가지고 있는 것으로도 볼 수 있음

MVVM 패턴

👉 프로그램을 각각의 역할에 따라 Model, View, ViewModel로 나누어 설계한 디자인 패턴
👉 ViewModel을 추가해서 ViewController의 일을 덜어주고 크기를 줄여준 패턴
👉 Model
　　👉 애플리케이션이 무엇을 할지 정의하는 파트
　　👉 앱의 데이터 및 비즈니스 로직을 가짐(DB, 변수 등)
👉 View
　　👉 사용자에게 어떤 것을 화면으로 보여주는 역할
　　👉 UI 요소
👉 ViewModel
　　👉 View(+ViewController)와 Model의 다리 역할
　　👉 일반적으로 View에서 수행된 사용자의 동작에 반응하여 Model을 변경하고, Model의 변경 사항을 View로 업데이트하는 역할
👉 View에 해당하는 UIView, UIViewController는 각자의 ViewModel을 소유함
　　👉 View가 ViewModel을 소유하고 있기 때문에 ViewModel은 View를 몰라도 됨
　　👉 View가 ViewModel을 소유하고, ViewModel이 Model을 소유할 수 있는 방식
👉 ViewModel은 View와 바인딩되어, 데이터와 사용자 액션을 주고 받음
　　👉 View에서 유저 액션을 ViewModel에게 전송함
　　👉 전송받은 데이터를 ViewModel에서 Model에게 업데이트를 요청함
　　👉 업데이트 후 Model에서 ViewModel에게 변경사항 알려줌
　　👉 ViewModel은 응답받은 데이터를 가공하여 저장함
　　👉 ViewModel에 의해 데이터가 저장되면 Data Binding에 의해 View가 자동으로 업데이트
　　　　👉 바인딩을 하고 있기에 ViewModel의 변경사항을 View 쪽에서 반응적으로 확인해서 반영
　　　　　　👉 MVP 패턴에 존재하던 “보이지 않는 연관성”까지 해소
　　　　　　👉 View와 ViewModel을 바인딩을 하는 접착제로 Rx가 매우 강력함
　　　　👉 Data Binding : ViewModel의 데이터와 UI의 싱크를 맞추는 것
　　　　　　👉 로직이 분리되어 있어도 한쪽이 바뀌면 다른 한쪽도 업데이트되어 데이터의 일관성을 유지할 수 있음
👉 MVVM 패턴은 Testability가 좋으며 많은 양의 코드를 가짐

Singleton 패턴

👉 단 하나의 인스턴스를 생성하여 사용하는 디자인 패턴
👉 데이터 공유가 쉬우며, 메모리 측면에서 여러 이점이 있음
　　👉 미리 생성한 인스턴스를 이용하는 것이기에, 속도 측면에 이점이 있고, 메모리 낭비를 방지할 수 있음
👉 멀티 스레드 환경에서 여러 개의 객체가 생성되는 문제가 발생할 수 있다는 단점이 있음
👋 싱글턴 인스턴스로 너무 많은 데이터를 공유하게 되면 클래스들 간의 결합도가 높아지고 코드 수정과 테스트가 어려워 진다는 단점도 있음
　　👋 객체 지향 설계 원칙에 적합하지 X
　　👋 결합도 : 내부 구현을 변경했을 때 이것이 다른 모듈에 영향을 미치는 경우 높은 결합도라 함