Deving

iOS) RIBs에서의 ViewDidLoad() 호출 시점 - init()에서 ViewDidLoad()가 호출되는 것에 관하여

snowe — Mon, 21 Mar 2022 20:56:57 +0900

들어가며

요즘 RIBs라는 아키텍쳐를 사용해서 개발을 하고 있다. RIBs에는 Router, Interactor, Builder, View, (Presenter)라는 개념이 등장한다. VIPER패턴에 익숙한 사람이라면 이런 개념들 또한 익숙할 것이다.

무튼 주제와 가까워져 보자면, 이슈사항은 RIBs와 Reacorkit을 함께 사용하면서 발생했다.

RIBs에서 ViewDidLoad(), didBecomeActive()의 호출 순서에 대한 고찰

그리고 나의 이슈트래킹

ReactorKit을 사용하기 위해서는 View에서도 ReactorKit의 존재를 알아야했는데, 이를 막기 위해 RIBs의 PresentableListener를 사용하였다.

protocol TransactionDetailPresentableListener: AnyObject {
	typealias Action = TransactionDetailAction
	typealias State = TransactionDetailState
	
	var state: Observable<State> { get }
	var currentState: State { get }
	
	func sendAction(_ action: Action)
}

그리고 기존에는 Reactor를 통해서 bind가 이루어져야했지만 위와같이 구현하면서 View는 ReactorKit의 존재를 모르기 때문에 별도로 위 Listener를 통한 bind메서드를 구현해주었다.

init() {
    super.init(nibName: nil, bundle: nil)
    ...
    bind(to: listener)
}

// MARK: Reactor

func bind(to listener: TransactionDetailPresentableListener?) {
    guard let listener = listener else { return }
    bindActions(to: listener)
    bindStates(from: listener)
}

func bindActions(to listener: TransactionDetailPresentableListener) {}

func bindStates(from listener: TransactionDetailPresentableListener) {
    listener.state.map(\.transactionInfo)
        .distinctUntilChanged()
        .bind(with: self, onNext: {(owner, response) in
            owner.responseBindToCell(with: response)
        }).disposed(by: disposeBag)
}

이러면 이제 뷰컨은 PresentableListener의 sendAction(_ :)을 통해 액션을 전달하고, 비즈니스 로직을 담당하는 Interactor에서 액션에 대한 Mutate, Reduce가 이루어진 뒤, 최종적으로 State를 반환한다. bind메서드로 listener의 state를 구독해놓았기 때문에 변화된 상태가 반환되면 bindStates내의 코드가 동작하게 된다.

문제는 이때 발생했다. init() 내에 작성해둔 bind메서드가 제대로 동작하지 않아 새로운 State가 반환되어도 뷰컨은 아무런 업데이트도 일어나지 않았다. init()시점에 뷰컨에 작성해둔 bind의 파라미터로 들어가야 할 listener가 nil인것이 이유였다.

이때부터 혼란이 찾아왔다. 프로젝트에는 리액터 킷을 사용하고 있는 RIB이 3개 더 있었는데 현재 작업 중인 RIB에서만 ViewController에서 listener에 nil이 들어왔다.. 그래서 답답한 나머지 리액터킷을 사용중인 RIB들의 생명주기 호출 순서 로그를 다 찍어보았다.

앞서 언급한 문제없이 잘 되는(리액터킷을 사용중인 3개의) RIB에서는 didBecomeActive()가 viewDidLoad()보다 먼저 불렸고, 대부분의 RIB에서는 viewDidLoad()가 didBecomeActive()보다 먼저 불렸다. 내가 알고있던 것과 달랐다. RIBs 튜토리얼에서도 didBecomeActive() 이후에 viewDidLoad()가 불렸고, 어디를 찾아봐도 이 순서가 디폴트였기 때문이다.

그래서 당시 패스트캠퍼스 강의로 RIBs를 기반으로 한 슈퍼앱 강의가 있었는데 그 강사분께 메일로 질문을 드려 답변을 받았다.

그 강의에서 진행 중인 프로젝트에서도 내가 알고있던 것과 다르게 viewDidLoad() -> didBecomeActive() 순으로 호출이 이루어지고 있었다.

친절하게 답변해주신 노수진님께 감사드립니다 :)

메일을 통해 얻은 가장 큰 수확은 달라질 수 있는 viewDidLoad()의 호출 시점이다.

아까 말했듯 RIBs는 Router, Interactor, Builder, View로 이루어져있다. 이들은 각자의 생명주기가 있고, 이는 RIBs 깃헙에 나와있는 튜토리얼을 진행하다보면 자연스레 알게된다. 튜토리얼을 마친 뒤 나는 무의식적으로 Interactor의 didBecomeActive()가 먼저 호출되고 View의 ViewController()가 이후에 호출된다는 것을 당연하게 생각하고 있었다. 이 순서는 무조건 보장된다고 생각했다. 그래서 더 깊게 알아보지 않았던게 화근이 되었다.

각 RIB의 build메서드에서는 본인의 뷰컨 인스턴스 및 자식 RIB들의 builder를 만들고 이를 라우팅의 인스턴스 파라미터로 전달한다. 라우터에서는 이들을 가지고 attach, detach를 할 때 사용한다.

func build(withListener listener: HomeListener) -> HomeRouting {

    let component = HomeComponent(dependency: dependency)

    let viewController = HomeViewController()
    let interactor = HomeInteractor(dependency: component, presenter: viewController)

    let transactionDetailBuilder = TransactionDetailBuilder(dependency: component)
    interactor.listener = listener

    return HomeRouter(
            interactor: interactor,
            viewController: viewController,	
            transactionDetailBuilder: transactionDetailBuilder
        )
}

내가 만약 addSubView와 같은 view에 접근하는 코드를 뷰컨의 viewDidLoad()에 작성해두었다면, 이 메서드에서는 아무런 생명주기도 호출되지 않는다. 하지만 이슈를 겪었던 나처럼 init()에 view에 접근하는 코드를 작성해두었다면 build메서드가 호출되면서 viewController가 인스턴스화 될 때 viewDidLoad()가 호출된다.

init()에서 뷰에 접근하지 않았다면 attach될 때 didBecomeActive가 호출 된 이후 뷰가 처음으로 접근 될 때 loadView()가 호출되고 viewDidLoad()가 호출될 것이다. push, present함으로써 무조건 view에 접근하는 것은 아니다.

암튼 그래서 내가 겪은 이슈는 해결을 하였다. init()에 view접근을 함으로써 listener가 들어오기 전에 뷰가 그려진 것이다.
나는 지금까지 얻은 정보들을 팀원에게 공유했다. 그리고 팀원들 중 한명이 "init()에서 뷰에 접근하는 것이 괜찮을까?" 라는 궁금증을 갖게 해주었다.

ViewDidLoad()가 init() 시점에 호출되어도 괜찮을까?

궁금증은 정확하게 "init()에서 뷰에 접근하여 viewDidLoad()가 호출되는 것이 성능상의 비효율을 가져오지는 않을까?" 였다.
질문을 드렸던 강사님께서 init()에 view에 접근하는 방식을 자주 사용한다고 말씀하셔서 재차 질문을 드려보았다.

내가 잘못 생각하고 있던 점도 있었지만, 전체적으로는 고민해 볼 만한 이슈였다고 생각한다.
결론적으로 이 질문에 대한 답변은 두 가지 로 나눌 수 있을 것 같다.

1. RIBs처럼 비즈니스 로직의 시작이 view가 되어서는 안되는 아키텍쳐
2. MVC처럼 비즈니스 로직의 시작이 view가 될수도 있는 아키텍쳐

RIBs를 사용한다면 모든 비즈니스 로직의 시작은 Interactor에서 이루어져야 하며, view는 최대한 바보같이 Interactor가 시키는 대로만 하는 수동적인 객체로 만들어야한다. 따라서 내가 이슈를 만나게 된 계기인 bind(listener: )의 호출 또한 Interactor의 active시점에 맞추어 Interactor가 호출시켜주는 것이 옳은 방법이라고 생각이 들었다. viewDidLoad()의 호출 시점에 의해 이후 비즈니스로직이 좌지우지 되서는 안된다고 생각했기 때문이다.

내가 겪은 이슈 외에 다른 발생가능한 성능상의 이슈를 생각해보았지만, RIBs 아키텍쳐에서 view의 viewDidLoad()나 init()에서는 뷰를 그리는 일 이외에 다른 일이 일어나서는 안된다. 그것이 아키텍쳐의 장점 중 하나이다. 따라서 성능상의 비효율을 일으킬 수 있는 것은 view를 미리 로드하는 정도일 것이다. RIBs에서는 build메서드에서 뷰컨을 인스턴스화 한다. 그리고 이 build메서드는 Router에서 attach시점이 되어서야 present/push를 하기 위해 호출된다. attach와 present는 거의 셋트로 동작하기 때문에 무엇이 먼저 호출되던 성능상의 비효율을 야기할 정도는 아닐 것이라고 생각한다.

하지만 만약 비즈니스 로직이 viewDidLoad()에도 포함될 수 있는 MVC와 같은 아키텍쳐에서는 어떨까?
MVC에서는 아래와 같은 코드가 가능해진다.

override func viewDidLoad() {
    super.viewDidLoad()
    configureUI()
    callUserInfoAPI()
    callPermissionAPI()
}

이 말인 즉슨, 탭바와 같이 뷰컨을 인스턴스로 만들어서 가지고 있어야하는 경우 불필요한 시점에 view를 포함한 서비스 호출까지 이루어질 수 있음을 의미한다. 이게 점점 많아질 경우 성능상의 비효율은 충분히 일어날 수 있다고 생각이된다.

결론에 와서 생각해보면 RIBs구조에 맞지 않는 코드를 작성해서(bind 호출을 viewDidLoad()에게 맡겨버린) 이와같은 이슈를 만나게 되었다. 하지만 이를 통해 평소에 생각하지 못했던 것들을 생각하게 되었고, 앞으로 더 좋은 코드를 작성할 수 있게되었기에 좋은 경험이었던 것 같다 :)

iOS) PinLayout

snowe — Wed, 2 Feb 2022 12:30:53 +0900

https://github.com/layoutBox/PinLayout 을 참고했습니다.

PinLayout

Luc Dion이라는 개발자가 만든 프레임워크이다. layoutBox라는 Swift를 사용한 layout 오픈 소스 organization 관리자인 이분은 PinLayout뿐만 아니라 FlexLayout을 만든 사람이기도 하다.

PinLayout은 기본적으로 AutoLayout을 사용하지 않고 레이아웃을 구성할 수 있도록 도와주는 프레임워크이다. AutoLayout을 사용하지 않음으로서 렌더링 성능이 훨씬 빠르다고 한다(8~12배). PinLayout은 수동으로 view를 layout하는데 때문에 Manual Layout과 속도가 비슷하거나 더 빠르다.

https://github.com/layoutBox/PinLayout/blob/master/docs/Benchmark.md

SnapKit이 AutoLayout을 좀 더 직관적으로 잡을 수 있도록 도와준 프레임워크라면,

PinLayout은 ManualLayout을 직관적으로 잡을 수 있게 도와주는 프레임워크이다.

(그렇다고 PinLayout을 사용하면 무조건 AutoLayout을 사용하면 안되는 것은 아니고 부분적으로도 적용할 수 있다.)

유의사항

PinLayout은 auto layout constrainst를 사용하지 않는다, 수동적으로 view들의 layout을 잡는 프레임워크이다.

이러한 이유때문에 우리는 디바이스의 회전을 포함한 layout의 업데이트를 UIView.layoutSubviews() 혹은 UIViewController.viewDidLayoutSubViews()에서 작성해주어야한다.

PinLayout 의 철칙

Manual layouting (auto layout에 의존하지 않는다).
PinLayout은 가능한 한 간단하고 빠른 상태로 존재한다. 앞서 말했듯, manual layout만큼 빠르다. performance results below.
Full control: You're in the middle of the layout process, no magic black box(음 내가 다 관리할 수 있다 정도..?)
한번에 하나의 뷰를 layout한다. 코드와 디버깅을 간단하게 만들어준다.
간결한 구문을 가짐으로써 대부분의 뷰를 한 줄로 layout할 수 있다.

Edges Layout

Superview에게 모든 edge를 10만큼 떨어뜨려서 레이아웃 잡기

빠르게 위의 레이아웃을 잡기위한 코드부터 보자면

viewA.pin.top(10).bottom(10).left(10).right(10) // 방법 1
view.pin.all(10) // 방법 2

이런식으로 사용한다. snp 대신 pin을 쓰는 방식이라고 생각하면 된다.

조금 다른 점이 있다면 snapkit의 경우에는 superView와 safeArea 모두 명시를 해주어야 했지만 pinLayout은 좀 다르다.

default가 superView이다.

따라서 기본적으로 top, bottom, left, right가 superview의 edge를 기준으로 한다.

그래서 safeArea만 따로 처리해주면 된다.

edge(top, left, right, bottom)의 layout을 잡는 방법에는 4가지가 있다.

1. top(_ offset: CGFloat), 2. top()

일반적인 사용. 띄우고 싶은 offset을 넣는다. 아예 안넣으면 0으로 인지

2. top(_ offset: Percent)

%로 넣을 수 있는건데..음 잘 쓰일지는 의문이다.

3. top(_ margin: UIEdgeInsets)

UIEdgeInsets을 사용하기 때문에 safeArea Layout을 잡을 때 유용하다.

testView.pin.top(self.view.pin.safeArea.top)

center의 layout을 잡기 위한 속성은 다음과 같다.

1. vCenter(vertical)

(_offset: CGFloat), (_offset: Percent), ()

// left, right를 superView에 맞추고 
// y축 중앙(vertical)에 
// 높이 100 크기의 뷰를 정렬한다.
label.pin.left().right().vCenter().height(100)

2. hCenter(horizontal)

(_offset: CGFloat), (_offset: Percent), ()

// top, bottom을 superView에 
// x축(horizontal) 중앙에 맞추고
// 너비를 100을 준다
label.pin().top().bottom().hCenter().width(100)

이 외에도 다양한 메서드들이 존재한다. 메서드 이름들이 직관적이라서 크게 헷갈리는 건 없는 것 같다.

   view.pin.top(20).bottom(20)   // The view has a top margin and a bottom margin of 20 pixels 
   view.pin.top().left()         // The view is pinned directly on its parent top and left edge
   view.pin.all()                // The view fill completely its parent (horizontally and vertically)
   view.pin.all(pin.safeArea)    // The view fill completely its parent safeArea 
   view.pin.top(25%).hCenter()   // The view is centered horizontally with a top margin of 25%
   view.pin.left(12).vCenter()   // The view is centered vertically
   view.pin.start(20).end(20)    // Support right-to-left languages.
   view.pin.horizontally(20)     // The view is filling its parent width with a left and right margin.
   view.pin.top().horizontally() // The view is pinned at the top edge of its parent and fill it horizontally.

Layout multiple edges relative to superview

pinLayout은 topLeft, topCenter 등 좀 더 직관적인 네이밍으로 코드를 간결하게 줄여준다.

(_ offset: CGFloat)

예를 들어, 우측 상단으로 뷰를 붙이고 싶다면 이렇게 코드를 작성해야한다.

viewA.pin.top().right().size(100)

하지만 pinLayout에서 제공하는 키워드를 이용하면 좀 더 간결한 코드 작성이 가능해진다.

viewA.pin.topRight().size(100)

모두 같은 방식으로 사용이 가능하다.

하지만 얘는 percent나 UIEdgeInset 적용은 불가능하다.

얘네도 있음! 비슷한 친구들~

↔️ << 요 표시는 AutoLayout의 leading, trailing과 비슷한 개념이 적용된다는 뜻인데
우리나라는 글을 읽는 방향이 left to right라서 topStart와 topLeft가 똑같지만
글을 읽는 방향이 right to left인 나라에서는 topStart == topRight가 된다.

