김종권의 iOS 앱 개발 알아가기

목차) SwiftUI의 기본 - 목차 링크 * @Published, @objecervableObject 개념은 Combine이므로, Combine 관련 이전 포스팅 글 참고 @ObservedObejct 란? observable 객체를 구독하는 property wrapper observable 객체가 변경되면 뷰에 업데이트 시켜주는 기능 내부 코드 @available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) @propertyWrapper @frozen public struct ObservedObject : DynamicProperty where ObjectType : ObservableObject { @dynamicMemberLookup @frozen pub..

MVVM 핵심은 View와 ViewModel이고 각 역할을 기억 View: ViewModel에서 상태가 변하면 그 상태를 단순히 구독하고 있다가 View를 변경하는 역할 ViewModel: 상태 값을 저장하고 있고, 상태 값을 관리(계산 등)를 하는 역할 View와 ViewModel 구현 핵심 View에서 특정 UI의 action이 발생하면 ViewModel에 던져줌 ViewModel에서는 액션에 따라 특정 상태값을 관리하고 상태값을 변경 ViewModel의 상태값을 바라보고 있는 View는 그에 맞추어서 UI 변경 주의사항) 상태 관리 포인트는 View가 아니라 ViewModel이므로, 상태 관련 코드는 ViewModel 한 곳에서 수행되도록 할 것 View, ViewModel 구현 아이디어 enum을..

* 알아야하는 기본 지식 - 테스트 코드를 작성해야 하는 이유 - 클린 코드 (창발성) - DIP(Dependency Inversion Principle) 설계 전에 필요한 프레임워크 설치 RxSwift RxCocoa ViewModel을 testable되도록 만드는 이유 viewModel에는 UI 인풋에 따라 UseCase를 통해 비즈니스 로직을 실행 viewModel은 어떤값을 UI에 넘겨주어야하는지 정보를 담고 있는 컴포넌트 UI의 인풋부터 시작하여, 비즈니스 로직과 아웃풋까지 동시에 모두 테스트할 수 있는 컴포넌트는 ViewModel ViewModel을 testable하게 구현하는 아이디어 ex) LoginVM (로그인 ViewModel)을 만드는 예시 LoginVM 프로토콜을 만들어서 테스트할 때..

AppDelegate에서 첫 화면으로 AppDelegate는 앱 첫 시작화면으로 이동하는 AppFlowCoordinator를 소유 Coordinator를 통해 첫 시작화면으로 이동 Coordinator에서는 AppFlowDIContainer를 통해 이동하려는 화면에 해당하는 DIContainer 생성 > 이동하려는 화면의 Coordinator를 획득 > 이동하려는 화면의 coordinator에 정의되어 있는 start()함수를 통해 화면 전환 Coordinator 사용 방법 Coordinator를 사용하는 이유: ViewModel간 의존관계를 Coordinator로 끊은 상태 > ViewModel이 서로 의존하고 있지 않으므로 특정 ViewModel을 수정하면 Coordinator만 변경하면 되므로 상..

DTO DTO(Data Transfer Object): JSON의 response를 Entity로 변환 Data 하위에 존재 API로 부터 받은 response는 그대로 받고, response를 completion handler에서 domain 모델로 변환하는 식으로 사용 받은 response는 그대로 표출 > API의 response 모델을 알아보기 용이 사용하는 쪽에서 domain모델을 사용하도록 변환

Actor가 Entity를 받기까지 View는 ViewModel의 메소드를 호출 viewModel은 useCase 실행 > useCase는 Repository(DB or Network)에 데이터 요청 Repository에서 cache에 데이터가 있으면 바로 획득, 없으면 memory cache, disk cache로 기록 Respository로 부터 받은 데이터는 completion의 인수로 받을수 있어서 ViewModel이 이 데이터 획득 ViewModel은 자신의 Output 프로퍼티에 emit > 이 프로퍼티를 observe하고있던 View에서 Entity를 UI에 표출 예제 - Actor가 MovieList Entity를 요구 View는 ViewModel의 메소드를 호출 viewModel은 use..

의존관계 잘 변하는 것에서 변하지 않는것으로 의존관계가 되는게 이상적인 형태 잘 변하지 않는 계층인 Domain계층으로 Presentation과 Data 계층이 의존하는 형태 핵심: Actor가 Entity를 확인하는 flow View는 ViewModel의 메소드를 호출 viewModel은 useCase 실행 > useCase는 Repository(DB or Network)에 데이터 요청 Repository에서 cache에 데이터가 있으면 바로 획득, 없으면 memory cache, disk cache로 기록 Respository로 부터 받은 데이터는 completion의 인수로 받을수 있어서 ViewModel이 이 데이터 획득 ViewModel은 자신의 Output 프로퍼티에 emit > 이 프로퍼티를..

소스 코드의 의존성은 안쪽을 향하게끔 설계 안쪽으로 갈수록 잘 변하지 않는 요소들이기 때문 안쪽의 원은 바깥쪽의 원을 모르는 상태 바깥쪽의 원은 어떠한 것도 안쪽의 원에 영향을 주지 않는 구조 아키텍처 설계의 가정: 사용자(Actor)의 요구사항은 변경이 많이 없고 내부적으로 Web이나 DB, UI가 자주 바뀐다고 가정하여 설계 Entity Entity (=Enterprise Business Rules): Actor가 필요로 하는 데이터 모델을 의미 특정 '도메인'에서 사용되는 struct 모델 ex) Actor가 필요로하는 Movie와 MoviesPage에 관한 Entity struct Movie: Equatable, Identifiable { typealias Identifier = String en..