ZarttiOS

APNs(Apple Push Notification Service)를 이용하지 않고, 앱 내부적으로 Push Notification을 보내는 방식 장점 유저로부터 알림 권한만 승인받으면 특별한 설정 및 Certificate 등의 세팅 없이 Push Notification을 앱으로 전달 가능 단점 개발당시에 지정해둔 내용과 설정으로만 Notification이 전달되며, 특정 조건(특정 화면으로 진입한다던지 하는 등)을 만족해야만 Notification이 전달 푸시 알림 권한 요청 import UNUserNotifications class ViewController: UIViewController { let userNotiCenter = UNUserNotificationCenter.current() // 싱..

그럼 가장 안쪽 Layer에서 바깥 Layer로는 전혀 이동이 불가능한가? Apdater는, “Domain과 Infrastructure 사이의 번역기 역할을 수행한다.” 라고 언급 했었다. 이 때 흐름은 Controller → Use case → Presenter로 흐르게 된다. 이처럼 제어의 흐름이 원의 내부에서 외부로 향하는 것을 Crossing Boundaries 라고 한다. 하지만 위 흐름을 그대로 따른다면 Dependency Rule을 위반하게 된다. High-level인 Use case는 Low-level인 Presenter를 의존해서는 안되기 때문이다. 그래서 의존성 역전 원칙(DIP)을 적용하게 된다. 의존성 역전 원칙이란, 고수준 모듈이 저수준 모듈을 의존하는 것이 아니라, 저수준 모듈이..

관심사 분리는 어떻게 할까? Layer Clean Architecture 에서는 관심사를 분리하기 위해 소프트웨어를 계층으로 나누고, 각 계층이 독립적이기 위해 Layer를 설정하였다. Infrastructure Infrastructure Layer는 UI, DB, API, Framework 등이 존재하는 영역. 이는 Domain에 비해 형태가 자주, 쉽게 바뀔수 있다. Domain Domain Layer는 Business Logic이 존재하는 영역. Business Logic은 Infrastruecture에 비해 잘 변하지 않는 안정된 영역. Robert C. Martin(Uncle Bob)은, 이 경계를 기반으로 Layer를 나누고, 관심사를 분리하는 규칙을 의존성 규칙(Dependency Rule)..

Business Rule(= Business Logic = Domain Logic) 컴퓨터 프로그래밍에서 실세계의 규칙에 따라 데이터를 생성, 표시, 저장, 변경 하는 부분. 유저의 입력(UI)과 DB(Local, Remote) 사이에서 발생한 데이터 교환을 위해 특정 알고리즘이나 규칙이 정의된 부분. Business Logic은 Client의 요구에 따라 변경될 수 있다. 그렇기 때문에 별도로 관리 될 필요가 있다. System Architecture 시스템의 구조, 행위, 뷰를 정의하는 개념 모델. 시스템의 목적을 달성하기 위해 각 컴포넌트가 어떻게 상호작용하고 정보가 교환되는지 설명. 다양한 Architecture들이 존재하지만 모두 하나의 목적을 가지고 있다. 바로, 관심사의 분리. 관심사 분리의..

클린 아키텍처 사용을 고민하게된 배경 Architcure 시스템을 구성하는 서브 시스템, 컴포넌트와 같이 구성요소 간의 관계를 관리하는 시스템의 구조 프로그램 내에서 큰 구조로 구성되어 다른 구성 요소들을 관리하는 역할 Design Pattern 소프트웨어 개발 분야에서 반복해서 나타나는 문제점를 쉽게 해결하기 위해서 과거의 소프트웨어 개발과정에서 발견된 설계의 노하우를 바탕으로 이후에도 사용하기 좋은 형태로 가공해 정리한 것 특정 유형의 문제를 해결하는 방법으로 소프트웨어 아키텍처보다는 조금 더 좁은 개념에 포함 즉, 디자인 패턴은 아키텍처에 포함된다. MVC ViewController는 크게 아래 두 가지 일을 한다. Data를 User에게 보여주는 역할 UI를 다루는 역할 하지만 위 두 가지는 아래..

Rx는 MVVM 디자인 패턴에 특화되어있다. 한 쪽 방향으로 쉽게 Observing 할 수 있는 구조로 되어있기 때문이다. RX 와 MVVM를 같이 사용할 때의 장점 MVVM 패턴을 사용하게 되면 ViewModel로 비지니스 로직을 분리할 수 있게 되고, test를 쉽게 할 수 있다는 있다. 또한, 보통 프론트와 모바일 파트는 기획 및 설계가 이루어지면 디자인, 백엔드(서버)의 개발이 이루어진 후 개발을 들어간다. 하지만 MVVM 패턴을 이용하게되면 목업정도의 데이터 구조와 API 구조를 알고 있다면 먼저 개발을 진행하고 완성된 개발 스펙에 맞게 converting이 가능하도록 해준다. 예를 들어, API요청을 Rx를 사용하지 않고 callback(completion: @escaping) 형태를 사용해 ..

RxCocoa 란? UIKit의 View에 RxSwift 요소들을 Extension으로 접목시킨 라이브러리 Bind subscribe에서 onNext로 오는 값을 대입해주는 것. 순환참조 없이 사용할 수 있다. binder binding 할 수 있는 타입 subscribe와의 차이점은, Error의 컨트롤 가능여부 이다. UI는 반드시 MainThread에서 동작해야하므로 항상 observeOn(MainScheduler.instance)를 추가 해주어야한다. onError, onCompleted, 그리고 dispose가 되면 스트림이 끊어지게 된다. 비지니스 로직에서는 에러와 완료 처리가 필요하지만, UI에서 스트림이 끊어지면 다시 그 UI를 사용하지 못하게 되므로 주의 해야한다. catchErrorJu..

Subject란? 기존의 Observable 타입의 스트림은 한번 스트림을 생성하면 그 후에 스트림에 이벤트를 추가하는 것이 불가능 합니다. 하지만 Subject는 가능합니다. Subject로 스트림을 생성하게 될 경우, subscribe한 후에도 해당 Subject에 onNext로 이벤트를 보내는 것이 가능해집니다. 즉, Observable과 Observer 역할 모두 가능한 타입 입니다. Subject 종류 PublishSubject, BehaviorSubject, ReplaySubject, AsyncSubject가 있습니다. PublishSubject 스트림이 빈 상태로 시작합니다. 새로운 이벤트가 추가되면 추가 되는 시점에 Subscribe하고 있는 스트림에만 이벤트가 전달 됩니다. Behavio..