topStart(_ offset: CGFloat) / topStart() ↔️
topEnd(_ offset: CGFloat) / topEnd() ↔️
bottomStart(_ offset: CGFloat) / bottomStart() ↔️
bottomEnd(_ offset: CGFloat) / bottomEnd() ↔️
centerStart(_ offset: CGFloat) / centerStart() ↔️
centerEnd(_ offset: CGFloat) / centerEnd() ↔️

Relative Edges layout

pinLayout은 다른 뷰들과 상대적인 포지션을 잡는 메서드들이 존재한다. 그래서 pinLayout을 사용하면 view가 다른 view 옆에 위치해야하거나 위에 위치해야 할 때 보다 편리하게 하나의 키워드로 작성이 가능하다.

snapkit을 사용했다면 하나씩 잡아줘야해서 코드가 길어졌을 것이다.

Methods: 이런 메소드가 존재한다.

above(of: UIView) / above(of: [UIView])
below(of: UIView) / below(of: [UIView])
before(of: UIView) / before(of: [UIView]) ↔️
after(of: UIView) / after(of: [UIView]) ↔️
left(of: UIView) / left(of: [UIView])
right(of: UIView) / right(of: [UIView])

[Example 1]

이런 레이아웃을 잡으려면

oneView.pin.topLeft().size(200)
twoView.pin.after(of: self.oneView).size(100)
threeView.pin.after(of: self.oneView).below(of: self.twoView).size(50)

이런식으로 작성하는 느낌이다!

[Example 2]

또 다른 예시로, C라는 뷰가 오른쪽처럼 되려면 아래의 세가지 스타일의 방법이 있다.

세번째 줄의 코드에 horizontallyBetween에 주목하자 저렇게 쓰면 코드 길이가 또 한번 줄어든다

같은 방식으로 verticallyBetween도 있다.
horizontallyBetween(:UIView, and: UIView, aligned: VerticalAlign)
verticallyBetween(:UIView, and: UIView, aligned: HorizontalAlign)

viewC.pin.top().right(of: viewA).left(of: viewB).margin(10)

viewC.pin.top().left(to: viewA.edge.right).right(to: viewB.edge.left). margin(10)

viewC.pin.horizontallyBetween(viewA, and: viewB, aligned: .top).marginHorizontal(10)

여기에 추가적으로 alignment를 곁들여서 좀 더 쉽게 레이아웃을 잡을 수도 있다.

HorizontalAlignment(.left / .center / .right / .start ↔️/ .end ↔️)
VerticalAlignment(.top / .center / .bottom)

Methods:

above(of: UIView, aligned: HorizontalAlignment)
above(of: [UIView], aligned: HorizontalAlignment)
below(of: UIView, aligned: HorizontalAlignment)
below(of: [UIView], aligned: HorizontalAlignment)
before(of: UIView, aligned: HorizontalAlignment)↔️
before(of: [UIView], aligned: HorizontalAlignment)↔️
after(of: UIView, aligned: HorizontalAlignment)↔️
after(of: [UIView], aligned: HorizontalAlignment)↔️
left(of: UIView, aligned: VerticalAlignment)
left(of: [UIView], aligned: HorizontalAlignment)
right(of: UIView, aligned: VerticalAlignment)
right(of: [UIView], aligned: HorizontalAlignment)

[Example 3]

oneView.pin.topLeft().size(200)
twoView.pin.after(of: self.oneView, aligned: .bottom).size(100)
threeView.pin.below(of: self.twoView, aligned: .right).size(50)

Edge

"지금 뷰를 다른 뷰의 오른쪽에 맞추고싶어, 왼쪽에 맞추고싶어"

Edges(top, vCenter, bottom, left, hCenter, right, start, end)를 이용해서 레이아웃 잡기

Methods:

top(to edge: ViewEdge)
vCenter(to edge: ViewEdge)
bottom(to edge: ViewEdge)
left(to: edge: ViewEdge)
hCenter(to: edge: ViewEdge)
right(to: edge: ViewEdge)
start(to: edge: ViewEdge)↔️
end(to: edge: ViewEdge)↔️

[Example 1]

aView.pin
    .top(to: bView.edge.top)
    .hCenter(to: bView.edge.hCenter)
    .marginTop(10)

Anchors

"지금 뷰를 다른 뷰의 오른쪽위, 왼쪽아래에 맞추고싶어"

Methods:

topLeft(to anchor: Anchor)
topCenter(to anchor: Anchor)
topRight(to anchor: Anchor)
topStart(to anchor: Anchor)↔️
topEnd(to anchor: Anchor)↔️
centerLeft(to anchor: Anchor)
center(to anchor: Anchor)
centerRight(to anchor: Anchor)
centerStart(to anchor: Anchor)↔️
centerEnd(to anchor: Anchor)↔️
bottomLeft(to anchor: Anchor)
bottomCenter(to anchor: Anchor)
bottomRight(to anchor: Anchor)
bottomStart(to anchor: Anchor)↔️
bottomEnd(to anchor: Anchor)

[Example 1]

	viewB.pin.center(to: viewA.anchor.topRight)

Width, Height

"너비, 높이를 지정하고 싶어"

Basic

width(:CGFloat) / width(:Percent) / width(of: UIView)
height(:CGFloat) / height(:Percent) / height(of: UIView)
size(:CGSize) / size(:Percent) / size(_ sideLength: CGFloat) / size(of: UIView)

[Example]

view.pin.width(100)
view.pin.width(50%)
view.pin.width(of: view1)

Max/Min

minWidth(:CGFloat) / minWidth(:Percent)
maxWidth(:CGFloat) / maxWidth(:Percent)
minHeight(:CGFloat) / minHeight(:Percent)
maxHeight(:CGFloat) / maxHeight(:Percent)

[Example]

viewA.pin.top(20).hCenter().width(100%).maxWidth(200)

justify()라는 키워드를 사용해도 된다.

- justify(_ : HorizontalAlign)
- align(_ : VerticalAlign)

viewA.pin.top(20).horizontally().maxWidth(200).justify(.center)

Adjusting Size

"내용에 맞게 size를 유동적으로 조절하고싶어"

sizeToFit()
sizeToFit(: FitType)
- Parameter fitType
  - .width
  - .height
  - .widthFlexible
  - .heightFlexible

[Example]

 // Adjust the view's size based on the result of `UIView.sizeToFit()` and center it.
 view.pin.center().sizeToFit()

 // Adjust the view's size based on a width of 100 pixels.
 // The resulting width will always match the pinned property `width(100)`.
 view.pin.width(100).sizeToFit(.width)

 // Adjust the view's size based on view's current width.
 // The resulting width will always match the view's original width.
 // The resulting height will never be bigger than the specified `maxHeight`.
 view.pin.sizeToFit(.width).maxHeight(100)

 // Adjust the view's size based on 100% of the superview's height.
 // The resulting height will always match the pinned property `height(100%)`.
 view.pin.height(100%).sizeToFit(.height)

// Adjust the view's size based on view's current height.
// The resulting width will always match the view's original height.
view.pin.sizeToFit(.height)

// Since `.widthFlexible` has been specified, its possible that the resulting
// width will be smaller or bigger than 100 pixels, based of the label's sizeThatFits()
// method result.
label.pin.width(100).sizeToFit(.widthFlexible)

[Example 2]

	label.pin.after(of: image, aligned: .top).right().marginHorizontal(10).sizeToFit(.width)

Aspect Ratio

"너비나 높이만 지정하고 비율로 사이즈를 잡고싶어"

aspectRatio(_ ratio: CGFloat)
aspectRatio(of view: UIView)
aspectRatio():
UIImageView에서 사용했을 때에만 image의 dimension을 사용하여 비율을 잡아준다. 다른 타입의 view들에서 이 메서드는 영향이 없다.

[Example]

imageView.pin.top().hCenter().width(50%).aspectRatio()

safeArea, readable and layout margins

UIKit은 3 종류의 area/guide가 존재하는데 PinLayout은 이걸 다음과 같이 표현한다.

UIView.pin.safeArea: UIKit's UIView.safeAreaInsets / UIView.safeAreaLayoutGuide.
UIView.pin.readableMargins: UIKit's UIView.readableContentGuide.
UIView.pin.layoutMargins: UIKit's UIView.layoutMargins / UIView.layoutMarginsGuide.

ipad에서 나타낸 영역과 가이드들

UIView's transforms

지금까지는 .pin이라는 키워드를 사용했지만 .pinFrame이라는 키워드도 존재합니다.

아까 글의 서두에서 유의사항을 다룰 때 PinLayout은 수동으로 레이아웃을 잡기 때문에 회전과 같은 상황에서도 직접 처리를 해주어야 한다는 것을 암시했어요.

.pinFrame은 뷰의 변환이 일어나는 상황(UIView.transform, scailing, rotation(회전))에서 사용됩니다.

[pin]

변화가 일어나지 않는 뷰의 사이즈와 위치를 잡는다. pin을 사용하면 변화가 일어나기 전에 레이아웃이 적용된다. 따라서 만약 자체적인 레이아웃의 수정 없이 transform을 사용하여 애니메이션을 주고 싶은 상황에서는 유용하게 사용될 수 있다.

[pinFrame]
변화가 일어난 뷰의 사이즈와 위치를 잡는다. 따라서 변화가 일어난 뒤에 레이아웃을 잡는다.

[Example]

이런 뷰가 있다고 할 때, 이 뷰를 가운데로 정렬하고 뷰의 회전을 시킬 것이다.

.pin을 사용하면?

  view.transform = .init(rotationAngle: CGFloat.pi / 2)
  view.pin.center().width(100).height(50)

뷰의 레이아웃이 잡히고 나서 transform이 이루어지기 때문에 처음 잡았던 레이아웃이 유지된채로 회전이 일어난다.

.pinFrame을 사용하면?

  view.transform = .init(rotationAngle: CGFloat.pi / 2)
  view.pinFrame.center().width(100).height(50)

transform이 일어난 뒤에 뷰의 레이아웃이 잡히기 때문에 회전에 따라서 뷰의 레이아웃도 변경된다.

같은 맥락에서

  aView.transform = .init(scaleX: 1.5, y: 1.5)
  aView.pin.width(100).height(50)
  bView.pin.below(of: aView, aligned: .left)

viewB가 변환 전인 A의 below에 레이아웃되었따.

aView.transform = .init(scaleX: 1.5, y: 1.5)
aView.pin.width(100).height(50)
bView.pinFrame.below(of: aView, aligned: .left)

viewB가 변환 이후의 A의 below에 레이아웃되었다.

Warning

PinLayout은 가능하지 않은 pin rule이 적용될 수 없거나 유효하지 않는 경우에 대해서 콘솔에 warning메시지를 띄워준다.

요런 로그가 찍힘

warning을 끌 수도 있는데 기본적으로는 나오도록 설정이 되어있다.

PinLayout Guide

가이드도 따로 있다.

항상 같은 순서로 작성해야한다. 코드를 항상 같은 형식으로 유지함으로써 좀 더 이해하기 쉽게 하기위한 목적이다.

아래의 순서가 추천된다.

view.pin.[EDGE|ANCHOR|RELATIVE].[WIDTH|HEIGHT|SIZE].[pinEdges()].[MARGINS].[sizeToFit()]

로직도 이 순서대로 적용이 된다. pinEdges()가 margin 전에 적용되고 sizeToFit()이 그 이후에 적용된다.

EDGE도 아래의 순서를 지켜주면 좋다.

TOP, BOTTOM, LEFT, RIGHT

PinLayout에 대해 전반적으로 훑어보는 시간을 가져보았다.

SnapKit을 더 많은 사람들이 사용하고 있지만 PinLayout만이 가진 장점들이 존재하기 때문에 충분히 고려할 만한 선택지일 것 같다.

좀 더 사용해보아야 단점도 보이겠지? 일단은 오늘은 여까지!

2021년 회고(이달의 앱, 졸업, 취준)

snowe — Mon, 31 Jan 2022 23:51:01 +0900

들어가며

이번 2021년도 역시나 코로나와 함께였다. 내 첫 회고가 2020년인데 지금이 네번째 회고임에도 아직도 코로나와 함께라니.. 올해는 꼭 종식되었으면 좋겠다.

올해는 힘든 순간도 많았지만 이전의 힘든 순간들을 보상받은 날들도 많았던 것 같다. 그게 더 힘을 낼 수 있는 원동력이 되어주었고 그렇게 2021년에도 나름의 성과와 함께 행복한 연말을 보낼 수 있었다.

글의 제목에 써 놓았듯 이번 회고의 키워드는 크게 3가지이다.

이달의 앱, 졸업, 취준

Cherish가 가져다 준 선물, 이달의 앱

꽤 오래된 일이긴 한데, 2021년 9월 15일.. 무려 Apple 가을 이벤트가 열리고 있는 순간에 Cherish 단톡방이 울렸다.

아직도 생생해

처음엔 좀 안믿겼다. 왜 올라간거지? 싶었고.. 그치만! 우리가 그만큼 열심히 했고 나는 정말 애정을 가지고 있었던 서비스였기에 뿌듯함과 자랑스러움이 몰려왔다.

그렇게 시작을 한 Cherish는..

Cherish, 최고의 플레이

장난아니게 됐다.
(오늘의 앱은 심지어 두번 올라옴)

처음에 우리가 앱을 출시하기로 했던 이유는 3주라는 기간동안 팀원간의 화합이 너무 좋았고, 모두 서비스를 개발하는 기간과 서비스에 대한 애정이 비례하여 늘어났기때문이다. 그래서 Cherish의 끝맺음을 앱 출시로 결정했었다.
근데 위와 같은 놀라운 일들이 연속적으로 일어났고, 이로 인해 나는 사람들이 광고를 왜 맡기는지 알게 되었다.

01.30일 현재 다운로드 수

잔잔하다가 갑자기 송곳처럼 튀어오르는 부분이 앱스토어에 배너가 걸린 날이다.
앱스토어 덕분에 많은 사용자가 유입되었고 덕분에 아직까지도 MAU가 평균 250정도를 유지하고 있다.

이렇게 사랑해주시는데 가만히 있을 수 없지..

바로 회의를 했고 어떤 점을 개선해야하고 어떤 기능을 추가할지 논의하였다.
기존 앱에 남아있던 잔버그를 개선하였고 유저들이 보내준 피드백들을 취합하여 현재 팀 상황에서 빠르게 적용 가능한 기능들을 우선적으로 반영하였다.

이 유지보수 과정 속에서 나는 정말 값진 경험을 하였다.

현 아키텍쳐의 문제점
우리가 해왔던 git flow의 문제점
그때의 나를 욕하고 있는 지금의 나

이 세가지로 요약할 수 있을 것 같다.

현 아키텍쳐의 문제점

우리는 MVC로 개발해왔다. 이유를 묻는다면 Cherish는 내 첫 iOS 프로젝트였고, 아직 아키텍쳐를 깊게 공부할 수 있는 수준이 되지 못했었다. 앱이 잘 돌아가도록 완성하는 것이 가장 큰 목표였기에 MVC를 택해서 개발하였다. 그리고 무엇보다 다른 아키텍쳐의 필요성을 느끼고있지 못했다.

하지만 유지보수를 하면서 정말 Massive View Controller라는 말을 직접적으로 깨닫게 되었다. 버그가 발생했을 때 내가 예전에 쓴 코드는 정말 잘 기억이 나지 않았다. 그렇다고 테스트를 할 수도 없었다. UI와 비즈니스 로직이 너무 엮여있었기 때문에..

그래도 난 오히려 좋았다. 공부의 필요성을 느끼고 공부를 시작하는 것과 그냥 공부하는 것은 분명히 다르기 때문이다. 요즘 올라오는 글을 보면 알겠지만 지금은 RIBs를 공부중이다.

MVC를 하다가 새로운 아키텍쳐를 공부하니까 괜히 뭔가 더 대단해진 것 같고 그렇다..ㅋㅋ Cherish도 연습삼아 바꿔보아도 재미있을듯!

Git Flow의 문제점

나름 커밋 컨벤션도 만들고 했지만 어느정도 시간이 지나고 git에 대한 공부가 이루어진 뒤 보니 그때의 협업 방법이 최선이 아니라는 것을 알게 되었다. PR을 그저 merge의 수단으로만 사용했고 심지어는 PR없이 merge만 했을 때도 많았다. merge도 squash, rebase는 커녕 그냥 merge만 했었다ㅎㅎ

