• Massive View Controller(MVC를 비꼬는 약자) 증후군 피하기
• 가능한 적은 중복

struct Product {
    var name: String

    var rating: Double

    var price: Double?
}

class ProductViewModel: CellRepresentable {
    var product: Product

    var rowHeight: CGFloat = 80

    var price: String {
        guard let price = product.price else {
            return "free"
        }

        return "$\(price)"
    }

    init(product: Product) {
        self.product = product
    }

    func cellInstance(_ tableView: UITableView, indexPath: IndexPath) -> UITableViewCell {
        // Dequeue a cell

        let cell = tableView.dequeueReusableCell(withIdentifier: "ProductCell", for: indexPath) as! ProductTableViewCell


        // Pass ourselves (the view model) to setup the cell

        cell.setup(vm: self)

        // Return the cell

        return cell
    }
}

class ProductTableViewCell: UITableViewCell {
    func setup(vm: ProductViewModel) {
        self.textLabel?.text = vm.product.name
        self.detailTextLabel?.text = vm.price
    }
}

protocol CellRepresentable {
    var rowHeight: CGFloat { get }
    func cellInstance(_ tableView: UITableView, indexPath: IndexPath) -> UITableViewCell

}

extension SearchresultsViewController: UITableViewDataSource {
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return data.count
    }
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        return data[indexPath.row].cellInstance(tableView, indexPath: indexPath)
    }
}

extension SearchresultsViewController: UITableViewDelegate {
    func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
        return data[indexPath.row].rowHeight
    }
}

1. 이 패턴이 해결할 이슈들은 무엇인가?
2. 이것들은 어떻게 비슷한가?
3. 이것들은 어떻게 다른가?

• 장점: 최대의 테스트성; 뷰와 모델의 분리가 명확하다.
• 단점: 모든 데이터 바인딩을 여러분 스스로 해야하는, 더 많은 일거리(예를들어 모든 세터 프로퍼티들).

• 장점: 데이터 바인딩을 이용하여 코드의 양을 줄인다.
• 단점: 더 낮은 테스트성(데이터 바인딩 때문에), 모델에 직접 말하기 때문에 뷰는 더 낮은 캡슐화가 된다.

• • 뷰가 모델에 더 느슨하게 연결되있다. 프레젠터는 모델을 뷰에 바인딩할 책임을 가진다.
  • 뷰와의 인터렉션이 인터페이스를 통하기 때문에 유닛테스트하기 더 쉽다.
  • 보통 뷰:프레젠터는 1:1로 맵핑된다. 복잡한 뷰는 여러 프레젠터를 가질 것이다.

• • 컨트롤러는 행동 기반이고, 뷰를 통해 공유될 수 있다.
  • 표시를 위해 어떤 뷰를 선택할지 결정하는 책임일 수 있다.

1. 여러분 앱의 모든 의존성을 초기화한다.
2. 전역의 UIAppearance 값들을 초기설정한다.
3. 푸시 노티피케이션을 다룬다.
4. 푸시 노티피케이션을 등록한다.

public protocol ApplicationService: UIApplicationDelegate {}

import Foundation
import PluggableApplicationDelegate

final class LoggerApplicationService: NSObject, ApplicationService {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool {
        print("It has started!") return true
    }
    func applicationDidEnterBackground(_ application: UIApplication) {
        print("It has entered background”)
    }
}

import UIKit 
import PluggableApplicationDelegate 

@UIApplicationMain 
class AppDelegate: PluggableApplicationDelegate { 

    override var services: [ApplicationService] { 
        return [ LoggerApplicationService() ] 
    } 
}

import UIKit 
import PluggableApplicationDelegate 

@UIApplicationMain 
class AppDelegate: PluggableApplicationDelegate { 