시간이 지나면서 더 효율적인 협업 방법을 알게 되었고 조금은 늦었을 수 있지만 ISSUE와 PR의 코드리뷰를 적극 활용하려 노력했다. 앱잼때처럼 Cherish에 몰두할 수 없다보니 코드리뷰가 생각처럼 활발히 되지는 못해서 조금 아쉽기는 하지만 그래도 꾸준히 노력중이다.

merge에도 rebase와 squash에 대해 공부할 수 있었고 stash 라는 아주 좋은 녀석도 알게되었다.
Git은 알면 알수록 재밌는 것 같다. 아직 모르는 것들이 많지만 점점 알아가는 것이 재미있다.

그때의 나를 욕하고 있는 지금의 나

진짜 왜 코드를 저렇게 짰나 싶다. 근데 이건 어쩔 수 없는게 내가 계속 공부를 하고 있는 동안에는 어제 짠 코드가 오늘 보면 맘에 안든다.
같은 맥락에서 내가 짠 모든 코드를 갈아엎고 싶었다. 그때는 storyboard가 편했지만 지금은 code-base가 편해졌다. 이와 비슷하게 면접 준비를 하면서 여러가지를 알고나니 코드 스타일이 정말 많이 변해있었다.

모든 코드를 갈아 엎지는 못했지만 그래도 1/3 정도를 리팩토링 하였다. 나름 Composition도 활용하고 코드 효율성도 신경 쓰면서..했는데 지금보면 또 마음에 안들겠지?

무튼 리팩토링과 더불어 firebase 애널리틱스, fastlane 등을 적용해서 프로젝트의 방향성도 잡아보고, 귀찮은 과정을 개선하기도 했다.

Cherish라는 서비스를 통해 정말 많이 성장했던 것 같다.
그냥 공부하는 것 만으로는 느낄 수 없는 경험도 했고, 앱 개발자로서 얻은 인사이트가 상당하다.
이제 회사다니니까 시간은 좀 부족해지더라도 꾸준히..틈틈히 개선해서 서버 비용이 의미없어지는 그 날까지.. 노력해야지

졸업, 취준

2021년을 끝으로 학교의 졸업요건을 모두 갖췄다. 학점도 잘 채웠고, 졸업 작품도 복전 졸업논문도 잘 통과됐고..! 그리고 취뽀도 했다.

4학년 1학기 부터 인턴을 넣었고 코테, 면접을 보면서 꾸준히 공부했다. 떨어질 때 마다 낙담보다는 기록을 했고 부족한 부분을 다시 공부하려 노력했던 것 같다. 다른 사람들과 비교했을 때 정말 많이 넣은건 아니지만 그래도 1학기 때 6곳 2학기 때 14 곳 정도를 넣었다.

실제로 받은 질문들과 그 질문에서 나올 수 있는 꼬리질문들을 나름대로 정리했었다

취준하면서 그래도 제일 힘들었던 순간을 꼽자면 코테 떨어질 때, 면접에서 꼬이기 시작할 때 인 것 같다.

코테부터 이야기 하자면 나는 그닥 알고리즘적인 사고가 뛰어난 건 아닌 것 같았다. 처음엔 정말 기대조차 못할정도의 결과로 떨어졌다. 1학기때는 모든 코테에서 거의 한, 두문제 밖에 못 풀었으니까..?

그래도 계속 꾸준히 하니까 늘긴 하더라, 2학기때는 떨어지더라도 커트에 근접하게 떨어졌고, 하다보니 IT 대기업 코테에 붙을 정도의 실력이 됐다.
역시 알고리즘은 묵묵히 꾸준히 해야하는 것인가..

채용 프로세스에는 과제 전형이 있는 곳도 있었는데, 내가 짜는 코드에 대해 명확히 파악하고 있었던 것이 코드 리뷰를 하면서 큰 도움이 되었다. 내 코드의 장점, 이렇게 짠 이유에 대해 충분히 설명이 가능했고 단점에 대해서도 받아들일 수 있었다.

iOS로 취준을 했던 나는 iOS 면접 질문을 아카이빙 해 놓은 레포를 바탕으로 혼자 하나씩 꾸준히 공부하였다.

GitHub - snowedev/I-am-interviewee: ‍ iOS 기술 면접을 준비하는 레포

‍ iOS 기술 면접을 준비하는 레포. Contribute to snowedev/I-am-interviewee development by creating an account on GitHub.

github.com

원래는 여기 있는 질문들을 다 채우고 public으로 돌리려했으나.. 공부할수록 공부할 것들이 많아지다보니 이러다간 영원히 private일 것 같아.. 일단 돌려놓고 천천히 추가하려한다.

무튼 코테를 떨어지며 다른 진로를 고민해보기도 하고, 가까스로 간 면접에서 멘탈이 부서져도 보고, 어쩔때는 칭찬도 들으면서 자신감도 얻었었다. 나는 그렇게 취준을 마무리했다.

요즘은 새로운 스택을 공부하느라 바쁘다. RIBs, ReactorKit, Rx, Tuist, FlexLayout 등등.. 지금까지 공부한 것들이 아닌 새롭게 익혀 실무에 적용해야하는 것이 부담으로 다가올때도 있지만 그만큼 내가 성장할 수 있는 포인트가 많아지는 것 같아서 기대되기도 한다. 그래도 다행히 새로운걸 배우는 게 아직 재미있다 :)

지금 이렇게 쓰다보니 생략된 부분이 많은 것 같긴하지만 내가 취준을 하며 몸소 느낀 취준을 앞둔 누군가에게 해줄 수 있는 말은 명확하다.

기업마다 인재를 보는 시각은 다르다. 면접이라는 단편적인 절차로 내가 지금까지 해 온 공부를 전부 증명하기란 어려우니 떨어졌다고 너무 자신을 한없이 깎아내리지 않았으면 좋겠다. 소리 한번 지르고 털어버리자. 세상은 넓고 좋은 기업은 생각보다 많다.
망친 면접을 잊으려고 하기 보다는 그 면접을 두번이고 세번이고 복기하면서 그날의 질문을 준비해보자. 정말 내가 부족한 부분만 찝어내는 몇 없는 면접관이다.
너무 조급해 하지 않았으면 좋겠다. 나도 정말 조급한 순간이 많았지만, 조급함 때문에 오히려 아무것도 못하는 상황이 생기더라.. 약간의 여유를 갖기 위해 노력하는건 좋은 것 같다.

2021년 한 해도 이렇게 지나갔다.
2022년에는 개발자로서 더 성장하고, 돈도 잘 모으고, 코로나 좀 끝나서 맘 편히 놀고, 주변 사람도 잘 챙기는 한 해가 되었으면 좋겠다.

iOS) RIBs Tutorial 3 - Dependency 활용

snowe — Wed, 26 Jan 2022 09:25:23 +0900

RIBs Dependency Injection and Communication

튜토리얼2를 마쳤다는 전제 하에 진행됩니다.

튜토리얼2 까지는 RIBs의 핵심 개념들에 대해서 다루었습니다. 튜토리얼3 에서는 새로운 RIB을 만들지 않고 지금까지 만들었던 RIBs를 수정하는 방식으로 진행됩니다.

지금까지의 RIB Tree

Goals

TicTacToe Game의 처음 시작 화면에 몇가지가 추가됩니다.

게임에 어떤 플레이어들이 참가하는지 알고싶기에 플레이어의 이름을 표시해준다.
플레이어들이 게임을 여러번 한다면 그들의 게임 스코어를 추적해서 누적 점수를 시작 화면에 보여준다.

위의 것들을 하기위해서 우리는 다음과 같은 목표를 갖게 됩니다.

Builder의 build 메서드를 통해 동적인 dependency를 하위 RIB에 넘겨주는 것
Dependency Injection(DI, 의존성 주입) tree를 사용해 정적인 dependency를 넘겨주는 것
- Swfitd의 확장 기반의 의존성을 따릅니다.
RIB life-cycle을 사용하여 Rx stream의 life-cycle을 관리하는 것

Dynamic dependencies

튜토리얼 1에서 우리는 로그인 형식을 만들었고 거기서 입력받은 플레이어들의 이름은 LoggedOut RIB 부터 Root RIB까지 전달되었습니다. 하지만 튜토리얼 2에서 우리가 새롭게 만든 뷰에서 그 데이터를 사용하지 않았어요.

이번 튜토리얼에서 RIB tree를 따라서 그 데이터(플레이어 이름)를 하위 RIB인 OffGame, TicTacToe RIB에게 전달할거에요

동적 dependency부터 시작하겠습니다!

0. LoggedInBuildable protocol을 아래와 같이 업데이트해서 두 플레이어의 이름을 가변 dependency로 받을 수 있도록 해주세요.

protocol LoggedInBuildable: Buildable {
    func build(withListener listener: LoggedInListener, 
               player1Name: String, 
               player2Name: String) -> LoggedInRouting
}

1. 방금 수정한 LoggedInBuildable protocol을 준수하는 LoggedInBuilder의 build메서드도 수정한대로 업데이트 해주어야겠죠?

func build(withListener listener: LoggedInListener, player1Name: String, player2Name: String) -> LoggedInRouting {
    let component = LoggedInComponent(dependency: dependency,
                                      player1Name: player1Name,
                                      player2Name: player2Name)
}

이렇게 함으로써 LoggedIn의 상위 RIB으로 부터 받아온 플레이어의 이름들은 동적 dependency에서 정적 dependency로 효율적으로 변환되고 하위 RIB에서 사용할 수 있게됩니다.

2. 위에서 LoggedIn으로 라우팅될때 플레이어의 이름을 받을 수 있도록 위에서 LoggedInBuilder의 build메서드를 수정했어요
이제 RootRouter 클래스에서 LoggedIn으로 라우팅해줄때 사용되는 routeToLoggedIn 메서드도 플레이어 이름을 받을 수 있게 파라미터를 수정해줄게요.

func routeToLoggedIn(withPlayer1Name player1Name: String, player2Name: String) {
    // Detach logged out.
    if let loggedOut = self.loggedOut {
        detachChild(loggedOut)
        viewController.dismiss(viewController: loggedOut.viewControllable)
        self.loggedOut = nil
    }

    let loggedIn = loggedInBuilder.build(withListener: interactor, player1Name: player1Name, player2Name: player2Name)
    attachChild(loggedIn)
}

지금까지 진행한 수정사항들을 통해서 사용자에 의해 입력된 플레이어의 이름들은 LoggedOut RIB에 의해 처리되며, 그 결과 LoggedIn RIB, 그리고 그 하위 RIB에서 사용할 수 있게 되었어요

Dynamic dependencies VS Static dependencies

우리는 LoggedIn RIB이 build될 때 플레이어 이름들을 주입하기로 결정했습니다. 이를 동적 주입이라고 합니다.
이렇게 하지 않는다면 RootBuilder에서 build할 때 넣어주는 방법이 있는데요, 이러한 경우에는 RootBuilder가 만들어지는 시점에 플레이어 이름이 없을 수도 있기 때문에 옵셔널로 받아주어야 합니다.

옵셔널이 생기게 되면 옵셔널 체이닝, 혹은 바인딩과 같은 추가적인 코드가 발생하게 되기 때문에 그런 상황에서 추천되지 않는 방식인 것 같다.

따라서 우리가 진행한 것처럼 적절하게 범위가 한정된 종속성은 불변 가정을 할 수 있게 하고 번거로운 옵셔널 처리를 하지 않아도 돼요.

정리하자면 static으로 종속성을 넣어줄 경우 Optional Value에 대한 불필요한, 불합리한 코드를 작성하는 경우가 생긴다면 적당한 Scope를 지정하여 동적으로 종속성을 넣어주는 것도 좋은 방법이 될 수 있습니다.

RIB's Dependencies and Components

Dependency, Component에 대한 개념을 지금까지 다루지 않았는데요.

RIBs에서
Dependency는 RIB이 제대로 인스턴스화 되기 위해 상위 RIB으로부터 필요한 종속성을 나열하는 프로토콜입니다.
Component는 Dependency 프로토콜의 수행자입니다. 상위 종속성을 RIB의 빌더에 제공하는것 외에도, Component는 RIB이 자신과 하위 RIB을 위해 만드는 Dependency를 소유할 책임이 있습니다.

보통 상위 RIB이 하위 RIB을 인스턴스화 할 때, 자신의 Component를 하위 Builder에 생성자 dependency로 주입합니다.

func build() -> LaunchRouting { 		
    ...         
    let component = RootComponent(dependency: dependency,rootViewController: viewController)
    ...          
    // 보통 상위 RIB이 하위 RIB을 인스턴스화 할 때, 
    // 자신의 Component를 하위 Builder에 생성자 dependency로 주입합니다.
    let loggedOutBuilder = LoggedOutBuilder(dependency: component) 
    let loggedInBuilder = LoggedInBuilder(dependency: component)  
    
    return RootRouter(
        interactor: interactor, 
        viewController: viewController, 
        loggedOutBuilder: loggedOutBuilder,
        loggedInBuilder: loggedInBuilder)
}

주입된 각각의 Component는 하위 RIB에게 어떤 종속성을 노출시킬지 결정합니다.

Component에 포함되어있는 종속성은 일반적으로 DI(의존성 주입) 트리 아래로 전달되어야 하는 일부 상태를 보유하거나, 구성하는 데 비용이 많이 들고, 성능상의 이유로 RIB간에 공유됩니다.

Passing the player names to the OffGame scope using the DI tree

위에서 공부했듯이 종속성에는 동적인 것과 정적인 것이 존재해요. 정적인 종속성을 주입할 때에는 주입하는 값이 옵셔널일 경우 비효율적인 일이 발생한다는 것까지 배웠습니다.

이제 우리가 종속성을 주입할 친구는 OffGame RIB이고 이 친구는 무조건 플레이어 이름을 가져야만 해요 옵셔널이 아니라는 뜻이죠?

0. 그래서 정적으로 종속성을 주입해줄거에요. OffGameDependency를 다음과 같이 수정해주세요.
이 정적 종속성은 상위 RIB에 의해 OffGame RIB이 이니셜라이징 될 때 무조건 담겨서 와야해요.

protocol OffGameDependency: Dependency {
    var player1Name: String { get }
    var player2Name: String { get }
}

1. 다음으로 우리는 이 종속성을 OffGame 자신의 Scope 내에서 사용할 수 있도록 해줄거에요.

fileprivate으로 선언해줌으로써 OffGameBuilder.swift 파일 내에서만 사용할 수 있어요
LoggedInComponent에서는 하위 RIB에게 값을 제공해주어야 해서 fileprivate을 사용하지 않았습니다.

OffGameComponent를 다음과 같이 수정해주세요

final class OffGameComponent: Component<OffGameDependency> {     fileprivate var player1Name: String {         return dependency.player1Name     }      fileprivate var player2Name: String {         return dependency.player2Name     } }

위 코드를 작성함으로써 우리는 이제 상위 RIB으로 부터 player1Name과 player2Name을 꼭 받아야해요. 하지만 아까 LoggedIn RIB의 LoggedInComponent에서 이미 넘겨주도록 구현해놨기 때문에 별도로 진행할 필요는 없습니다.

2. 이 종속성을 OffGameViewController의 생성자를 통해 OffGameViewController로 넘겨줄거에요. 정석대로라면 OffGameInteractor에 이를 넘겨주고 OffGamePresentable을 통해 뷰가 이 정보를 보여줄 수 있도록 메서드를 작성해주어야 하지만 현재 플레이어 이름을 보여주는것에는 별도의 로직이 필요 없기 때문에 바로 ViewController로 넣어줍니다.

view controller에 종속성을 주입하기 위해 OffGameBuilder를 다음과 같이 업데이트 해주세요

final class OffGameBuilder: Builder<OffGameDependency>, OffGameBuildable {
    override init(dependency: OffGameDependency) {
        super.init(dependency: dependency)
    }

    func build(withListener listener: OffGameListener) -> OffGameRouting {
        let component = OffGameComponent(dependency: dependency)
        let viewController = OffGameViewController(player1Name: component.player1Name,
                                                   player2Name: component.player2Name)
        let interactor = OffGameInteractor(presenter: viewController)
        interactor.listener = listener
        return OffGameRouter(interactor: interactor, viewController: viewController)
    }
}

그리고 OffGameViewController이 플레이어 이름을 이니셜라이징하는 동안 받을 수 있게 수정 해주세요.

...

private let player1Name: String
private let player2Name: String

init(player1Name: String, player2Name: String) {
    self.player1Name = player1Name
    self.player2Name = player2Name
    super.init(nibName: nil, bundle: nil)
}

...

이제 데이터는 다 받아왔으니 받아온 데이터를 라벨에 보여줄 수 있도록 UI를 구성해주시면 됩니다!

~~게임에 어떤 플레이어들이 참가하는지 알고싶기에 플레이어의 이름을 표시해준다.~~

Track scores using a Rx stream

지금은 게임이 끝나면 플레이어는 그냥 다시 게임을 시작할 수 있는 화면으로만 이동하게 됩니다.
이제 Rx stream을 사용하여 점수를 관찰해서 시작화면에서 누적점수를 볼 수 있도록 하려고 합니다.

RIBs를 설치하면 그 안에 Rx도 포함되어있을 정도로 Rx가 굉장히 널리 사용되는데요. 하위 RIB이 자신의 상위 RIB으로부터 동적인 데이터를 얻어야 할 때, 데이터 생산자 측에서 Observable로 데이터를 감싸고 데이터를 사용해야하는 쪽에서 이를 subscribe하는 방식으로 자주 사용됩니다.

우리의 경우, 게임 스코어는 게임이 진행되는 TicTacToe RIB에 의해 업데이트 되어야 합니다. 그리고 그 스코어는 스코어를 보여줄 OffGame RIB에 의해 사용될 것입니다. TicTacToe와 OffGame은 서로의 존재를 모르기 때문에 아무것도 안거치고 직접적으로 데이터를 주고받을 수는 없습니다. 하지만 두 RIB의 부모가 같기때문에 LoggedIn RIB에서 score stream을 구현할것입니다.

우리는 총 두가지(ScoreStream(읽기전용), MutableScoreStream(가변버전))를 Models/ScoreStream에서 만들어놨습니다. 이에 대해서는 아래에서 추가적으로 설명됩니다.

LoggedInComponent에서 공유 ScoreStream 인스턴스를 만들어주세요.

TicTacToe, OffGame 모두에 전달해야하기 때문에 LoggedInComponent에 생성.
MutableScoreStream은 LoggedIn RIB과 그 하위 RIB에서 사용하도록 만든 싱글톤 인스턴스입니다.

var mutableScoreStream: MutableScoreStream {
    return shared { ScoreStreamImpl() }
}

Stream 부분에 대해서 좀 이해가 어려웠는데 잘 설명해주신 글이 있어서 인용해왔습니다.

그런데 왜 shared로 만드는가? shared의 내부 구성?

Component의 기본 구현을 보면 다음과 같은 shared라는 함수가 만들어져 있다. 여기서 __function은 shared를 부른 주체인 mutalbeScoreStream이다. 기본 Component 클래스에는 sharedInstance라는 프로퍼티가 있는데 이 프로퍼티에 [키:밸류] 형태로 전달인자를 저장해놓는다. 만약 해당 키로 저장된게 있으면 그걸 사용하고, 없으면 새로 저장한다. component 내에서 공유되는 dependency는 shared에 저장한다.
public final func shared<T>(__function: String = #function, _ factory: () -> T) -> T {
 lock.lock()   
 defer { 
         lock.unlock()
 }    

 if let instance = (sharedInstances[__function] as? T?) ?? nil {
     return instance
 } 

 let instance = factory()
 sharedInstances[__function] = instance
 return instance
}  
// MARK: - Private 
private var sharedInstances = [String: Any]()
private let lock = NSRecursiveLock()
shared 인스턴스는 주어진 scope에 대해 생성된 싱글톤을 의미한다. (우리의 경우, scope는 LoggedIn RIB와 모든 자식을 포함한다). 스트림은 대부분의 상태 저장 객체와 마찬가지로 일반적으로 범위가 있는 싱글톤이다. 그러나 대부분의 다른 dependency는 stateless해야 하며, 따라서 공유되지 않아야 한다.

LoggedInComponent에서 mutableScoreStream 프로퍼티는 fileprivate가 아니라 internal로 생성되었다는 것을 알아두자. LoggedIn의 children이 접근할 수 있어야 하기 때문에 이 프로퍼티를 파일 외부에 노출해야 한다. 이 요구 사항이 유지되지 않으면, stream을 파일 내에 캡슐화하는 것이 바람직하다.

그리고, RIB에서 직접 사용되는 dependency만 component의 기본 구현에 배치되어야 하며, 플레이어 이름과 같은 동적 종속성에서 주입되는 stored property는 예외다. 그러니까 mutableScoreStream같은건 LoggedInInteractor(LoggedInRIB)에서 바로 쓰이므로 LoggedInComponent에다가 넣은 것이고, 만약에 어디에 전달되는 용도의 dependency였다면 해당 전달child를 구현하는 부분의 Extension에 넣어야 한다. 예를 들어 OffGame에 전달하는 경우에, LoggedInComponent+OffGame 파일에 넣는것이좋다.

이제 mutableScoreStream을 LoggedInInteractor로 넘겨준다. 이로써 나중에 스코어를 갱신할 수 있다.

...

private let mutableScoreStream: MutableScoreStream

init(mutableScoreStream: MutableScoreStream) {
    self.mutableScoreStream = mutableScoreStream
}

...

// LoggedInBuilder  
func build(withListener listener: LoggedInListener, player1Name: String, player2Name: String) -> LoggedInRouting {
    let component = LoggedInComponent(dependency: dependency,
                                      player1Name: player1Name,
                                      player2Name: player2Name)
    let interactor = LoggedInInteractor(mutableScoreStream: component.mutableScoreStream)

...

Passing a read-only ScoreStream down to OffGame scope for displaying

이제 우리는 읽기 버전의 ScoreStream을 OffGame RIB에서 게임이 끝나면 점수를 보여주는 데에 사용할 수 있도록(수정은 X) 내려줄거에요. OffGameDependency 프로토콜 내부에 읽기버젼의 ScoreStream을 선언해주세요. OffGame RIB의 범위 내에서만 사용가능한(fileprivate) dependency로써 선언해주셔야합니다.

protocol OffGameDependency: Dependency {
    var player1Name: String { get }
    var player2Name: String { get }
    var scoreStream: ScoreStream { get }
}

OffGameComponent에서 dependency fileprivate로 선언해주세요.

fileprivate var scoreStream: ScoreStream {
    return dependency.scoreStream
}

OffGame의 builder는 OffGameInteractor가 이 데이터를 사용할 수 있도록 stream을 주입시켜주어야해요

func build(withListener listener: OffGameListener) -> OffGameRouting {
    let component = OffGameComponent(dependency: dependency)
    let viewController = OffGameViewController(player1Name: component.player1Name,
                                               player2Name: component.player2Name)
    let interactor = OffGameInteractor(presenter: viewController,
                                       scoreStream: component.scoreStream)
}

이제 OffGameInteractor 의 생성자는 score stream을 받을 수 있도록 변경되었습니다.

...

private let scoreStream: ScoreStream

init(presenter: OffGamePresentable,
     scoreStream: ScoreStream) {
    self.scoreStream = scoreStream
    super.init(presenter: presenter)
    presenter.listener = self
}

...

LoggedIn RIB에서 한것과 다르게 OffGameComponent에서는 fileprivate으로 stream을 선언해주었는데
LoggedIn RIB에서는 하위 RIB에서 사용이 가능하도록 하기 위해서 fileprivate을 사용하지 않은것이고 OffGame에서는 OffGame의 하위 RIB이 이 dependency를 참조할 수 없게 하기 위해서 fileprivate으로 선언하였습니다.

읽기 전용 score stream은 오로지 OffGame 안에서만 필요하고 그 외에 LoggedIn RIB 등에서는 필요하지 않기 때문에, 제공된 소스코드를 보면 이 dependency를 LoggedInComponent+OffGame extension에 위치시켜놓았습니다.

// LoggedInComponent+OffGame.swift 
extension LoggedInComponent: OffGameDependency {
    var scoreStream: ScoreStream {
        return mutableScoreStream
    }
}

Display the scores by subscribing to the score stream

이제 OffGame RIB은 score stream을 구독해야합니다. stream에 의해 새로운 점수 값에 대한 노티가 일어나고 나면, OffGamePresentable은 이 값을 view controller에게 전달할거에요. Rx의 subscription을 통해 우리는 저장된 상태를 제거하고 데이터를 반영한 UI를 자동적으로 업데이트 합니다.

점수 값을 셋팅할 수 있게 OffGamePresentable 프로토콜을 업데이트 해주세요. 이 프로토콜(OffGamePresentable)은 우리가 interactor에서 view로 소통하는 경우에 사용합니다!

protocol OffGamePresentable: Presentable {
    weak var listener: OffGamePresentableListener? { get set }
    func set(score: Score)
}

우리는 OffGameInteractor 클래스 내에서 subscription을 만들고 stream이 새로운 값을 내뱉을 때 OffGamePresentable을 통해 새로운 값을 셋팅해줄거에요

override func didBecomeActive() {  
    super.didBecomeActive()    
    updateScore() 
}  

private func updateScore() {    
    scoreStream.score         
    .subscribe(      
        onNext: { (score: Score) in  
            self.presenter.set(score: score)
            }
        )
        .disposeOnDeactivate(interactor: self)
        // OffGameInteractor가 deactivate될때 자동적으로 dispose해준다
}

disposeOnDeactivate?
Interactor의 생명주기를 기반으로 deactivate될 때 자동적으로 구독을 삭제한다. 우리는 거의 항상 이러한 Rx 수명 주기 관리 유틸리티를 활용하기 위해 interactor 또는 worker 클래스에서 Rx 구독을 활용해야한다.

이제 뷰컨에서 점수를 보여주어야하는데 이건 제공해주는 샘플 코드를 복붙하면 된당
아직 점수가 실시간으로 반영되어 화면에 보여지고있지는 않다.

Updating the score stream when a game is over

게임이 끝나고나서 TicTacToe RIB은 자신의 listener를 통해 LoggedInInteractor를 호출해주어야한다. 그러기 위해서 메서드를 선언하자.

protocol TicTacToeListener: class {
    func gameDidEnd(withWinner winner: PlayerType?)
}

우리가 게임의 승자가 결정되고 이를 뷰컨이 활용할 수 있게 하는 방법은 몇가지가 존재한다.

TicTacToeInteractor가 승자에 대한 데이터를 지역변수로 가지고 있고 전달한다.
TicTacToeViewController가 게임진행 alert창이 닫히면 closeGame 메서드를 통해 승자를 interactor에게 넘긴다.

기술적으로 두 방법 다 괜찮은 방법이다.

1번 방법의 이점은 모든 데이터가 TicTacToeInteractor안에서 캡슐화 되어있다는 것이다. 단점으로는 로컬의 변경 가능한 상태를 유지하고 있어야 한다는 것인데, 우리가 사용중인 RIB의 범위가 넓다는 사실에 의해 조금 상쇄되는 단점입니다. 각 RIB의 로컬 상태는 잘 캡슐화 되어있고 제한되기 때문에 새로운 게임을 시작해서 새롭게 TicTacToe RIB을 만들면 이전거는 새로운 지역 변수로 초기화 됩니다.

두번째 방법을 사용한다면 우리는 1번에서 유의해야 할 단점은 신경쓰지 않아도 되지만 비즈니스 로직을 view controller에서 처리해야합니다.

이번 튜토리얼에서는 두 방법의 이점만을 활용하기 위해서 Swift의 클로져를 활용할거에요. 클로져를 활용하면 Interactor가 view controller에게 게임이 끝났음을 알릴 때, view controller가 상태를 업데이트 한 후 completion handler를 호출하게 할 수 있어요.
이렇게 되면 승자에 대한 데이터가 TicTacToeInteractor 안에서 캡슐화되고 추가적인 상태 값을 저장하지 않을거에요. 또한, closeGame 메서드를 view controller의 리스터안에 불필요하게 만들 필요도 없게됩니다!

TicTacToePresentableListener 에서 closeGame 메서드를 지우고 아래 메서드를 추가해주세요.

protocol TicTacToePresentableListener: class {
    func placeCurrentPlayerMark(atRow row: Int, col: Int)
}

TicTacToeViewController에서 announce 메서드를 수정해주세요. completion handler를 인자로 받고 사용자가 alert창을 끄면 호출할 수 있도록 하는 작업입니다. announce 메서드는 player중 한명이 게임의 승자가 되었을 때 interactor에의해 호출이 됩니다.

func announce(winner: PlayerType?, withCompletionHandler handler: @escaping () -> ()) {
    let winnerString: String = {
        if let winner = winner {
            switch winner {
            case .player1:
                return "Red won!"
            case .player2:
                return "Blue won!"
            }
        } else {
            return "It's a draw!"
        }
    }()
    let alert = UIAlertController(title: winnerString, message: nil, preferredStyle: .alert)
    let closeAction = UIAlertAction(title: "Close Game", style: UIAlertActionStyle.default) { _ in
        handler()
    }
    alert.addAction(closeAction)
    present(alert, animated: true, completion: nil)
}

TicTacToePresentable 프로토콜에서 announce 메서드가 completion handler를 파라미터로 받을 수 있게 수정해주세요.

protocol TicTacToePresentable: Presentable {
    ...

    func announce(winner: PlayerType?, withCompletionHandler handler: @escaping () -> ())
}

TicTacToeInteractor에서도 수정! 뷰컨에서 리스너를 통해 interactor에게 아래 메서드를 호출시킬거에요.

func placeCurrentPlayerMark(atRow row: Int, col: Int) {
    guard board[row][col] == nil else {
        return
    }

    let currentPlayer = getAndFlipCurrentPlayer()
    board[row][col] = currentPlayer
    presenter.setCell(atRow: row, col: col, withPlayerType: currentPlayer)

    if let winner = checkWinner() {
        presenter.announce(winner: winner) {
            self.listener?.gameDidEnd(withWinner: winner)
        }
    }
}

마지막으로 LoggedInInteracor에서 gameDidEnd 메서드의 구현부를 다음과 같이 수정해주세요.
게임의 새로운 승자가 나오면 score stream을 업데이트 해줄거에요.

func gameDidEnd(withWinner winner: PlayerType?) {
    if let winner = winner {
        mutableScoreStream.updateScore(withWinner: winner)
    }
    router?.routeToOffGame()
}

완성

iOS) RIBs Tutorial 2

snowe — Thu, 13 Jan 2022 17:29:43 +0900

Tutorial 1 내용 간단 요약

Goal

- RIB에 존재하는 Interactor, Builder, Router, Presenter등이 서로 어떻게 커뮤니케이션 하는지 이해하기

Official Wiki

GitHub - uber/RIBs: Uber's cross-platform mobile architecture framework.

Uber's cross-platform mobile architecture framework. - GitHub - uber/RIBs: Uber's cross-platform mobile architecture framework.

github.com

소스코드

GitHub - snowedev/Study-RIBs: Practice Architecture(RIBs)

Practice Architecture(RIBs). Contribute to snowedev/Study-RIBs development by creating an account on GitHub.

github.com

Tutorial 2

Goal

상위RIB과 소통하는 하위RIB 만들기
상위RIB의 Interactor가 결정하는 대로 하위RIB을 attaching / detaching 해보기
view-less RIB 만들기
- view-less RIB이 detach될 때 view의 변경 정리하기
RIB의 life cycle 이해하기
- 상위 RIB이 처음 로드될 때 하위 RIB attach하기
RIB unit testing

Project Structure

이전의 튜토리얼을 완료했다면 Root와 LoggedOut, 두개의 RIB으로 구성된 트리가 있을거에요. 이번 튜토리얼에서는 LoggedIn, OffGame 그리고 TicTacToe 라는 세가지 추가적인 RIB을 트리에 붙일겁니다. 완성될 트리 구조는 아래와 같습니다.