    override var services: [ApplicationService] { 
        return [ 
            PushNotificationsService(), 
            AnalyticsService(), 
            CustomAppearanceService(),
            FirebaseService(), 
            FacebookSDKService() 
        ] 
    } 
}

• VIPER 아키텍처란?
• VIPER 아키텍처로 iOS 앱 만들기
• VIPER 아키텍처의 이점들

• View : View의 책임은 사용자의 동작을 Presenter로 보내주고 Presenter가 요청하는 모든 것을 보여준다.
• Intereactor : 이것은 비지니스 로직을 가지고있는 앱의 뼈대이다.
• Presenter : 이것의 책임은 사용자 동작에 Interactor에서 데이터를 뽑아온 뒤, 그것을 보여주기 위해 View에 보낸다. 또한 네비게이션(화면이동)을 위해 router(혹은 wireframe)에게 물어보기도한다.
• Entity : Interactor에서 사용하는 기본 오브젝트 모델이다.
• Router : 이것은 어느 화면이 언제 나타날지에대한 정보를 담고 있는 네비게이션 로직이다. 보통 wireframe으로 쓰인다.

• 시작화면 : 일반적인 시작화면이다 따라서 더 설명할건 없다.
• PostListView :화면  이 PostListView는 포스팅 목록을 가져와라고 Presenter에게 말한다. 그런 다음 Presenter는 관련 데이터를 위해 Interactor에게 접근한다. Intereactor는 로컬 데이터베이스에서 그 데이터의 사용 가능 여부를 확인해보고, 만약 데이터가 있으면 Presenter로 반환하고, Presenter는 View로 반환한다. 데이터가 로컬 데이터베이스에 없을경우 네트워크를 호출하여 데이터를 가져온 다음 Presenter에게 반환한다. 그리고 역시 이 데이터를 로컬 데이터베이스(CoreData)에 저장한다.
• PostDetailView 화면 : 사용자가 PostViewList에 표시된 포스트를 클릭하면, PostListPresenter는 PostDetailView를 열어도 되는지 Router(PostListWireFrame)에게 물어본다. 선택된 포스팅의 세부사항이 이 화면에 나타난다.

• 재사용성과 테스트용이함을 위해 코드를 분리할 수 있다.
• 그 역할에 맞춰 앱 컴포넌트를 분리할 수 있으며, 이것을 seperation of concern이라 부른다.
• 새 기능을 추가하기 쉽다.
• UI 로직이 비지니스 로직으로부터 떨어져있기 때문에 자연스럽게 테스트를 만들기 쉬워진다.

1. Smalltalk-80
2. 코코아(AppKit/UIKit)
3. Taligent
4. 컨트롤러 문제
5. 바인딩
6. 새로운 무언가?
7. 결론

아마 UI 개발에서 널리 인용된 패턴은 Model-View-Controller(MVC)이다. 또한 많이들 잘못 인용되고 있다. 나는 MVC가 이것처럼 아무것도 아니게 되버렸다고 설명한 것을 보는데 시간가는줄 몰랐다 - Martin Fowler, GUI Architectures

Model View Controller(MVC)

Model View Presenter(MVP)

• 사용자는 View에서 상호작용한다.
• View와 Presenter는 one-to-one 관계를 가진다. 이 의미는 하나의 View는 하나의 Presenter에 맵핑된다.
• View는 Presenter에 참조하고 있지만, Model에는 참조하지 않는다.
• View와 Presenter 사이에 두 방향으로 소통할 수 있다.

Model View ViewModel(MVVM)

• 사용자는 View에서 상호작용한다.
• View와 ViewModel은 many-to-one 관계를 가진다. 그 의미는 여러 View는 하나의 ViewModel에 맴핑될 수 있다.
• View는 ViewModel에 참조되지만 ViewModel은 View에대해 모른다.
• View와 ViewModel의 사이에 두방향 데이터 바인딩을 제공한다.

안드로이드 구현

• Activity / 앱 플로우의 독립적인 기능을 재사용할 수 있다.
• Activity 수를 줄인다.(앱 용량을 덜 잡아 먹는다)
• Controller와 의존적인 부분을 줄인다.

• Controller를 가볍게 만들어라, View와 Model을 연결해주는 역할만 하면 된다.(단일 책임 원칙)
• 이벤트를 다른 Controller에게 넘겨주어라(i.e. analytics)
• 안드로이드 클래스로부터 분리해라 ― 재사용을 위해

관련된 좋은 습관들

• Controller는 추상화에 의존한다(interface)
• 시스템 구성과 의존성을 컨트롤하기위해 코드 중심에 위치시킨다.
• 차후에 의존성 주입(dependency injection)을 옮길 수 있게 한다.

• 우리는 여러 기록장치를 사용하기 때문에 파사드를 이용해 이 API들을 한데 모아둘 필요가 있다.
• A/B 테스트나 다른 임시적인 기능들은 추상화돼있어야하고, 분리된 Controller나 파사드를 통해 접근가능해야한다.

이것들은 어떻게 생겼을까?

• Square mortar: Activity 라이프 사이클의 행동으로부터 분리시켜, View를 가볍게 만들고 View를 Controller와 한 쌍으로 만들어주는 간편한 라이브러리
• inloop AndroidViewModel: 엄청난 양의 코드 없이 Fragment나 Activity로부터 데이터와 상태를 분리시켜준다. 벙어리(dumb) View가 되는걸 줄인다.
• sockeqwe mosby: 현대 안드로이드 앱을 위한 Model-View-Presenter 라이브러리.

왜 우리가 MVC로부터 갈아타게 되었을까?

1. 로컬 객체에서 상태를 갱신
2. UI를 갱신
3. 데이터베이스를 갱신
4. 네트워크 연결이 가능해지면 서버로 보낼 그 변화를 큐에 넣기
5. 다른 객체에 상태 변화를 알리기

• Delegation
• KVO
• NSNotificationCenter
• Callback Blocks
• 소스의 신뢰로서 DB를 이용하기

• 예측불가능하고, 순차적으로(cascading)처럼 상태가 갱신됨
• 컴포넌트 사이에 의존성을 이해하기 쉽지 않음
• 정보의 흐름이 엉켜있음
• 소스의 신뢰가 불분명함

Flux로 들어가기전에 가벼운 설명

• view는 오직 store로부터 데이터를 받는다. store가 갱신되면 view에 있는 메소드를 이용해 불러낸다.
• view는 오직 action을 dispatch 함으로서 상태를 바꿀 수 있다. action은 단지 의도(intent)를 표현하는 역할이고 비즈니스 로직은 view로부터 숨겨져있기 때문이다.
• store는 action을 받았을 때만 그 상태를 갱신한다.

iOS를 위한 PlanGrid에서의 Flux

• 기능/view 특정 store : 각 View Controller(혹은 View Controller와 가깝게 연관된 각 그룹들)는 그것의 store를 받는다. 이 store는 view에 특화된 상태를 만든다.
• 상태를 공유하는 store : 우리는 수많은 view들 사이에서 상태가 공유되는데, 이 상태들을 저장하고 관리하는 store를 가진다. 우리는 이 어마어마한 양의 store들을 최소화시키기위해 노력중이다. IssueStore가 그 예시인데, 이것은 현재 선택된 청사진을 볼 수 있는지 없는지에 관한 모든 이슈 상태를 관리한다. 이 이슈들을 화면에 보여주거나 소통하는 수많은 view들은 이 store로부터 정보가 나온다. 이 store의 타입은 필수로 실시간 갱신되는 데이터베이스 쿼리처럼 동작한다.

1. 연관된 모든 action을 dispatcher와 함께 store를 등록한다. 이 예제에선 모든 AnnotationFilteringActions이 될 것이다.
2. 각 action들별로 호출할 수 있는 핸들러를 만든다.
3. 핸들러와 함께 필요한 비즈니스 로직을 동작하고 완성에 상태를 갱신한다.

1. 필요로 하는 모든 action을 위해 dispatcher와 함께 store를 등록한다. 현재 예제에서는 모두 annotationFilteringActions이 되어야한다.
2. 각 개별 action들을 위해 불릴 수 있는 핸들러를 구현한다.
3. 핸들러 안에서 해당 비즈니스 로직을 실행하고 그 결과의 상태를 갱신한다.

1. 상태 타입의 모양을 정의한다.
2. action을 정의한다.
3. 각 action들의 비즈니스 로직과 상태 변화를 구현한다. ― 이것은 store 안에 구현되있다.
4. view를 표현하기 위해 상태를 맵핑하는 UI 바인딩을 구현한다.

테스트 작성하기

1. store에서 비즈니스 로직
2. view 모델 프로바이더(이것은 우리 React이다 ― 입력 상태에 따라 UI 표현을 처리하는 함수 형태이다)

결론

• 새로운 기능을 조화롭게 구현한다. store, view 프로바이더, view controller의 기능의 구조는 거의 동일하다.
• 상태와 action을 잘 정렬함으로서 그 기능이 어떻게 동작하는지 이해하기 쉽고, BDD 스타일로 테스트 할 수 있다.
• store와 view를 강력하게 분리해준다. 특정 코드가 모호하게 있는 것이 드물다.
• 코드 읽기가 굉장히 간단해진다. view가 의존하는 것이 명확하게 보인다. 이게 디버깅하기 매우 수훨하게 해주기까지 한다.
• 위의 모든 것들이 새 개발자가 투입될때 쉽게 적응하게 만들어준다.

• UIKit 컴포넌트와 통합하는 첫 걸음이 약간 고통스러울 수 있다. React 컴포넌트와 다르게 UIKit view들은 새 상태에 의해 그들 스스로 간단하게 업데이트 되는 API 지원이 미흡하다. 이것이 조금 힘든 점이고, 우리는 view 바인딩에서 손수 구현하던지 UIKit 컴포넌트를 감싸는 커스텀 컴포넌트를 만들어야 할 필요가 있었다.
• 아직 우리 모든 새 코드가 Flux 패턴을 정확히 따르지 못했다. 예를들어 Flux에서 동작하는 네비게이션/라우팅 시스템이 아직 자리잡지 못했다. 그래서 Flux 아키텍처에 동등한 패턴을 통합시키던지 ReSwift Router를 사용하여 비슷한 실제 라우터를 사용할 필요가 있었다.
• 앱의 큰 요소들을 거쳐서쳐 공유되는 상태를 위해 좋은 패턴으로 만들어야한다.(이 포스팅의 초반부에서 "store의 영역은 어디까지인가?"라는 주제로 이야기하였다.) 기존 Flux 패턴으로의 store 사이에 의존성을 만들어야할까? 다른 대안은 무엇이 있을까?

• Flux - 페이스북의 공식적인 Flux 사이트. 원래의 소개가 들어있다.
• Unidirectional Data Flow in Swift - Swift에서의 Redux 개념과 원래의 ReSwift 구현에대해 이야기한다.
• ReSwift - Swift에서 Redux를 구현한 것.
• ReSwift Router - ReSwift 앱을 위한 정의된 라우터

ReactiveX는 시퀸스를 observable 함으로서 비동기와 이벤트 기반 프로그램으로 구성된 라이브러리이다.— reactivex.io

• (번역)Unit Testing in Swift — Part 1: The Philosophy
• (번역)Unit Testing iOS in Swift — Part 2: A Testable Architecture

1. Observable, Observer, Subscribe
   : 옵저버 디자인 패턴에서 사용하는 용어로, Observer는 구독(Subscribe)하는 오브젝트, Observable은 구독당하는 오브젝트를 말한다. Observer는 Observable에게 자기 자신을 넘겨줘서 Observable에서 이벤트가 발생할때 Observer에 있는 메소드를 호출해줌으로서 구독할 수 있다. 이 글에선 Observer나 Observable에 적합한 한글번역을 찾지 못해, 그대로 표기하였다.

우리 아키텍처를 보다 더 테스트하기 쉽게 만드는 과정은, 코드를 다른 방면으로도 더 낫게 만들어 줄 것이다. 보통 테스트 가능한 설계는 좋은 소프트웨어 설계와 직결된다.

ViewController와 함께 다루기

• (번역)Implementing MVVM in iOS with RxSwift
• (번역)iOS 아키텍쳐 패턴들

의존성 주입(Dependency Injection)

외부 프레임워크

서비스 팩토리(Service Factory)

모의 객체(Mocks)

1. 당신이 모의로 할 프로토콜을 구현한다.
2. 각 메소드는 모의객체 안에 methodDidGetCalled 라는 불리언 프로퍼티를 가지고 있어야하고 requestedParameterX 프로퍼티는 옵셔널하게 가지고 있는다. 이 메소드 구현은 보통 마지막에 이 프로퍼티를 설정하는 것이다. 여러분은 테스트한 클래스에 그 메소드가 옳바른 파라미터와 함께 호출 되었는지 나중에 확인해 볼 수 있다.
3. 만약 메소드가 리턴값이나 완료 핸들러의 뭉치를 가진다면 구조체에 methodXShouldFail이라는 불리언 프로퍼티가 있다. 이 메소드 구현은 불리언을 체크하고 성공하든 못했든 결과를 반환한다. 이렇게하면 테스트한 클래스에 실패가 생겼을 때 다루기 유용해진다.

테스트 작성하기

VIPER란?

유스케이스에 기반한 앱 설계

VIPER의 주요 부분

• View : Presenter에 의해 요청 받은 것을 화면에 표시하고, 유조의 입력을 Presenter에게 넘겨준다.
• Interactor : 유스케이스에 의해 부여된 비지니스 로직을 담고있다.
• Presenter : (Interactor로부터 받은)content를 화면에 보여주기 위해 준비하거나, (Interactor 로부터 요청한 데이터인) 유저 입력에 반응하여 처리하는 View 로직을 담고 있다.
• Entity : Interactor에 의해 사용되는 기본 모델의 객체를 담는다.
• Routing : 명령에의해 어떤 화면으로 갈지 알고있는 navigation 로직을 담고 있다.

Interactor

Entity

Presenter

View

Routing

VIPER에 맞춰진 앱 컴포넌트

모듈을 만들기 위해 VIPER를 사용하기

VIPER에서 테스트

결론

Swift 부록

Structs

Type Safety

iOS 아키텍처 관련 번역글

• (번역)iOS 아키텍쳐 패턴들 (스압주의)
• (번역)언제 VIPER를 사용할까?
• (번역)Brigade's Experience Using an MVC Alterative
• (번역)Architecting iOS Apps with VIPER objc.io

번역에 도움을 주신 분 :

• 정상엽

• 재사용에 용이함
• 동업에 적합함
• 일을 잘 분배할 수 있음
• 테스트하기 쉬움

VIPER는 무엇이고 어떻게 이것을 사용하는가?

• View/User Interface
• Interactor
• Presenter/Event Handler
• Entity
• Router/Wireframe

View/User Interface

• 유저게에 정보를 표시
• 유저의 인터렉션을 감지

유저에게 정보를 표시

유저 인터렉션을 감지

Presenter/Event Handler

• 무엇을 표시할지 View에게 말함
• 이벤트를 관리(다룬다)

무엇을 표시할지 View에게 말함

이벤트를 관리

Interactor

• 비즈니스 로직을 실행

비즈니스 로직을 실행시키기

Data Manager

• 데이터를 검색
• 데티러를 저장(부가적인)

데이터를 검색

데이터를 저장

• Data Manager는 먼저 'User ID'를 넘겨줌으로써 일치하는 해당 유저가 있는지 확인한다.
• 만일 유저를 찾으면 Interactor에게 알리고 메소드는 return된다.
• 만일 유저를 못 찾으면 Data Manager는 백엔드에서 유저를 찾아보고 서버를 이용하여 처리한다.
• 서버로부터 유저 정보를 받으면 유저는 첫 persistent가 되고 interactor에게 알린다.

Service

• 특정 Entity들을 위해 서버로 네트워크 요청을 날린다.

특정 Entity들을 위해 서버로 네트워크 요청 날리기

Entity

• 데이터를 표현한다.

Router/Wireframe

• 모든 다른 클래스 객체들을 초기화
• 앱에서 다른 View로의 경로를 다루기

모든 다른 클래스 객체를 초기화

• View는 로그인 화면을 표시한다.
• Presenter는 특정 유저이름, 패스워드를 받아 로그인 요청을 날리는 그런 이벤트들을 다룬다.
• Interactor는 유저 로그인 시도와 같은 이벤트를 위해 Data Manager에게 어떤 ㅁ[소드가 필요한지 알고있다.
• Data Manager는 어떤 Service가 검색에 사용되는지, 어떤 Service가 서버로 정보를 보낼 수 있는지 알고있다.
• Service는 실제 요청을 보내기 위해 HTTP URL을 알고있다.
• Entity는 서버로부터 받은 응답으로써 앱에 적용가능한 정보로 변환된 형태이다.

앱에서 다른 View로 라우팅하기

• View는 유저가 로그인을 요청했다고 Presenter에게 알린다.
• Presenter는 이 요청을 알아차리고 모듈의 각 기능을 수행후 Wireframe에게 알린다.

VIPER의 이점

• 재사용에 용이함
• 동업에 적합
• 일을 잘 나눌 수 있음
• 테스트하기 쉬움

재사용에 용이함

동업에 적합

일을 잘 나눌 수 있음

테스트하기 쉬움

결론

• Introduction to VIPER
• Architecting iOS Apps with VIPER