여기서 LoggedIn RIB은 view-less입니다. 이 RIB은 오로지 TicTacToe와 OffGame RIB사이의 전환에 대한 역할만을 담당합니다.

나머지 RIB들은 자신만의 뷰컨과 스크린에 보여줄 뷰들을 가지고 있습니다.

OffGame RIB은 플레이어가 새로운 게임을 시작할 수 있게 해줍니다. 그래서 "Start Geme" 버튼을 가질 것입니다.

TicTacToe RIB은 게임 영역을 보여줄 것이며 플레이어가 이동을 할 수 있도록 해줄 것입니다.

Communicating with a parent RIB

제일 먼저 뭘 할거냐면, 상위 RIB과 하위 RIB간의 소통을 구현해볼거에요

사용자가 플레이어 이름 텍스트필드에 이름을 입력한 뒤 로그인 버튼을 탭하면 게임을 시작할 수 있게 해주어야 하잖아요. 그래서 현재 뷰에서 "Start Game" 뷰로 이동되도록 할거에요. 이걸 위해서 현재 활성화 되어있는 LoggedOut RIB은 Root RIB에게 로그인 액션에 대해 알려주어야 합니다. 이를 통해 Root Router는 LoggedOut RIB에서 LoggedIn RIB으로 전환제어를 하게 됩니다. 이어서, view-less RIB인 LoggedIn RIB은 OffGame RIB을 불러올 것이고 그 뷰를 뷰 컨트롤러에 띄울거에요.

대략적인 흐름은 이렇게 되는데 이제 어떤식으로 LoggedOut 과 Root가 소통할 것인지 알아볼게요.

Root RIB이 LoggedOut RIB의 상위 RIB이기 때문에, Root의 Router는 LoggedOut Interactor의 리스너가 됩니다. 우리는 이 리스너를 통해 로그인 이벤트를 LoggedOut RIB에서 Root RIB으로 전달할거에요

위와 같은 역할을 위해서 LoggedOutListener를 다음과 같이 업데이트 해주세요

protocol LoggedOutListener: class {
    func didLogin(withPlayer1Name player1Name: String, player2Name: String)
}

이제 요 리스너를 채택하게 되면 LoggedOut RIB의 상위 RIB은 강제적으로 didLogin을 구현해야하고 컴파일러가 이를 감시합니다.

이제 리스너를 만들었으니 LoggedOut RIB에서 login 액션이 발동됐을 때 리스너를 호출함으로써 상위 RIB에게 알려주어야 겠네요.

LoggedOutInteractor 내부에 있는 login 메서드의 구현부를 바꿔줄게요.

func login(withPlayer1Name player1Name: String?, player2Name: String?) {
    let player1NameWithDefault = playerName(player1Name, withDefaultName: "Player 1")
    let player2NameWithDefault = playerName(player2Name, withDefaultName: "Player 2")
    listener?.didLogin(withPlayer1Name: player1NameWithDefault, player2Name: player2NameWithDefault)
}

이제 LoggedOut RIB의 리스너는 사용자가 "Login" 버튼을 탭하면 호출될거에요

Routing to LoggedIn RIB

처음에 보았던 RIB 트리에서 볼 수 있지만, 사용자가 로그인을 하고 나면(리스너를 통해 그걸 인지하고 나면) Root RIB은 LoggedOut RIB -> LoggedIn RIB 으로 전환을 시켜주어야 해요.

RootRouting 프로토콜에 LoggedIn RIB으로 라우팅 해주기 위한 코드를 작성할게요

// MARK: Root/RootInteractor.swift

protocol RootRouting: ViewableRouting {
    func routeToLoggedIn(withPlayer1Name player1Name: String, player2Name: String)
}

이 코드를 통해 RootInteractor와 RootRouter간의 계약이 성립되었어요

그리고 RootInteractor에서 LoggedOutListner 프로토콜에 생성한 메서드인 didLogin의 body를 아래와 같이 작성해줄게요.

// MARK: Root/RootInteractor.swift

final class RootInteractor: PresentableInteractor<RootPresentable>, RootInteractable, RootPresentableListener {
    func didLogin(withPlayerName player1Name: String, player2Name: String) {
        router?.routeToLoggedIn(withPlayer1Name: player1Name, player2Name: player2Name)
    }
    // ...
  }

지금까지 작성한 코드를 요약하자면,

이제 LoggedOut RIB에서 로그인 버튼을 탭하면 LoggedOutListener 프로토콜에 의해 LoggedOut의 상위 RIB(Root RIB)에서 didLogin 메서드가 호출이 될거고, router의 routeToLoggedIn을 호출할거에요.

이를 통해 유저가 로그인을 하게 되면, Root RIB이 LoggedIn RIB으로 라우팅 할 수 있게 됩니다. 하지만 우리는 아직 LoggedIn RIB을 가지고 있지 않기 때문에 Root RIB에서 전환이 될 수 없어요. 얼른 구현하러 갑시당

튜토리얼의 LoggedIn 그룹에서 DELETE\_ME.swift 파일을 지우고, LoggedIn 폴더에서 RIB 템플릿을 선택하여 LoggedIn RIB을 만듭시다("Owns corresponding view"는 체크 해제 해주세요 요놈은 view-less RIB이니까요).

그러면 LoggedInRouter, LoggedInBuilder, LoggedInInteractor 라는 세가지의 파일이 생성됩니다.

Attaching a viewless LoggedIn RIB and detaching LoggedOut RIB when the users log in

새롭게 생성된 RIB을 attach 하기 위해서, RootRouter는 그걸 빌드할 수 있어야 합니다. LoggedInBuildable 프로토콜을 생성자 주입을 통해 RootRouter에 전달하여 이를 가능하게 합니다. RootRouter의 코드를 다음과 같이 수정할게요.

// MARK: Root/RootRouter.swift
init(interactor: RootInteractable,
     viewController: RootViewControllable,
     loggedOutBuilder: LoggedOutBuildable,
     loggedInBuilder: LoggedInBuildable) { // new
    self.loggedOutBuilder = loggedOutBuilder
    self.loggedInBuilder = loggedInBuilder // new
    super.init(interactor: interactor, viewController: viewController)
    interactor.router = self
}

// MARK: - Private

private let loggedInBuilder: LoggedInBuilder // new

...

그리고나서, LoggedIntBuilder 구체 클래스를 인스턴스화 하고 그걸 RootRouter에 주입할 수 있게 RootBuilder를 업데이트 할게요. RootBuilder의 build() 메서드를 수정해주세요.

// MARK: Router/RootBuilder.swift

func build() -> LaunchRouting {
    let viewController = RootViewController()
    let component = RootComponent(dependency: dependency,
                                  rootViewController: viewController)
    let interactor = RootInteractor(presenter: viewController)

    let loggedOutBuilder = LoggedOutBuilder(dependency: component)
    let loggedInBuilder = LoggedInBuilder(dependency: component) // new
    return RootRouter(interactor: interactor,
                      viewController: viewController,
                      loggedOutBuilder: loggedOutBuilder,
                      loggedInBuilder: loggedInBuilder) // new
}

방금 수정한 코드를 보면 생성자 주입을 사용하여 LoggedInBuilder에 대한 종속성으로 RootComponent를 전달하고 있어요. 이 부분에 대해서는 튜토리얼 3에서 다룬다고 하네여!

RootRouter는 LoggedInBuilder 클래스 대신 LoggedInBuildable 프로토콜에 의존합니다. 이를 통해 RootRouter를 단위 테스트할 때 LoggedInBuildable에 대한 테스트 모의를 전달할 수 있습니다. 동시에 이는 프로토콜 기반 프로그래밍 원칙을 따르므로 RootRouter와 LoggedInBuilder가 밀접하게 결합되지 않도록 합니다.

이제 LoggedIn RIB에 대한 상용구 코드를 전부 생성했고 Root RIB이 LoggedIn RIB을 인스턴스화 할 수 있습니다. 이제 RootRouter 안에 routeToLoggedIn 메서드를 구현해야합니다.

detach를 하려면 dismiss가 필요하겠네요, RootRouter에 RootViewControllable 프로토콜 내에 아래처럼 dismiss를 추가해주세요.

// MARK: Root/RootRouter.swift
protocol RootViewControllable: ViewControllable {
    func present(viewController: ViewControllable)
    func dismiss(viewController: ViewControllable)
}

저 프로토콜을 준수하고 있는 RootViewController에서 dismiss에 대한 구현부도 작성해주어야겠죠?

// MARK: Root/RootViewController
func dismiss(viewController: ViewControllable) {
    if presentedViewController === viewController.uiviewController {
        dismiss(animated: true, completion: nil)
    }
}

이제 본격적으로 detach/attach 부분을 작성해볼게요. RootRouter에 다음의 코드를 새롭게 추가해주세요

// MARK: - RootRouting

func routeToLoggedIn(withPlayer1Name player1Name: String, player2Name: String) {
    // Detach LoggedOut RIB.
    if let loggedOut = self.loggedOut {
        detachChild(loggedOut)
        viewController.dismiss(viewController: loggedOut.viewControllable)
        self.loggedOut = nil
    }

    let loggedIn = loggedInBuilder.build(withListener: interactor)
    attachChild(loggedIn)
}

위 코드에서 볼 수 있듯 새로운 하위 RIB으로 전환하려면, 상위 RIB은 먼저 지금 붙어있는 하위 RIB을 detach 해야합니다. 그 다음에 새로운 하위 RIB을 만들고 방금 detach한 자리에 attach 해줍니다.

RIB과 뷰 계층 구조 간의 일관성을 유지하는 것도 상위 RIB의 책임입니다. 만약 하위 RIB이 view controller를 가지고 있다면 상위 RIB은 하위 RIB이 detach 될 때 하위 view controller 또한 dismiss 하거나 present 해주어야합니다.

위의 routeToLoggedn를 통해 자신의 view controller를 가진 RIB을 어떻게 attach하는지 이해해보시면 좋습니다!

새롭게 생성된 LoggedIn RIB으로부터 이벤트를 받을 수 있도록 하기 위해, Root RIB은 자신의 interactor를 LoggedIn RIB의 리스너로 구성합니다. 위 코드에서 Root RIB이 하위 RIB을 빌드할 때 그런 일들이 일어나게 되는데, 이 시점에서 아직 루트 RIB는 LoggedIn RIB의 요청에 응답할 수 있는 프로토콜을 구현하지 않습니다.

RIB은 프로토콜 기반이므로 리스너 인터페이스를 준수하는것에 엄격합니다. 다른 암시적 관찰 방법 대신 프로토콜을 사용하므로 부모가 자식의 모든 이벤트를 구현하지 않을때 런타임이 아닌 컴파일러에서 오류를 반환하게 됩니다.

이제 RootInteractable을 LoggedInBuilder의 빌드 메서드에 대한 리스너로 전달하므로 RootInteractabl은 LoggedInListener 프로토콜을 준수해야 합니다. RootInteractable에 해당 프로토콜을 따르도록 추가해주세요.

// LoggedInListener 추가
protocol RootInteractable: Interactable, LoggedOutListener, LoggedInListener {
    var router: RootRouting? { get set }
    var listener: RootListener? { get set }
}

이제, RootRouter는 routeToLoggedIn 메서드를 통해 LoggedIn RIB으로 라우팅할 때 LoggedOut RIB을 detach할 수 있고 view controller도 dismiss할 수 있습니다.

Pass in LoggedInViewControllable instead of creating it

LoggedIn RIB이 자신의 view을 가지고 있지 않지만 여전히 하위 RIB의 뷰들은 보여주어야 할 필요가 있기 때문에, LoggedIn RIB은 view의 조상(상위 view)로의 접근이 가능해야합니다. 튜토리얼에서 LoggedIn RIB의 상위 RIB은 Root RIB이기 때문에 이 조상 뷰 또한 Root RIB에서 제공이 되어야합니다.

RootViewController에 아래의 extension을 추가해서 LoggedInViewControllable을 준수하도록 해주세요

// MARK: LoggedInViewControllable

extension RootViewController: LoggedInViewControllable {
}

우리는 LoggedinViewControllable 인스턴스를 LoggedIn RIB에 주입 할 필요가 있는데 얘 역시 tutorial 3에서 다룬대요.

지금은 일단 LoggedInBuilder.swift를 이 코드로 채워주면 된다네요

여기까지 되면 이제 LoggedIn RIB은 Root RIB에 의해 수행된 LoggedInViewControllable의 메서드를 통해 하위 RIB들을 show/hide 할 수 있게 됩니다.

Attaching the OffGame RIB when the LoggedIn RIB loads

앞서 언급했듯 LoggedIn RIB은 view-less 하기 때문에 오로지 자신의 하위 RIB들간의 전환만 가능합니다. 이제 그 하위 RIB들을 만들어볼거에요. "Start Game" 버튼을 가지고있고 이를 관리하는 OffGame이라고 불리는 RIB을 만들어봅시당

OffGame폴더 내에 이번에는 뷰를 가진 RIB을 만들어줄게요.

RIB템플릿을 선택하고 "Owns corresponding view"를 체크한 상태로 만들어주세요.

그리고 OffGameViewController에 이 코드를 추가해주세요.

이제 OffGame RIB을 상위 RIB인 LoggedIn RIB과 연결해봅시다. LoggedIn RIB은 OffGame RIB을 자신의 하위 RIB으로서 attach할 수 있어야합니다.

OffGameBuildable 인스턴스에 대한 종속성을 선언하기 위해 LoggedInRouter의 생성자를 변경해야해요.

init(interactor: LoggedInInteractable,
     viewController: LoggedInViewControllable,
     offGameBuilder: OffGameBuildable) { // new
    self.viewController = viewController
    self.offGameBuilder = offGameBuilder //new
    super.init(interactor: interactor)
    interactor.router = self
}

// MARK: - Private

...

private let offGameBuilder: OffGameBuildable // new

이제 LoggedInBuilder를 수정해서 OffGameBuilder 클래스를 인스턴스화하고 LoggedInRouter 인스턴스에 주입합니다. 다음과 같이 빌드 기능을 수정해주세요.

// MARK: LoggedIn/LoggedInBuilder.swift

func build(withListener listener: LoggedInListener) -> LoggedInRouting {
    let component = LoggedInComponent(dependency: dependency)
    let interactor = LoggedInInteractor()
    interactor.listener = listener

    let offGameBuilder = OffGameBuilder(dependency: component)
    return LoggedInRouter(interactor: interactor,
                          viewController: component.loggedInViewController,
                          offGameBuilder: offGameBuilder)
}

여기까지하면 에러가 하나 나올텐데.. 이걸 해결하려면 OffGameBuilder의 계약된 종속성을 만족해야합니다. 음 약속을 지켜야한다는 거죠?

OffGameBuilder의 계약된 종속성을 만족하기 위해서, 우리는 LoggedInComponent 클래스를 OffGameComponent를 준수할 수 있게 수정해야합니다(RIB 종속성과 컴포넌트들은 튜토리얼 3에서 좀 더 자세하게 다룬대요).

// MARK: LoggedIn/LoggedInComponent.swift

final class LoggedInComponent: Component<LoggedInDependency>, OffGameDependency {
    
    fileprivate var loggedInViewController: LoggedInViewControllable {
        return dependency.loggedInViewController
    }
}

사용자가 로그인 한 뒤 즉각적으로 OffGame RIB에 의한 시작 화면이 나오면 참 좋겠죠? 그래서 LoggedIn RIB은 자신이 로드 되자마자 OffGame RIB을 attach해주어야 해요.

LoggedInRouter에서 didLoad 메서드를 오버라이드 해서 OffGame RIB을 바로 띄울 수 있도록 로드해주세요

// MARK: LoggedIn/LoggedInRouter.swift


// MARK: - Private

...

private var currentChild: ViewableRouting?

private func attachOffGame() {
    let offGame = offGameBuilder.build(withListener: interactor)
    self.currentChild = offGame
    attachChild(offGame)
    viewController.present(viewController: offGame.viewControllable)
}

override func didLoad() {
    super.didLoad()
    attachOffGame()
}

...

이러면 이제 Argument type 'LoggedInInteractable' does not conform to expected type 'OffGameListener' 라는 에러가 뜨것죠?

해주면 되죠 LoggedInInteractable이 OffGameListener 프로토콜을 준수하도록 해줄게요. 이걸 준수해주어야 OffGame RIB 이벤트를 받을 수 있게 됩니다.

protocol LoggedInInteractable: Interactable, OffGameListener {
    weak var router: LoggedInRouting? { get set }
    weak var listener: LoggedInListener? { get set }
}

이제, LoggedIn RIB은 로딩이 된 후에 바로 OffGame RIB을 attach할 수 있고, OffGame에서 오는 이벤트들을 들을 수 있습니다.

Cleaning up the attached views when the LoggedIn RIB is detached

LoggedIn RIB이 자신의 뷰를 가지고 있지 않고, 오히려 상위 계층 뷰를 수정하기 때문에 Root RIB는 LoggedIn RIB가 수행했을 수 있는 뷰의 수정을 자동으로 제거할 방법이 없습니다.

다행히 Viewless LoggedIn RIB을 생성하는 데 사용한 Xcode 템플릿은 LoggedIn RIB이 분리될 때 뷰 수정 사항을 정리할 수 있는 후크를 이미 제공합니다.(다행이다)

LoggedInViewControllable 프로토콜에 present, dismiss 메서드를 만들어주세요

protocol LoggedInViewControllable: ViewControllable {
    func present(viewController: ViewControllable)
    func dismiss(viewController: ViewControllable)
}

그리고 나서 우리는 cleanupViews라는 메서드가 현재 자식RIB의 view controller를 dismiss 해줄 수 있도록 해줄거에요.

LoggedInRouter의 cleanupViews 메서드를 다음과 같이 바꿔주세요

func cleanupViews() {
    if let currentChild = currentChild {
        viewController.dismiss(viewController: currentChild.viewControllable)
    }
}

cleanupViews 메소드는 상위 RIB이 LoggedIn RIB를 detach 할 때 LoggedInInteractor에 의해 호출됩니다. cleanupViews에서 현재 보여지고 있는 뷰 컨트롤러를 해제함으로써 LoggedIn RIB이 분리된 후 상위 RIB의 뷰 계층 구조에 뷰를 남기지 않도록 보장합니다.

Switching to TicTacToe RIB on tapping "Start Game" button

지금까지 했던 거랑 비슷하니까 혼자 해보라는데..TicTacToe 자체의 UI는 이미 튜토리얼 프로젝트에 만들어져있어요.

뭘 해주면 될까요 일단 우리가 방금까지 만든 OffGame RIB과 같은 계층에 있는 RIB이니까 마찬가지로 TicTacToe RIB의 상위 RIB은 LoggedIn RIB이겠네요!

일단 LoggedIn RIB이 로드되자마자 OffGame RIB을 호출하잖아요. 그리고나서 OffGame RIB에서 Start를 탭 하면 TicTacToe RIB으로 전환해주어야해요.

1. 가장 먼저 OffGame RIB의 Start버튼에 대한 TapGesture를 추가해줄게요.

// MARK: OffGame/OffGameViewController.swift

// MARK: - Private
private func buildStartButton() {
	...
    
    startButton.rx.tap								
        .subscribe(onNext: { [weak self] in
            self?.listener?.startTicTacToe()
        })
        .disposed(by: disposeBag)
}

private let disposeBag = DisposeBag() 

...

2. VC에서 Interactor로 전달할 수 있도록 PresentableListener에 메소드를 추가해주세요

// OffGameViewController.swift

protocol OffGamePresentableListener: class {
    func startTicTacToe()
}

3. Listener를 통해 상위 RIB에 이벤트를 전달할 수 있도록 할게요

// OffGameInteractor.swift
...

protocol OffGameListener: AnyObject {
    func startTicTacToe()
}

final class OffGameInteractor: PresentableInteractor<OffGamePresentable>, OffGameInteractable, OffGamePresentableListener {
    
    func startTicTacToe() {
        listener?.attachTicTacToe()
    }
    
    ...
}

4. 이제 상위 RIB(LoggedIn RIB)에서 startTicTacToe에 대한 구현부를 작성하면 돼요

// LoggedInInteractor에서 Routing 메서드 추가

protocol LoggedInRouting: Routing {
    func cleanupViews()
    // TODO: Declare methods the interactor can invoke to manage sub-tree via the router.
    func routeToTicTacToe()
}

// LoggedInRouter.swift

func routeToTicTacToe() {
    attachTicTacToe()
    detachCurrentChild()
}

// MARK: - Private

...

private func attachTicTacToe() {
    let tictactoe = ticTacToeBuilder.build(withListener: interactor)
    self.currentChild = tictactoe
    attachChild(tictactoe)
    viewController.present(viewController: tictactoe.viewControllable)
}

private func detachCurrentChild() {
    if let currentChild = currentChild {
        detachChild(currentChild)
        viewController.dismiss(viewController: currentChild.viewControllable)
        self.currentChild = nil
    }
}

5. 하위 리스너를 상위 RIB Router에 연결해준다

// LoggedInInteractor.swift

protocol LoggedInInteractable: Interactable, OffGameListener, TicTacToeListener {
    var router: LoggedInRouting? { get set }
    var listener: LoggedInListener? { get set }
}

6. TicTacToe Builder의 종속성을 LoggedInRouter의 생성자에 생성해주기

init(interactor: LoggedInInteractable,
     viewController: LoggedInViewControllable,
     offGameBuilder: OffGameBuildable,
     tictactoeBuilder: TicTacToeBuildable) { 		// new

    self.viewController = viewController
    self.offGameBuilder = offGameBuilder
    self.ticTacToeBuilder = tictactoeBuilder		// new

    super.init(interactor: interactor)
    interactor.router = self
}

// MARK: - Private    
...
private let ticTacToeBuilder: TicTacToeBuildable	// new

6-1. LoggedInBuilder를 수정해서 TicTacToe Builder 클래스를 인스턴스화하고 LoggedInRouter 인스턴스에 주입

func build(withListener listener: LoggedInListener) -> LoggedInRouting {
    let component = LoggedInComponent(dependency: dependency)
    let interactor = LoggedInInteractor()
    interactor.listener = listener

    let offGameBuilder = OffGameBuilder(dependency: component)
    let tictactoeBuilder = TicTacToeBuilder(dependency: component)		// new

    return LoggedInRouter(interactor: interactor,
                          viewController: component.loggedInViewController,
                          offGameBuilder: offGameBuilder,
                          tictactoeBuilder: tictactoeBuilder)			// new
}

6-2. TicTacToeBuilder의 계약된 종속성을 만족하기 위해서, 우리는 LoggedInComponent 클래스를 TicTacToeComponent를 준수할 수 있게 수정

// MARK: LoggedIn/LoggedInBuilder.swift

final class LoggedInComponent: Component<LoggedInDependency>, OffGameDependency, TicTacToeDependency {
    
    fileprivate var loggedInViewController: LoggedInViewControllable {
        return dependency.loggedInViewController
    }
}

7. 5번에서 상위 RIB이 TicTacToe의 Listener를 준수하게 되면서 TicTacToe 리스너의 gameDidEnd() 메서드를 구현해야하는데 이건 다음 스텝에서 하는거 같아서 그냥 주석처리 해두면 된다

여기까지 완료되면

요렇게 된다!

Attaching the OffGame RIB and detaching the TicTacToe RIB when we have a winner

위의 gif에서 게임이 끝나면 TicTacToe RIB에서 다시 게임을 시작할 수 있는 OffGame RIB 으로 돌아가야합니다.

그러려면 지금 attach 되어있는 TicTacToe RIB를 detach하고 OffGame RIB을 attach 해주어야겠네요.

LoggedIn RIB과 <-> OffGame RIB / TicTacToe RIB 사이의 attach,detach를 구현해놨고

지금까지 한것과 동일한 리스너 기반 라우팅 패턴을 사용하면 돼요. 제공된 코드의 TicTacToe RIB에는 이미 리스너가 설정되어 있습니다. LoggedIn RIB가 TicTacToe 이벤트에 응답할 수 있도록 LoggedInInteractor에서 구현하기만 하면 됩니다.

LoggedInRouting 프로토콜에 routeToOffGame 메서드를 선언해주세요

// LoggedInInteractor.swift

protocol LoggedInRouting: Routing {
    func routeToTicTacToe()
    func routeToOffGame()
    func cleanupViews()
}

아까 비워두었던 gameDidEnd() 메서드의 바디를 작성할게요

// LoggedInInteractor.swift

final class LoggedInInteractor: Interactor, LoggedInInteractable {
    ...
	
    // MARK: - TicTacToeListener
    
    func gameDidEnd() {
        router?.routeToOffGame()
    }
}

그런 다음, routeToOffGame 메서드를 LoggedInRouter 클래스 안에서 구현해주세요

// LoggedInRouter.swift

final class LoggedInRouter: Router<LoggedInInteractable>, LoggedInRouting {
    ...
    func routeToOffGame() {
        detachCurrentChild()
        attachOffGame()
    }
    ...
}

완성

iOS) RIBs Architecture

snowe — Wed, 12 Jan 2022 22:53:44 +0900

https://github.com/uber/RIBs/wiki를 바탕으로 공부한 RIBs에 대해 정리를 하는 글입니다.

RIBs란?

RIBs는 Uber의 크로스 플랫폼 아키텍쳐 프레임워크입니다. RIBs는 다음과 같은 원칙들을 준수합니다.

Encourage Cross-Platform Collaboration

하나의 서비스를 기준으로 볼 때 Android, iOS 모두 개발적인 측면에서 복잡한 부분들은 대체로 비슷합니다. 이 점을 활용하여 RIBs는 Android와 iOS 모두 비슷한 개발 패턴들을 제공합니다. 이는 iOS, Android 팀 모두 하나의 단일 아키텍쳐를 서로 공유할 수 있음을 의미하는데 이를 통해 서로의 비즈니스 로직을 점검해줄 수 있다는 장점이 생깁니다(뭔가 아키텍쳐의 틀을 딱 정해두는 것은 장점이자 단점이 될 수 있을 것 같아요).

Minimize Global States and Decisions

전역에 걸친 변경들(Global state changes)은 개발자로 하여금 예기치 못한 행동을 유발할 수 있고, 그런 변경들이 가져올 수 있는 영향에 대해 개발자들이 완벽히 파악하기란 쉽지 않습니다. RIBs는 잘 독립된 각각의 RIB들의 상태를 deep hierarchy 내에서 캡슐화하여 그러한 이슈를 피할 수 있습니다.

Testability and Isolation

Class들은 독립적으로 생각되어야 하고 Unit Test가 쉬워야 합니다. 각각의 RIB 클래스들은 서로 다른 책임들을 갖습니다(Routing, Business Logic, View Logic, 다른 RIB 클래스의 생성 등). 더불어, 부모 RIB 로직은 자식 RIB로직과 분리되어 있습니다. 이것이 RIB 클래스들이 테스트가 쉽고 독립적으로 생각될 수 있는 이유입니다.

Tooling for Developer Productivity

Adopting non-trivial architectural patterns does not scale beyond small applications without robust tooling. 이건 뭔 느낌의 말인지는 알겠는데 한국어로 표현을 못하겠네요..허허

여기서 하고싶은 말은 다른 아키텍쳐를 사용해도 강력한 tooling 기능이 있어야 되는데 RIBs는 그걸 자체적으로 제공해서 좋다는 의미인 것 같아요. 코드 생성, 정적 분석 및 runtime integrations에 대한 IDE 툴링을 제공한다고 합니다.

Open-Closed Principle

개발자는 언제든지 현재 코드를 수정하지 않고 새로운 기능을 추가할 수 있어야 합니다.(새로운 기능을 추가하기 위해 기존 코드를 계속 건드려야하면 안좋긴 하겠죠) 이것은 RIBs를 사용하면 가능합니다. 예를들어, 부모 RIB을 거의 변경하지 않고 부모의 종속성이 필요한 복잡한 자식 RIB을 attach하거나 build할 수 있습니다.

Structured around Business Logic

앱의 비즈니스 로직 구조는 UI의 구조를 엄격하게 따를 필요는 없습니다. 예를 들어, 뷰의 성능과 애니메이션을 용이하게 하기 위해서, 뷰 계층 구조는 RIB의 구조보다 더 얕을 수 있습니다. 아니면 단일 기능 RIB이 각각 다른 위치에 나타나는 세개의 뷰들을 컨트롤 할 수도 있습니다.(...?)(Or, a single feature RIB may control the appearance of three views that appear at different places in the UI.)

Explicit Contracts

요구사항들은 compile-time safe contracts으로 선언되어야 합니다. 클래스 종속성과 순서(ordering) 종속성이 충족되지 않으면 클래스는 컴파일되지 않아야 합니다. 우리는 ReactiveX를 사용하여 순서 종속성을 나타내고, 유형 안전 종속성 주입(DI) 시스템을 사용하여 클래스 종속성을 나타내고, 많은 DI 범위를 사용하여 데이터 불변성 생성을 권장합니다.

음 몇개는 아직 읽어도 모르겠는 것들이 있는데.. 일단 계속 하다보면 이해가 될거라 믿습니다..!

RIB의 구조

아까 위에서 Testability and Isolation 부분에서 RIB의 클래스들은 각각 다른 책임을 갖는다고 했어요. 여기서는 그것과 관련된 내용을 다룹니다.

VIPER라는 아키텍쳐에서 발전된 형태가 RIBs이기 때문에 VIPER를 기존에 사용해보신 분들은 좀 더 이해가 빠르실 것 같아요. 저는 안써봤기 때문에 찬찬히 살펴보면

RIBs는 보통 아래와 같은 구성요소로 이루어져 있어요. 모든 구성 요소들은 자체 클래스로 구현됩니다. 그래서 각각 자신만의 책임을 갖는 셈이 되는거죠.

Interactor

Interactor는 비즈니스 로직이 포함됩니다.
Rx로 subscription을 수행하는 곳도 이 곳이고
상태 변결에 대한 결정,
무슨 데이터를 어디에 저장할 것인지,
어떤 다른 RIBs가 자식으로서 attached되어야 하는지 등을 결정하게 됩니다.

Interactor에 의해 수행되는 모든 동작들은 반드시 자신의 life cycle 내에서 동작해야합니다.

RIBs에는 Interactor가 활성화 된 경우에만 비즈니스 로직이 실행되도록 tooling이 내장되어 있습니다. 그 결과, Interactor가 비활성화되는 시나리오는 방지되지만 subscriptions이 계속 발생하여 비즈니스 로직이나 UI상태에 원치 않는 업데이트가 발생합니다. 그래서 꼭 life cycle 내에서 동작할 수 있도록 해주어야합니다.

Router

Router는 Interactor가 주는걸 듣고(받고?) 그걸 자식 RIB에 attaching, detaching 행위로 변환합니다. Router는 다음과 같은 세가지 간단한 이유로 존재합니다.

1. Router는 Humble Objects의 역할을 하여, 하위 Interactor를 속이거나 그 존재에 대해 신경 쓸 필요없이 복잡한 Interactor 로직을 쉽게 테스트 할 수 있습니다

* Humble Object: 테스트 가능한 객체를 감싸는 wrapper로, 테스트하기 어려운 객체의 로직을 비용 효율적인 방식으로 가져오는 방법.

2. Router는 부모 interactor와 자식 interactor간에 추가 추상화 계층을 만듭니다. 이로 인해 interactor간의 동기 통신이 조금 더 어려워지고, RIBs간의 직접 연결 대신 reactive communication 채택이 권장됩니다.

3. Router는 interactor에 의해 수행될 수 있는 단순하고 반복적인 라우팅 로직을 포함하고있습니다. 이 상용구 코드(boilerplate code)를 제외하면(Router로 뺌으로써) Interactor를 작게 유지하고 RIB이 제공하는 핵심 비즈니스 로직에 더 집중 할 수 있습니다.

Builder

Builder의 책임은 모든 RIB의 구성 클래스와 각 RIB의 자식에 대한 빌더를 인스턴스화하는 것입니다.

Builder에서 클래스 생성 로직을 분리하면 iOS에서 모의 가능성(mockability)에 대한 지원이 추가괴고 나머지 RIB 코드는 DI구현의 세부 사항에 영향을 미치지 않습니다. Builder는 프로젝트에 사용된 DI 시스템을 인식해야 하는 RIB의 유일한 부분입니다. 다른 빌더를 구현하면 다른 DI 메커니즘을 사용하여 프로젝트에서 나머지 RIB 코드를 재사용할 수 있습니다.

Presenter

Presenter는 Business Model을 View Model로 혹은 그 반대로 변환하는 stateless 클래스입니다. View Model 변환 테스트를 용이하게 하는데에 사용될 수 있습니다. 하지만 종종 이러한 변환이 너무 사소하면 이 클래스를 만들지 않습니다. 그러한 경우에는 view model를 변환하는 것은 View(Controller)나 Interactor의 책임이 됩니다.

View(Controller)

View는 UI를 빌드하고 업데이트합니다.

UI컴포넌트들의 레이아웃을 잡고 인스턴스화 하는것,
user interaction을 처리하는 것,
UI 컴포넌트들을 받은 데이터로 채우는 것,
애니메이션 등이 View가 하는 일에 포함됩니다.

View는 가능한 한 "벙어리"이도록 디자인되어 있습니다(가능한 한 뭔가 주도적으로 뭔가를 하기보다 시키는 것만 하라는 소리인듯). 그들은 그저 정보를 보여줍니다. 그래서 일반적으로, View는 unit test가 필요한 코드를 포함하지 않습니다.

Component

Component는 RIB 종속성을 관리하기 위해 사용됩니다. 애네는 RIB을 구성하는 다른 유닛들을 인스턴스화 하여 Builder를 돕습니다.

Component는 RIB를 구축하는 데 필요한 외부 종속성에 대한 액세스를 제공하고,
RIB 자체에 의해 생성된 종속성을 소유하고 다른 RIB에서 이에 대한 액세스를 제어합니다.
상위 RIB의 구성요소는 일반적으로 상위 RIB의 종속성에 대한 하위 액세스를 제공하기 위해 하위 RIB의 빌더에 주입됩니다.

RIB의 상태 관리

앱의 상태는 현재 RIB 트리에 연결된 RIB에 의해 대부분 관리되고 표현됩니다. 예를 들어, 사용자가 아래와 같은 트리를 갖는 차량 공유 앱을 사용한다고 했을 때 사용자가 타는 flow에 따라 앱은 RIB을 attach하고 detach합니다.

RIB은 그들의 범위 내에서만 상태 결정을 합니다. 예를 들어, LoggedIn RIB은 Requset 와 OnTrip 과 같은 상태간 전환에 대해서만 상태 결정을 합니다. 그 말은 즉슨, 우리가 OnTrip 화면에 들어간 뒤 어떻게 행동할 것인지에 대한 결정은 LoggedIn RIB에서는 전혀 하지 않는다는 것을 의미합니다.

RIB을 추가/삭제 함으로써 모든 상태를 저장할 수 있는 것은 아닙니다. 예를 들어, 사용자의 프로필 성정이 변경 될 때, 어떤 RIB도 attach 혹은 detach 되지 않습니다. 일반적으로 이 상태는 세부사항이 변경될 때 값을 다시 방출하는 불변 모델 스트림(streams of immutable models)에 저장됩니다. 예를 들어, 사용자의 이름은 LoggedIn 범위 내에 있는 ProfileDataStream 에 저장 될 수 있습니다. 오직 네트워크의 응답만이 이 Stream에 쓰기 권한으로 접근할 수 있습니다. 우리는 DI 그래프 아래로 이러한 스트림에 대한 읽기 액세스를 제공하는 인터페이스를 전달합니다.

RIB은 RIB 상태에 대해 단일 정보 소스를 강제하고 있지 않습니다. 이것은 React와 같은 독단적인 프레임워크가 이미 기본적으로 제공하는 것과 대조됩니다. 각 RIB의 컨텍스트 내에서 단방향 데이터 흐름을 촉진하는 패턴을 채택하도록 선택하거나 효율적인 플랫폼 애니메이션 프레임워크를 활용하기 위해 비즈니스 상태와 보기 상태가 일시적으로 분기되도록 할 수 있습니다.

RIB 간의 상호작용

Interactor가 비즈니스 로직 결정을 할 때, 또 다른 RIB에 completion과 같은 이벤트에 대해 알려주고, 데이터를 보내야 할 수도 있습니다. RIBs프레임워크에는 RIB 간에 데이터를 전달하는 단일 방법이 포함되어있지 않습니다. 그럼에도 불구하고, 몇몇의 일반적인 패턴들을 용이하게 하기 위해 만들어졌습니다.

일반적으로, 만약 커뮤니케이션이 하위 RIB으로 하향 전달되는 경우, 우리는 이 정보를 Rx Stream으로 전달합니다. 혹은 데이터가 하위 RIB의 build() 에 파라미터로서 포함될 수 있습니다. 이러한 경우, 이 파라미터는 하위 RIB의 life time동안 변하지 않습니다.

만약 커뮤니케이션이 반대로 RIB 트리에서 상위 RIB의 Interactor로 전달된다면(상향통신), 하위 RIB보다(상위 RIB이) 더 오래 남아있을 수 있기 때문에 listener 인터페이스를 통해 커뮤케이션이 진행됩니다.

상위 RIB 또는 DI 그래프의 일부 객체는 listener 인터페이스를 구현하고 DI 그래프에 배치하여 하위 RIB이 호출할 수 있도록 합니다.

부모(상위)가 자녀(하위)의 Rx 스트림을 직접 구독하도록 하는 대신 이 패턴을 사용하여 데이터를 위쪽으로 전달하면 몇 가지 이점이 있습니다. 메모리 누수를 방지하고 부모가 어떤 자식이 연결되어 있는지 모른 채 작성, 테스트 및 유지 관리할 수 있으며 자식 RIB를 연결/분리하는 데 필요한 의식의 양을 줄입니다. 이런 식으로 자식 RIB를 연결할 때 Rx 스트림이나 수신기를 등록 취소/재등록할 필요가 없습니다.

여기까지 인데..음..

감이 잡히는 것도 있고 아닌 것도 있지만.. 일단 튜토리얼도 4단계로 있으니까 계속 진행해보면서 이해해보겠습니다 :)

ETC) 내가 했던 Mac Setting 목록

snowe — Mon, 10 Jan 2022 23:09:29 +0900

Basic

Keyboard - Text 우측 체크박스 전부 해제
Accessibility - Pointer Control - Trackpad Options - Enable dragging three finger drag 로 설정(세손가락으로 드래그하기)
Finder - Preferences
- New Finder windows show에서 폴더 설정해주기
- Advanced - show all filename extensions
- Downloads폴더 - View - View Option
  - Group by : Date added
  - Sort by : Name

Useful Apps

Alfred
AppCleaner
Chromium(크로미움으로 설치하기-용량,메모리측면에서 조흠)
Hidden Bar
IINA
Itsycal
KakaoTalk
KeyboardCleanTool
Magnet
Monosnap
Notion
Keka
Spark
Unicorn Blocker
VLC
YouTube Music(크롬 바로가기 앱)

Developer Apps

GitKraken
Figma
Google Sheets
Postman
Karabiner-Elements(한영키 전환 안버벅이게)
Karabiner-EvenViewer(한영키 전환 안버벅이게)
Sublime Text
Typora
Visual Studio Code
Xcode
D2coding 글씨체 설치해서 Xcode에 적용시키기
Zeplin
Slack

Useful

항상 ₩ 대신 ` 입력하기

$ cd ~/Library
$ mkdir KeyBindings
$ cd KeyBindings
$ touch DefaultKeyBinding.dict
$ vi DefaultKeyBinding.dict

{
  "₩" = ("insertText:", "`");
}

하고 재부팅

확장자 기본 연결 프로그램 설정

확장자 파일 우클릭 - Get Info - Open with - app 선택 - Change All

Terminal Setting

Homebrew 설치

https://brew.sh/index_ko 에서 brew 설치

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

(M1)이라면 설치 이후에 아래 코드 추가적으로 실행

eval $(/opt/homebrew/bin/brew shellenv)

zsh, Oh My Zsh

// zsh
$ brew install zsh

// oh-my-zsh
$ sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Node.js, epxress

// node설치하면서 npm 자동 설치됨 $ npm install express $ brew install node

iTerm2

  $ brew cask install iterm2

색상스키마(Snazzy), 테마설정(https://github.com/romkatv/powerlevel10k#pure-compatibility, pure테마),
username, vscode 터미널에 iterm2 적용, 폰트 적용 등등은 구글링 ㄱㄱ
iterm2 설정법 추천블로그

vscode code .명령어
vscode - ⇧ ⌘ P - Shell command 입력 - Shell Command: Install 'code' command in PATH - Terminal 재실행

Git

기본 내장 git은 버전이 오래됐다.

// 오버라이드 옵션
// command line tool 최소 버전 충족 못하면 설치하라뜸
$ brew install -s git

// Options에서 pcre에 체크표시 되어있는지 확인
// 없으면 설치 "brew install pcre"
$ brew info git

// git version 2.24.3 (Apple Git-128) 아까 확인한 옛날 버전이 뜬다면
$ git --version

// "/usr/bin/git" -> 내장 버전
$ which git
$ export PATH=/usr/local/bin:$PATH

// "/usr/local/bin/git" -> 새로 설치한 버전
$ which git

//git version 2.23.0
$ git --version

// 계정정보 설정
$ git config --global user.name "your name"
$ git config --global user.email "your email"

// 한글 파일명 처리를 위한 설정
$ git config --global core.precomposeunicode true
$ git config --global core.quotepath false

Git SSH & GPG 설정

DerivedData 폴더 지우는 단축키 만들기

Automator - Quick Action 선택해서 하기

[Automator] DerivedData 폴더 지우는 단축어 만들기

Git) rebase-merge, squash-merge

snowe — Tue, 28 Dec 2021 22:35:08 +0900

오늘은 merge의 종류들 중 rebase&merge와 squash&merge에 대해 알아보려고 합니다!

PR을 올리고 해당 PR을 merge를 할 수 있는 방식에는 총 3가지가 있습니다.

merge
Squash and merge
Rebase and merge

merge

그냥 가장 일반적인 merge입니다. 아무런 설정도 하지 않았을 때 default 값이죠.

NHN Cloud meetup자료에 잘 설명된 그림이 있어서 가져와 보았습니다.

일반 merge를 하게 될 경우에는 브랜치에서 커밋된 a->b->c 친구들을 참조하는 새로운 커밋 노드인 m이 생성됩니다. 이 m이라는 커밋 노드는 parent로 init과 c를 가지게 됩니다.

Squash and Merge

다음은 Squash and Merge입니다. 음..Squash라는 단어는 "밀치고 들어가다, 헤치고 들어가다" 라는 뜻을 지니고 있나봐요.

실제로 동작하는 방식이 그런 단어의 의미를 잘 살리고 있는지는 모르겠지만 그림을 보면..

브랜치에서 커밋된 a->b->c 친구들을 한데 모아 놓은 커밋이 새롭게 생성되며 머지가 됩니다. 이 때 이 커밋은 parent로 init만을 가지게 됩니다.

squash는 처음 공부하는거니까 실습을 해보았어요.

예를들어 만약, 아래와 같이 커밋된 3개의 기록이 Squash and Merge를 통해 merge해 줄 경우

다음과 같이 하나의 커밋내에 3개의 커밋이 함께 기록됩니다.

Rebase and Merge

rebase가 그나마 익숙하죠..? 이전 글에서도 알아보았듯 rebase 는 브랜치의 시작점을 똑 떼어서 붙이는 느낌입니다.

브랜치에서 커밋된 a->b->c 친구들을 그대로 옮기는 방식입니다. 그렇기 때문에 새로운 커밋이 추가되지않으며 브랜치가 없었다는 듯 linear한 history를 보실 수 있습니다.

그럼 각 merge를 언제 사용?

저는 보통 git flow를 따르면서 협업을 하는데 그럴경우 master, develop, feat, hotfix 브랜치를 파게 될 거에요.

master는 정말 최최최종, develop은 PR을 approved받고 merge한 경우, feat은 실제로 개발할 때 직접적인 커밋을 위해 사용하는 브랜치, hotfix는 버그 잡는 용이겠죠? 이렇게 나뉘어져 있다고 가정했을 때,

develop - feat 브랜치 간 merge
- 사용: Squash and Merge
- 이유: feat 브랜치는 말그대로 실시간 개발용 브랜치이기 때문에 커밋 히스토리가 복잡한 경향이 있어요. 때문에 그러한 복잡한 커밋들을 모두 묶어 하나의 새로운 커밋으로 남기고, 그 하나만을 develop 브랜치에서 관리하는 편이 더 수월하답니다. 또한, Rebase를 사용하게 되면 어느 지점부터 새로운 브랜치의 작업인지 구분이 사라지기 때문에 피하게 되는 것 같아요.
master - develop 브랜치 간 merge
- 사용: Rebase and Merge
- 이유: develop의 내용을 master에 추가한다는 건 무언가 새롭게 버전업을 하기 위한 경우가 대부분이기때문에 굳이 일반 merge로 불필요한 새로운 커밋을 만들 필요가 없으며 squash로 merge된 feat의 기록들을 또 한번 squash해 줄 필요가 없을거에요.
hotfix - develop/master 브랜치 간 merge
- 사용: Merge / Squash and Merge
- 이유: Squash를 통해 머지했다는 커밋으로 흔적을 남기는게 좋을 것 같습니다!

마치며

rebase, squash는 항상 꼭 merge랑 사용해야하는 것은 아닙니다! rebase의 심리스한 특성과 squash의 모아서 보여주는 특성은 독단적으로 사용할 때도 유효하기 때문에 이 특성을 활용하여 history를 정리할 때에도 사용된답니다!

이렇게 오늘은 merge의 방식에 대해 알아보았습니다. 감사합니다 :)

iOS) URLSession + NSCache 실습(2) - NSCache

snowe — Wed, 15 Sep 2021 13:57:36 +0900

저번 글에 이어서 오늘은 자주 사용하는 이미지 캐싱 라이브러리인 Kingfisher의 Base인 NSCache에 대해서 알아보도록 할게요!

Caching을 하는 이유

예를들어, 서버에서 어떤 API를 호출해서 이미지를 받아온다고 한다면 우리는 그 이미지 처리를 위해 비동기 코드를 작성하곤 합니다. 가장 주된 이유는 이미지를 받아오는데에 걸리는 시간이 이미지 크기에 따라 엄청 오래걸릴 수 있기 때문이죠!

같은 이유로 사용자가 방금 불러온 이미지인데 잠깐 나갔다가 들어왔을 때 다시 API를 호출하고 이미지를 불러올 때 같은 시간이 소요된다면 비효율적이겠죠? 이미지의 크기가 크다면 클수록 더더욱 그럴 것 같아요.

그래서 우리는 기기 내부에 존재하는 임시 저장소인 Cache에 이미 불러온 이미지를 넣어두고 빠르게 꺼내 쓸 수 있게 하는거에요. 그리고 이러한 행위 자체를 Caching이라고 합니다!

Cache의 종류

Cache는 두 종류인데, Memory Cache, Disk Cache로 나뉩니다.

Memory Cache

기기를 끄면 사라지는 Cache에요. 오늘 우리가 알아볼 NSCache를 통해서 구현할 수 있습니다!

Disk Cache

메모리 캐시와 다르게 기기를 꺼도 남아있어요.
두 가지 방법으로 구현할 수 있는데, UserDefault를 사용한다면 앱을 삭제했을 때 같이 사라질 것이고, 파일 경로에 이미지를 저장한다면 앱이 삭제되더라도 캐시가 남아있게 됩니다.

필수는 아니지만 보통은 파일 경로에 저장하는 것 같습니다

Cache 구현

Caching 순서도

API를 호출해서 이미지 url을 받아온다.
url을 key값으로 memory cache에 저장된 데이터가 있는지 확인한다.
있으면 쓰고 없다면 disk cache에서 확인해본다.
거기도 없다면 url로 이미지를 가져온 뒤 memory cache와 disk cache에 각각 저장해준다.

Memory Cache 구현

아까 memory cache는 NSCache를 통해 구현한다고 했죠?! 저는 NSCache를 아래와 같이 싱글톤 객체로 구현해주었어요!

class ImageCacheManager {
    // 키값으로 쓸타입과 캐시에 넣을 타입을 정해주면된다.
    // 내가 사용할 key값: Image URL String
    static let shared = NSCache<NSString, UIImage>()
    private init() {}
}

막간을 이용한 한가지 꿀팁
NSString에서 lastPathComponent 속성을 사용하면 url에서 파일명만 추출할 수 있다.

예를들어, www.test.com/image/test.png 라면 test.jpg만 뽑아오는 것

그래서 무튼 위에서 만든 NSCache 객체를 아래처럼 사용하여 캐싱하면 된다.

let cacheKey = NSString(string: url).lastPathComponent

// 다운로드된 이미지를 메모리 캐시에 저장
ImageCacheManager.shared.setObject(image, forKey: cacheKey as NSString)

Disk Cache 구현

Disk Cache는 File Manager를 이용해서 구현할 수 있어요.

File Manager는 파일 시스템과 상호작용하는 주요 수단으로써 파일 시스템의 내용에 대한 편리한 인터페이스라고 애플 독스가 설명해주고있어요

암튼, 이걸로 구현을 할건데 먼저 저장될 디렉토리를 찾기 위해서 NSSearchPathForDirectoriesInDomains를 사용해야해요 NSSearchPathForDirectoriesInDomains는 디렉토리 검색 경로 목록을 생성해줘요.

NSSearchPathForDirectoriesInDomains(directory: FileManager.SerachPathDirectory, domainMask: FileManager.SearchPathDomainMask, expandTilde: Bool)

여기서 첫번째 파라미터인 directory에 들어가는 기본 제공 path는 이만큼이 있어요.

그리고 expandTilde를 true로 해주면 해당 경로 뒤에 문자열을 붙여서 새로운 경로를 만들 수 있어요!

이정도로 하고 우리가 사용할 path를 아래처럼 구성할 수 있겠네요.

let cacheKey = NSString(string: url).lastPathComponent

// 1. 경로로 cache폴더를 지정
guard let path = NSSearchPathForDirectoriesInDomains(.cachesDirectory, .userDomainMask, true).first else { return }

// 2. 1에서 지정한 cache경로 뒤에 key값으로 폴더 생성
let filePath = URL(fileURLWithPath: path).appendingPathComponent(cacheKey)

위에가 path, 아래가 filePath

그럼 이제 FileManager 객체를 만들고 그 안에 우리가 찾는 이미지가 저장되어있는지 체크해주면 끝!

let fileManager = FileManager()

// 이 이름으로 캐싱된 데이터 있니?
if fileManager.fileExists(atPath: filePath.path) {
    guard let imageData = try? Data(contentsOf: filePath) else {
        print("disk cache image data nil")
        return
    }

    guard let cachedImage = UIImage(data: imageData) else {
        print("disk cache image data nil")
        return
    }

    DispatchQueue.main.sync {
        print("CACHE>> Load Disk cache")
        // disk cache에서 썼으면 다음을 위해 memory cache에도 저장해주기
        ImageCacheManager.shared.setObject(cachedImage, forKey: cacheKey as NSString)
        self.image = cachedImage
    }
    return
}

전체 코드 및 설명

메모리 캐시와 디스크 캐시 처리를 따로 빼서 코드를 간소화 할 수도 있겠지만 일단은 설명을 위해 쭉 순서대로 작성해보았습니다.

import UIKit

extension UIImageView { 
    func setImageUrl(_ url: String) {

        // 캐시에 사용될 Key 값
        let cacheKey = NSString(string: url).lastPathComponent

        // MARK: Memory Cache
        // 1. `url`을 key값으로 `memory cache`에 저장된 데이터가 있는지 확인한다.
        if let cachedImage = ImageCacheManager.shared.object(forKey: cacheKey as NSString) {
            DispatchQueue.main.sync {
                print("CACHE>> Load Memory cache")
                // 불러오려는 이미지가 이미 메모리 캐시에 저장되어 있으면 캐싱된 이미지를 사용
                self.image = cachedImage
            }
            return
        }

        // 메모리 캐시에 원하는 이미지가 없다면

        // MARK: Disk Cache
        // 2. disk cache(UserDefault 혹은 기기Directory에있는 file)에서 확인
        guard let path = NSSearchPathForDirectoriesInDomains(.cachesDirectory, .userDomainMask, true).first else { return }

        let filePath = URL(fileURLWithPath: path).appendingPathComponent(cacheKey)
        let fileManager = FileManager()

        if fileManager.fileExists(atPath: filePath.path) {
            guard let imageData = try? Data(contentsOf: filePath) else {
                print("disk cache image data nil")
                return
            }

            guard let cachedImage = UIImage(data: imageData) else {
                print("disk cache image data nil")
                return
            }

            DispatchQueue.main.sync {
                print("CACHE>> Load Disk cache")
                // 있다면 다음에 더 빨리 불러오기 위해 memory cache에 추가해주고 사용한다.
                ImageCacheManager.shared.setObject(cachedImage, forKey: cacheKey as NSString)
                self.image = cachedImage
            }
            return
        }

        // 이마저도 없다면
        // 3. 서버통신을 통해서 받은 URL로 이미지를 가져온다.
        DispatchQueue.global(qos: .background).async {
            if let url = URL(string: url) {
                URLSession.shared.dataTask(with: url) { (data, res, err) in
                    if let _ = err {
                        DispatchQueue.main.async {
                            self.image = UIImage()
                        }
                        return
                    }
                    DispatchQueue.main.async {
                        if let data = data, let image = UIImage(data: data) {
                            print("CACHE>> No cache I'll make new")
                            // URL로 이미지 불러와서 사용
                            self.image = image

                            // 다음을 위해 caching 해주기
                            // 다운로드된 이미지를 메모리 캐시에 저장
                            ImageCacheManager.shared.setObject(image, forKey: cacheKey as NSString)
                            // 다운로드된 이미지를 디스크 캐시에 저장
                            fileManager.createFile(atPath: filePath.path, contents: image.jpegData(compressionQuality: 0.4), attributes: nil)
                        }
                    }
                }.resume()
            }
        }
    }
}

마치며, 주의점

순수하게 구현하려니까 직접 구현해야하는 부분이 많긴해도 재밌는 것 같아요.

그리고 사실 이게 전부는 아니에요..ㅎㅎ 만약 서버에서 이미지를 교체했지만 이미지 파일명은 그대로일 경우 현재 방식대로면 파일명으로 캐시 데이터를 찾으니까 이전 이미지를 계속해서 불러오겠죠? 이러면 안되는데 말이에요

이걸 방지하기 위해서 ETag라는 리소스 식별자를 사용한다고 합니다. 사용을 위해서는 서버에도 이를 처리하기 위한 개발이 되어있어야 해요.
header부에 ETag값을 넣고 변경/미변경의 응답코드를 다르게 줌으로서 리소스 변경이 있는지 없는지를 확인할 수 있는 방법이어서 해당 문제를 해결할 수 있다고 하네요!

다음엔 이것도 공부해볼게요. 감사합니다 :)

iOS) URLSession + NSCache 실습(1) - URLSession

snowe — Tue, 14 Sep 2021 23:21:56 +0900

Kingfisher, Alamofire, Moya 많이들 사용하시나요? 저도 사용하고 있습니다만..
얘네를 사용하는 이유가 URLSession, NSCache등을 사용할 때 번거로움이 많아서잖아요? 근데 제가 그 번거로움을 못 느껴본 것 같아서 이참에 직접 구현하며 경험해보고 정말 어떤 점이 좋은 건지 공부해보려고 해요.

URLSession을 먼저 알아볼게요

URLSession?

HTTP/HTTPS를 통해 콘텐츠 및 데이터를 주고받기 위해 애플에서 만든 서버 통신 API 클래스.

HTTP/HTTPS외에도 인증, 쿠키 관리, 캐시 등도 지원한대요(사실 메서드 되게 많으니까 definition 참고하는게 더 좋을듯).

URLSession은 기본적으로 비동기로 구현이 되어있어요. 그래서 구현 할 때 별도의 비동기 처리는 필요하지 않습니다!

하지만 통신시 일어나는 UI처리가 있을 수 있겠죠?! UI 관련 처리는 모두 Main Thread에서 이루어져야하기 때문에 DispatchQueue.main.sync 내부에서 처리해야 됨을 유의해야합니다!(사실 어차피 Xcode가 보라색 알림문구로 알려주긴함)

URLSession을 사용하는 순서?

URLSessionConfiguration을 설정하고, Session을 생성합니다.
통신할 URL과 Request 객체를 준비합니다.
사용할 Task를 결정하고, Completion Handler / Delegate 메소드를 작성합니다.
- 간단한 통신: Completion Handler , Background 상태일때에도 동작: Delegate 패턴을 주로 사용
Task를 실행합니다.
Task 완료 후 Completion Handler를 실행합니다.

제가 연습한 코드로 살펴보면..!

import Foundation

struct TestService {
    static let shared = CAFETIService()
    
    // MARK: - baseURL + path
    let baseURL = "http://유.알.엘/"
    var urlString: String { get { baseURL + "패.쓰" } }
    let token = "토.큰"
    
    func fetchTestData(answers: [Int], completion: @escaping (NetworkResult<모델>) -> ()) {
        if let url = URL(string: urlString) {
            // MARK: 1.URLSessionConfiguration을 설정하고, Session을 생성합니다.
            let session = URLSession(configuration: .default)
            
            // MARK: 2.통신할 URL과 Request 객체를 준비합니다.
            var requestURL = URLRequest(url: url)
            requestURL.setValue("Application/json", forHTTPHeaderField: "Content-Type")
            requestURL.setValue(token, forHTTPHeaderField: "token")
            requestURL.httpMethod = "POST"
            
            let body = ["answers": answers]
            guard let bodyData = try? JSONSerialization.data(withJSONObject: body, options: []) else { return }
            requestURL.httpBody = bodyData
            
            // MARK: 3.사용할 Task 를 결정하고, 그에 맞는 Completion Handler, 혹은 Delegate 메소드를 작성합니다.
            let dataTask = session.dataTask(with: requestURL) { (data, response, error) in
                if error != nil {
                    print(error!)
                    return
                }
                
                if let bindingData = data {
                    do {
                        let decodedData = try JSONDecoder().decode(모델.self, from: bindingData)
                        // MARK: 5.Task 완료 후 Completion Handler를 실행합니다.
                        completion(.success(decodedData))
                    } catch {
                        print(error.localizedDescription)
                    }
                }
            }
            // MARK: 4.Task를 실행합니다.
            dataTask.resume()
        }
    }
}

순서는 이렇고 이제 1번부터 생소한 용어를 짚어가면서 살펴볼게요!

1. URLSessionConfiguration을 설정하고, Session을 생성한다.

우리는 URL과 Request객체를 가지고 통신을 할거에요

이때, 통신을 위해서는 URLSession 세션 객체를 생성해야합니다. 이는 URLSessionConfiguration을 통해 생성할 수 있어요.

URLSessionConfiguration이 제공하는 세션 객체의 유형은 아래의 "3가지"입니다.

아 그 전에 하나 유의해야 할 점이 한 가지 있어요. URLSession의 definition에 보면 configuration이 @NSCopying을 준수하고 있는 모습을 볼 수 있는데, 이는 기능적으로 자신의 복사본을 통해 동작하는 느낌인것 같더라구요?! 그래서 한번 선언된 Session 객체를 추후에다른 유형으로 변경하고자 할 때에는 새롭게 객체를 만들어주어야한다고 합니다!

Default Session(기본)

: 디스크가 기반 캐싱, 자격 증명 및 쿠키 저장소 개체를 사용하는 세션

: delegate 지정이 가능하다

URLSessionConfiguration(.default)

Ephemeral Session (임시/하루살이 세션)

: Default Session에서 설명한 저장소 개체를 사용하지 않는 세션, Private하다.

URLSessionConfiguration(.ephemeral)

Background Session(백그라운드)

: 백그라운드에서도 통신을 수행할 수 있는 세션

URLSessionConfiguration(.background)

2. 통신할 URL과 Request 객체를 준비합니다.

우리가 통신을 할 때 필요한 baseURL+path, 그리고 통신을 위해 넣어주어야 할 Request 객체를 준비해주어야겠죠?

..code..

// 통신을 주고 받을 URL
let baseURL = "http://~~~~/"
var urlString: String { get { baseURL + "PATH자리" } }

if let url = URL(string: urlString) {
      // MARK: 1.URLSessionConfiguration을 설정하고, Session을 생성합니다.
      let session = URLSession(configuration: .default)
		
      // MARK: 2.통신할 URL과 Request 객체를 준비합니다.
      // Request 객체 생성
      var requestURL = URLRequest(url: url)
      
      // Request Header 구성
      requestURL.setValue("Application/json", forHTTPHeaderField: "Content-Type")
      requestURL.setValue(token, forHTTPHeaderField: "token")
      
      // HTTP Method는 기본이 "GET", 그 외에는 아래처럼 별도 설정 필요
      requestURL.httpMethod = "POST"

      // Request Body
      let body = ["answers": answers]
      guard let bodyData = try? JSONSerialization.data(withJSONObject: body, options: []) else { return }
      
      // Request 객체에 할당
      requestURL.httpBody = bodyData
      
      // ...
      // MARK: 3.사용할 Task 를 결정하고, 그에 맞는 Completion Handler, 혹은 Delegate 메소드를 작성합니다. 
}

3. 사용할 Task를 결정하고, Completion Handler / Delegate 메소드를 작성합니다.

간단한 통신: Completion Handler , Background 상태일때에도 동작: Delegate 패턴을 주로 사용

4. Task를 실행합니다.

5. Task 완료 후 Completion Handler를 실행합니다.

Task객체란?

Session객체를 통해 서버로 요청을 보내고 난 뒤, 응답을 받을 때 필요한 객체. 3가지 유형이 있다.

URLSessionDataTask
: Data객체를 통해 데이터를 주고받은 Task 수행

URLSessionUploadTask
: Data를 파일로 변환 후 업로드하는 Task 수행

URLSessionDownloadTask
: Data를 파일로 변환 후 다운로드하는 Task 수행

: 백그라운드 다운로드도 지원하며 일시정지 또한 가능하다.

// MARK: 3.사용할 Task를 결정합니다.고, 그에 맞는 Completion Handler를 작성합니다.
let dataTask = session.dataTask(with: requestURL) { (data, response, error) in
    if error != nil {
        print(error!)
        return
    }
    
    // 데이터 바인딩
    if let bindingData = data {
          do {
                // 통신을 성공하여 데이터를 받았다면 JSON 타입 데이터를 사용 가능하도록 디코딩
                let decodedData = try JSONDecoder().decode(CAFETI.self, from: bindingData)
                // MARK: 5.Task 완료 후 Completion Handler를 실행합니다.
                completion(.success(decodedData))
            } catch {
                print(error.localizedDescription)
        }
      }
    }
    
    // MARK: 4.Task를 실행합니다.
    dataTask.resume()
}

Final. 서비스 메서드 호출

@objc
private func tappedLoad() {
    TestService.shared.fetchTestData(answers: 데이터 넣기) { [self] response in
        switch response {
        case .success(let data):
        case .requestErr(let err):
        case .pathErr:
        case .serverErr:
        case .networkFail:
        }
    }
}

오늘은 URLSession에 대한 전반적인 부분들을 직접 사용하면서 익혀보았습니다.

사실 오늘 호출한 API가 제가 만든 API인데 response로 이미지가 오는 API를 가져왔기 때문에 다음엔 이걸로 이미지 캐싱을 연습해볼게요!

감사합니다 :)