애플사이다의 iOS 개발 일지

[iOS] Bottom Sheet 버그 - viewDidLoad에서 layout을 설정하면 안되는 이유

Applecider — Sun, 14 Apr 2024 21:48:19 +0900

서비스에서 진행 중인 굵직한 이벤트가 있다면

앱을 실행하고 Home 화면에 진입했을 때, 애니메이션과 함께 Bottom Sheet (이하 바텀시트)를 띄워준다.

바텀시트를 노출하는 앱은 매우 흔하다.

dim 영역이나 x 버튼을 탭하면 Sheet가 내려가도록 구현되어 있다.

29CM	무신사	ABLY	오늘의집	Shein	쿠팡

개인적으로 귀찮아서 습관적으로 무조건 닫기 버튼을 누르긴 하지만... ㅋㅋㅋ (솔직히 사용성 너무 안 좋다고 생각함)

그래서인지 아마존, Etsy, Temu 같은 글로벌 앱에서는 이러한 시트를 띄우지 않고 있었다.

아무튼 이번에는 이러한 바텀시트를 구현하는 과정에서 겪었던 버그를 파헤쳐보려 한다.

제목에서 벌써 스포하고 있듯이 ViewDidLoad 시점에 Bottom Sheet의 layout을 잡아줬던 게 원인이었다.

먼저, 버그는 이랬다

viewController 위에 바텀시트를 subview로 올리고

바텀시트의 imageView의 width/height를 viewController width와 동일하게 잡아줬다.

그리고 아래에서 위로 올라오는 애니메이션 효과를 주기 위해

초기에는 imageView의 top을 바텀시트의 bottom으로 맞춰서 바닥에 숨겨두고,
바텀시트를 띄울 때는 imageView의 top을 바텀시트의 height 만큼 올려줬다.

1) HomeBottomSheetView 내부적으로 layout을 잡아주는 코드

// layout 초기 설정
addSubview(imageView)
imageView.snp.makeConstraints { make in
    make.leading.trailing.equalToSuperview()
    make.top.equalTo(snp.bottom)
    make.height.equalTo(snp.width) // ✅ 바텀시트 height == width
}

// 바텀시트를 show/close하는 로직
func show() {
    layoutIfNeeded()

    UIView.animate(withDuration: 0.25) {
        self.dimView.alpha = 1
        // ✅ imageView top == 바텀시트 height 만큼 올려주기
        self.setImageViewOffsetY(to: -self.imageView.bounds.size.height)
    }
}

func close() {
    UIView.animate(withDuration: 0.25) {
        self.dimView.alpha = 0
        // ✅ imageView top == 바텀시트 bottom으로 내려서 숨기기 
        self.setImageViewOffsetY(to: 0)
    } completion: { [weak self] _ in
        self?.removeFromSuperview()
    }
}

private func setImageViewOffsetY(to offsetY: CGFloat) {
    imageView.snp.updateConstraints { make in
        make.top.equalTo(snp.bottom).offset(offsetY)
    }
    layoutIfNeeded()
}

2) ViewController에서 바텀시트를 올려주는 코드

override func viewDidLoad() {
    super.viewDidLoad()

    showBottomSheet()
}

private func showBottomSheet() {
    let bottomSheetView = HomeBottomSheetView()

    // ✅ dim 영역이 있으므로 전체화면 크기로 잡아줌 
    view.addSubview(bottomSheetView)
    bottomSheetView.snp.makeConstraints { make in
        make.edges.equalToSuperview()
    }
    bottomSheetView.show()
}

그런데..! 아래와 같이 기기마다 바텀시트의 bottom inset이 다르게 나타났다.

(기기는 왼쪽부터 iPhone 15 / 13 mini / SE)

삼체 너무 재밌음.

버그 원인은 뭘까?

결론부터 말하자면 원인은

1) ViewController와 연결된 storyboard가 존재했고

2) 바텀시트의 layout을 viewDidLoad 시점에 설정했기 때문이었다.

conflict을 피하기 위해 storyboard 없이 layout을 그리는 데에 익숙해지다보니

이처럼 storyboard를 사용하고 있는 ViewController의 특성을 고려하지 못했다...!

ViewController의 lifecycle method로 실험해 보자

view를 띄울 때

viewDidLoad, viewWillAppear, viewDidLayoutSubviews가 차례로 호출되는데

각 시점에서 view의 width를 찍어봤다.

override func viewDidLoad() {
    super.viewDidLoad()
    print("viewDidLoad ...", view.frame.size.width)
}

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    print("viewWillAppear ...", view.frame.size.width)
}

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()
    print("viewDidLayoutSubviews ...", view.frame.size.width)
}

그랬더니...!

실험했던 iPhone SE의 Screen width는 375인데

아래처럼 viewDidLoad에서만 393으로 잘못된 값이 찍히는 것을 확인할 수 있었다.

그럼 393은 어디에서 온 숫자일까?

스오플을 뒤져보니... 놀랍게도...!
storyboard에서 설정한 기기의 Screen width였다.

세상의 모든 Storyboard 없애고 싶다..

ViewDidLoad에서 Layout을 잡으면 안 되는 이유는?

그렇다면 왜 viewDidLoad에서는 잘못된 너비가 찍히는 걸까?

이 시점에는 view frame이 정확히 계산되지 않은 상태이기 때문이다.

공식 문서에서 확인해보자.

viewDidLoad() 를 다시 보게 될 날이 올 줄이야..

공식문서를 읽어보면...

"viewDidLoad가 호출되는 시점은 view hierarchy를 메모리에 로드한 직후"라고 말한다.

(view를 view hierarchy에 추가했다는 뜻이 아니다.)

공식문서가 좀 불친절하긴 하지만

마지막 문장 "viewDidLoad를 override하여 nib 파일에서 로드한 view에 대한 추가적인 초기화를 할 수 있다"에서 볼 수 있듯이

view를 초기화까지만 하고, layout은 하면 안 되는 걸 유추해야 할 것 같다.

그럼 찾아본 김에 viewWillAppear(_:)도 살펴보자.

"view를 표시하는 것과 관련된 작업"을 할 때 viewWillAppear를 override하라고 명시되어 있다.

iOS13+부터 쓸 수 있는 viewIsAppearing(_:) 도 보자.

viewWillAppear가 호출된 이후

view가 실제로 hierarchy에 추가된 뒤, viewIsAppearing이 호출되는 것을 알 수 있다.

(view가 hierarchy에 추가됐다는 것은 parentView or window에 올라갔음을 의미한다.)

왠지 hierarchy에 추가된 이후 시점인 viewIsAppearing에서

바텀시트를 띄워주면 해결될 것 같지만... 그건 아니었다.

참고 - 호출 순서

아래에 viewWillAppear에 대한 자세한 내용이 들어있었다.

구체적인 메커니즘은 다른 문서를 뒤져봐야 더 정확히 알겠지만..

일단 공식문서를 바탕으로 각 lifecycle 메서드에서 바텀시트가 어떻게 나타나는지 테스트해봤다.

위 내용을 보면

viewWillAppear 시점에 설정한 애니메이션은

viewController 전환 애니메이션과 동시에 화면에 나타난다는 것을 알 수 있다.

예를 들어,

홈 바텀시트가 올라오는 애니메이션을 viewWillAppear 시점에 설정했다면

이건 NavigationController에 의해 push 된 homeViewController가 오른쪽에서 밀려 들어오는 애니메이션과

동시에 보여진다는 거다.

아래처럼 말이다.

vc은 오른쪽에서 왼쪽으로, 바텀시트는 아래에서 위로

홈 화면은 대부분 앱을 실행하자마자 보이는 첫 번째 화면이기 때문에

viewController 전환 애니메이션 없이, 바텀시트 애니메이션만 나타낼 수 있다.

(만약 홈 화면이 첫번째 화면이 아니라면 viewDidAppear 시점에 띄우는 게 차선책이다.)

공식문서 내용처럼

viewWillAppear 직후에 viewIsAppearing이 호출되는데

viewIsAppearing에서 바텀시트를 띄우면, 위로 올라오는 애니메이션이 보이지 않는다.

마지막으로, viewDidLayoutSubviews()는 어떨까?

"뷰의 subviews가 모두 layout 완료된 이후에 변화를 주고 싶을 때 override 한다"고 되어있다.

이것만 봤을 때는 이 시점에 바텀시트를 띄워도 될 것 같다.

viewDidLayoutSubviews 문서

하지만 viewIsAppearing 문서에 이런 내용이 있다.

"viewWill/DidLayoutSubviews는 transition이 진행되는 동안 여러 번 호출될 수 있다."

따라서 바텀시트는 한 번만 띄워야 하므로 viewDidLayoutSubviews는 적절하지 않다는 것을 알 수 있다.

viewIsAppearing 문서

실제로 아래처럼 바텀시트가 여러 번 띄워지는 것을 볼 수 있다.

(바텀시트가 숨겨지는 transaction에 의해 layoutSubviews, viewDidLayoutSubviews가 다시 호출된 듯)

결론

storyboard를 연결한 viewController에만 발생하는 버그이지만

협업하는 팀원이 storyboard를 추가할 수도 있으니까

subview layout은 viewDidLoad 대신 viewWillAppear에서 잡는 것이 안전하다.

(다만, view constraints에 따라 layoutIfNeeded를 호출해야 할 수 있고,

viewController 전환 애니메이션과 분리해야 하는 경우 viewDidAppear에서 잡아야 할 수도 있다.)

그리고 당연한 거지만 viewWillAppear는 다른 화면으로 이동했다가 home으로 되돌아왔을 때 재호출되므로

앱을 실행했을 때 한 번만 노출하기 위해
바텀시트가 띄워졌는지 여부를 homeVC의 프로퍼티로 저장하여 flag로 활용해야 한다.

참고로 바텀시트를 포함한 예제코드를 만들었는데, 위 버그가 재현되지 않아 한참 삽질을 했다.

알고 보니 storyboard에서 is initial view controller로 체크한 경우에는

viewDidLoad에서도 view width가 잘 잡히는 거였다.

직접 구현해보고 싶다면 SecondViewController를 push 해서 테스트해야 함을 잊지 말자!

예제 코드는 GitHub Repo에 올려두었다.

- Reference

Apple Developer Documentation > viewIsAppearing(_:)
Apple Developer Documentation > viewDidLoad()
StackOverFlow > view.frame.width IS correct in viewDidLoad with storyboard
StackOverFlow > Loading View Controller from xib return wrong frame
바텀시트 예제 코드 > GitHub Repo

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Combine] 기본 원리 - Publisher/Subscriber/Cancellable Protocol, Subscription 메커니즘 (2/3)

Applecider — Sun, 4 Feb 2024 21:34:06 +0900

지난번에는 RxSwift와 Combine을 비교하고,

5가지 중요한 개념인 Publishers, Operators, Subscribers, Subscriptions, Cancellable을 간단히 알아봤다.

지난 포스팅 [Combine] 기본 원리 - Apple이 만든 RxSwift를 이해해 보자 (1/3)을 참고

계속해서 Combine 기본 원리를 알아보자.

이번에는 Publisher / Subscriber / Cancellable Protocol의 개념과

Subscription 메커니즘을 자세히 살펴봤다.

1. Publisher Protocol

AnyPublisher를 이해하려면, Publisher Protocol을 알아야 한다.

Publisher는 이벤트를 방출 (publish) 한다. 기존의 NotificationCenter와 비슷하다.

Publisher Protocol의 정의는 이렇다.

defines the requirements for a type to be able to transmit a sequence of values.

(값을 방출할 수 있는 타입에 대한 요구사항을 정의한다.)

즉, 값을 방출하는 Publisher를 만들고 싶다면

Publisher Protocol에서 만들어 둔 특정 요구사항을 따르게 해야 한다.

요구사항을 간단하게 요약하면 아래와 같다. 대략적인 구성만 보자.

Protocol의 연관타입으로 방출할 값의 타입 (Output), 방출할 수도 있는 에러 타입 (Failure)을 정해뒀다.

에러를 절대 방출하지 않는다면 Never를 사용한다.

struct AnyPublisher<Output, Failure> where Failure : Error

protocol Publisher {
    associatedtype Output
    associatedtype Failure: Error
}

2. Subscriber Protocol

마찬가지로 Subscriber Protocol의 정의도 살펴보자.

defines the requirements for a type to be able to receive input from a publisher.

(publisher로부터 값을 받을 수 있는 타입에 대한 요구사항을 정의한다.)

Subscriber는 Publisher로부터 어떻게 값을 받아올 수 있을까?

sink 메서드, assign 메서드를 사용하는 2가지 방법이 있다.

sink 메서드

sink 메서드의 형태를 뜯어보자.

func sink(receiveValue: @escaping ((Self.Output) -> Void)) -> AnyCancellable

Publisher로부터 받은 값의 타입인 Output,

escaping closure를 넘기게 될 receiveValue 매개변수,

그리고 AnyCancellable이 반환된다는 것을 알 수 있다.

즉, subscriber는 sink 메서드에 클로저를 전달해 publisher의 output을 처리 하도록 한다.

예시는 이렇다.

let myNotification = Notification.Name("MyNotification")
let center = NotificationCenter.default

// ✅ NotificationCenter.Publisher 타입을 반환
let publisher = center.publisher(for: myNotification, object: nil)

// ✅ publisher로부터 받은 값을 처리
let subscription = publisher.sink { _ in
    print("Notification received from a publisher!")
}

// ✅ 값을 방출
center.post(name: myNotification, object: nil)

// ✅ 구독 취소
subscription.cancel()

assign(to:on:) 메서드

다음으로 assign(to:on:) 메서드를 뜯어보자.

func assign<Root>(
    to keyPath: ReferenceWritableKeyPath<Root, Self.Output>,
    on object: Root
) -> AnyCancellable

keyPath가 눈에 띈다.

publisher로부터 전달받은 값을 객체의 KVO 호환되는 프로퍼티에 할당한다.

예시를 보면 쉽다.

assign 메서드를 사용하면 label, textView 등에 직접 할당이 가능하므로 UIKit과 함께 사용할 때 특히 더 유용하다.

class SomeObject {
    var value: String = "" {
        didSet {
            print(value)
        }
    }
}
let object = SomeObject()

// ✅ 총 2번 방출됨
let publisher = ["Hello", "world!"].publisher 

// ✅ 객체의 프로퍼티에 바로 반영시킴
_ = publisher.assign(to: \.value, on: object)

assign(to:) 메서드

참고로 assign(to:)을 통한 re-publish도 가능하다.

publisher에서 방출된 값을 @Published 프로퍼티에다가 다시 republish 할 수 있다.

class SomeObject {
  // ✅ Property wrapper @Published 
  @Published var value = 0
}
let object = SomeObject()

// ✅ $
object.$value.sink {
    print("@@@", $0)
}

// ✅ 새롭운 값 할당함 -> sink 호출됨
(0..<5).publisher.assign(to: &object.$value)

// 출력
@@@ 0
@@@ 0
@@@ 1
@@@ 2
@@@ 3
@@@ 4

@Published를 붙이면, 해당 프로퍼티의 value의 변화를 추적하는 publisher가 생성된다.
object.$value 형태로 $를 붙이면, value에 대한 publisher에 접근하여 subscribe 할 수 있다.
assign(to:) 메서드에 &object.$value가 전달되었다. 이때 &는 value 프로퍼티에 대한 inout 참조를 의미한다.
즉, 방출된 값 0~4는 object의 value publisher에다가 할당된다는 뜻이다.

여기서 한 가지 특이한 점은

assign(to:)는 Cancellables를 반환하지 않는다는 것이다.

@Published 프로퍼티가 deinit될 때 subscription이 자동으로 cancel 되도록 만들어져있다.

따라서 assign(to:on:) 메서드와 달리, assign(to:)에서는 retain cycle이 생성되지 않아서

메모리 관리 측면에서 보다 안전하다는 장점이 있다.

class MyObject {
    @Published var word: String = ""
    var subscriptions = Set<AnyCancellable>()
	
    init() {
        ["A", "B", "C"].publisher
        //   retain cycle 형성됨!!! 
        .assign(to: \.word, on: self)  
        .store(in: &subscriptions)

        // ✅ retain cycle 안생김
        .assign(to: &$word) 
	  }
}

3. Cancellable protocol

AnyCancellable 타입이 채택하며, cancel()을 구현해야 한다.

더 이상 값을 받을 필요가 없으면 subscription을 cancel 하는게 자원 절약에 좋다.

더 자세히 보자면,

subscription은 cancellation token 역할을 하는 anyCancellable 인스턴스를 반환하는데,

이 토큰을 통해 원할 때 subscription cancel을 할 수 있다.

subscription.cancel()이 가능한 것은 Subscription Protocol이 Cancellable을 상속하기 때문이다.

cancel을 호출하지 않으면, subscription이 아래 상황까지 유지된다.

1) publisher가 완료될 때까지

2) subscription을 저장한 프로퍼티가 deinit 될 때까지

4. Subscriber가 Publisher를 구독하는 과정 (feat. 다이어그램)

Publisher와 Subscriber가 구독을 통해 연결되고 값이 전달할 때,

어떤 과정을 거치는지 자세히 알아보자.

1. Subscriber가 Publisher를 구독한다.

2. Publisher가 Subscription (구독)을 생성하고, Subscriber에게 준다.

3. Subscriber가 값을 요청한다.

4. Publisher는 값을 보낸다.

5. Publisher가 completion을 보낸다.

이 관점에서 다시 위에서 봤던 Protocol을 뜯어보자.

Publisher Protocol+

먼저 Publisher Protocol이다.

public protocol Publisher {
  associatedtype Output 
  associatedtype Failure: Error 

  // 2 - 1에서 내부적으로 이걸 호출함 (subscriber를 publisher한테 붙여서 subscription 생성)
  func receive<S>(subscriber: S)
    where S: Subscriber,
    Self.Failure == S.Failure,
    Self.Output == S.Input
}

extension Publisher {
  // 1 - subscribe가 이걸 호출해서 구독을 시작함
  public func subscribe<S>(_ subscriber: S)
    where S : Subscriber,
    Self.Failure == S.Failure,
    Self.Output == S.Input
}

Subscriber는 Publisher를 구독하기 위해 해당 Publisher의 subscribe 메서드를 호출한다.
subscribe 메서드는 내부적으로 receive 메서드를 호출하는데, 이때 Subscription이 생성된다.
(Subscriber가 Publisher와 연결된다.)

Subscriber protocol+

public protocol Subscriber: CustomCombineIdentifierConvertible {
  associatedtype Input  
  associatedtype Failure: Error  

  // 1 - subscriber에게 subscription을 전달 (publisher가 이걸 호출)
  func receive(subscription: Subscription)

  // 2 - subscriber에게 새로운 값을 전달 (publisher가 이걸 호출)
  func receive(_ input: Self.Input) -> Subscribers.Demand

  // 3 - subscriber에게 subscription 끝났음을 전달 (publisher가 이걸 호출)
  func receive(completion: Subscribers.Completion<Self.Failure>)
}

Publisher는 Subscriber의 receive(subscription:) 메서드를 호출해서
Subscriber에게 생성된 Subscription을 전달한다.
Publisher는 Subscriber의 receive(_:) 메서드를 호출해서 방출한 값을 보낸다.
Publisher는 Subscriber의 receive(completion:) 메서드를 호출해서
더 이상 값을 방출할 필요가 없는 상황이라서 구독을 취소한다고 알려준다.

Subscription protocol+

그런데 위에서 계속 언급한 Subscription이란 뭘까?

단순히 Publisher와 Subscriber의 연결이라고 봐도 무방하다.

public protocol Subscription: Cancellable, CustomCombineIdentifierConvertible {
    // subscriber가 이걸 호출해서 값을 받겠다고 전달함
    // subscriber가 받을 새로운 값의 최대개수를 지정 가능
    func request(_ demand: Subscribers.Demand)
}

Subscriber는 request(_:) 메서드를 호출해서 앞으로 계속 값을 받을 의향이 있다고 알려준다.
이때 Demand를 통해 subscriber가 받아올 값의 최대 개수를 지정할 수 있다.

*참고로 Subscription은 커스텀이 가능해서 꽤 복잡한 내용인데,

사실상 개발자가 직접 커스텀할 일이 없을 것 같아서 내용을 매우 많이 생략했다.

예를 들면 Demand에 받아올 값의 최대 개수를 지정할 때,

새로운 max값이 기존 max값에 더해진다. (새로운+기존 max값 >= subscriber가 지금까지 받은 총 값의 개수)

그래서 negative값이 전달되면 fatalError 호출된다.

이런 거... 아마 평생 몰라도 될듯

RxSwift를 처음 접했을 때, Binding이라는 개념 자체가 너무 생소해서 메커니즘을 찾아볼 여유가 없었는데

이번에 Combine을 분석하면서 내부적인 Flow를 이해할 수 있게 되어 의미있었다.

그리고 개인적으로 Combine을 파헤쳐 본 소감을 말하자면,

최대한 공식문서를 통해 스터디를 하는 게 바람직하다고 생각하고, 그러려고 노력하는 편이지만

솔직히 Combine 같은 주제는 공식 문서만으로는 이해하기 어려운 게 맞는 것 같다.

"Publisher가 Subscriber에게 Subscription을 전달한다"는 것을 알기 위해
얼마나 많은 선행 지식을 이해해야 하는지... 절레절레...

일에 치이고, 기술 부채에 허덕이는 개발자라면 이럴 때는 현실적으로 Kodeco의 도움을 받는 것도 좋은 것 같다.

- Reference

관련 포스팅
- [Combine] 기본 원리 - Apple이 만든 RxSwift를 이해해보자 (1/3)
Apple Developer Documentation > Combine
Apple > WWDC 2019 > Introducing Combine
Apple > WWDC 2019 > Combine in Practice
Kodeco > Combine: Asynchronous Programming with Swift

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Combine] 기본 원리 - Apple이 만든 RxSwift를 이해해보자 (1/3)

Applecider — Sun, 21 Jan 2024 15:06:55 +0900

최근 RxSwift를 Combine으로 전환하면서

Combine의 원리에 대해 자세히 알아봤다.

Combine 공식문서와 Kodeco의 Combine 자료가 큰 도움이 되었다.

개인적으로 Combine+UIKit 조합은 좋지 않은지, 꼭 SwiftUI와 함께 써야 하는지 궁금했다.

결론적으로 Combine이 first-party라서 더 안전하고, 성능이 좋기 때문에
그리고 UIKit에서 사용할 수 있는 API가 많이 나왔기 때문에 (assign 등등)
Combine+UIKit 조합도 괜찮다!! 라는 답을 얻었다.

Combine은 비동기 처리를 쉽게 해주는 도구이므로

네트워크 layer, 새로 구현하는 화면 등 프로젝트 일부에만 사용해도 괜찮으니

여러 시도를 해보는 게 좋은 것 같다.

Combine+UIKit 사용 예시도 다음에 포스팅할 예정이다.

먼저 간단히 표로 RxSwift와 Combine을 비교해보자.
Rxswift/Combine Cheatsheet을 자주 참고했다.

RxSwift에서 제공하지 않는 기능은 CombineExt 라이브러리를 활용한다. (ex. CurrentValueRelay 등)

이제 Combine 관련 커뮤니티도 제법 커졌다.

	RxSwift	Combine
Framework Consumption	Third-party	First-party
Maintained by	Open-Source / Community	Apple / Community (커뮤니티 커짐)


던지는 애	Observable	AnyPublisher
받는 애	Observer	AnySubscriber
둘다 하는 애 (초기값 없음)	PublishSubject - value, error, completed 던짐	PassthroughSubject - value, error, finish 던짐
둘다 하는 애 (초기값 있음)	BehaviorSubject	CurrentValueSubject
	Single	*Future (Deffered)

구독	.subscribe	.sink or .assign
버리기	.disposed(by: disposeBag)	.store(in: &cancellables)

스레드 전환 (down only)	observeOn	receiveOn(on:)
스레드 전환	SubscribeOn (up & down)	*Subscribe(on:) (down only)
기타 공통 Operator	just, combineLatest, zip, debounce …	- 대부분 동일하게 있음
	merge(A,B,C)	A.merge(with: B,C)
	do	handleEvents
	skip	dropFirst
	take	prefix
	valueChanged	removeDuplicates

없는거	BehaviorRelay /PublishRelay	❌ *CombineExt CurrentValueRelay
	.asObservable	*직접 구현 ReadOnly/CurrentValuePublisher

1. Introduction

Combine이 등장하기 전에 비동기 처리를 어떻게 했을까?

NotificationCenter, delegate pattern, Grand Central Dispatch (or Operations), Closures, Timer 등이 있다.

이제 위의 모든 기능은 Combine으로 통합하여 구현할 수 있다.

2. Combine Basics

Combine framework 공식문서를 열면 가장 먼저 보이는 문장이다.

비동기 이벤트, 선언적, publishers, subscribers라는 단어가 키워드임을 알 수 있다.

The Combine framework provides a declarative Swift API for processing values over time.
These values can represent many kinds of asynchronous events.

Combine declares publishers to expose values that can change over time, and
subscribers to receive those values from the publishers.

이제 Combine의 3개 주요 요소인 Publishers, Operators, Subscribers를 보자.

1) Publishers

Subscribers에게 값을 방출한다.
3개 종류의 이벤트를 방출할 수 있다. 그리고 한 번 complete 되면 (성공이든 실패든) 더 이상 emit하지 않는다.
(1) Output
(2) successful completion
(3) Failure 안 함
error handling 기능을 기본 제공한다.
Publisher protocol은 2개 타입에 대한 Generic 타입이다.
(1) Publisher.Output : output 값의 타입 (ex. Int)
(2) Publisher.Failure : 실패 시 publisher가 throw 하는 error 타입
*만약 publisher가 절대 실패하지 않으면 Never 타입을 사용한다.

2) Operators

Publisher protocol에 선언된 메서드이며, 동일하거나 새로운 publisher를 반환한다.
highly decoupled/composable하다.
항상 input 및 output을 가지며, 흔히 upstream/downstream라고 불린다.

3) Subscribers

방출된 output 또는 completion events를 받아서 뭔가를 한다.
기본 제공되는 2개 종류의 subscribers가 있다.
(1) sink subscriber : provide closures with your code that will receive output values and completions.
(2) assign subscriber : without the need of custom code, bind the resulting output to some property on your data model or on a UI control to display the data directly on-screen via a key path.

그리고 문서를 읽다 보면 Subscriptions, Cancellable에 대한 언급이 많다.

4) Subscriptions

When you add a subscriber at the end of a subscription,
it “activates” the publisher all the way at the beginning of the chain.
Subscriptions (pub sub mechanism)의 장점 : allow you to declare a chain of asynchronous events with their own custom code and error handling only once.

5) Cancellable

Cancellable을 통해 memory 관리가 자동으로 된다.
ex. ViewController의 프로퍼티로 Cancellable 또는 [AnyCancellable]을 들고 있도록 하는데,
이 때문에 subscription의 lifespan을 쉽게 bind 할 수 있다.
(VC dismiss/deinit → properties deinit → subscription cancel)

다음 포스팅에서는 Publishers, Subscribers, Cancellable Protocol에 대해 알아보고,

Subscriptions 과정을 뜯어볼 예정이다.

- Reference

Apple Developer Documentation > Combine
Kodeco > Combine: Asynchronous Programming with Swift
GitHub > Rxswift to Combine Cheatsheet
GitHub > CombineExt

[2023년 회고] 개발자로 커리어 전환, 1년 후기 - 더 이상 일하는 게 괴롭지 않다

Applecider — Sun, 24 Dec 2023 23:08:26 +0900

연말 크리스마스 시즌을 맞아 2023년 회고를 작성했다.

약 1년 4개월 동안 개발자로 근무해 본 시점에서 소감을 남겼고 (주관 가득 주의)

작년 회고에 작성했던 목표를 얼마나 실천했는지 확인하고, 새로운 연간 계획을 세워봤다.

목차는 아래와 같다.

1. IT회사에서 개발자로 일하기

2. 올해 목표였던 것

3. 내년 목표
+)

회사 이벤트였던 '인간 크리스마스 Day' - 크리스마스 트리 인간이 올 줄은 몰랐다

1. IT회사에서 개발자로 일하기

IT와는 사뭇 동떨어진 일터에서 근무하다가 개발자로 취업한 뒤 여러 방면에서 문화 충격을 받았다.

사무실에서 카페처럼 BGM을 틀어주는 것만으로도 충격이었다.

대부분 긍정적인 충격이었기 때문에 그 경험을 털어놓고 싶어서 입이 근질근질했다.

그런데 입사 초반에는 단점보다는 장점만 말하게 될 것 같아서 해가 바뀔 때까지 기다렸다.

말하자면 제품을 구매한 직후에 쓴 후기보다 1개월 사용 후기가 더 믿을 만한 것처럼 1년 근무 후기를 올려야 할 것 같았다.

지난 회사에서 느꼈던 갈증

커리어 전환을 하기 전에는 환경공학을 전공하고, 2021년까지 발전소에서 환경 엔지니어로 근무했었다.

발전소를 포함해서 대부분의 발전/제조업의 주요 업무는 전화기 (전자전기, 화공, 기계) 전공자에게 주어지고

그 외 직접적인 성과를 낼 수 없는 staff 부서는 회사 내 입지와 대우에도, 개인적인 성장에도 한계가 많았다.

먼저 회사 내 입지가 중요했던 이유는 근무했던 곳이 협업이 많은 팀이었기 때문이다.

전공 관련 기사 자격증을 4개 따고, 업무 역량을 기르려고 노력했지만

직접 공사를 주관하거나 설비를 운영하는 주요 부서의 협조가 없으면 일을 할 수 없었다.

업무 우선순위에서 밀리다 보니 우리 팀은 그냥 귀찮은 일 시키는 부서일 뿐이었다.

자세히 말하자면 10 페이지 정도 쓸 수 있지만.. 이 정도로 줄였다.

그리고 이미 staff 조직의 한계에 대해 감안하고 입사를 했지만

일을 하면 할수록 루틴 업무를 기계적으로 수행하는 것이 적성에 맞지 않는다는 것을 여실히 알게 되었다.

그리고 동시에 작년에 했던 업무를 똑같이 반복하며 안정적으로 월급을 받는 환경을 선호하는 성향의 사람들이 있다는 것도 인정하게 됐다.

결론적으로는 꾸준히 성과를 내고 성장할 수 있는 환경에서, 배울 점이 많은 동료들과 일하고 싶다는 꿈을 안고 개발 공부를 시작했었다.

그래서 지금은?

약 1년 4개월 정도 개발자로 근무해 본 소감을 말하자면 대만족이다.

앞서 말한 두 가지 갈증이 모두 해소됐기 때문이다.

우선 IT회사에서 개발팀은 직접적인 성과를 만들어내는 핵심 부서에 속한다.

새로운 서비스를 만들 때 관여하는 부서가 많지만 개발팀을 통해서 기획을 실현시킬 수 있어 기여도가 높은 편이라고 생각한다.

특히 모바일 앱은 사용자가 서비스를 이용하는 접점이 되기 때문에 서비스 지표가 오를 때 직접적인 성취감을 느낄 수 있다.

이렇게 성과를 만드는 부서이기 때문에 회사 내에서 대우도 좋다.

그리고 이러한 주요 업무를 컴공 전공자가 아님에도 맡을 수 있다는 게 굉장히 큰 매력이다.

물론 전공자가 아닌 만큼 열심히 해야 한다는 압박감도 크지만...

어차피 공부가 일상이어야 하는 개발자에게 좋은 동기부여가 된다고 생각하고 있다. 오히려 좋아

또 무엇보다 같이 일하는 동료들이 좋다.

일주일 동안 가장 많은 시간을 보내는 사무실에

억지로 노력하지 않아도 자연스레 마음이 가는 동료들이 있다는 게 회사 생활을 얼마나 즐겁게 만드는지 배우는 중이다.

지난 회사와 분위기 자체가 많이 달라서 비교하는 게 무의미할 수도 있지만

비효율적인 업무는 거의 제로에 가깝고, 일상적인 소통이 수평적이라 훨씬 덜 힘든 것도 한 몫한다.

그래서 현재 수직적인 회사에서 위와 비슷한 갈증을 갖고 있는 분이라면..

일이 인생에서 차지하는 비중이 큰 편인데 직장 만족도가 낮아서 괴롭다면

개발자로 전향하는 것이 좋은 탈출구가 될 수 있다,

마치 다른 나라에 와서 근무하는 것처럼 환경을 완전히 바꾸는 것이 어느 정도는 가능하다는 말을 꼭 드리고 싶었다.

힘든 점

그렇지만 당연히 개발자로서 겪는 어려움도 있는데 그중 하나는

24시간 Slack을 모니터링하면서... 버그가 발생했을 때 즉시 대응해야 한다는 것이다.

이상하게 퇴근시간 직전에 버그 제보가 올라와서 집에 못가고 디버깅을 했던 때가 적지 않았다. 밤을 새는 일은 거의 없지만 ㅎㅎ

생각해보니 그래도 서버 개발자의 고충에 비해서는 좀 나은 것 같다.

앱 개발자는 당장 새벽에 버그를 고치더라도 AppStore 심사를 거쳐야 배포할 수 있기 때문에

치명적인 에러가 발생했을 때도 다음 날 오전에 해결하는 게 일반적이다.

반면 서버개발자는 즉시 배포가 가능하므로 새벽에 대응해야 할 때도 있다...

그리고 다른 하나는

12시간 Slack을 모니터링하면서... 개발 중인 피처 의 정책이나 디자인이 바뀌었을 때 즉시 대응해야 한다는 것이다.

생각보다 개발 도중에 큼직한 변경사항이 생기는 경우가 있는데 메시지를 놓쳤다가 나중에 일을 두 번 해야 할 때도 있었다.

그래서 로직을 짜면서 몰입력을 유지하면서도 Slack을 수시로 확인해야 한다는 점에서

일반 기업처럼 책상 위에 전화기가 놓여있지는 않지만 그럼에도 꽤 많은 컨텍스트 스위칭이 발생한다고 느꼈다.

요즘은 업무가 많은 시기에는 사무실이 조용한 오전 8시에 일찍 출근해서 몰입할 수 있는 시간을 확보하고 있다.

2. 올해 목표였던 것

작년 회고를 보며 올해 목표를 얼마나 실행했는지 정량적으로 평가해봤다.

10개 목표의 중요도가 다르지만 단순 평균을 내면 87%이다.

완벽하지는 않지만 꽤 만족스러운 결과인 것 같다.

1) 회사에서 진행 중인 글로벌앱 출시 프로젝트를 완수하고, 안정적인 서비스 운영에 기여하기

100%

당연한 걸 수도 있지만 개발자로는 첫 회사였기 때문에 더더욱 회사 업무에 가장 시간과 노력을 많이 들였다.

글로벌 서비스 론칭을 앞둔 시점에 투입되어 업무량이 적지 않았지만...

그래도 그만큼 채팅 기능을 포함해 여러 복잡한 view를 원 없이 그려볼 수 있어서 좋았다.

또 동일한 피처가 국내앱에 구현되어 있는 경우가 있는데,

이때 기존 코드를 구경하는 것, 그리고 개선하는 것 모두 흥미로운 작업이었다.

국내/해외 서비스를 모두 경험할 수 있는 환경에 감사하다.

글로벌앱을 론칭하고 1년 정도 되었는데 아직은 작고 소중한 수준이긴 하지만 매출이 꾸준히 늘고 있어서 뿌듯하다.

2) 업무 중에 접한 키워드 꾸준히 스터디하기

70%

지식이 미천해서 새롭게 알게 된 개념이 너무 많았기 때문에 모든 키워드를 스터디하지는 못했다. (고 변명해본다...)
하지만 기록충답게 근무일지에 모두 메모해뒀으므로 시간이 날 때마다 틈틈이 공부할 계획이다.
예를 들면 Deferred deeplink, App Scheme, Kinesis logging, Web socket, Localization, Combine, Push notification, Server-driven view 등을 구현해봤고, 그 외 Charles, Kibana, Tableau 등의 툴을 다뤄봤다.

3) 팀원들과 더 잘 협업하기 (29cm의 김우성 개발자님의 특강으로 들었던 “PR로 협업하기”를 회사 코드리뷰에 적용해 볼 계획이다.)

90%

팀 내 발표를 통해 PR 활용 방법을 공유하고, 실제로 팀에서 쓰는 PR template을 개선했다.

문제해결에 참고했던 Reference, AS-IS/TO-BE를 공유하는 것이 협업에 도움이 되었다는 평가를 들어서 뿌듯했다.

새로운 시도에 열려있는 팀원들 덕분에 가능했다.

이외에도 기록 덕후로서 Onboarding 과정에서 배운 것을 모두 문서로 남겨서

팀 내 Confluence 문서를 기준으로

Most active reader 1위 (912 views), Most active contributors 1위 (21 created, 84 updated)를 했다.

그중에서도 Charles/Tableau/딥링크 테스트 관련 튜토리얼 문서를 작성했었는데

팀원들로부터 유용하게 활용하고 있다는 피드백을 들었다.

취준할 때 이력서에 문서화 역량을 엄청 강조하면서도 이게 정말 도움이 될까 의구심을 가졌었는데,

실제로 긍정적인 평가를 받아서 혼자서 조용히 기뻐하고 있다. 세상의 모든 기록덕후 만세!

4) 팀원들과 진행 중인 디자인 패턴 스터디 1회/주 참여하기

70%

이 스터디를 했었다는 사실을 방금 깨달았다.

후반으로 갈수록 아무도 참여하지 않아서 끝을 보지 못했는데, 연초에 혼자서라도 마무리를 지어야 할 것 같다.

업무에 적용할 수 있는 부분이 생각보다 많지 않았지만, 패턴을 공부하는 것 자체는 재밌었다.

5) 노수진님의 슈퍼앱 운영을 위한 확장성 높은 앱 아키텍처 구축 강의 듣기

100%

요즘 '모듈화'가 유행인만큼 핫한 주제인 RIBs 아키텍처에 대해 배웠다.

배울수록 슈퍼앱이 아니면 RIBs의 장점을 활용할 수 없을 것이라는 생각이 들었고, 지금 당장 실무에는 적용할 수 없겠다고 결론 내렸다.

하지만 의존성 역전, 테스트 코드에 대해 이해하는 데 굉장히 큰 도움을 받았다.

6) 사이드 프로젝트로 ‘우리뭐먹지’ 앱 고도화하기 (지도, 즐겨찾기, 로그인 기능)

사이드 프로젝트는 전혀 못했다.

게다가 믿기 어렵지만 서버 비용이 청구되기 시작해서 서버를 껐더니 AppStore에서 앱이 내려갔다.

애정을 가지고 출시했던 앱이긴 하지만, 다시 봐도 부족한 점이 많아서 일단 더 이상 개발은 하지 않기로 했다.

내년에 다른 앱을 출시해 꾸준히 업데이트해 볼 계획이다.

7) 글또 구성원과 소통하고, 블로깅 1회/2주 하기

80%

패스를 2번 썼고, 휴가 시즌에 푹 쉬다가 제출 시기를 잊어버린 적이 있었다.

하지만 글또 덕분에 꾸준히 블로깅을 할 수 있었고,

무엇보다 글쓰기를 좋아하는 다른 개발자분들을 통해 많은 영감을 받을 수 있었던 소중한 창구였다.

글또를 소개해주신 예거에게 다시 한번 감사를!

블로그 포스팅을 작년에 비해 많이 하지는 못했지만 예전에 썼던 글이 종종 역주행하면서

7월, 9월, 10월에는 월간 방문수가 5천명을 돌파해서 뿌듯했다. 컨텐츠의 위력을 다시 한번 느꼈다.

8) WWDC 1회/주 보고 정리하기

70%

처음에는 당장 업무에 관련이 없더라도 새로운 지식을 꾸준히 습득하자는 욕심이 있었다. 지금도 욕심은 있다...

하지만 1~2번 목표에서 볼 수 있듯이 업무에 관련된 내용만 공부해도 너무 벅찼고,

UIKit 관련 업데이트가 많이 줄어서 더욱 손이 가지 않았다. 그래서 Localization 위주로만 보게 되었다.

그래도 Localization은 모조리 (약 10개) 훓었으니 이렇게라도 본 게 어디인가 싶기도 하다.

내년에는 performance 관련된 영상을 미리 찾아두고, 1회/월 보는 것을 목표로 삼아야겠다.

9) iOS 관련 컨퍼런스 1회/년 참석하기

200%

대문자 I인 인간이라서 이 목표는 솔직히 스스로 세우면서도 안지킬지도 모른다고 생각했다.

그런데 웬걸, 우연한 기회로 처음 참석했던 개발자 컨퍼런스 KWDC23에서 발표까지 하게 되었다.

당시 회사에서 갑자기 다른 프로젝트에 배치되는 바람에 주중에는 회사 일로 고생하고, 주말에는 울면서 발표 준비를 했었는데,

많은 분들의 도움을 받아 무사히 마무리할 수 있었다. 이때 살짝 번아웃와서 이후로 블로그 포스팅을 4개월 동안 쉬었다... ㅎㅎㅎ

자세한 내용은 KWDC23 연사 참여 후기를 참고

그리고 렛어스고 가서 야곰이랑 오프라인으로는 처음 인사했다. 떨려 하면서 갔는데 야곰은 모르실 듯 ㅎㅎㅎ

컨퍼런스에 가면 반가운 얼굴들도 있고,

혼자서 공부하려면 한참 걸리는 내용을 누군가가 대신 열심히 공부해서 떠먹여 주는 느낌이라 재밌다.

10) 단어장 만들어서 영어 공부하기

90%

처음에는 개발문서를 영어로 읽으면서 모르는 단어나 문장을 기록했었는데, 복습하는 것이 쉽지 않았다.

그때 마침 예거가 말해보카라는 앱을 소개해주셔서 매일 출퇴근길에 편하게 공부하고 있다.

개발 용어를 기반으로 학습하는 건 아니라서 좀 아쉽지만,

말해보카만큼 꾸준히 사용하게 되는 앱이 없는 것 같아서 매우 잘 쓰고 있다.
궁금하시다면 말해보카 앱 리뷰를 참고

3. 내년 목표

목표에는 긴 설명이 필요 없으니 간단히 남겨봤다.

지난 해에 이어서 글로벌앱이 개발 측면에서 안정적으로 운영되고, 디자인/운영 측면에서 성과를 낼 수 있도록 기여하기
국내앱 프로젝트에 참여할 때 기여할 수 있는 방법 고민하기
업무 중에 접한 키워드 꾸준히 스터디하기
Combine, SwiftUI 1회/주 스터디하기
새롭게 기획하고 있는 사이드 프로젝트에서 앱 출시하고, 1회 이상 업데이트하기
블로깅 1회/2주 하기
글또 구성원과 글에 대해 논의하기. iOS 이외 분야의 글도 읽기
멘토 활동을 통해 지식 전파하고, 신선한 시도에서 영감받기
performance 관련 WWDC 1회/월 정리하기
iOS 관련 컨퍼런스 1회/년 참석하기
30분/일 영어공부. ChatGPT 활용해서 하루 일과 영어로 정리하기
4회/주 아침 운동, 명상하기

+)

올해를 추억할 이미지로 마무리

올해 블로그 방문수

올해 그렸던 view들... 자식 같고 소중하다

즐거웠던 순간들

Count down 타이머 만들기 - 2개 날짜 비교 (feat. Localization)

Applecider — Sat, 9 Dec 2023 14:12:11 +0900

앱으로 쇼핑을 하다 보면 구매를 부추기는 장치가 여럿 마련되어 있는데

그중 하나가 Time Deal (특정 기간 동안 할인), Flash Sale (짧은 기간동안 한정 수량을 할인) 등의 이벤트이고

일반적으로 1초마다 시간을 업데이트하는 카운트 다운 타이머가 옆에 배치된다.

할인이 곧 끝나니 얼른 지르라는 은근한 압박을 주는데

이런 할인에 전혀 영향을 받지 않는 사용자도 있겠지만

UI/UX 관점에서 초 단위의 숫자가 계속 바뀌어서 시선이 집중되는 효과가 있다.

그래서 Home, PDP, 할인전 화면 등에서 주로 노출한다.

Amazon	SHEIN	쿠팡	오늘의집

이번 포스팅에서는 이러한 Count down 타이머를 구현해보고자 한다.

먼저 요구사항을 정리해보고, 단계별로 만들어 보자.

TODO:

1. 남은 할인기간 계산하기

2. Label에 원하는 format으로 시간 표시하기

3. Timer를 통해 1초마다 Label 업데이트하기

4. 추가적인 개선사항

1. 남은 할인기간 계산하기

Time Deal은 할인 종료시점이 정해져 있다.

이번 예제에서는 2023년 12월 31일 24시 (한국 timeZone 기준)에 할인이 끝나고, 서버에서 이 시간을 내려준다고 가정하자.

글로벌 서비스라면 종료시점을 ISO8601 format이 적용된

2024-01-01T00:00:00+09:00 문자열을 서버로부터 받게 될 것이다.

TimeManager 싱글턴 객체를 만들고, 현재 시각에서 할인 종료시점까지 남은 시간을 구해보자.

3가지 키 포인트만 알면 쉽다!

기본적으로 2개의 시 간을 비교할 때 Calendar의 dateComponents 메서드를 활용한다.
그러려면 시간 문자열을 Date 타입으로 변환해야 한다.
이때 변환을 위해 ISO8601DateFormatter이 필요하다.

final class FlashSaleManager { 
    // ✅ calendar를 사용하여 시간 비교
    private let calendar = Calendar.autoupdatingCurrent
    
    // ✅ 서버에서 받아온 시간 문자열을 Date 타입으로 변환하기 위한 formatter
    private let iso8601Formatter: ISO8601DateFormatter = {
        let formatter = ISO8601DateFormatter()
        // "yyyy-MM-dd'T'HH:mm:ssZZZZZ" (ex. 2023-12-31T15:00:00+00:00)
        formatter.formatOptions = [.withInternetDateTime]
        return formatter
    }()

    private func date(from dateText: String) -> Date? {
        return iso8601Formatter.date(from: dateText)
    }

    // ✅ 남은 시간을 구하기 (매개변수에 서버 문자열 전달)
    func remainTime(to dateText: String) -> DateComponents? {
        guard let date2 = date(from: dateText) else { return nil }
        
        let date1 = Date() // 현재 시각
        return calendar.dateComponents([.day, .hour, .minute, .second], from: date1, to: date2)
    }
}

시간을 표현할 format을 설정할 때 dateFormatter를 만드는데 (ex. "AM 3:04", "Apr 28", "Friday, Apr 28, 2023" 등)
이와 별개로 서버에서 받은 시간을 변환하는 용도로 ISO8601DateFormatter를 만들어두면 편리하다.
서버에서 받은 종료시점 (date2)을 ISO8601DateFormatter를 활용하여 Date 타입으로 변환한다.
현재 시각 (date1)은 Date()로 구한다.
마지막으로 calendar의 dateComponents 메서드를 활용하여 2개 시간을 비교한다.
이때 비교할 시간 단위를 설정할 수 있는데, 이번에는 '일/시/분/초' 단위로 지정했다.

2. Label에 원하는 format으로 시간 표시하기

2개 시간을 비교한 결과를 Label에 표시해보자.

이번 예시에서는 아래처럼 "Ends in dd:hh:mm:ss" 형태로 표현해봤다.

참 쉽죠

방금 위에서 만들었던 remainTime 메서드에 로직을 추가했다.

일/시/분/초 단위의 시간 차이를 dateComponents 타입으로 만들었으니

각각을 두 자리의 숫자로 표시해주면 된다.

(최근 개발된 API를 활용할 수 있겠지만 귀찮아서.. 일단.. 이렇게..)

func formattedRemainTime(to dateText: String) -> String? {
    guard let date2 = date(from: dateText) else { return nil }

    let date1 = Date()
    let countdownComponents = calendar.dateComponents([.day, .hour, .minute, .second], from: date1, to: date2)

    guard let days = countdownComponents.day,
          let hours = countdownComponents.hour,
          let minutes = countdownComponents.minute,
          let seconds = countdownComponents.second else { return nil }

    // ✅ 두 자리 숫자로 표시
    return String(format: "%02d:%02d:%02d:%02d", days, hours, minutes, seconds)
}

3. Timer를 통해 1초마다 Label 업데이트하기

이제 카운트 다운을 하기 위해 Timer를 설정해주자.

final class FlashSaleUnitView: UIView {
    private var timer: Timer?
    private lazy var timeBadgeView: TimeBadgeView = createTimeBadgeView()
    
    // ✅ 타이머 설정
    func startTimer() {
        if timer?.isValid != true {
            let timer = Timer(timeInterval: 1, repeats: true) { [weak self] _ in
                self?.changeTimeText()
            }
            self.timer = timer
            RunLoop.main.add(timer, forMode: .common)
        }
    }
    
    // ✅ Label에 남은 시간 텍스트 반영
    private func changeTimeText() {
        // 서버에서 받은 종료시점 "2024-01-01T00:00:00+09:00"
        guard let dueDateText = viewModel.saleDueDate, 
              let remainTimeText = FlashSaleManager.shared.formattedRemainTime(to: dueDateText) else { return }
        
        timeBadgeView.setTime(remainTimeText)
    }
}

타이머를 통해 1초마다 텍스트를 바꿔주면 된다.
유저가 화면 스크롤할 때도 텍스트가 바뀌도록 main run loop에서 timer가 실행되도록 설정했다.
서버에서 받은 할인종료 시점 saleDueDate을 위에서 만든 formattedRemainTime(to:)에 전달해서 남은 기간을 알아내고,
Label에 반영하면 끝이다.

다른 화면으로 이동했을 때 timer를 정지시키고, 다시 재진입했을 때 실행시키는 로직도 잊지 말고 넣어주자.

timerDelegate를 통해 viewController의 viewWillDisappear/viewWillAppear 시점에 timerStop/timerStart를 호출하도록 했다.

deinit { // view deinit 시점에 호출
    stopTimer()
}

func stopTimer() { // viewController viewWillDisappear 시점에 호출
    if let timer,
       timer.isValid {
        timer.invalidate()
    }
}

참고) 여기까지 따라왔다면 한 가지 의문이 들 수 있다.

'최초 한 번만 남은 시간을 계산하고, 이후에는 Timer로 -1초씩 해주면 되는 거 아닌가?'

그래서 찾아봤는데 카운트 다운할 때 Timer는 부정확하기 때문에 Date를 써야 한다고 한다.
SoF > Don't use NSTimer that way. NSTimer is normally used to fire a selector at some time interval. It isn't high precision (...)

GCD Timer 등 정확도 높은 timer를 만드는 방법도 찾았지만..

Apple Technical Note에서도 비용이 크고, 단 1개 timer만 정확도를 높일 수 있기 때문에 지양하는 방식이라고 명시하고 있어서 패스했다.

(정확도 높은 timer 만들려면 Real time thread라는 녀석한테 일을 시켜야 하는데, 이거 과부하되면 다 망한다는 내용.. 아마도..)

SoF > high precision timer

Apple/TN2169 > Don't use a high precision timer unless you really need it. They consume compute cycles and battery. There can only be a limited number of high precsion timers active at once.

Apple/Dispatch Source > Note that some latency is to be expected for all timers, even when a leeway value of zero is specified.

4. 추가적인 개선사항

1) Label 너비 고정시키기

이 상태로도 좋지만 개선점을 찾아낸 분들이 있을 것 같다.

개인적으로 숫자가 바뀔 때마다 Label 너비가 늘었다 줄었다하는 게... 눈에 너무 거슬렸다.

늘었다가 줄었다가 하는 Label

아래처럼 숫자마다 텍스트 너비가 다르기 때문에 발생하는 문제이다.

최대 8 / 최소 1

다른 앱을 벤치마킹해봤을 때

늘었다 줄었다하는 걸 그대로 내버려 둔 곳도 있었고, 너비에 고정값을 지정한 곳도 있었다.

이번 예시처럼 backgroundColor를 적용한 경우에는 너비를 고정하는 게 디자인상 깔끔하다고 판단해서

최대 너비를 지정하는 방법으로 개선해봤다.

// view 그릴 때
// ✅ 최대 너비인 숫자 텍스트를 활용
let maxWidthText = "88:48:48:48"
let fixedWidth = maxWidthText.width(font: .systemFont(ofSize: 13, weight: .bold)).ceiling(to: 0)

addSubview(timeLabel)
timeLabel.snp.makeConstraints { make in
    make.width.equalTo(fixedWidth)
}

// extension String
func width(font: UIFont) -> CGFloat {
    let fontAttributes = [NSAttributedString.Key.font: font]
    let size = self.size(withAttributes: fontAttributes)
    return size.width
}

숫자가 "88:48:48:48"일 때 텍스트 너비가 최대가 되기 때문에 이 값을 활용했다.
텍스트 중에는 88이 최대너비이고, 시간을 표현하는 숫자 중에서는 48이 가장 너비가 크므로
일에는 88, 시/분/초에는 각각 48을 넣어서 텍스트 너비를 구했다.

이제 아래처럼 깔끔하다.

너비 고정 버전

2) 시간 초과된 케이스 처리하기

그리고 현재 시각이 할인 종료기간을 초과했을 때 어떻게 대응할지 고려해보면 좋다.

회사마다 할인전을 운영하는 정책과도 연관이 있을 것이다.

아마 할인기간이 종료되면 해당 Unit이 노출되지 않도록 서버에서 처리하겠지만

서버에서 잘못 내려준다면 숫자에 -가 붙게 된다.

서버 고장났을 때

아래처럼 클라이언트 로직에도 방어코드를 추가하면 기부니가 조커든요. ☺️

방어코드 있을 때

위에서 만든 formattedRemainTime(to:) 메서드에서 isExpired 여부를 bool 타입으로 반환하도록 개선해주면 된다.

    func formattedRemainTime(to dateText: String) -> (Bool, String)? {
        guard let date2 = date(from: dateText) else { return nil }
        
        let date1 = Date()
        // ✅ 종료시점 초과 여부를 판단
        let isExpired = calendar.compare(date1, to: date2, toGranularity: .second) == .orderedDescending
        let countdownComponents = calendar.dateComponents([.day, .hour, .minute, .second], from: date1, to: date2)
        
        guard let days = countdownComponents.day,
              let hours = countdownComponents.hour,
              let minutes = countdownComponents.minute,
              let seconds = countdownComponents.second else { return nil }
        
        // ✅ 종료된 경우 보여줄 텍스트 지정
        let remainTimeText = isExpired ? "00:00:00:00" : String(format: "%02d:%02d:%02d:%02d", days, hours, minutes, seconds)
        
        return (isExpired, remainTimeText)
    }

그리고 formattedRemainTime(to:) 메서드를 호출하는 시점에서

isExpired인 경우 timer를 종료하도록 추가해주자.

private func changeTimeText() {
    // 서버에서 받은 종료시점 "2024-01-01T00:00:00+09:00"
    guard let dueDateText = viewModel.saleDueDate, 
          let remainTimeText = FlashSaleManager.shared.formattedRemainTime(to: dueDateText) else { return }

    timeBadgeView.setTime(remainTimeText)

    // ✅ isExpired 이면 타이머 종료
    if isExpired {
        stopTimer()
    } 
}

2개의 날짜를 비교하고, 원하는 형태로 formatting 하고

timer를 사용하여 Label을 업데이트하는 과정을 거쳐서 Countdown Timer를 만들어봤다.

이커머스 뿐만 아니라 헬스케어, 영상/오디오 컨텐츠 앱에도 활용해 볼 수 있다.

로직 자체는 복잡하지 않으니 여러 가지 다른 디자인으로 만들어보면 재미있다.

카운트 다운할 때 애니메이션 효과를 넣는 코드도 구경해보기를 추천한다.

GitHub > LTMorphingLabel (Custom Label 장인..)
Blog > NamS > CountDown Animation Label 구현

- Reference

Apple Developer Documentation > Calendar > compare(_:to:toGranularity:)
Apple Developer Documentation > Calendar > dateComponents(_:from:to:)
Apple Archive > Technical Note TN2169 / High Precision Timers in iOS / OS X
SoF > How can I make a countdown with NSTimer?
SoF > How to make a countdown to date
SoF > high precision timer
SoF > How do I achieve very accurate timing in Swift?
Blog > Build a count down timer with Swift 3.0

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[컨퍼런스] KWDC23 연사 참여 후기: 자료조사는 시작일 뿐

Applecider — Thu, 27 Jul 2023 00:59:52 +0900

최근 코엑스에서 1,300여 명이 참석한 국내 최대 규모의 애플 생태계 컨퍼런스 KWDC23가 개최됐다.

Apple WWDC의 공식 후속행사 (WWDC Extra Event)로 진행된 최초의 국내 행사였다.

이번에 감사하게도 좋은 기회가 주어져서 Localization을 주제로 발표를 했는데,

발표를 하게 된 계기와 발표과정에서 배운 것들을 남겨봤다.

나중에 발표를 준비하시는 분들에게 참고가 되었으면 한다.

1. 발표 계기

5월의 어느 날 KWDC 준비위원회로부터 스피커 제안을 받았다.

입사 후 10개월 간 글로벌 앱을 개발하면서 배운 게 정말 많았지만,

쪼렙 1년차 개발자인데.. 내 미천한 지식으로 발표를 해도 될까? 고민이 됐다.

그런데 제안서를 살펴보니

개발자뿐만 아니라 디자이너, 기획자 등 Apple 생태계의 구성원이 참여하는 행사이고,

기술/스킬에 포커스된 세션, 경험 공유 세션 등 발표 영역/주제가 다양하다는 것을 알게 되어 발표를 하기로 결심했다.

몇 가지 희망 발표 주제를 정해서 스피커 신청서를 제출했고,

며칠 뒤 준비위원회로부터 긍정적인 답변을 받았다.

아래는 당시의 내적 갈등

운좋게 발표할 기회가 오다니. 한번 해보자!

발표 망할거면 안 하는 게 낫다. 조용히 살려고 개발자로 전직한 거 아니었어?

만약 망하더라도 이번 발표를 통해 성장할 수 있을거야

컨퍼런스 처음인데 발표 망한 개발자로 낙인찍힐래?

발표 내용이 한 사람에게라도 도움이 된다면 뿌듯할 거야

글로벌 앱 만들려는 사람들은 이미 다 알고 있는 내용이지 않을까?

시간 많으니까 열심히 준비하면 돼

2. 준비과정

발표 주제 탐색

글로벌 프로젝트를 하면서 많은 걸 경험했었다.

처음에는 채팅 기능을 개발하면서 배웠던 Up scroll pagination, 소켓 통신 등을 다루려고 했다.

그런데 관련 내용이 WWDC23에서 거의 언급되지 않았다.

(KWDC23이라는 네이밍에 걸맞게 WWDC23의 내용을 커버해야 한다는 조건이 있었다.)

그래서 결국 Localization으로 주제를 정했다.

글로벌 앱을 개발하면서 가장 심혈을 기울였던 부분은 아래와 같았다.

사용자의 Locale 및 TimeZone에 맞게 서비스 (배송가능 상품, 배송비 등)와 데이터 (날짜/시간, 번역어 등)를 제공하고,

Locale에 따라 변경이 잦은 데이터를 Server-driven으로 관리하고,
사용자의 Region은 싱가포르이지만, 베트남 친구에게 선물을 보내는 케이스에 대응하는 등등
그래서 처음에는 개발자를 타겟으로 글로벌 비즈니스에서 발생할 수 있는 문제 상황과 해결 방법을 소개하려고 계획했다.

고민한 점

그런데 예상과 달리...

WWDC 20-23을 공부해 보니 Localization 관련 기술들이 너무 다양했고,

프로젝트에 활용한 건 아주 일부였음을 알게 됐다.

그리고 해당 기술을 설명하기 위해서는 여러 언어에 대한 배경지식이 필요했다.

예를 들어 WWDC23 (Unlock the power of grammatical agreement)에서 Term of address라는 개념이 언급됐는데,

스페인어처럼 성별을 구분하는 언어에 대한 이해도가 약간 있어야 했고,

WWDC21 (What’s new in Foundation)을 봐야 왜 Automatic grammar agreement API가 도입됐는지 제대로 이해할 수 있었다.

또 마찬가지로 애플이 왜 stringdict 파일을 만들었는지, Pluralization이 뭔지 설명하려면

우크라이나어의 특성을 이해해야 했다.

이런 게 한두 가지가 아니었다. 기절할 만큼 많았다. ㅇ<-<

자료조사하면서 올렸던 인스타 스토리

그래서...

Localization을 처음 접해본 사람도 알아들을 수 있는 수준으로 타겟을 변경했고,

이 발표를 보고 난 뒤에 WWDC를 들었을 때 쉽게 이해할 수 있도록 도움을 주는 것을 목표로 삼게 됐다.

그래서 발표 초반부에 Locale, TimeZone, Calendar에 대한 기초적인 개념 설명을 추가하게 됐다.

7월 초에는 온라인 리허설을 진행했는데

KWDC 준비위원회분들이 구체적이고 따뜻한 피드백을 주셔서 멘탈 관리에 큰 힘이 됐다. ㅎㅎ

그렇게 탄생한 발표 목차

Localization 발표 목차

그리고 발표 제목은 글로벌 앱을 위한 Localization이었는데

다른 연사자분들이 제목을 힙하게 지으시길래 ㅎㅎ

뒤에 부제를 덧붙여서 어그로를 끌어봤다.

그렇게 탄생한 발표 제목

Localization 발표 제목

후회하는 점

발표를 끝낸 시점에서 아쉬움이 남는 건 자료 조사에 너무 많은 시간을 쏟았다는 것이다.

초반에는 개발자를 타겟으로 했기 때문에 기술적인 내용을 철저히 준비하려 했고

Localization과 관련된 거라면 뭐든 탈탈 털어서 거의 모든 걸 다 봤다.

WWDC20/21/22/23 15편 이상, 관련 공식문서를 전부 (Archive까지 싹 다)... 봤다.

주말과 저녁시간을 모두 발표 준비에 쏟을 수밖에 없었다.

참고자료의 일부...

발표 방향을 제대로 설정한 뒤에 자료 조사를 했으면 좋았을 텐데

중간에 방향을 한 번 틀게 되면서 후반부에 시간이 좀 부족했다.

결과적으로 준비했던 기술적인 내용의 25% 정도 밖에 발표자료에 담지 못했다.

시간이 더 있었다면... 내용 구성 자체를 더 고민해보거나, 글로벌 앱 사례를 보완할 수 있었을 것 같다.

3. D-1 리허설

발표 전 날에는 코엑스에 가서 현장 리허설을 했다.

강당 규모가 가장 컸던 명동 홀에서 연습을 했는데, 상상했던 것과 분위기가 달라서 긴장됐다.

강렬한 핀 조명을 받으니 눈이 부셔서 객석이 잘 안보였고... 그래서 오히려 좋기도 했다. (?)

아렉스가 찍어주신 리허설 현장

4. D-DAY

발표 시간은 오전 11시였는데, 그래서 정말 다행이었다고 생각한다.

긴장되는 건 빨리 끝내는 게 좋다.

리허설을 할 때까지도 '국내에 글로벌 비즈니스를 하려는 회사가 많지 않을텐데 몇 명 안 오면 어쩌지?' 하며 전전긍긍했는데

그런 걱정이 무색하게 현장의 열기는 뜨거웠다.

발표 20분 전부터 강당 앞에 줄을 서는 분들이 생겼고, 발표를 시작할 때 이미 객석이 꽉 차있었다.

이때부터 긴장이 엄청 되기 시작했고, 연습한 대로만 하자고 다짐을 했다.

근데 강단에 섰을 때 머리가 하얘져서 KWDC23 연사자로 참여하게 되어 영광이고 감사하다는 인사말도 빼먹어버렸다. <-<

발표를 시작한 뒤에는 스크린에 띄운 발표자료를 핸드폰으로 촬영하는 분들이 꽤 보여서

'이걸 왜 찍으시지? 이 내용이 도움이 되긴 하는구나?' 싶어서 긴장이 풀렸다.

핀 조명에 사라진 이목구비 / 전리품

발표를 끝낸 뒤에는 부트캠프 동기들, 일하며 알게 된 분들, 선생님들을 만나며 반갑고 기쁜 시간을 보냈다.

특히 연사자 대기실에서 평소 팬이었던 멋진 블로거분들을 많이 뵈었는데

연예인 목격한 것처럼 설레고 신기했고 ㅎㅎ 이번 기회로 함께 할 수 있어서 즐거웠다.

행사장에서 마주쳤을 때 내 블로그 글을 잘 읽고 있다고..! 얘기해주는 분들이 계셔서 약간 부끄럽고 많이 뿌듯했다.

하지만 슈퍼파워 I인 나는 너무 많은 사람을 한꺼번에 보게 되어 정신이 없었다.

진이 빠져서 부스를 한 군데도 못 갔고, 발표자 뒤풀이에도 참석하지 못해서 아쉬움이 남는다. ㅎㅎ

5. Thanks to

이 자리를 빌어 고마움을 전하고 싶은 분들이 있다.

우선 시간을 내어 발표를 들으러 와주신 분들께 정말 감사드리고, 발표 내용이 조금이나마 도움이 되었으면 좋겠다고 바라본다.

먼저 예거와 호댕, 작고 소중한 주말시간을 내서 꼼꼼히 발표 피드백을 해주셨고, 자료를 갈아엎으며 방황할 때 많은 도움을 주셨다.

예거는 키노트 전문가여서 애니메이션 특강까지 해주셔서 큰 도움이 됐다.

이외에도 행사장에서 만나거나 따로 연락해서 응원해준 부캠 동기들 덕분에 뭉클했고 많은 힘을 받았다.

야곰아카데미에서 만난 소중한 인연 절대 지켜

또 소들님 (갑자기 소환해서 죄송해요)도 발표자료 피드백을 해주셨는데, 고민하고 있던 부분을 콕 집어 의견을 주셔서 정말 감사했다.

심지어 초면인 상태에서 ㅠㅠ 피드백 요청을 드렸는데 장문의 의견을 주셔서 정말 무한 감동이었다...

그리고 발표자료에 아이디어스 글로벌 앱 사례를 어떻게 녹일지 함께 고민해 주신 셀 리더님,

휴가 중에 말없이 행사장에 와서 발표를 들으시고, 주변에서 들은 호평을 전해주며 응원해주신 전-셀 리더님,

예상 못했는데 맨 앞줄에 ㅋㅋㅋ 달려와 앉아서 발표 내내 큰 대답과 호응을 해준 따뜻하고 든든한 우리 iOS셀원들,

공부하느라 바쁜 시기에 초대에 응해주고 맨 앞에서 응원해준 빠키,

큰 규모의 애플 생태계 컨퍼런스를 만들기 위해 본업과 병행해서 몇 달 동안 고생하신

다른 모든 스피커분들과 준비위원회, 자원봉사자분들께도 정말 감사하고 함께 할 수 있어서 영광이었다는 말씀을 전하고 싶다.

마지막으로 이 모든 것을 가능하게 해준..

애플 생태계에 발들일 수 있도록 노베이스 비전공자를 iOS 개발자로 키워주신 야곰에게 다시 무한히 감사함을 느꼈다.

준비과정이 수월하지만은 않아서 멘탈이 나갈 때도 있었지만

그럼에도 불구하고 발표하기로 한 건 잘한 선택이었다.

특정 일자에 특정 지식을 공유한다는 명확한 목표가 있어서 스터디를 하는데 제대로 동기부여가 됐기 때문이다.

그리고 무엇보다, 부족한 점이 많은 발표였음에도 발표를 들어주신 분들의 지지와 응원을 들을 수 있어서 좋았다.

(힘들게 얻은 러닝을 열정적으로 공유하려고 하는 개발자 생태계가 아직도 신기하다.)

발표를 준비하며 정리한 자료와 QnA 내용은 블로그에 천천히 포스팅할 계획이다.

- Reference

KWDC23 공식 웹
Apple - WWDC Extra Event
Apple - WWDC23 > Unlock the power of grammatical agreement
Apple - WWDC21 > What’s new in Foundation

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[디자인 패턴] Prototype - 의존성 없이 객체를 복사할 때

Applecider — Sun, 16 Jul 2023 21:42:35 +0900

GoF 디자인 패턴 중 하나인 Prototype 패턴을 정리했다.

- Ref : 도서 <Dive into Design Patterns>, Alexander Shvets 저

문제 상황

객체 A가 있고, 해당 객체의 복사본을 만들고 싶은 상황이다.
이때 새로운 객체 인스턴스를 생성하고, 원본 (객체 A)의 프로퍼티 값들을 새 객체에 모두 복사하는 방법이 있다.
문제점 : 객체의 프로퍼티 중 일부가 비공개라면 외부에서 접근할 수 없다. 또한 복사하려면 원본을 알아야 하므로 해당 객체에 대한 의존성이 생긴다.

패턴 설명

요약 : 의존성 없이 객체를 복사하는 생성 패턴이다.
Prototype = 시제품, 시험용으로 만들어 본 샘플 제품
- 실제 산업의 프로토타입 : 대량 생산 이전에 테스트용으로 만드는 샘플 제품
- 프로그래밍의 프로토타입 : 세포 분열과 비슷함. ‘원본 세포’는 복사본을 만들어내기 위한 ‘프로토타입 역할’을 함
복제를 지원하는 객체를 ‘프로토타입’이라고 부른다.
- 매번 객체를 처음부터 새로 만들지 않는다.
- ‘복제되는 객체’에게 복제 프로세스를 위임한다. (설정값을 지정하여 미리 만들어둔 프로토타입을 복제해서 쓴다.)

Prototype Protocol : clone 메서드를 정의한다. (반환타입은 Prototype Protocol 자기 자신이다.)
ConcretePrototype : clone 메서드를 구현한다. (원본 객체의 프로퍼티값을 복사한다.)
Client : Prototype Protocol을 채택한 모든 객체의 복사본을 생성 가능하다.

예시 코드

// MARK: - Prototype Protocol
protocol Prototype {
    init(prototype: Self)
}
extension Prototype {
    func clone() -> Self {
        return type(of: self).init(prototype: self)
    }
}

// MARK: - Concrete Prototype
class ConcretePrototype1: Prototype {
    var name: String
    var weight: Double
    
    init(name: String, weight: Double) {
        self.name = name
        self.weight = weight
    }
    
    required convenience init(prototype: ConcretePrototype1) {
        self.init(name: prototype.name, weight: prototype.weight)
    }

    func printStatus() {
        print("ConcretePrototype1 - name \(name) / weight \(weight)")
    }
}

class ConcretePrototype2: Prototype {
    var name: String
    var weight: Double
    
    init(name: String, weight: Double) {
        self.name = name
        self.weight = weight
    }
    
    required convenience init(prototype: ConcretePrototype2) {
        self.init(name: prototype.name, weight: prototype.weight)
    }

    func printStatus() {
        print("ConcretePrototype2 - name \(name) / weight \(weight)")
    }
}

// MARK: - Client
class Client {
    func main() {
        let concrete1 = ConcretePrototype1(name: "con1", weight: 1.0)
        let concrete2 = ConcretePrototype2(name: "con2", weight: 2.0)
        
        print("Original")
        concrete1.printStatus()
        concrete2.printStatus()
        
        let copied1 = concrete1.clone() // 완전히 새로운 객체 (원본의 참조가 복사된 게 아님)
        let copied2 = concrete2.clone()
        
        print("Clone")
        copied1.printStatus()
        copied2.printStatus()
        
        print("---")
        copied1.weight += 10.0  // 원본에 영향을 미치지 않음
        concrete1.printStatus() // 1
        copied1.printStatus()   // 11
    }
}

//Original
//ConcretePrototype1 - name con1 / weight 1.0
//ConcretePrototype2 - name con2 / weight 2.0

//Clone
//ConcretePrototype1 - name con1 / weight 1.0
//ConcretePrototype2 - name con2 / weight 2.0
//---
//ConcretePrototype1 - name con1 / weight 1.0
//ConcretePrototype1 - name con1 / weight 11.0

장점

복사할 객체에 대한 의존성을 없앤다.
중복되는 initializer 코드를 제거할 수 있다. (만들어 둔 프로토타입을 복제해서 쓰면 되므로)
복잡한 객체를 쉽게 생성한다.
복잡한 객체에 대한 설정값을 처리할 때 상속 대신 사용 가능한 방법이다.

단점

순환 참조를 하는 복잡한 객체를 복제하는 것은 어려울 수 있다.

- Reference

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[디자인 패턴] Command - 실행할 작업을 덩어리로 관리할 때

Applecider — Sun, 2 Jul 2023 22:51:59 +0900

GoF 디자인 패턴 중 하나인 Command 패턴을 정리했다.

- Ref : 도서 <Dive into Design Patterns>, Alexander Shvets 저

문제 상황

Text Editor 프로그램을 개발하는 중이며, 텍스트를 저장할 Save Button을 만들었다.
Button을 상속받아 자식클래스로 Save Button을 구현한 뒤, save 기능을 추가했다.
그런데 Save Button 뿐만 아니라 Ctrl+C 단축키로도 복사를 하고 싶고,
텍스트와 서식을 동시에 복사할 Super Save Button을 추가하고 싶어졌다.
기존 방식으로 하면 버튼/단축키에 중복 코드가 생기고, 자식클래스 종류가 너무 많아질 수 있다는 문제점이 있다.

패턴 설명

Command의 사전적 정의는 “명령, 명령어”이다.
Command 패턴에서는 실행할 작업을 캡슐화하여 하나의 덩어리로 취급한다.
즉, 실행할 명령 (ex. SaveCommand)을 별도 타입으로 정의해 두고,
필요한 곳 (ex. SaveButton, SaveShortcut)에 해당 명령 덩어리를 주입시켜서 활용한다.
관심사 분리의 원칙에 따라 UI 로직과 비즈니스 로직을 분리하는게 좋다.
Command 객체는 UI 객체와 비즈니스 로직 객체 사이의 연결고리 역할을 한다.
덕분에 UI 객체가 비즈니스 로직에게 직접 작업을 요청하지 않는다.
Command 패턴은 아래 5가지 역할로 구성된다.
언뜻 복잡해보이지만 예시코드를 먼저 보면 쉽게 이해할 수 있다.

Command 패턴의 구조

Invoker (발송자) : 커맨드에게 일을 시킨다. 커맨드 객체의 참조를 저장할 프로퍼티를 가진다.
Command 인터페이스 : 단일 메서드 execute()를 선언한다.
Concrete Command : 일을 구현한다. Concrete Command를 초기화할 때,
Receiver 자체 (또는 Receiver의 메서드를 실행하는 데 필요한 매개변수)를 전달받아 프로퍼티로 가진다.
Receiver (수신자) : 실제로 작업이 실행되는 곳이다.
Client : Concrete Command를 초기화한다.

예시 코드

// Command
protocol Command {
    func execute()
}

// Concrete Command
class SaveCommand: Command {
    var textEditor: TextEditor
    
    init(textEditor: TextEditor) {
        self.textEditor = textEditor
    }
    
    func execute() {
        // 복사 기능을 구현
        let currentText = textEditor.text
        textEditor.clipboard = currentText
        print("Text Copied!")
    }
}

// Invoker - 커맨드에게 일을 시킴
class SaveButton {
    var command: Command? // 커맨드를 저장
    
    func setCommand(_ command: Command) {
        self.command = command
    }
    
    func executeCommand() {
        command?.execute()
    }
}
class SaveShortcut {
    var command: Command?

    func setCommand(_ command: Command) {
        self.command = command
    }

    func executeCommand() {
        command?.execute()
    }
}

// Receiver - 실제로 작업이 실행되는 곳
class TextEditor {
    // 가정 : 복사 기능이 실행되면 -> text를 clipboard에 저장함
    var text: String = ""
    var clipboard: String = ""
}

// Client
let textEditor = TextEditor() // receiver

let saveCommand = SaveCommand(textEditor: textEditor)

let saveButton = SaveButton() // invoker-1
saveButton.setCommand(saveCommand)
saveButton.executeCommand() // Text Copied! 출력

let saveShortcut = SaveShortcut() // invoker-2
saveShortcut.setCommand(saveCommand) // 재사용 가능
saveShortcut.executeCommand() // Text Copied! 출력

장점

단일책임 원칙을 준수한다. Receiver (TextEditor)와 Invoker (SaveButton)의 결합도가 줄어든다.
개방폐쇄 원칙을 준수한다. client 코드를 변경하지 않고도 새로운 Command를 추가할 수 있다.
Redo/Undo 기능, 작업 예약 기능을 쉽게 구현할 수 있다.
- SaveCommand 외에도 PasteCommand, WriteCommand 등을 만들고,
  작업을 실행할 때마다 Command Stack에 쌓아서 히스토리를 관리하면 된다.
- 일부 데이터의 접근이 제한된 경우 (private) Memento 패턴으로 대체 가능하다.
간단한 Command를 조합해서 복잡한 Command를 만들어낼 수 있다.

단점

코드 복잡도가 높아진다.

- Reference

도서 <Dive into Design Patterns>, Alexander Shvets 저

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[toss] iOS 개발자를 위한 SLASH23 리뷰

Applecider — Sun, 18 Jun 2023 23:57:26 +0900

toss의 디자인 컨퍼런스 SIMPLICITY23에 이어 개발자 컨퍼런스 SLASH23가 진행됐다.

SLASH23은 토스 개발자들의 기술적 고민과 성취를 공유하는 자리이며, 총 24개 세션으로 구성되어 있다.

그중 클라이언트 개발자가 눈여겨 봐야 할 세션은 3가지가 있다.

클라이언트 관련 세션 - SLASH23

1. Rally로 3분 만에 애니메이션 완성하기
2. 레고처럼 조립하는 토스 앱
3. 누구나 쓸 수 있는 접근성 높은 토스 만들기

하나씩 간단히 정리해 봤다.

나중에 언젠가... 시간이 나면 다른 세션도 정리해보고 싶다.

1. Rally로 3분 만에 애니메이션 완성하기

저번에 포스팅했던 SIMPLICITY23 리뷰에서

첫 번째로 다뤘던 인터렉션, 꼭 넣어야 해요? 세션과 연결되는 내용이다.

사실 대부분의 내용을 SIMPLICITY23에서 다뤘기에 크게 새로운 정보는 없었다.

디자이너 세션을 안 본 분들을 위해 요약하자면,

배경 : 제품에 인터렉션을 추가하면서 생겨난 커뮤니케이션 비용을 줄이기 위해
Andriod/iOS/Web에서 동일한 개발 언어와 로직을 사용하는 Rally라는 애니메이션 라이브러리를 만들게 됐다.
작업 방법 : 디자이너가 프레이머로 인터랙션 컴포넌트를 사용해서 Motion을 만들면,
프레이머 inspect에서 Rally 코드를 확인할 수 있다.

개발자 관점에서 와닿았던 내용은 이랬다.

화면의 여러 UI가 유기적으로 움직이는 애니메이션은 개발 난이도가 높고, 가독성이 낮으므로 유지보수 비용이 증가한다.

애니메이션을 관리하려면 애니메이션을 자유롭게 컨트롤할 수 있어야 한다.

예를 들면 애니메이션의 재생/역재생, 일시정지, 특정 시점으로 이동 등이 간편해야 한다.

이 부분이 대부분의 회사에서 마주하는 가장 큰 허들인 것 같다.

애니메이션 다루기 - SLASH23

Rally는 pseudo code 형태로 소통하고, 개발 시에는 각 플랫폼별 언어로 번역해서 사용한다고 한다.

Rally 예시 - SLASH23

Rally는 이렇게 구성된다.

먼저 Easing (값이 시간에 따라 어떻게 변화할지)을 바탕으로 Rally의 최소 단위인 Motion (어떻게 움직일지)을 만들고,
재생의 최소 단위인 Rally를 통해 애니메이션을 적용할 target에 연결한 뒤,
Timeline을 통해 여러 개의 Rally를 스케줄링하는 구조이다.
자주 쓰는 설정값을 모아둔 프리셋도 있다.
애니메이션을 컨트롤하기 위한 API (play, backward.play 등)도 정의되어 있다.

이러한 Rally의 구성요소는 아래처럼 저번 세션에 더 명확히 정리되어 있다.

Rally 구성요소 - SIMPLICITY23

인터렉션 디자인 시스템이 있다는 것만으로 놀라운데, 크로스 플랫폼 inspect 기능까지 있다니 너무 멋지다...

(근데 하나만 봐야 한다면 설명이 더 짜임새 있는 SIMPLICITY23의 세션을 보는 것을 추천한다.)

*SIMPLICITY23의 해당 세션 내용이 궁금하다면?
[toss] SIMPLICITY23 리뷰 > #1. 인터렉션 꼭 넣어야 해요?

2. 레고처럼 조립하는 토스 앱

레고라는 단어를 보자마자 'RIBs' 얘기를 하겠구나! 직감했다.

근데 아니었음...

문제상황

앱의 규모가 커지면 모듈 분리 (앱을 여러 모듈로 나누고, 모듈 간의 구조를 설계하는 작업)이 중요하다.

기존에는 아래처럼 기능별 Layer로 분리되어 있었다.

Feature Layer의 모듈은 각자 하위 의 Service Layer 모듈만을 의존하게 된다.

기존 - 기능별 Layer로 분리됨

하지만 토스에 여러 기능이 추가되면서 Feature Layer에 많은 모듈이 생기고,

모듈 간의 의존성이 복잡해지는 문제가 발생했다.

빌드 속도가 느려지고, 순환 참조가 자주 발생하기도 했다.

예를 들어 홈에서 사용자를 인증하기 위해 홈 Feature가 인증 Feature를 의존하게 되어

동일한 Layer의 모듈 간 의존 관계가 꼬이게 된 것이다.

따라서 홈 Feature 및 인증 Feature를 사용하는 홈 인증 Service를 따로 만들고,

두 Feature가 홈 인증 Service를 의존하도록 개선했지만...

또 다시 이로 인해 지나치게 많은 Layer가 생기는 문제가 있었다.

Feature Layer에 여전히 존재하는 의존성 문제

Microfeatures Architecture로의 전환

결론적으로 Tuist에서 제작한 모듈 구조인 Microfeatures Architecture를 도입했다.

모듈의 역할과 상호 관계는 아래와 같다.

Microfeatures Architecture의 구조 / 모듈 간 관계

Feature : 실제 기능을 구현한 모듈
Interface : feature 기능 중 외부에 공개할 interface
Testing : interface 모듈의 Mocking을 제공
Tests : unit test
Example : 기능을 테스트할 수 있는 작은 단위의 앱 target (빠르게 일부만 빌드/배포 가능)

전체 코드에 대해 새로운 Architecture로 전환하는 과정에서 작업량에 대한 부담과 수많은 conflict이 걸림돌이 됐다고 한다.

따라서 반복 작업은 Tuist의 Template/Scaffold 기능을 활용했고 (template으로 쉽게 모듈을 생성),

iOS 전체 인원이 전환 작업에 대한 필요성을 공감하고 적극적으로 참여할 수 있도록 했다고 한다.

Microfeatures Architecture의 장점

기자에서 개발자로 커리어를 전환한 과정을 담은 글 '노베이스에서 토스 합격까지'로 유명한

송범근님의 장점 소개가 이어졌다. 흥미진진

토스 앱은 거대하지만, 피처를 개발할 때는 마치 작은 앱을 만드는 것처럼 작업이 가능하다고 한다.

각 피처별 Example 앱을 예로 들자면,

첫째, Example 앱을 통해 특정 기능의 결과 케이스를 모두 확인 가능하다.

개인적으로 담당한 피처에 대해 스스로 개발자 테스트를 할 때,

Charles의 Map local, Rewrite 기능을 활용해서 모든 성공/실패 케이스를 Mock 데이터를 적용해 확인해야 했는데

이렇게 결과 케이스를 모두를 한눈에 확인 가능하다니 너무 유용할 것 같다..!

둘째, Example 앱은 작은 앱 target 형태로 만들어지는데, 빌드 시간이 짧아서 개발 생산성을 높일 수 있다.

예를 들어 송금 Example 앱을 만든다면

레고를 조립하듯이 송금 Feature/Interface, 인증 Interface/Testing 등 필요한 부분만 가져와서 쓰면 된다.

이때 인증 Testing에는 Mock 데이터가 들어있어서

실제 인증 절차를 거치지 않고 가볍게 결과물을 확인 가능하다.

송금 Example 앱의 예시

셋째, Example 앱을 내부 배포할 수 있어서 디자이너, QA와의 협업 효율이 향상됐다고 한다.

Example 앱만 봐도 이렇게 많은 장점이 있다니 놀라웠다.

Tuist도 듣기만 하고 실제 써보지 않았는데,

당장 전체 프로젝트를 개선하지는 못하더라도 하나씩 공부하며 부분 적용해 보자는 목표가 생겼다.

3. 누구나 쓸 수 있는 접근성 높은 토스 만들기

토스가 모바일 접근성에 진심인 이유는?라는 글로도 문서화되어 있다.

접근성을 신경 쓰게 된 계기

토스의 사용자가 늘어나며 접근성 개선에 대한 사용자의 건의가 지속적으로 발생했는데,

UX를 개선하고, 개발 생산성을 높이기 위해 TDS (toss Design System) 차원에서 대응하기로 결정했다고 한다.

웹페이지 메인 - toss

큰 글씨 모드 대응

가장 먼저 작업한 것은 큰 글씨 모드 대응이었다.

기존에 개발 난이도를 낮추기 위해 사용했던 numberOfLines = 1을 해제하여

큰 글씨 모드일 때 버튼의 title text, 목록 항목의 cell title text가 잘리지 않도록 방지했고,

UI 요소를 재배치하여 컨텐츠가 들어갈 공간을 확보했다.

numberOfLines 개선 전 -> 후

Tab Bar처럼 공간이 한정되어 있어 Layout 배치 변경이 어렵다면

말 줄임 (truncatingTail) 로직을 유지한 채, 특정 항목을 탭하면 Bottom Sheet를 띄워 추가 정보를 제공하는 방법으로 해결했다고 한다.

Bottom Sheet로 해결

또한 가독성을 위해 의도적으로 개행 (줄 바꿈)을 넣고 있는데

1.3배 등 특정 글자 크기에서 개행이 오히려 가독성을 떨어트리는 경우가 발생했다.

이 경우에는 개행 문자 ("\n")를 공백 ("")으로 대체하여 개행이 되지 않게 수정했다고 한다.

개행을 공백으로 개선 전 -> 후

스크린 리더 (Voice Over)

그다음은 Voice Over (안드로이드의 Talk Back) 기능이다.

아래의 2가지 개념이 있다.

대체 텍스트 : 이미지 등 시각 자료에 대한 추가 정보를 줌
초점 : UI를 포커싱함 (Voice Over를 시작하면 Voice로 읽히는 영역이 차례로 하나씩 포커싱됨)

Voice Over 기능을 별도로 구현하지 않는다면,

시스템은 자동으로 위에서 아래, 왼쪽에서 오른쪽 방향으로 초점을 이동시키는데

이때 약관 list에서 아래와 같은 문제가 발생한다.

체크 버튼이 어떤 항목에 대한 것인지, 화살표 버튼이 어떤 동작을 하는 것인지 Voice만으로는 알 수가 없는 것이다.

대체 텍스트 및 초점 개선 전 -> 후

부트캠프 시절에는 야곰의 가르침을 따라 Accessibility에 대해 심층적으로 공부했었다.

큰 글씨 모드 (Larger Text)에서 StackView axis를 horizontal에서 vertical로 바꾸어 label 배치를 dynamic하게 조정하고,

VoiceOver까지 구현하는 등 실제 프로젝트에 적용해봤었다.

하지만 실무에 와서는 전혀 신경쓰지 못하고 있었다...

Accessibility의 중요성은 알지만 비즈니스 임팩트가 큰 작업을 우선시하다보니

VoiceOver는 커녕 Dynamic Font, 다크 모드, 가로 모드 등 기초적인 기능도 포기하고 있었다.

그런데 주 1회 배포를 하며, 빠르게 피처를 만드는 토스에서 Accessibility를 챙긴다니 놀라웠다.

결론 : 건강하고 빠릿한 조직

Slash의 여러 세션에서 공통적으로 느꼈던 부분인데

토스는 구성원이 문제 의식에 공감한다면 빠르게 실행으로 이어지는 좋은 문화를 가진 것 같다.

이런 조직적인 행동력이 정말 정말 부럽다...

이처럼 똑똑하고 실행력 있는 개발자들의 고민과 문제해결 사례가 궁금하다면

toss의 SLASH23 세션을 가볍게 들어보는 것을 추천한다!

번외

왜 컨퍼런스 이름을 Slash로 네이밍했을까 궁금증이 들어서 ChatGPT한테 물어봤다.

답변이 그럴싸했다.

SLASH 네이밍의 비밀 - ChatGPT

- Reference

지난 글
- [toss] SIMPLICITY23 리뷰 - 프로덕트 디자이너의 고민 엿보기
toss > SLASH23
Tuist.io
toss feed > 토스가 모바일 접근성에 진심인 이유는?
Blog > '노베이스에서 토스 합격까지'

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[toss] iOS 개발자를 위한 SIMPLICITY23 리뷰 - 디자이너와 친해지기

Applecider — Sun, 4 Jun 2023 23:56:12 +0900

toss SIMPLICITY23의 세션을 온라인으로 구경하고 재밌었던 4개 세션을 가져와 봤다.

SIMPLICITY23은 토스의 2023년 디자인 컨퍼런스이다.

토스가 UX 기획에 가장 중요하게 생각하는 원칙인 단순함 (Simplicity)을 따서 네이밍했다고 한다.

크게 5개 카테고리, 총 23개 세션으로 구성되어 있다.

SIMPLICITY23 - toss

개발자가 디자인 컨퍼런스에 왜 참여해야 할까?

디자인팀의 경험과 노하우를 공유하는 자리인데, 개발자가 참여할 필요가 있을까?

개인적으로 개발자는 디자이너와 긴밀하게 협업하는 위치이므로

디자이너가 마주하는 어려움과 고민을 이해하는 것이 중요하다고 생각한다.

그리고 주로 프로덕트 디자이너에 대한 이야기지만 개발자에게도 도움되는 내용도 많다.

장애물을 만났을 때 어떤 마인드셋을 가졌는지, 문제해결을 위해 구성원을 어떻게 설득했는지 등

일잘러의 태도도 살펴볼 수 있어서 좋았다.

소감부터 먼저 말하자면

토스의 저 세상 문화

처음에는 사실 이런 의문을 가졌다.

'토스가 애플도 아닌데 왜 이런 세션을 열까? 왜 토스만의 고급 정보를 굳이 공개할까?'

그런데 세션을 보고 나니 알겠다.

토스에서 토스 문화를 누리면서 일해보고 싶다는 강력한 동기부여를 받았다.

"문화가 복지다. 유능한 동료가 복지다."라는 말이 잘 맞는 회사인 것 같다.

이렇게 회사 내부적인 이야기를 밖에다가 해도 되나 싶을 정도로

구체적인 문제해결 사례와 토스만의 디자인 원칙을 볼 수 있어서 좋았다.

심지어 성공 사례뿐만 아니라 실패 사례까지 들을 수 있었는데, 실패를 허용하고 적극적으로 시도하는 문화가 정말 좋아 보였다.

혁신 그 잡채

게다가 컨퍼런스의 내용도 좋았지만, 형식 자체도 혁신적이었다.

세션은 디자이너를 인터뷰하는 방식으로 진행되는데

유튜브의 수많은 인터뷰 영상처럼 두 사람을 투 샷으로 잡고, 아래에 자막을 까는 식으로 만든 게 아니라

둘의 대화를 interactive 자막으로 보여주는 팟캐스트 형태로 진행됐는데

내용에 몰입하기 좋았고, 모바일 화면도 같이 나와서 쉽게 이해할 수 있었다. 기획자 천재 아닌가?

팟캐스트 형식 - SIMPLICITY23

"프로젝트를 마친 시점에서 과거의 자신에게 조언을 해준다면?"이라는 질문도 신선했다.

1. 인터렉션, 꼭 넣어야 해요?

문제상황

제품에 인터렉션을 넣으면 UX가 좋아진다는 건 모두 알지만, 구현 비용 때문에 엄두가 나지 않는 게 현실이다.

토스도 인터렉션 디자이너팀은 사실상 작년에 만들어졌고, 대부분의 화면이 정적이다 보니

"구현이 어렵다, 모션이 개발 공수 대비 임팩트가 없을 것 같다"... 등의 부정적인 인식이 많았다고 한다.

*인터렉션 디자인이 궁금하다면?

toss 블로그에 모션, 금융을 즐겁고 쉬운 경험으로 만드는 방법 포스팅으로 구체적인 내용을 더 읽을 수 있다.

해결방법

인터렉션은 단순히 심미적인 기능 (예뻐 보이기만 하는 것!) 뿐만 아니라

애플/구글의 디자인처럼 사용자에게 더 명확한 피드백을 줄 수 있다는 장점이 있는데,

이것을 디자이너가 구성원들에게 적극 어필했다.

첫째로 인터렉션으로 지표를 개선하는 사례를 만들었고, 실제로 이탈률이 감소한 것을 확인했다.

그리고 앱 전체에 영향을 미치는 기능인 버튼의 터치 이펙트를 다듬었다.

예를 들어 버튼이 눌리는 느낌이 나도록 모션을 만든 것이다.

둘째로 공수를 최소화했다.

실제 CollectionView에 모션을 주는 게 아니라 CollectionView 위에 새 레이어를 올리고 모션을 적용해서 한 화면인 것처럼

눈속임 모션으로 공수를 줄였다.

인터뷰이가 안드로이드의 Material 가이드 (= iOS의 HIG 같은 문서)를 통해 이런 아이디어를 생각하게 됐다는 계기까지 공유해 주셨다. 천재인데 천사임...

안드로이드 쪽에는 관심이 없었는데 나중에 Material 가이드와 HIG를 비교하는 글을 써보면 재밌을 것 같다.

그다음 인터렉션을 재사용하여 공수를 줄였다.

여기서 놀라운 점은 '디자인 시스템'과 비슷하게 '인터렉션 시스템'을 만들었다는 것이다. 진짜 대단하다...

간지 그 잡채, 인터렉션 시스템 - toss

근데 또 여기서 문제는 iOS, 안드로이드, 웹의 용어나 동작 방식이 모두 달랐던 것이다.

그래서 각 플랫폼별 담당자가 모두 모여서 플랫폼 공통 스펙을 만들었다.

복잡한 모션을 표현할 수 있는 공통의 언어를 만든 것이다.

결론적으로 개발자와 디자이너 모두 편해졌다고 한다.

Figma에서 inspect를 열면 바로 Rally 코드를 확인 가능하다. 그저 놀랍다... 사실 이거보고 우리회사는 못쓰겠구나 싶었다.

회사의 디자이너분에게 건너들었는데,

토스는 디자인툴로 Figma 대신, 코드 기반의 Framer라는 프로그램을 쓴다고 한다.

커뮤니케이션 측면에서 배운 점

인터렉션 시스템을 빠르게 전파시 킨 비결도 있다.

슬랙에 #animate-noti라는 모니터링 채널을 만들어서

다른 구성원들이 인터렉션, 모션, 랠리 관련 단어를 언급할 때 자동으로 알림이 오도록 하고

스레드에 찾아가서 Rally 코드를 쓰면 된다고 직접 안내했다고 한다.

2. 크고 복잡한 제품 과감하게 갈아엎기

문제상황

기존의 '내 문서함' 기능에 너무 특성이 다른 기능 (ex. 주민등본 발급, 관리비 납부, 세금 납부, 건강검진 안내 등)이 엉켜있어서

화면의 복잡도가 높아지고 사용자가 직관적으로 앱을 사용할 수 없게 되는 문제가 있었다.

워크샵만 3번 가고, 몇 개월을 날렸다고 한다.

해결방법

결론적으로는 특정 서류를 접했을 때 사용자가 Main Action이 뭘까? (= 가장 먼저 어떤 행동을 할까?)를 기준으로 3개 종류로 분류했다.

첫 번째는 발급하는 액션 (주민등본 발급), 두 번째는 납부하는 액션 (통신비), 세 번째는 알림과 통지를 받는 것 (백신접종 안내)

그리고 진입점이 필요없는 화면은 과감하게 메뉴에서 제거했다.

예를 들어 보험사 통지서는 특정시점에 가입 유저에게 알림만 주면 되고, 별도의 액션이 없다.

그래서 다시 이 기능을 찾아 들어올 일이 거의 없다.

그런데 여기서 굉장히 정치적인 문제가 생겼다.

문서 기능을 3개 종류로 쪼개고 나니, 더 이상 1개의 진입점으로 고정시킬 수 없게 된 것이다.

근데 기존의 '내 문서함' 진입점은 전체 탭의 상단에 위치하므로 좋은 트래픽을 받고 있었다.

PO 입장에서는 제품을 성공시켜야 하므로 트래픽을 포기하기 힘들었다. ('크로스 액티베이션'이라도 되지 않을까?)

근데 결국 단기적인 지표보다는 사용자 중심으로 기능을 만드는 것에 집중하면

장기적으로 전체적인 제품 성장에 도움이 될 거라는 믿음을 가졌다고 한다.

결론만 보면 당연한 얘기지만, 고민의 과정을 엿볼 수 있어 좋았다.

Product Principle 엿보기

개인적으로 토스는 디자인 원칙이 분명하고, 원칙에 대한 팀원들의 살제 공감도가 높아보였다.

예를 들면 Product Principal의 One thing per on page (한 화면에서 하나를 말해야 한다)가 지켜지지 않는 예

등본 떼기 외에도 성적증명서, 자격증명서 떼기 도 가능한데,

'내 문서함' 네이밍이 너무 제네럴해서, '등본 떼기'로 하니까 이제는 너무 지엽적인 문제가 있었다.

결론적으로 '증명서 떼기'로 바꾸되 '토스 주민센터'라는 카테고리로 표시해서 직관성을 높였는데 반응이 좋았다고 한다.

3. 초등학생도 쓸 수 있는 제품 만들기

문제상황

만 14세 이상을 위한 모바일 금융상품이 없었다.

도입 시 장애물

법적 절차가 까다로움
유사 프로덕트가 없어서 마켓 핏 이 검증되지 않음
비즈니스 임팩트가 작음

해결방법

마인드셋

어려움을 겪고 있는 유저의 문제를 해결해주는 것이 더 가치있지 않을까?
(이미 모든 서비스를 누리고 있는 만 14 이상 vs. 서비스가 전혀 없는 만 14세 미만)

장점 (구성원을 설득한 논리)

나이가 어린 유저를 Lock-in 시키는 효과

리스크

자녀의 사생활 보호를 위해 부모에게 사용 내역을 공유하지 않도록 했다.
-> 부모 입장에서는 자녀가 갈취/사기당하는 상황 등이 우려되는 문제가 있다.
-> 토스의 FDS 시스템 (이상 거래를 감지/차단하여 문제 해결)을 고도화한 청소년 전용 FDS 시스템을 구축해서 해결했다.
용어에 대한 어려움을 느끼지 않도록 최대한 쉬운 용어를 사용했다.
- 자산 -> 지갑, 송금 -> 돈 보내기, 소비 -> 용돈 기입장

MVP 스펙은 어떻게 정했나?

"만 14세 미만의 유저가 어떤 기능 때문에 가입하고 싶어할까?"를 고민했다.
-> 사용 불가를 알리는 기존 화면을 활용하여 설문을 진행했다.
-> 압도적인 답변이었던 송금만 구현했다.
출시 후 '토스에게 알려주세요' 메뉴를 추가하여 추가 설문을 진행했다.
-> 1~10위 기능을 모두 배포했더니 유저 만족도가 굉장히 높았다. ('토스는 내가 원하는 걸 만들어준다!')

디자이너가 배운 점

만드는 사람과 유저와의 간극이 클 때는 더 적극적으로 유저 보이스를 들어야 한다.
(제품 곳곳에 맥락에 맞는 설문 넣기, 임직원 자녀 또는 리쿠르팅을 통해 어린이 인터뷰하기 등)
반대의 목소리가 많은 프로덕트는 유저에게 전달할 수 있는 가치를 먼저 파악하는 것이 중요하다.

4. UX 라이팅, 혼자가 아닌 함께 잘 쓰기

*UX 라이팅이란?

사용자들이 서비스를 사용할 때 접하게 되는 단어, 문구들을 설계하는 일입니다. 서비스와 사용자 간 커뮤니케이션을 디자인하는 역할이기도 하죠. (...) 명확성, 일관성, 꼼꼼함, 자기 인식, 사용자 입장에서의 맥락 등을 종합적으로 고려해 결과물을 만들어낼 수 있어야 합니다.

토스에는 UX 라이터가 3명 밖에 없어서(?) 토스의 모든 글을 전부 관리하는 것이 불가능하다.

그래서 동료들의 글쓰기 실력을 향상시키기 위한 고민을 한다.

예를 들어 푸시 메시지를 개선한 사례가 있다.

자유롭게 문제점을 제보하는 #problem-of-toss 슬랙 채널이 있는데,

푸시 메시지에 대해 공통적으로 '다른 푸시들과 조금 느낌이 다르다'는 내용이 많았다.

Writing Principle

토스에는 텍스트 디자인 규칙을 정의한 8가지 Writing Principle이 있는데,

이 원칙을 근거해서 글을 개선해나갔다.

- Universal Words : 모든 사람들이 이해하는 단어를 써야한다. 드라마, 영화 소재, 밈은 사용을 지양한다.

- Suggest than Force : 너무 강한 어조의 문구로 유저에게 공포감을 주지 않는다.

- Predictable Hint : 다음 내용을 짐작 가능하게 쓴다.

이 원칙도 이미 토스 기술블로그의 '토스의 8가지 라이팅 원칙들' 포스트로 정리되어 있다.

ㄷㄷ.... 이 글 자체도 너무 좋다. ✨✨✨

'좋은 에러 메시지를 만드는 6가지 원칙' 포스트도 추천한다.

문제상황

푸시가 투자 콘텐츠로 연결되는 중요한 진입점이므로 자극적인 푸시 문구를 작성했다.

특이한 문구나 이모지를 활용해서 반응률을 높이자. vs. UX가 좋아야 한다.

해결방법

먼저 유저의 의견을 들었는데, 콘텐츠에 이미 부정적인 댓글이 달려있었다.

그래서 UX 라이팅 원칙을 기반으로 증권 콘텐츠 푸시에 대한 가이드라인을 제작했다.

글을 검토하는 포인트

정보와 표현 2가지 차원 (어떤 정보를 담을지, 어떻게 표한할지)으로 나눠서 체크하면 좋다.

- ex. 정보 : 공급자 중심의 밸류는 아닐까? (종목 이름보다 수익률이 얼마인지 소개하는 게 유용하다!)

- ex. 표현 : 상투적인 표현이 아닐까? (오름세로 출발했어요. -> 시작이 좋아요.)

고민한 점

이렇게 개선해서 문구는 좋아졌지만, 반응률이 낮아지지 않을까?하는 우려가 있었다.

동일한 메시지를 정보/표현/문장 형태가 다르게 푸시 문구 실험을 진행했다.

결과적으로 유저가 '9시'라는 시간에 잘 반응한다는 러닝을 얻었다.

이런 식으로 월 단위로 러닝을 정리하고, Winning/Losing 패턴을 공유해서 지표를 높이는 게 가능하다고 구성원에게 어필했다고 한다.

또한 기존 글의 패턴을 파악하여 카테고리별 템플릿을 만들고, Winning 패턴의 디스크립션을 만들어서 둘을 조합해 사용하도록 했다.

MVP 버전의 글로벌 앱을 만들면서

개발자이지만 앱에 들어가는 문구를 함께 고민했었는데, 간단한 메시지도 매번 어렵게 느껴져서 오래 고민했었다.

특히 국내에서 런칭하는 해외 서비스인 만큼

외국인 유저 입장에서는 번역투가 심하거나 맥락에 맞지 않는 단어를 사용하는 등 문장이 매끄럽지 않으면

비즈니스 자체에 대한 신뢰도가 떨어질 수 있다는 생각이 들었다.

지금 재직중인 회사에는 UX 라이터가 없지만, 필요성에 대해 매우 공감하게 됐다.

쓰다보니 필기 노트처럼 됐지만...

UX에 관심이 많은 개발자라면, 또는 디자이너의 고민을 이해하고 싶다면

관심 가는 세션을 가벼운 마음으로 들어보는 것을 추천한다. (각 섹션은 15분 내외이다!)

- Reference

toss > Simplicity23 전체 세션보기
toss careers > Simplicity23, 오늘도 문제를 해결하고 있을 모든 디자이너에게
안드로이드의 Material 가이드
toss feed > 모션, 금융을 즐겁고 쉬운 경험으로 만드는 방법
toss tech > 토스의 8가지 라이팅 원칙들
toss tech > 좋은 에러 메시지를 만드는 6가지 원칙
toss feed > 토스가 금융을 더 쉽게 만드는 또 하나의 방법, UX Writing
Blog > Lisa - What is UX Wrting?
Article > ICUNOW - UX 라이팅이란?

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[앱 리뷰] 말해보카 - 스마트폰 중독 활용하여 꾸준히 영어공부하기

Applecider — Sun, 21 May 2023 23:59:12 +0900

대부분의 개발자는 매일 영어로 된 공식문서와 블로그 글을 읽기 때문에 업무 중에도 영어에 노출이 많이 되는 편이다.

하지만 대부분 영어를 잘하나? 그건 아닐 것이다.

영어 공식문서를 책으로 따지자면 몇 십 권을 봤겠지만, 아직도 속독이 어려워 매번 번역기에 돌리고 싶은 충동이 든다.

이번 포스팅은 '말해보카'라는 앱을 통해 2개월 동안 꾸준히 영어공부를 한 경험을 소개하려고 한다.

나는 영어공부를 왜 하는가? - 언젠가 이민 가려고

개발자가 되기로 결심한 이유 중 하나는 개발이 이민에 유리한 직군이기 때문이었다.

20대 때 길지 않지만 호주, 인도, 태국에서 총 1년 6개월 정도 일해본 경험이 있는데,

평균적인 한국인만큼만 일해도 조직에서 주목받고 승진할 수 있겠다는 생각을 했다.

그래서 기회가 주어질 때 언제든 이민을 떠날 수 있도록 영어공부를 꾸준히 하자고 결심했지만... 쉽지 않았다.

나는 영어공부를 어떻게 해왔나?

영어공부는 어떻게 하면 좋을까? 영어공부에 미쳐있는 한국에는 공부방법과 컨텐츠가 수두룩하다.

나는 지금까지 이렇게 영어공부를 해왔다.

대학생 때는 대학교 영어강의와 해커스의 토플 자료를 통해 어휘/Listening/Reading 위주의 공부를,

사회초년생 때는 Input은 많지만 Output이 부족함을 깨닫고 통번역대학원 입시학원에 등록해서 Speaking/Writing 공부를 했다.

그 후 태국에서 국제기구 인턴으로 9개월간 일하면서 영어 Speaking이 가장 많이 늘었던 것 같다.

회의, 업무자료 작성, 스몰톡 등 모든 일상에서 영어를 사용해야 하는 환경 덕분에 강도 높은 성장이 가능했다.

24시간 마음 졸이며 영어시험을 치고 있는 것 같은 압박감 때문에 정신적으로 허덕이기도 했다.

한국에 돌아왔을 때는 따로 영어공부를 하지 않아도 (물론 시험용 벼락치기는 했지만) 토익 975점, 오픽 AL을 딸 수 있었다.

내 영어공부는 왜 실패했나? : 꾸준한 복습이 어렵다

하지만 그 영어 실력은... 별로 오래가지 않았다...

한국에 돌아와 5년간 직장생활을 하면서 영어를 거의 사용하지 않았고, 언어 능력은 빠르게 퇴화했다.

퇴사하고 개발공부를 시작했을 때, 소화해야만 하는 기술 문서와 영상들이 쏟아졌다.

그런데 아주 기초적이고 이미 알고 있는 내용임에도 영어로 읽다 보니 시간이 너무 오래 걸렸고,

Apple에서 매년 나오는 WWDC 영상은 자막이 있어도 알아듣기가 힘들었다.

그래서 다년간의 영어공부 실패 경험을 살려

개발 관련 영어문서에서 모르는 단어나 문장을 기록하고, 매일 읽는 것을 목표로 삼았다.

아래처럼 Evernote에 단어장을 만들었는데,

이동하면서 보기에 폰트 크기가 너무 작고, 꽤 많은 집중력이 필요해서

결국 정리만 하고 복습은 하지 않게 되었다.

그러다가 부트캠프 동기인 예거를 통해 '말해보카'라는 앱을 알게 됐다.

2개월 정도 써봤는데 매일 출퇴근길에 15분 이상 공부하는 습관을 만들 수 있었고,

무엇보다 이 앱으로 smart하게 공부하는 것이 어떤 것인지 구경하는 재미가 쏠쏠하다.

나중에 언젠가... 학습 앱을 개발한다면 이 앱을 많이 참고할 것 같다.

말해보카의 영어공부 방법

말해보카는 공부 영역을 크게 3가지로 나눈다.

하단 탭바를 보면 어휘 / 리스닝 / 문법 (쓰기) 탭이 있다.

각 탭마다 어떤 방식으로 공부를 시키는지 간단히 살펴보자.

(2개월 동안 총 1,567 단어나 공부했다!)

1. 어휘 - 영어 문장에 빈칸 채우기

먼저 단어 공부 방법은 이렇다.

한글 해석과 함께 빈칸이 있는 영어 문장이 주어지는데, 그 빈칸에 들어갈 적합한 단어를 주관식으로 쓰면 된다.

사용자는 단어를 입력하기만 하면 되니까 사용성이 너무 좋다.

사용자의 학습 레벨을 측정해서 적합한 난이도의 단어를 제시하는 것은 물론,

비슷한 뜻을 가진 단어지만 맥락상 맞지 않는 단어를 입력했을 때 그 차이점을 보여준다.

예를 들면 아래에서 "신빙성"이라는 단어를 맞춰야 하는데 사용자가 credibility를 입력할 것 같으면,

해당 단어가 왜 적합하지 않은지 친절하게 설명해 준다!

말해보카에 푹 빠지게 된 똑똑한 기능이다.

이 방식의 장점은 영단어를 문맥과 함께 학습하는 것이 가능하다는 점이다.

다년간의 영어공부 실패 경험을 통해 "authenticity = 전통성" 형태로 영어와 한글을 1:1 대응으로 암기하면 안 된다는 걸 알고 있다.

영어와 한국어는 언어 체계 자체가 다르므로 영어 특유의 문장 구조와 문맥을 함께 익히는 것이 중요하기 때문이다.

그리고 말해보카는 발음이 특이한 단어가 있다면 알려주고, 모든 문장을 원어민이 읽어주기 때문에

사전이나 종이 단어장으로 공부하는 것보다 훨씬 기억에 오래 남고, 정확한 발음까지 학습할 수 있다.

2. 리스닝 - 듣고 따라 말하기

리스닝 탭에서는 문장을 듣고, 곧바로 따라 말하는 방식으로 Listening/Speaking 학습을 한다.

실외에서는 녹음이 어려워서 몇 번 해보지 않았는데 (Speaking 공부가 제일 필요하면서 왜...)

발음 정밀 진단 (베타 기능)도 가능해서 도움이 많이 될 것 같다.

시간이 많은 날에는 아래처럼 유튜브 학습으로 Ted 강의를 받아쓰기하는데,

WWDC을 한 번에 듣고 이해하는 것이 목표인 나에게 딱이었다.

3. 문법 - 영어문장 완성하기

일상적으로 Reading/Listening 할 때 접하는 영어문장은 보통 평서문이라서 의문문을 거의 쓰지 않는다.

그런데 막상 개발 관련 구글링을 할 때는 의문문을 써야 하는데, 너무 오랜만에 쓰다 보니 의문문을 구성하는 게 헷갈릴 때가 있었다.

문법 탭에서는 아래처럼 주어진 단어를 조합해서 문장을 완성하도록 되어있다.

특정 문법 주제에 대해 직접 예문을 만들어보면서 영어 문장구조에 익숙해지는 연습을 할 수 있다.

덕분에 예전보다 의문문을 만드는 게 훨씬 수월해졌다.

그리고 10대 때 은색 표지의 맨투맨 책에서 배웠던 문법 지식이 nn년의 세월을 거슬러 뇌리를 스치는 재미도 쏠쏠하다.

아래는 to 부정사의 be to 용법. 분명히 예전에 배웠던 건데 까맣게 잊고 있었다.

쓸데없는 문법도 있지만, 아래 문장처럼 문법을 모르면 단어만으로는 문장을 제대로 해석할 수 없는 경우도 있기 때문에 유용하다.

말해보카의 장점

개인적으로 생각하는 강력한 장점 3가지를 꼽아봤다.

1. 단순하고 재미있음

한 화면에 1개의 문장/단어가 배치되므로

출퇴근길처럼 집중력이 흐트러지기 쉬운 환경에서도 공부를 할 수 있다.

그리고 틀린 문제의 복습 주기가 딱 알맞다.

예를 들어 사용자가 여러 번 틀린 문제는 더 자주 출제되는데,

내가 얼마 전에 틀렸던 문제가 다시 돌아왔을 때 정답을 맞히면 희열이 있다!

2. 커스텀 단어장

개인적으로 이민을 목표로 하고 있기 때문에 드라마/영화 같은 사적인 영어보다는

업무에 활용 가능한 공적 언어를 배우고 싶었다.

말해보카에서는 이렇게 단어 학습에 출제할 자료를 직접 선택할 수 있다.

내가 선택한 건 상황별 > 비즈니스 단어장, 유튜브 > TED, 연설, 강연, 인터뷰, School of Life, Wall Street Journal 등이다.

3. 중독을 공부에 활용 가능함

나는 스마트폰 중독이라 하루종일 폰을 놓지 않고 있는데,

그러다 보니 자연스레 하루에 15분, 많게는 1시간 동안 말해보카를 쓰게 된다.

스마트폰 중독은 보통 생산성 저하를 가져오는데, 아무 생각 없이 유튜브 쇼츠를 보듯이 영어 단어를 외우게 될 때가 있어서 좋다.

나는 경쟁 중독이기도 하다. K-교육체계에 익숙한 한국인이라면 대부분 그럴 것이다.

말해보카도 그 점을 알아서 리그 탭을 만들었는데, 주간 학습량으로 순위를 매겨서 보여준다.

영역별 학습이 끝날 때마다 순위가 얼마나 올라갔는지 알 수 있다.

처음에는 신경 쓰지 않았는데, 레벨이 계속 올라가다 보니 학습량이 많은 그룹에 속하게 되었다.

근데 내가 하위권에 머물러 있다는 사실이 은근히 신경 쓰여서... 더 공부를 하게 되는 효과가 있었다.

말해보카의 단점

말해보카의 단점을 굳이 말하자면 유료라는 점이다.

이미 양질의 무료 영어학습 컨텐츠가 많은데 유료 구독을 하는 게 돈이 아깝게 느껴질 수 있다.

하지만 12개월 구독을 하면 월 8,000원 수준이라 부담스럽지 않고,

직접 사용해 보니 유용한 기능이 많아서 돈이 아깝지 않았다.

꾸준히 재밌게 영어공부를 하고 싶은 개발자라면

말해보카에서 제공하는 7일 무료체험을 해보는 것을 추천한다!

- Reference

말해보카 유료 기능을 2개월 사용해 본 경험
말해보카 웹
Blog > Jager-yoo의 개발자는 영어공부 어떻게 해요?

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[채팅 기능] Stretchable Image로 채팅 버블 구현하기 (1/5)

Applecider — Sun, 7 May 2023 02:10:31 +0900

최근 9개월간 국내 제품을 해외 45개국에 판매하는 글로벌 프로젝트에 참여해 왔다.

2023년 2월에 MVP 버전의 앱을 출시했고, 그 이후 앱을 고도화하는 작업을 진행하고 있다.

최근 가장 전념하고 있는 건 판매자와 구매자 간의 채팅 기능을 개발하는 것이다.

Socket 통신, Polling, Stomp 등 처음 접하게 된 네트워크 개념도 있었고,

글로벌 서비스라서 고민해 볼 수 있는 TimeZone, Locale, DateFormat 처리,

채팅 목록과 채팅 상세 화면의 복잡한 UI 구현, Up Scrolling 등

쉽지 않지만 흥미진진한 문제들을 맞닥뜨리며, 단기간에 경험치를 쑥쑥 올리고 있다.

이렇게 채팅 기능을 구현하면서 학습한 아래의 5개 주제를 시리즈 형식으로 포스팅해보려 한다.

1. Stretchable Image - 채팅 버블 구현하기

2. ScrollView의 inset, scroll 버그 (부제: Known issue인줄 알았다면 삽질을 안했을텐데)

3. TimeZone/Locale/Calendar - 국가별 시간 표시, 채팅 버블 배치

4. Up Scroll Pagination - CGAffineTransform으로 CollectionView와 cell 뒤집기

5. Socket/Polling/Stomp 이해하기 - 양방향 네트워크 구현

이번 포스팅에서는 첫번째 주제인 Stretchable Image를 다룬다.

Introduction

채팅 상세 화면에서 가장 기본적인 UI는 "채팅 버블"이다.

채팅 버블이라는 네이밍에서 유추 가능하듯이 말풍선 모양으로 묶인 1개의 메시지를 의미한다.

이 채팅 버블을 구현해보자.

평소 카카오톡을 사용할 때 채팅방의 디자인을 눈여겨본 적이 있다면

텍스트가 길어질수록 채팅 버블의 크기 (너비/높이)도 커진다는 것을 알고 있을 것이다.

채팅 상세화면 (카톡 / 예시)

문제점

이 버블 UI를 어떻게 구현할까?

일단 짐작가는 대로 화면을 그려보자.

말풍선을 쌓아나가는 형태이므로 CollectionView를 만들어 말풍선 1개를 Cell로 구성하고,

Cell 위에 말풍선 imageView를 올리고,
말풍선 imageView의 subView로 message Label, translation button을 올리면 된다.

그리고 빌드해보면?

언뜻보면 잘 그려진 것 같지만 문제가 있다.

버블이 커질수록 말풍선의 모서리가 점점 둥글어져서 못생겨지는 것이다! (cornerRadius 값이 커지기 때문이다.)

이미지가 커질수록 모서리가 둥글어짐

이때 이미지의 확대 영역을 설정할 수 있는 Stretchable Image가 필요하다.

참고로 안드로이드에서는 9-Patch 이미지라고 부른다.

Stretchable Image란?

Stretchable Image를 직역하면 "늘어날 수 있는 이미지"이다.

Stretchable Image를 사용하면 이미지 크기를 키울 때, 이미지의 특정 영역만 늘어나도록 설정할 수 있다.

아래 그림으로 비교해보자.

일반적인 이미지의 크기를 키우면 이미지 전체가 일괄적으로 확대되지만 (왼쪽)

Stretchable Image는 모서리를 제외한 중앙 영역만 늘어난다. (오른쪽)

왼쪽: 일반 이미지 / 오른쪽: Stretchable Image

아래처럼 꼬리가 있는 말풍선 그림으로 보면 쉽게 이해할 수 있다.

1: 이미지 원본 / 2: 일반 이미지 / 3: Stretchable Image

공식문서 UIImage - Define a stretchable image에 그림과 함께 개념이 설명되어 있다.

아래 그림처럼 inset을 설정하면, 모서리 영역은 늘어나지 않도록 고정할 수 있다.

정확히는 inset으로 인해 이미지가 9개 영역으로 구분되며, 각각 수평/수직 방향으로 다르게 변형된다.

예를 들어 Top/Bottom inset 영역은 높이는 고정되고, 너비는 늘어난다.

반대로 Left/Right inset 영역은 너비는 고정되고, 높이는 늘어난다.

Stretchable Image 구현하기

Stretchable Image를 만드는 방법은 2가지가 있다.

하나는 Asset의 Slicing을 사용하는 것이고, 다른 하나는 코드로 구현하는 것이다.

방법-1. Asset Slicing 활용

이 방법은 이미지 위에 직접 확대 영역을 표시할 수 있어서 간편하다.

그리고 코드로 구현하지 않아도 이미지를 재사용 가능하므로 개인적으로 이 방법을 선호한다.

Asset에서 이미지를 선택하고, 우상단의 Show Slicing을 클릭한다.

(이번 예시에서는 2x, 3x png 파일을 사용했다.)

그 다음 이미지 위의 Start Slicing을 클릭하고, 확대 가능 영역의 방향 (수평, 수직&수평, 수직)을 선택한다.

채팅 버블은 너비와 높이 모두 늘어나야 하므로 수직&수평을 선택했다.

우하단의 Slicing 탭에서 Slices와 Center를 각각 설정한다.

(위에서 수직&수평을 선택했다면 Slices는 자동으로 입력된다.)

Slices : Horizontal and Vertical = 너비, 높이 둘다 늘어나게 할거임
(Horizontal = 너비만 늘어나게 할거임,
None = Strechtable Image 안쓸거임)
Center : Strectches = 늘린 공간은 이미지를 확대해서 채울거임
(Tiles = 늘린 공간을 타일 형태로 똑같은 이미지를 여러 개 복붙하는 방식으로 채울거임)

그리고 이미지 위에 확대 가능한 영역을 지정해주면 끝이다!

아래 화살표로 표시한 영역이다.

모서리 부분은 선택하지 않았기 때문에 이제 늘어나지 않는다.

참고로 궁금해서 실험해봤는데, 아래처럼 Slicing을 사용하되 확대 가능 영역을 지정하지 않으면 어떻게 될까?

버블이 원본-선 형태로 깨진다.

방법-2. resizableImage(withCapInsets:resizingMode:) 활용

코드로 구현하는 방법도 구조는 동일하다.

capInsets = 확대하지 않을 영역 (ex. 모서리)을 지정함
resizingMode = 늘어난 영역을 어떻게 채울건지 (Stretches인지 Tiles인지)

Cap insets에는 어떤 값을 넣어야 할까?

예를 들어, Asset의 원본 이미지가 72x72 pixel이고, 모서리의 둥글게 처리된 부분이 10 pixel이라면

inset은 10으로 설정하면 된다.

이때 2x, 3x png 파일을 모두 사용한다면 inset에 고정값을 넣는 것보다

이미지 크기의 특정 비율을 할당하는 방법이 더 낫다.

예를 들어 left/right inset에는 image.size.width * 0.4, top/bottom inset에는 image.size.height * 0.4를 할당하면 된다.

참고로 여기서 조금 헷갈릴 수 있는데, inset에 width * 0.5, height * 0.5를 할당하면 이미지가 안 늘어날까?

답은 "늘어난다"이다.

cap inset은 이미지의 원본 크기 (ex. 72x72 pixel)를 기준으로 설정한 것이기 때문에

이미지를 키우면 cap 영역으로 설정되지 않은 중앙 부분이 늘어나게 된다.

private let bubbleImageView: UIImageView = {
    let imageView = UIImageView()
    imageView.tintColor = .systemGray6
    imageView.isUserInteractionEnabled = true
    
    // 방법-1. inset에 고정값 할당
    let inset = 10.0
    imageView.image = UIImage(named: "bubble")?.resizableImage(withCapInsets: UIEdgeInsets(top: inset, left: inset, bottom: inset, right: inset), resizingMode: .stretch).template
    
    // 방법-2. inset에 이미지 비율 할당
    let image = UIImage(named: "bubble")
    let horizontalInset = (image?.size.width ?? 0.0) * 0.4
    let verticalInset = (image?.size.height ?? 0.0) * 0.4   
    imageView.image = image?.resizableImage(withCapInsets: UIEdgeInsets(top: verticalInset, left: horizontalInset, bottom: verticalInset, right: horizontalInset), resizingMode: .stretch).template

    return imageView
}()

주의할 점

삽질하면서 하나 알아낸 것이 있다.

Asset에 넣을 이미지는 가장 최소 크기로 준비해야 한다는 점이다.

Stretchable Image는 확대는 가능하지만, 축소는 불가능하기 때문이다.

심지어 공식문서에 "Stretchable images are commonly used to create backgrounds that can grow or shrink to fill the available space." 라고 명시되어 있는데 실제로 해보면 줄어들지 않는다... 애플놈들 부들부들

예를 들어 위에서 본 Short one 텍스트 버블이 가장 작은 크기였는데

만약 준비한 Asset 이미지의 크기가 더 크다면?

버블이 줄어들지 않으므로 버블 모서리가 뾰족하게 보일 수 있다. (의도한 cornerRadius보다 작아진 상태)

이렇게 채팅 버블 이미지처럼 이미지 크기를 늘릴 때 특정 영역만 확대되도록 설정하고 싶다면

Stretchable Image를 사용해보자!

예제 코드

private let bubbleImageView: UIImageView = {
    let imageView = UIImageView()
    imageView.tintColor = .systemGray6
    // ✅imageView의 subView로 label/button을 올리므로
    // tap gesture를 처리하려면 isUserInteractionEnabled 설정이 필요함
    imageView.isUserInteractionEnabled = true 

    let image = UIImage(named: "bubble")
    let horizontalInset = (image?.size.width ?? 0.0) * 0.4
    let verticalInset = (image?.size.height ?? 0.0) * 0.4   
    // ✅resizableImage 활용
    imageView.image = image?.resizableImage(withCapInsets: UIEdgeInsets(top: verticalInset, left: horizontalInset, bottom: verticalInset, right: horizontalInset), resizingMode: .stretch).template
    return imageView
}()
private let msgLabel: UILabel = {
    let label = UILabel()
    label.numberOfLines = 0
    label.setContentCompressionResistancePriority(.required, for: .vertical)
    label.setContentHuggingPriority(.required, for: .vertical)
    return label
}()
private let translatedMsgLabel: UILabel = {
    let label = UILabel()
    label.numberOfLines = 0
    return label
}()
private lazy var translationButton: UIButton = {
    let button = UIButton()
    button.setTitle("See Translation".localized, for: .normal)
    button.setTitle("Hide Translation".localized, for: .selected)
    button.setTitleColor(UIColor.systemGrey, for: .normal)
    button.setTitleColor(UIColor.systemGrey, for: .selected)
    button.titleLabel?.font = .systemFont(ofSize: 12)
    button.addAction(UIAction { [weak self] _ in
        self?.translationButtonTapped()
    }, for: .touchUpInside)
    return button
}()

// ...

private func makeLayout() {
    addSubview(bubbleImageView)
    let leadingOffset = Const.horizontalPadding + Const.artistThumbnailViewSize + Const.artistThumbnailViewRightMargin
    bubbleImageView.snp.makeConstraints { make in
        make.top.equalToSuperview()
        make.leading.equalToSuperview().offset(leadingOffset)
        make.bottom.equalToSuperview().inset(Const.bottomPadding)
    }

    bubbleImageView.addSubview(msgLabel)
    msgLabel.snp.makeConstraints { make in
        make.top.equalToSuperview().offset(Const.contentPadding.top)
        make.leading.equalToSuperview().offset(Const.contentPadding.left)
        make.trailing.lessThanOrEqualToSuperview().inset(Const.contentPadding.right)
    }

    bubbleImageView.addSubview(translatedMsgLabel)
    originalMsgLabel.snp.makeConstraints { make in
        make.top.equalTo(msgLabel.snp.bottom)
        make.leading.equalToSuperview().offset(Const.contentPadding.left)
        make.trailing.lessThanOrEqualToSuperview().inset(Const.contentPadding.right)
    }

    bubbleImageView.addSubview(translationButton)
    translationButton.snp.makeConstraints { make in
        make.top.equalTo(translatedMsgLabel.snp.bottom)
        make.leading.greaterThanOrEqualTo(msgLabel)
        make.bottom.equalToSuperview().inset(Const.contentPadding.bottom)
        make.height.equalTo(Const.originalButtonHeight)
    }
    translationButton.titleLabel?.snp.makeConstraints { make in
        make.leading.equalTo(msgLabel.snp.leading)
        make.trailing.equalTo(bubbleImageView).inset(Const.contentPadding.right) 
    }   
}

- Reference

Apple Developer Documentation > UIImage - Define a stretchable image
Apple Developer Documentation > resizableImage(withCapInsets:resizingMode:)
StackOverflow > Set stretching parameters for images programmatically in swift for iOS
Blog > Strechable Image를 이용해 이미지 늘리기

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[삽질 방지] UIButton이 Tap Gesture를 인식 못하는 원인 5가지

Applecider — Sun, 23 Apr 2023 22:12:56 +0900

버튼을 구현하는 건 굉장히 쉽다.

하지만 모든 작업을 다 한 것 같은데도 버튼이 Tap Gesture를 인식하지 못할 때가 있어서 답답했던 경험이 있다.

너무 간단한 기능이라서 오히려 적절한 검색 키워드를 찾거나 문제 원인을 파악하기가 더 어려웠다.

삽질하면서 찾아낸 원인 5가지를 정리해 봤다.

1. Storyboard Connection이 잘못된 경우

해결하기 가장 간단한 오류이다. Storyboard의 버튼과 @IBAction 메서드의 연결이 잘못된 경우이다.

여러 개의 버튼 또는 action 메서드를 복붙해서 만들었거나, 단순히 드래그를 잘못해서 발생한다.

아래처럼 Touch Up Inside 이벤트에 연결된 메서드가 1개 여야 정상동작한다.

코드로 UI를 그리는 작업에 익숙해졌는데, 반년만에 다시 Storyboard를 사용하면서 잠시 헤맸었다.

*현업에서도 Storyboard를 쓸까?

협업 시 Conflict이 발생해서 현업에서는 UI를 모두 코드로 구현하는 줄 알았는데 아니었다.

화면 구성이 단순하거나, 재사용이 필요 없다고 판단되는 화면은

빠르게 작업 가능한 Storyboard (정확하게는 Interface builder)를 쓰기도 한다.

2. 이벤트에 대한 action을 잘못 구현한 경우

코드로 UIButton을 구현하는 방법은 아래 코드처럼 세 가지 정도가 있다.

addTarget(_:action:for:) 또는 addAction(_:for:) 메서드, primaryAction 주입을 활용하는 것이다.

이때 이벤트가 발생했을 때 실행될 action을 잘못 구현했을 수 있다.

이것도 해결이 단순하니 설명은 생략했다.

// 방법-1. addTarget 메서드 활용
private lazy var backButton: UIButton = {
    let button = UIButton()
    // ...
    button.addTarget(self, action: #selector(backButtonTapped), for: .touchUpInside)
    return button
}()

@objc 
func backButtonTapped() {
    navigationController?.popViewController(animated: true)
}

// 방법-2. addAction 메서드 활용
private lazy var backButton: UIButton = {
    let button = UIButton()
    button.addAction(UIAction { [weak self] _ in
        self?.originalButtonTapped()
    }, for: .touchUpInside)
    // ...
    return button
}()

// 방법-3. 초기화 시 UIAction을 주입
private lazy var backButton: UIButton = {
    let button = UIButton(primaryAction: UIAction { [weak self] _ in
        self?.navigationController?.popViewController(animated: true)
    })
    // ...
    return button
}()

3. 버튼이 위치/크기를 정확히 잡지 못한 경우

스오플에서 찾지 못한 원인이었다.

설정한 layout constraints가 충분하지 않아서 버튼의 position/size가 명확히 잡히지 않은 경우이다.

xcode가 임의로 충돌하는 constraints를 제거해서 일단 view를 그리긴 한다.

그래서 화면만으로는 문제가 없어 보이지만 버튼을 탭했을 때 이벤트에 반응하지 않는다.

Debug view hierarchy에서 확인하면

"Horizontal position is ambiguous for UIButton", "Width is ambiguous for UIButton" 등의 Layout issues가 뜬다.

이때 이벤트에 반응하지 않는 진짜 원인이 뭘까?
버튼의 위치가 화면상에 보이는 영역을 벗어났는데,

clipToBounds가 false (default)라서

"눈에는 보이지만 탭 이벤트를 인식할 수 없는 상태"인 것으로 추측해 봤다.

*clipToBounds란?
true일 때 view bounds의 밖으로 벗어난 subviews를 자른다. (default = false)

4. imageView 또는 stackView 위에 버튼을 올린 경우

알고 보면 너무 간단하지만 오래 삽질했다.

imageView 또는 stackView의 subview로 버튼을 올리는 경우,

imageView의 isUserInteractionEnabled이 false (default)여서 탭 제스처를 무시해 버린다.

즉, 버튼의 superview가 제스처를 빼앗아 무시해 버린 것이다.

따라서 이것만 처리해 주면 해결된다.

bubbleImageView.isUserInteractionEnabled = true // 이제 subview로 이벤트를 전달함

bubbleImageView.addSubview(translationButton) // 버튼이 이벤트를 받음

UIButton은 UIControl을 상속받으므로 별도 처리를 하지 않아도 이벤트를 인식하지만

UIImageView는 아니라는 것을 다시 뼈에 새겨본다.

imageView.addSubview(button) 구조

5. 버튼을 isUserInteractionEnabled = false인 뭔가가 덮어서

4번과 비슷하게 다른 UI에게 제스처를 빼앗긴 경우이다.

view hierarchy를 통해 버튼을 덮고 있는 UI가 없는지 확인해 보자.

5번과 관련해서 헷갈리는 부분이 있어 정리해 봤다.

위의 스크린샷처럼 collectionView cell 위에 버튼을 올린 구조에서

collectionView에 gesture recognizer를 추가한 뒤, 버튼을 탭하면 어떻게 될까?

'gesture recognizer가 제스처를 빼앗아버려서 버튼이 동작하지 않겠지?'라고 예상했는데 아니었다.
(다시 생각해보면 당연히 버튼이 제스처를 빼앗는다. view hierarchy상 button이 가장 위에 있기 때문이다.)

버튼 영역을 탭했을 때 gesture recognizer는 동작하지 않고, 버튼에게 touch가 전달된다.

(단, cell 영역 중에서 버튼이 아닌 곳을 탭하면,
gesture recognizer가 제스처를 빼앗아서 collectionView의 didSelectItemAt 메서드가 호출되지 않는다. <- 이 때문에 헷갈린다.)

그런데 만약 gesture recognizer가 항상 제스처를 인식하도록 하고 싶다면?

또는 didSelectItemAt이 호출되도록 하고 싶다면?

gesture recognizer의 cancelsTouchesInView를 false로 바꾸면 된다.

버튼 영역을 탭했을 때 gesture recognizer와 버튼 모두에게 touch가 전달된다.
(cell 영역 중에서 버튼이 아닌 곳을 탭하면,

gesture recognizer와 didSelectItemAt 모두 동작한다.)

let tapGR = UITapGestureRecognizer(target: self, action: #selector(collectionViewDidTapped))
tapGR.cancelsTouchesInView = false  // GR이 항상 동작하게 하려면 필요
collectionView.addGestureRecognizer(tapGR)

- 검색 키워드 : how to not take way gesture from cell to collectionView, swift

How to add tap gesture to UICollectionView, while maintaining cell selection?

*cancelsTouchesInView란?

true (default)일 때 gesture recognizer가 제스처를 인식하면, 보류 (pending)된 제스처의 touches가 view로 전달되지 않고, 기존에 전달된 touches는 (touchesCancelled(_:with:) 메시지를 통해) 취소된다.

false일 때 multi-touch sequence의 모든 touches를 view가 전달받는다.

이때 '보류된 제스처의 touches'는 무슨 뜻일까?

사용자가 화면을 터치했을 때, gesture recognizer는 이게 Tab, Swipe, Long Press 등 중에서 어떤 건지 판단이 필요하다.

터치가 처음 발생한 시점 (touchesBegan)에는 알 수 없다.

따라서 gesture recognizer가 제스처를 인식하는 동안 touch 객체의 전달이 지연된다.

'보류된 제스처의 touches'는 이러한 touch 객체들을 의미한다.

UIGestureRecognizer 공식문서의 cancelsTouchesInView 설명이 좀 더 친절하다.

요약해보면,

(default인 true일 때) gesture recognizer가 제스처를 인식했을 때, 해당 제스처의 touch 객체를 view에게 전달하지 않는다.

If a gesture recognizer recognizes its gesture, it unbinds the remaining touches of that gesture from their view (so the window won’t deliver them). The window cancels the previously delivered touches with a (touchesCancelled(_:with:)) message. If a gesture recognizer doesn’t recognize its gesture, the view receives all touches in the multi-touch sequence.

즉, 원래는 responder chain에 따라 버튼이 touch event를 처리하게 되는데,

cancelsTouchesInView를 false로 바꾸면

gesture recognizer가 제스처를 인식했을 때 view (gesture recognizer가 장착된 collectionView)에게 touch가 전달되면서

버튼 (버튼 영역을 탭했을 때) 또는 didSelectItemAt (cell 중에서 버튼 이외 영역을 탭했을 때) 이 동작하게 된다.

(근데 cancelsTouchesInView를 false로 바꾼다고 해도

버튼이 제스처를 빼앗아가는데, 왜 gesture recognizer가 제스처를 인식하게 되는걸까...?

나중에 다시 정리가 필요할 것 같다. )

- Reference

삽질
Apple Developer Documentation > isUserInteractionEnabled
Apple Developer Documentation > clipsToBounds
Apple Developer Documentation > cancelsTouchesInView
Apple Developer Documentation > UIGestureRecognizer
StackOverflow > How to add tap gesture to UICollectionView, while maintaining cell selection?
Blog > Zeddios - 제스쳐(gesture) 사용해보기

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[디자인 패턴] Singleton

Applecider — Sun, 26 Mar 2023 21:09:18 +0900

문제 상황

현재 로그인한 사용자의 id, nickname, email 등의 User Data는 어떻게 관리하는 게 좋을까?
앱을 사용하는 동안 로그인 상태가 수시로 변경될 수 있으므로 여러 화면에서 접근할 수 있어야 한다. 예를 들어 앱을 최초실행 했을 때 로그인화면에서 sign in 할 수 있고, 로그아웃 화면에서 sign out 할 수 있고, 다시 비로그인 상태에서 좋아요 버튼을 눌렀을 때 modal로 띄워지는 로그인 화면에서 sign in 할 수도 있다.
이때 여러 화면에서 어떠한 시점에 접근하더라도 로그인 상태는 동일해야 한다. 따라서 공유 리소스 형태로 관리하고 싶다.
위 상황에서 Singleton 패턴이 해결책이 될 수 있다.

패턴 설명

클래스의 인스턴스를 1개만 만들고, 이 인스턴스에 대해 여러 화면에서 접근하도록 한 패턴이다.
- 의문 - 전역변수를 쓰면 되지 않나? : 예상치 못한 시점에 인스턴스를 덮어쓰기할 수 있어서 위험하다.
  (싱글턴은 만들어둔 인스턴스가 덮어쓰기되지 않도록 보호 가능)

위 그림에서는 getInstance() 메서드를 통해 인스턴스를 반환하도록 했지만,
Swift 문법에 따라 static 프로퍼티를 선언하여 항상 똑같은 인스턴스를 반환하도록 해도 된다.
default initializer를 private로 설정하여 외부에서 인스턴스를 추가 생성하지 못하도록 방지한다.

장점

클래스가 단 1개의 인스턴스만 가지는 것을 보장한다.
인스턴스에 대한 전역 접근이 가능하다.
메모리 사용 측면에서 효율적일지도 모른다. (아래 단점 참고) Swift에서 static 프로퍼티는 최초 접근할 때 lazy한 방식으로 초기화되기 때문이다.

단점

Singleton은 다른 디자인 패턴에 비해 단점이 많다. 그래서 Singleton은 디자인 패턴이 아니라는 말까지 있다.
따라서 아래의 단점에 유의해서 사용해야 한다.

단일책임 원칙을 위반한다. 한 객체가 여러 가지 역할을 담당한다.
(1개의 인스턴스만 생성하도록 제어하는 역할을 하면서, 동시에 User Data를 관리하는 역할을 하는 등 두 가지 기능을 동시에 한다는 뜻인듯?)
코드 간 결합도가 높아진다. 너무 많은 데이터를 공유할 경우, 개방폐쇄 원칙을 위반한다. 추적이 어렵다.
테스트 코드 작성이 어렵다. (공유 리소스이므로 테스트 코드를 위한 목적만으로 사용하는 게 불가능함. 또한 해당 클래스를 상속하는 Mock 객체를 초기화하는 것도 불가능함)
메모리 사용 측면에서 비효율적이다. static 프로퍼티에 인스턴스를 저장하므로 앱의 lifecycle 동안 메모리에 해당 인스턴스를 올려서 사용하기 때문이다.
다중 스레드 환경에서 여러 스레드가 인스턴스를 여러 번 생성하지 않도록 스레드 lock이 필요할 수 있다.

예시 코드

class UserManager {
  static let shared = UserManager() // 단 하나의 인스턴스를 공유하여 사용함
  private var id: Int?

  private init() { } // 외부에서 인스턴스를 추가 생성 못하도록 방지
  
  func saveId(_ id: Int) {
    self.id = id
  }
  
  func deleteId() {
    self.id = nil
  }
}

// Client
// sign in 하는 시점
UserManager.shared.saveId(100)

// sign out 하는 시점
UserManager.shared.deleteId()

초기화 과정이 복잡하다면 약간 복잡한 아래 방법도 가능하다.

class NetworkManager {
    // MARK: - Properties
    // 클로저를 통해 복잡한 형태의 초기화가 가능함
    private static var sharedNetworkManager: NetworkManager = {
        let networkManager = NetworkManager(baseURL: API.baseURL)

        // Configuration
        // ...

        return networkManager
    }()

    let baseURL: URL

    // MARK: - Initializers
    private init(baseURL: URL) {
        self.baseURL = baseURL
    }

    // MARK: - Accessors
    class func shared() -> NetworkManager {
        return sharedNetworkManager
    }
}

Reference

Blog - Cocoacasts > Are Singletons Bad
Blog - Cocoacasts > What Is a Singleton and How To Create One In Swift

[ModernRIBs] Xcode Template 설치하기 (간단) - install-xcode-template.sh

Applecider — Fri, 3 Mar 2023 17:40:35 +0900

ModernRIBs README 하단을 보면 Xcode Template을 설치하라고 나온다.

설치 방법을 간단히 알아보자.

(script라길래 Build Phases의 Run script 말하는 줄 알았는데 아니었음..)

ModernRIBs README 하단

참고로 Template을 추가하면 new file을 생성할 때 아래처럼 선택이 가능하다.

Template이 추가된 상태

ModernRIBs Template 설치 방법

1. 프로젝트 파일을 준비한다.

2. CocoaPod 또는 SPM으로 ModernRIBs 프레임워크를 설치한다.

3. https://github.com/DevYeom/ModernRIBs 코드를 다운받는다.

4. 해당 폴더로 이동한 뒤 터미널에 아래를 입력한다.

$ cd tooling  // Template 파일이 tooling에 위치해있음
$ sh install-xcode-template.sh  // 설치 시작

아래 문구가 보이면 설치 끝!

==> Copying up ModernRIB Xcode file templates...
==> ... success!
==> ModernRIB have been set up. In Xcode, select 'New File...' to use ModernRIB templates.

- Reference

GitHub > ModernRIBs
Blog > RIBs 튜토리얼

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[디자인 패턴] Builder - 초기화 과정이 복잡할 때

Applecider — Mon, 20 Feb 2023 19:45:45 +0900

문제 상황

여러 개의 프로퍼티, 중첩 타입 등을 지정해야 하므로 초기화 과정이 복잡한 객체가 존재한다.
이때 모든 가능한 매개변수를 포함하는 거대한 생성자를 만들게 되는데, 가독성이 떨어지고, 사용하지 않는 매개변수가 존재하므로 비효율적이라는 문제가 있다.

패턴 설명

복잡한 객체를 단계별로 생성하는 패턴이다.
객체를 생성하는 과정에서 해당 객체에 접근 불가하도록 막는다.
Builder를 통해 객체를 초기화하고, 외부에서 프로퍼티값을 메서드 주입받아 객체를 완성한다.
Director를 선택적으로 활용할 수 있다. Build 관련 메서드들의 실행 순서를 정의하는 역할을 담당한다.
객체를 종류별로 구분하여 생성 과정을 분기처리하고자 할 때 활용하면 좋다.

장점

복잡한 객체를 단계적으로 생성하거나, 생성 단계를 연기할 수 있다.
다양한 종류의 객체를 생성할 때 코드 재사용성이 좋다.
단일 책임 원칙을 준수한다.

단점

Builder 타입 등 클래스/구조체를 추가해야 하므로 코드의 복잡도가 증가한다.

예시

[2022년 회고] 5년의 커리어를 접고, 노베이스에서 iOS개발자가 되기까지

Applecider — Sun, 12 Feb 2023 16:24:17 +0900

개발자 글쓰기 모임인 “글또”의 8기로 참여하게 되었다. 다른 개발자들과 함께 좋은 글을 쓰는 방법에 대해 고민하고 성장하고 싶다는 것이 계기였다. 글또에 공유할 첫 번째 글로 <2022년 회고>를 작성해보려 한다.

(2023년으로 넘어온지 벌써 한 달이 지난 시점이라 많이 늦었지만... 그래도 글또 덕분에 바쁜 와중에 글을 쓸 동기부여를 받았다.)

2022년을 한 줄 요약하면

“노베이스로 부트캠프 7개월 과정을 거치고, 5개월 뒤 iOS 개발자로 취직했다.” 이다.

이걸 좀 더 풀어보자면

“5년간 쌓아온 커리어를 접고,

야곰아카데미 부트캠프에서 7개월 동안 공부하고,

제주 한달살이로 워케이션하면서 개인 앱을 출시하고,

수십 번의 탈락 끝에 아이디어스의 iOS 개발자로 취직했다.”가 된다.

그 과정에서 느낀 것, 배운 것과 앞으로의 다짐을 적어보려 한다.

다뤄볼 내용은 아래와 같다.

1. 2022년 연간 목표

2. 4가지 성취

2-1. 부트캠프 수료

2-2. 앱 출시 (feat. 제주 한달살이 워케이션)

2-3. 이커머스 iOS 개발자로 취업

2-4. 꾸준한 블로깅

3. 재평가

3-1. 좋았던 점

3-2. 아쉬운 점

4. 2023년 연간 목표

*회고란?

회고는 개발공부를 시작하면서 처음 접한 개념이었다. 부트캠프에서, 그리고 현재 재직 중인 회사에서 회고를 진행해 봤다. 일정 기간을 주기로 내가 지나온 길을 재평가하고, 이를 바탕으로 앞으로 갈 일에 도움이 될만한 포인트를 찾아낸다는 것에 의의가 있다. 또한 무엇보다 초심을 잃지 않도록 스스로 체크리스트를 만들어 현 상태를 점검하는 기회가 된다.

1. 2022년 연간 목표

모바일 앱을 통해 다양한 분야에서 사람들의 일상이 바뀌는 것을 목격했고, 각종 앱의 해비 유저였던 나는 자연스레 앱 개발에 관심을 갖게 됐다. 당시 발전소에서 엔지니어로 근무 중이었는데, 변화와 성장에 갈증을 느껴서 유튜브와 책을 통해 Swift 독학을 시작했다.

그러다가 야곰아카데미를 알게 되었고, 2021년 9월 시작되는 부트캠프에 등록할 계획을 세우고 퇴사를 했다. 당시 대리로 승진도 했고 나름 잘 다니던 회사였기 때문에 고민이 컸지만, 아래의 말을 듣고는 커리어 전환에 더욱 확신을 가지게 되었다.

“지금 있는 곳에서의 5년 후를 생각해 봐.”

같은 분야에서 일했고, 10년 동안 알고 지내며 많은 영감과 자극을 주는 선배가 해 준 말이었다. 내 계획과 비슷하게 IT 분야로 커리어를 전환하여 스타트업에 취업했고, 능력을 인정받아서 취업한 지 1개월 만에 연봉을 1천만원 높여 받고 보람차게 일하고 있었다. 이걸 가까이서 지켜보며 수평적인 조직 문화, 그리고 빠르게 결정하고 효율적으로 일하기를 경험해보고 싶었기에 스타트업에 취업하는 것을 목표로 잡았다.

2021년 회고는 따로 작성하지 않고, 부트캠프 후기로 대체했는데, 개발에 뛰어들게 된 얘기는 나중에 풀어보려 한다.

2022년 설정했던 커리어 목표

해마다 Notion을 활용해서 연간 목표를 세운다. 월 단위로 Review하는 시간을 통해 목표를 수정하기도 한다.
커리어 외에도 건강, 재테크, 문화생활, 관계, 여행 항목으로 나누어 관리한다.

2. 4가지 성취

2-1. 부트캠프 수료

부트캠프 생활은 다시 생각해도 치열했다. 새로운 개념을 배우고, 프로젝트에 적용하고, 토요일에는 복습스터디를 하는 생활의 반복이었다. 야곰아카데미의 교육철학에 따라 끊임없이 근거를 찾으며 문제를 해결하는 연습을 했다.

이상적인 동시에 지금 생각해 보면 굉장히 무서운 말이다. 개발자로서 필수적으로 지녀야 할 태도이기도 하지만, 누군가 떠먹여 주는 게 아니기 때문에 온라인상의 방대한 텍스트를 뒤지고, 추론하고, 다시 코드를 수정하고, 새로운 문제를 만나고…의 과정을 거쳐야 하는데, 끝이 안 보여서 막막하기도 하고 고통스러울 때가 많기 때문이다.

가장 힘들었을 때는 iOS 공부의 ‘3대 장벽’을 만났던 시점이었는데, 노베이스라서 당연히 힘든 거라고 위안 삼으며, 부트캠프의 동기/선배들과 함께 머리를 쥐 뜯으며 스터디를 했다. 힘든 만큼 문제를 해결했을 때의 희열도 컸다. 내가 작성한 코드가 시뮬레이터 상에 화면으로 그려지는 것이 재밌었다.

*3대 장벽 - TableView, 네트워크, RxSwift

큰 좌절을 가져다 준 계산기 프로젝트 (왼쪽) / 처음 네트워크를 구현했던 오픈마켓 프로젝트 (오른쪽)

너무나 하고 싶었던 개발 공부에 전념할 수 있어서 기쁘기도 했고, 때로는 유능한 동기들과 나를 비교하면서 ‘내가 이 친구들처럼 정말 좋은 개발자가 될 수 있을까?’ 하는 두려움이 커지기도 했다. 그래도 iOS를 업으로 삼는 좋은 동료들을 만나서 재밌게 공부하고 함께 성장했던 시간이라 소중한 경험이었다.

GitHub - 부트캠프에서 진행했던 프로젝트

*자세한 내용은 부트캠프 후기 포스팅을 참고

*링크는 GitHub 프로필을 참고

2-2. 앱 출시 (feat. 제주 한달살이 워케이션)

퇴사한 뒤 제대로 휴식할 시간이 없었기 때문에 부트캠프를 수료한 이후 나에게 주는 선물로 제주 한달살이를 계획했었다. 남들보다 늦게 시작했기 때문에 빨리 취업을 해야 한다는 조급한 마음도 들었지만, 나이를 먹으며 몇 번의 취업/이직을 경험해 본 결과 어디든 일자리는 있고, 굶어 죽지는 않을 거라는 믿음이 있어서 가능했다. (나이 드는 것의 장점도 나중에 써봐야겠다.) 게다가 마침 비슷한 시기에 친구가 회사에서 승진을 하고 안식월을 받아서 운 좋게도 함께 할 수 있었다.

당시 부트캠프에서 잘 맞았던 동기 호댕과 함께 앱 출시 프로젝트 '우리뭐먹지'를 진행하고 있었다. 미니게임을 통해 사용자 취향을 분석해서 다 같이 먹을 메뉴를 추천해 주는 앱이다. 수익을 내는 게 아니라 포트폴리오용으로 만들기로 한 것이었지만, 그래도 짜임새 있는 앱을 개발해보고 싶어서 지인을 통해 서버 개발자와 디자이너까지 섭외했다. 이 과정에서 어렵다고 느꼈던 RxSwift, MVVM, URLSession에 대해 제대로 체화할 수 있었고, 서버 개발자나 디자이너와 소통하면서 자연스레 실무에서 발생할만한 문제도 직접 대응해 보는 소중한 경험이 되었다.

*AppStore 출시 앱 ‘우리뭐먹지’에 대한 자세한 내용은 인디 앱 개발 포스팅을 참고

앱 스크린샷

앱의 기능을 설명하는 글과 스크린샷을 준비하고, 새벽까지 작업을 하다가 Apple에 심사 제출을 했는데, 불과 10분 만에 승인 메일을 받았었다. 이때 너무 기뻐서 같이 여행 중이던 친구를 깨워서 소식을 전했던 기억이 난다.

출시 승인을 받은 메일

사실은 제주도에 가기 전에 앱 출시를 완료하고 편안한 마음으로 떠날 수 있을 줄 알았는데… 코드 퀄리티에 욕심을 부리다 보니 작업 기간이 늘어지면서 제주도에서도 코딩을 해야했다. 베케이션 (Vacation)이 워케이션(Workcation)이 됐지만 나름 뜻깊은 경험이었다. 문제해결을 하려면 생각을 해야 하지만, 뇌에 과부하가 오면 머리가 굴러가지 않아서 애를 먹곤 했는데, 주변에 바다와 산이 있으니 언제든 훌쩍 장소를 옮겨 리프레시할 수 있다는 게 큰 장점이었다. 이때 등산과 위스키에 심취해서 요즘도 즐기고 있다.

겉으로는 평안해보이지만 끝없는 디버깅과 싸우는 중

2-3. 이커머스 iOS 개발자로 취업

제주도에서 돌아온 직후부터 취업 준비를 시작했다. 이력서를 다듬고, 서류를 제출하고, 채용 과제를 했다. 채용 과제는 생각보다 어렵지 않았지만, 면접 준비가 만만치 않았다. Swift/iOS 지식을 재정비하면서 아직 멀었구나, 하는 생각을 했다. 이때 앨런의 Swift 강의를 들었는데 비동기, 메모리와 관련해서 이해도를 높일 수 있었다.

가고 싶은 기업에서 채용공고가 나지 않아서 마음 졸이기도 했고, 면접에서 예상외로 긍정적인 평가를 받아 기쁘기도 했다. 이미 취직/이직을 해봐서 면접을 적지 않게 경험해 봤지만, 그럼에도 면접은 어려웠고 결과를 장담할 수 없었다.

결과적으로 핸드메이드 상품 거래 플랫폼인 ‘아이디어스’ (백패커)에서 합격 통보를 받아 입사하게 되었다. 사실 최종면접을 심하게 망했다고 생각해서 속으로 포기하고 새로운 협업 프로젝트를 구상 중이었다. 심지어 회사 인사팀에서 전화가 왔을 때 ‘여기는 왜 탈락자한테도 전화를 주지?’하고 생각했는데, 합격 소식을 들어서 굉장히 놀라고 기뻐했던 기억이 난다.

아이디어스는 평소에 자주 사용했던 앱이기도 하고, 핸드메이드 제품을 다루며 국내 수공예 시장을 키우는데 기여할 수 있다는 의미가 있어 개인적으로 애정이 가기 때문에 즐겁게 일할 수 있을 것 같아 설레었다. 또 다른 도메인에 비해 화면이 복잡하고, 새로운 기능이 정기적으로 도입되는 이커머스 업계에서 빠르게 성장할 것이 기대됐다.

백패커 강남캠프 사무실

입사 직후에 터미널에 git clone을 입력해서 현업 코드를 확인하던 순간이 기억에 남는다. 예상은 했지만 프로젝트 규모가 매우 크고 복잡해서 순간적으로 눈앞이 캄캄했지만, 기존에 작성된 문서를 참고하기도 하고, 앱 사용자의 Kinesis Log를 관리하는 작은 업무를 담당하기 시작하면서 차츰 코드와 서비스에 대한 이해도를 키워나갈 수 있었다.

회사 생활은 아직까지 대만족이다. 팀원이 7명인데, 시니어 개발자가 많아서 문제가 생겼을 때 조언을 구할 수 있고, 누군가 질문을 했을 때 누가 먼저랄 것 없이 도움을 주려는 협조적인 팀원들이 많아서 많은 자극을 받았다. 팀원들이 좋아서 일을 더 열심히 하고, 팀에 기여하고 싶은 마음이 생기는 선순환을 경험했다. (전 직장에서는 정반대로… 읍읍)

복지적인 측면에서는 주 2회 재택근무, 유연 근무제, 휴가 결재 필요 없음, 넉넉한 간식 창고, 반려견과 함께 출근 등 매우 자유도가 높은 환경이라 놀라면서 다니고 있다. (IT업계에서는 흔할지도 모르지만, 화재/폭발 사고가 발생하는 발전소에 있다가 온 나에게는 그저 신세계…)

2-4. 꾸준한 블로깅

마지막으로 한 가지 성과를 덧붙이자면, 기술 블로그를 꾸준히 운영하고 방문자수를 늘려왔다는 점이다. 부트캠프를 시작하면서 블로그를 개설했고, 구글링을 해봤지만 해결하기 어려웠던 내용 위주로 포스팅을 해왔는데, 보람 있게도 꾸준히 방문자수가 늘었다.

특히 12월에는 페북 게시글과 카톡 단톡방에 내가 작성했던 글이 공유되면서 유입량이 급등했었다. 해당 포스트는 일주일 동안 조회수 1천을 넘기기도 했다. 반년 전에 작성했던 글이 현재의 누군가에게 도움이 될 수 있다니, 컨텐츠의 위력을 실감했고 뿌듯함을 느꼈다.

블로그의 베스트셀러 TOP 3

1) 인디 앱 개발 포스팅

[인디 앱개발] ✨ 앱 기획부터 출시까지 참고한 링크 - 앱 기획, 디자인, 개발, 배포 준비

최근 2개월 동안 개발했던 앱을 출시하게 됐다. 기획부터 시작해서 디자인, 서버 개발, iOS 개발에 직접 관여하며 진행했던 프로젝트인 만큼 재밌었고 배운 게 많았다. 그 과정에서 단계별로 고려

applecider2020.tistory.com

2) Hashable 해야 한다?

[Swift] Hashable 해야 한다? 해쉬값이란? (간단 요약)

안녕하세요. 애플사이다 입니다. Swift Language Guide의 네 번째 챕터 Collection Types에 "Hashable"과 "해쉬값 (Hash Value)"이 등장합니다. 해쉬 개념을 제대로 이해하려면 해쉬 테이블 (Hash Table)이라는 자료구

applecider2020.tistory.com

3) Diffable DataSource 이해하기

[CollectionView] Diffable DataSource 이해하기 (1/3) - Advances in UI Data Sources (WWDC19)

CollectionView / TableView와 관련해서 "Diffable DataSource" 개념이 등장했다. 러닝커브가 조금 있는 내용이라 포스팅을 남기려고 한다. ✏️ 새로운 기술을 습득하기 가장 좋은 방법은 Apple이 만든 WWDC 영

applecider2020.tistory.com

3. 재평가

이에 대해 좋았던 점, 아쉬운 점을 간단히 정리해 봤다.

3-1. 좋았던 점

굵직한 3가지 목표 (부트캠프 수료, 앱 출시, 개발자로 취업)을 모두 달성했다.
역량이 부족하다는 생각에 자책을 할 때가 있는데, 스스로에 대한 믿음이 (조금) 생겼다.
커리어 전환을 해보니, 해외에서 일을 하는 것처럼 느껴질 정도로 업무 환경이 달랐다. 한글을 쓴다는 공통점만 있고 나머지는 모든 면에서 달랐다. 매우 수평적인 조직문화, 서로를 존중하는 팀원들, 체계적/효율적으로 진행되는 업무를 경험하게 되어 매우 만족하고 있다.
나는 기록 덕후 (a.k.a. 기록충)인데, 개발 업계에서는 이게 장점으로 취급된다. 새로 배운 내용을 정리하고 누군가와 공유하는 것을 좋아하는 사람들이 많아서 반갑다.
내 MBTI는 INTJ인데 살면서 같은 유형의 사람들을 많이 만나보지 못했다. 그래서 ‘내가 이상한, 유별난 사람인가?’ 하는 생각을 종종 했었다. 그런데 개발자 세계에서 INT* 유형은 꽤나 흔하다. 부트캠프에서, 회사에서 고요하게 자신의 일에 몰두하는 비슷한 성향이 동료들이 많아서 은근히 든든하다. (밖에서 만날 수 없었던 이유는 다들 집에서 조용히 뭔가를 하고 있기 때문이었던 것 같다.)

3-2. 아쉬운 점

개발 과정에서 문제를 만났을 때 공식문서를 읽는 것에 매몰되는 경우가 있었다. 그래서 구글링 키워드를 충분히 고민해보지 않았다. (빠르게 문제해결을 못한다고 자책할 시간에 구글링을 하자. 구글은 답을 알고 있다.)
회사에서 담당하게 된 프로젝트의 작업을 하느라 급급해서, 다른 팀원들이 작성한 코드를 제대로 보지 못했다. 내년에는 점심시간 직후, 회의를 끝낸 직후 등 컨텍스트 스위칭이 발생한 타이밍을 활용해 볼 계획이다.
스타트업에 취업하는 게 목표였으면서, 코딩테스트를 보려고 기웃거렸다. 그래서 부트캠프에서 코딩테스트 스터디에 참여했었는데, (간접적으로는 도움이 됐겠지만) 물리적으로 시간이 부족할 수밖에 없는 상황에서 모든 걸 다하려고 욕심부리느라 에너지를 낭비했던 것 같다.
출시한 앱을 업데이트 하지 않고 방치했다.
영어 공부를 위해 개발 용어를 단어장에 정리하려는 계획이 있었는데 하다가 포기했다.
한달살이를 할 때 매일 아침 조깅을 할 계획이었는데 못했다. ㅎㅎ

4. 2023년 연간 목표

회사에서 진행 중인 글로벌앱 출시 프로젝트를 무사히 완수하고, 안정적인 서비스 운영에 기여하기
업무 중에 접한 키워드 꾸준히 스터디하기
팀원들과 더 잘 협업하기 (29cm의 김우성 개발자님의 특강으로 들었던 “PR로 협업하기”를 회사 코드리뷰에 적용해 볼 계획이다.)
팀원들과 진행 중인 디자인 패턴 스터디 1회/주 참여하기
노수진님의 강의 듣기 (슈퍼앱 운영을 위한 확장성 높은 앱 아키텍처 구축)
사이드 프로젝트로 ‘우리뭐먹지’ 앱 고도화하기 (지도, 즐겨찾기, 로그인 기능)
글또 구성원과 소통하고, 블로깅 1회/2주 하기
WWDC 1회/주 보고 정리하기
iOS 관련 컨퍼런스 1회/년 참석하기
단어장 만들어서 영어 공부하기

쓰다 보니 글이 용두사미가 되었는데... 글또 활동을 통해 보다 가볍고 가독성 좋은 글을 써보고 싶다.

- Reference

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[RxSwift] Bind, Driver, Relay - Observable/Subject 말고 다른 것도 써보자

Applecider — Sun, 29 Jan 2023 22:06:10 +0900

Swift 문법을 배우는 것과 RxSwift를 배우는 것은 큰 차이가 있었다.

Swift는 처음부터 차근차근 배워야 하지만

RxSwift는 활용 방식이나 관련된 Operator가 너무 다양해서 필요한 것을 잘 추려서 써야한다.

그래서 Rx를 배우는 데 많은 시행착오가 있었다.
ViewModel-ViewController를 binding 하는 기초 예제를 정리해보려고 한다. 언젠가는..

겨우 Observable, BehaviorSubject, PublishSubject를 잘 쓰게 된 이후로는 이것만 썼다.

그런데 Rx의 기능을 충분히 활용하고 있지 못한 것 같아서

그 다음 단계로 UI를 안전하게 처리하기 위한 Bind, Driver, Relay를 배웠는데 매우 유용했다.

이 내용을 간단히 소개해보려고 한다.

1. bind(to:)

binding할 때 순환참조를 방지한다.

코드를 줄일 수 있다.

RxCocoa의 기능이다. UI에다가 Rx 기능을 붙인 개념이다.

subscribe(onNext:) 대신 bind(to:)를 쓰면 되고,

self?.labelText.text = $0 형태 대신 label.rx.text 형태로 쓴다.

참고 - "bind를 쓰면 Main thread에서 실행하는 걸 보장한다"는 블로그 글이 있는데 잘못된 정보이다.
bind는 내부적으로 subscribe를 호출하기 때문이다.

public func bind(onNext: @escaping (Element) -> Void) -> Disposable {
    return self.subscribe(onNext: onNext, onError: { error in
        rxFatalErrorInDebug("Binding error: \(error)")
    })
}

2. Observable 대신 Driver

UI 특성상 stream이 끊기면 안된다.

서버가 일시적으로 불안정한 등의 예상치 못한 이유로 인해 stream이 끊길 수 있는데

버튼이 동작하지 않거나, 검색창에 검색어를 입력해도 아무 반응이 없는 문제가 발생한다.

*Google Books API를 활용해서 검색화면을 구현했을 때 간헐적으로 문제가 발생했다.

그래서 Driver는 error가 발생했을 때 임의 값으로 처리해서 stream을 유지해준다.

(매개변수 네이밍인 onErrorJustReturn이 매우 적절하다.)

subscribe(onNext:), bind(to:) 대신 drive()를 하면 된다.

그리고 자동으로 Main 스레드에서 처리하므로 UI 처리에 더욱 안전하다.

따라서 이제 observeOn(MainSceduler.instance)가 필요 없다.

3. Subject 대신 Relay

Subject도 마찬가지로 error가 발생해도 stream이 끊기지 않도록 해야 한다.

Relay는 Subject에서 error가 발생하면 무시해서 stream을 유지해준다.

Subject와 종류도 똑같다. BehaviorSubject 대신 BehaviorRelay를 사용하면 된다.

onError, onComplete이 발생하지 않는 개념이라서 무조건 받아들일 수 밖에 없다.

따라서 onNext() 대신 accept()를 쓴다.

- Reference

ReativeX
GitHub > RxSwift

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[디자인 패턴] Abstract Factory - 미리 정해둔 종류로만 객체를 생성할 때

Applecider — Mon, 16 Jan 2023 07:00:19 +0900

GoF 디자인 패턴 중 하나인 Abstract Factory 패턴을 정리했다.

이 패턴은 예시코드부터 보는 것을 추천한다.

- Ref : 도서 <Dive into Design Patterns>, Alexander Shvets 저

문제 상황

가구 판매 앱 개발과정에서 세트 제품군 (a family of reloated products)이 있다. (ex. 의자, 소파, 커피테이블)
또한 해당 세트 제품군에는 여러 스타일의 변형 (variants)이 있다. (ex. 아르데코, 빅토리안, 현대식)
고객이 가구를 주문하면, 동일한 스타일로 가구세트를 통일해야 하는 상황이다.
또한 새로운 제품 (새로운 스타일)이 자주 추가되므로 매번 기존 코드를 수정하는 번거로움을 피하고 싶다.

패턴 설명

이 패턴은 말로 설명하면 복잡한데, 예시를 보면 매우 쉽다.

요약 : Concrete 클래스가 없어도 특정 객체를 생성할 때 항상 미리 지정해 둔 종류로 생성하는 패턴이다.
먼저 세트 제품군 종류별 프로토콜을 생성한다. (ex. 의자 프로토콜)
이후 각 스타일의 제품이 위 프로토콜을 채택하도록 한다. (ex. 빅토리안 의자, 모던 의자 등)
그 다음 Abstract Factory 프로토콜을 선언하고, (ex. FurnitureFactory 프로토콜)
이후 각 스타일마다 위 프로토콜을 채택하도록 한다. (ex. 빅토리안 FurnitureFactory, 모던 FurnitureFactory 등)
클라이언트는 의자 프로토콜을 사용하여 모든 의자를 항상 동일한 방식으로 주문하게 된다.
(= 의자를 주문하기만 하면 항상 정해진 스타일로 온다는 뜻❗️)
Abstract Factory 패턴은 Factory Method 패턴의 집합을 기반으로 한다.

Abstract Factory 구조도

예시 코드

핵심은 초기화 시 스타일을 지정하면

-> 해당 스타일로 모든 제품군을 생성한다는 것이다.

// MARK: - 1️⃣ Chair
protocol Chair {
    func hasLegs()
    func sitOn()
}
class VictoryianChair: Chair {
    func hasLegs() { }
    func sitOn() { }
}
class ModernChair: Chair {
    func hasLegs() { }
    func sitOn() { }
}

// MARK: - Sofa
protocol Sofa { }  // 생략
class VictoryianSofa: Sofa { }
class ModernSofa: Sofa { }

// MARK: - CoffeeTable
protocol CoffeeTable { }  // 생략
class VictoryianCoffeeTable: CoffeeTable { }
class ModernCoffeeTable: CoffeeTable { }

// MARK: - 2️⃣ FurnitureFactory
protocol FurnitureFactory {
    func createChair() -> Chair
    func createSofa() -> Sofa
    func createCoffeeTable() -> CoffeeTable
}
class VictorianFurnitureFactory: FurnitureFactory {
    func createChair() -> Chair {
        print("VictoryianChair")
        return VictoryianChair()
    }
    func createSofa() -> Sofa {
        print("VictoryianSofa")
        return VictoryianSofa()
    }
    func createCoffeeTable() -> CoffeeTable {
        print("VictoryianCoffeeTable")
        return VictoryianCoffeeTable()
    }
}
class ModernFurnitureFactory: FurnitureFactory {
    func createChair() -> Chair {
        print("ModernChair")
        return ModernChair()
    }
    func createSofa() -> Sofa {
        print("ModernSofa")
        return ModernSofa()
    }
    func createCoffeeTable() -> CoffeeTable {
        print("ModernCoffeeTable")
        return ModernCoffeeTable()
    }
}

// MARK: - ✅ Client
class House {
    let factory: FurnitureFactory
    
    init(factory: FurnitureFactory) {  // 1. 초기화 시 스타일을 결정하면
        self.factory = factory
    }
    
    func service() {  // 2. 해당 스타일로 모든 세트 제품을 생성함 ❗️
        let chair = factory.createChair()
        let sofa = factory.createSofa()
        let coffeeTable = factory.createCoffeeTable()
    }
}

let victorianFurnitureFactory = VictorianFurnitureFactory()
let victorianHouse = House(factory: victorianFurnitureFactory)
victorianHouse.service()
//VictoryianChair
//VictoryianSofa
//VictoryianCoffeeTable

let modernFurnitureFactory = ModernFurnitureFactory()
let modernHouse = House(factory: modernFurnitureFactory)
modernHouse.service()
//ModernChair
//ModernSofa
//ModernCoffeeTable

활용하는 상황을 상상해보면 아래와 같다.

switch style {
case .victorian:
    let victorianFurnitureFactory = VictorianFurnitureFactory()
    let victorianHouse = House(factory: victorianFurnitureFactory)
    victorianHouse.service()
case .modern:
    let modernFurnitureFactory = ModernFurnitureFactory()
    let modernHouse = House(factory: modernFurnitureFactory)
    modernHouse.service()
// ...
}

장점

항상 특정한 종류의 제품만 생성하는 것을 보장할 수 있다.
Concrete Product와 클라이언트 간의 결합도를 낮춘다.
Product 초기화 코드를 특정 객체가 전담하므로 단일책임 원칙을 준수한다.
새로운 제품 (스타일)이 추가할 때 기존 클라이언트를 훼손하지 않으므로 개방폐쇄 원칙을 준수한다.

단점

새로운 프로토콜과 클래스를 추가해야 하므로 코드의 복잡도가 높아진다.

- Reference

도서 <Dive into Design Patterns>, Alexander Shvets 저

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[디자인 패턴] Factory Method - 비슷한 종류의 타입을 찍어낼 때

Applecider — Sat, 14 Jan 2023 18:29:21 +0900

GoF 디자인 패턴 중 하나인 Factory Method 패턴을 정리했다.

- Ref : 도서 <Dive into Design Patterns>, Alexander Shvets 저

문제 상황

물류관리 앱을 개발하는 과정에서 먼저 Truck (트럭) 운송 처리 로직을 만들었는데, 얼마 뒤 Ship (선박) 등 추가적인 운송수단 처리가 필요하게 됐다.
대부분의 코드가 기존의 Truck 클래스에 결합되어 있어 코드 재사용성이 떨어지는 문제가 있는 상황이다.

패턴 설명

요약 : 부모클래스에서 객체 생성 인터페이스를 제공하며, 동시에 자식클래스가 객체의 유형을 변경하여 생성 가능하도록 하는 패턴이다.
Product, Creator 역할이 필요하다.

Factory Method 구조도

1. Product

일반적인 객체 생성 코드를 부모클래스의 팩토리 메서드 내부에 배치한다.
팩토리 메서드는 생성한 객체를 반환하며, 이 객체를 Product (제품)라고 부른다.
현재 문제상황에서 Product는 Transport (Truck, Ship 등)이다.
여러 종류의 Product는 공통적인 프로토콜을 채택해야 한다.
클라이언트 (팩토리 메서드를 사용하는 코드)는 Product 간의 차이를 모른다.

2. Creator

위에서 설명한 부모클래스 역할을 Creator 클래스가 한다.
현재 문제상황에서 Creator는 Logistics (RoadLogistics, SeaLogistics 등)이다.
이제 자식클래스에서 팩토리 메서드를 override하여 반환하는 Product 타입을 변경할 수 있다.
네이밍에서 예상되는 것과 달리, Creator의 책임은 제품을 생성하는 게 아니라 제품과 관련된 핵심 비즈니스 로직을 처리하는 것이다. 팩토리 메서드는 이러한 비즈니스 로직을 Concrete Product 클래스로부터 분리 (디커플링)하는 데 도움을 준다.

예시 코드

부모클래스 Logistics는 팩토리 메서드에서 Truck (default transport 개념)을 생성하도록 했고,
자식클래스인 Road/SeaLogistics는 팩토리 메서드를 override하여 각각 Truck/Ship을 자체적으로 생성한다.

// MARK: - 1️⃣ Product
protocol Transport {
    func deliver()
}
class Truck: Transport {  // Concrete Product-1
    func deliver() {
        print("Truck - delivery started")
    }
}
class Ship: Transport {  // Concrete Product-2
    func deliver() {
        print("Ship - delivery started")
    }
}

// MARK: - 2️⃣ Creator
class Logistics {
    func createTransport() -> Transport {
        let defaultTransport = Truck()
        print("Truck - created")
        return defaultTransport
    }
    
    func service() {
        let transport: Transport = createTransport()
        print("Packages on board")
        transport.deliver()
    }
}
class RoadLogistics: Logistics {  // Concrete Creator-1
    override func createTransport() -> Transport {
        print("Truck - created")
        return Truck()
    }
}
class SeaLogistics: Logistics {  // Concrete Creator-2
    override func createTransport() -> Transport {
        print("Ship - created")
        return Ship()
    }
}

// MARK: - ✅ Client
let roadLogistics = RoadLogistics()
roadLogistics.service()
//Truck - created
//Packages on board
//Truck - delivery started

let seaLogistics = SeaLogistics()
seaLogistics.service()
//Ship - created
//Packages on board
//Ship - delivery started

활용안을 상상해보면 아래 형태일듯

if destinationType == .sameLand {
    let roadLogistics = RoadLogistics()
    roadLogistics.service()
} else {
    let seaLogistics = SeaLogistics()
    seaLogistics.service()
}

장점

데이터베이스 연결, 파일시스템, 네트워크 등 대규모 객체를 처리하는 상황에서 시스템 리소스를 절약할 수 있다.
Creator와 Concrete Product의 결합도를 낮춘다.
제품 초기화 기능을 한 객체에서 전담하므로 단일책임 원칙을 준수한다.
클라이언트 코드에 영향을 주지 않은 채로 새로운 Product를 도입할 수 있으므로 개방폐쇄 원칙을 준수한다.

단점

새로운 자식클래스를 생성해야 하므로 코드 복잡도가 높아진다.
따라서 Creator 클래스의 기존 계층구도에 패턴을 도입하는 것이 좋다.

- Reference

도서 <Dive into Design Patterns>, Alexander Shvets 저

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Blackhole] 맥북 소리 포함시켜서 화면녹화 (간단)

Applecider — Fri, 13 Jan 2023 20:24:01 +0900

맥북의 기본 화면녹화 기능을 사용하면, 소리가 포함되지 않는 문제가 있었다.

iShowUInstatnt는 유료화됐고, SoundFlower는 M1/Big Sur 이후 비정상 작동해서 BlackHole을 사용하게 됐다.

다중출력기기 설정이 필요한데 매우 쉽다.

1. BlackHole 설치

Existential Audio에서 최상단의 BlackHole 2ch 버전을 다운받으면 된다.

이메일 인증만 하면 무료로 사용 가능하다.

이때 사운드 설정에서 출력을 BlackHole 2ch로 설정하면, 화면녹화 시 소리가 포함된다.

하지만 스피커 출력이 되지 않아서 화면녹화 도중에 소리를 들을 수 없다.

그래서 아래의 다중출력기기 설정이 필요하다.

2. 다중출력기기 설정

오디오 MIDI 설정에서 다중출력기기 설정을 해야 한다.

*다중출력 = BlackHole과 맥북 스피커에 동시에 소리가 출력되도록 해줌

먼저 좌하단의 + 버튼 > 다중출력기기 생성을 누르고,

BlackHole, 맥북 스피커에 체크박스를 클릭한다.

그리고 사운드 설정에서 출력을 다중출력기기로 바꾼다.

3. 화면녹화 옵션 설정

마지막으로 화면녹화 시 옵션에서 BlackHole 2ch를 선택한다.

녹화에 필요한 사운드는 BlackHole 출력만 있으면 되기 때문이다. 이제 끝!

*화면녹화 단축키 : Cmd + Shift + 5

화면녹화 시 보이는 옵션 창

- Reference

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[레거시] Convert Objective-C to Swift 사이트

Applecider — Wed, 11 Jan 2023 20:23:38 +0900

현업에서 Objective-C로 작성된 레거시 코드를 이해해야 할 때

근데 공부하기는 싫을 때...

Object-C를 Swift로 변환해주는 기능을 사용하면 좋다.

SWIFTIFY

Swift화 해준다는 뜻의 SWIFTIFY라는 사이트를 추천한다.

사이트 네이밍 잘 지었다.

사용 방법은 매우 간단한데,

Objective-C 코드를 넣고 하단의 Convert Now 버튼을 탭하면 Swift로 변환이 된다.

코드 용량이 0.5KB을 초과하면 Sign in (회원가입)을 하라고 한다.

무료 서비스지만 회원가입 시 2회/일로 횟수제한이 있어서

귀찮아도 회원가입 안하고 코드를 여러 번 복붙하면서 쓰고 있다.

변환 예시

ChatGPT

23년 2월 업데이트

이제 Swiftify 같은 거 필요없다..

ChatGPT한테 물어보면 길이가 긴 코드도 Swift로 바꿔주고, 뜻도 설명해준다.

StackOverflow에서 objc로 작성된 코드가 궁금했다.

아래처럼 검색하면 된다.

convert this objective-c code to Swift code.
{objc 코드 복붙하기}

convert this objective-c code to Swift code.
NSMutableURLRequest *authRequest = [[[NSURLRequest alloc] initWithURL:authURL] mutableCopy]; [authRequest setHTTPMethod:@"POST"]; NSURLSession *session = [NSURLSession sharedSession]; [authRequest setValue:@"application/json" forHTTPHeaderField:@"Content-Type"]; NSDictionary *bodyDictionary = @{@"User_Name": user, @"Password_Hash": password}; if ([NSJSONSerialization isValidJSONObject:bodyDictionary]) { NSError *error; NSData *bodyData = [NSJSONSerialization dataWithJSONObject:bodyDictionary options:0 error:&error]; if (!error) { [authRequest setHTTPBody:bodyData]; } else { NSLog(@"Unable to convert to JSON DATA %@", error.localizedDescription); } }

아래는 ChatGPT의 답변이다.

놀랍다..

Cheat sheet

Objective-C 및 Swift를 비교한 Cheat sheet을 활용하는 것도 좋다.

Objective-C 때 코딩 안배워서 다행이다..

검색 키워드 : convert objc to swift

- Reference

SWIFTIFY
Hacking with Swift > Cheat sheet

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[UIImage] withRenderingMode(.alwaysTemplate)은 언제 쓸까? - tintColor가 적용되는 영역만 남길 때

Applecider — Sat, 31 Dec 2022 20:13:15 +0900

Profile 화면을 구현하다가 컬러가 2개 이상 적용된 이미지를 사용했을 때

이미지 전체가 tintColor로 뒤덮이는 문제가 발생했다.
(왼쪽처럼 구현하고 싶었는데, 오른쪽처럼 나타남)

대부분의 화면에서 이미지를 올릴 때 renderingMode를 .alwaysTemplate으로 설정했는데, 이게 원인이었다.

이미지의 renderingMode 3개 종류인 automatic/alwaysOriginal/alwaysTemplate을 정리했다.

결론

2개 종류의 이미지를 일반 화면 및 TabBar에 올리고,

Rendering Mode를 automatic, alwaysOriginal, alwaysTemplate 순으로 지정해봤다.

Custom Image : 흰색, 회색 2개 컬러가 사용된 이미지
System Image : SF Symbol을 활용

그리고 4개 이미지 모두 tintColor를 yellow로 지정했다.

Redering Mode 지정 (왼쪽부터 automatic, alwaysOriginal, alwaysTemplate 순)

2개 색상이 사용된 Custom 이미지를 먼저 보자.
- 일반 화면 (TabBar가 아닌 영역) : alwaysTemplate을 적용하면 이미지가 날아간다.
- TabBar 영역 : automatic, alwaysTemplate을 적용하면 이미지가 날아간다.
- 즉, 2개 색상이 사용된 이미지는 원본 색상을 적용해야 하므로 alwaysOriginal을 쓰면 된다!
SF Symbol을 사용한 System 이미지를 보자.
- alwaysOriginal이 아닐 때, 의도대로 투명한 사람 부분에 backgroundColor가 나타난다.
- 즉, 1개 색상이 사용된 이미지 또는 System 이미지에 tintColor를 적용해야 하므로 alwaysTemplate을 쓰면 된다!

	automatic	alwaysOriginal	alwaysTemplate
일반 화면 - Custom Image	원본	원본	이미지 날아감
일반 화면 - System Image	투명한 영역 투명하게 보임	원본 (투명한 부분도 원본색으로 보임)	투명한 영역 투명하게 보임
Tab Bar - Custom Image	이미지 날아감	원본	이미지 날아감
Tab Bar - System Image	투명한 영역 투명하게 보임	원본 (투명한 부분도 원본색으로 보임)	투명한 영역 투명하게 보임

Rendering Mode

UIImage.RenderingMode 공식문서부터 보자.

rendering mode란 UIKit이 이미지의 색상 정보를 어떻게 활용해서 이미지를 나타낼지 제어한다.

automatic : default
alwaysOriginal : 항상 원본 이미지를 나타낸다. (원본의 색상 정보대로 그린다는 뜻)
alwaysTemplate : 원본 색상 정보를 무시하고, *template 이미지를 나타낸다. (tintColor가 적용되는 부분만 남긴다는 뜻)❗️

template 이미지는 Article - Providing images for different appearances에서 자세히 설명한다.
내용 중 tintable images를 간단히 보자.

말로 설명하면 어려운데 그림으로 보면 쉽다.

이미지 중 투명한 영역은 backgroundColor가 보인다.

이미지 중 100% opaque 영역에는 tintColor가 100% 적용되고, 25% opaque 영역에는 tintColor가 25% 적용된다.

즉, tintColor는 이미지 중 투명한 영역이 아닌 부분에 적용된다.
그래서 tintColor가 적용되는 영역을 본 뜬 것 (색상만 바꾸면 되는 틀 역할)을 template image라고 부른다.

tintColor 맨날 썼는데 이번에 처음 알았음..

이왕 찾아본 김에 tintColor 공식문서도 확인해보자.

tintColor는 view hierarchy에 있는 (== UIImageView 위에 올린 모든 view에 적용됨)
template images를 tint하는 색깔이다.
위에서 다 정리했던 내용이라서 이해하기가 쉬웠다.
즉, template images에 적용되므로 Rendering mode를 .alwaysTemplate으로 설정해야 한다!

예제 코드

예제 코드로 화면에 나타난 이미지를 확인하며 마무리해보자.
전체 코드는 GitHub Repo를 참고

private func makeLayout() {
    // 1️⃣ ImageView (custom)
    // ✅ 주의 - withRenderingMode()는 속성을 바꾼 새로운 image를 반환함 
    let returnedCustomImage = UIImage(named: "custom_profile_fill")?.withRenderingMode(.alwaysOriginal)
//  let customImage = UIImage(named: "custom_profile_fill")
//  let returnedCustomImage = customImage?.withRenderingMode(.automatic)       // 1
//  let returnedCustomImage = customImage?.withRenderingMode(.alwaysOriginal)  // 2
//  let returnedCustomImage = customImage?.withRenderingMode(.alwaysTemplate)  // 3
    customImageView.image = returnedCustomImage
    customImageView.tintColor = .customYellow

    // 2️⃣ ImageView (system)
    let sfImage = UIImage(systemName: "person.circle.fill")
//  let returnedSFImage = sfImage?.withRenderingMode(.automatic)       // 1
    let returnedSFImage = sfImage?.withRenderingMode(.alwaysOriginal)  // 2
//  let returnedSFImage = sfImage?.withRenderingMode(.alwaysTemplate)  // 3
    systemImageView.image = returnedSFImage
    systemImageView.tintColor = .customYellow

    // 3️⃣ Tab Bar (custom)
    let customBarItemImage = UIImage(named: "custom_profile_fill")
//  let returnedCustomBarItemImage = customBarItemImage?.withRenderingMode(.automatic)       // 1
    let returnedCustomBarItemImage =  customBarItemImage?.withRenderingMode(.alwaysOriginal) // 2
//  let returnedCustomBarItemImage =  customBarItemImage?.withRenderingMode(.alwaysTemplate) // 3
    customBarItem.image = returnedCustomBarItemImage

    // 4️⃣ Tab Bar (system)
    let systemBarItemImage = UIImage(systemName: "person.circle.fill")
//  let returnedSystemBarItemImage = systemBarItemImage?.withRenderingMode(.automatic)      // 1
    let returnedSystemBarItemImage = systemBarItemImage?.withRenderingMode(.alwaysOriginal) // 2
//  let returnedSystemBarItemImage = systemBarItemImage?.withRenderingMode(.alwaysTemplate) // 3
    systemBarItem.image = returnedSystemBarItemImage

    mainTabBar.tintColor = .customYellow
    mainTabBar.barTintColor = .customGreen
}

1. automatic

default값이다.

Custom 이미지 : 일반 화면에서는 잘 보이지만, Tab Bar 영역에 올린 이미지는 날아간다.
System 이미지 : 일반/Tab Bar에서 모두 tintColor가 잘 적용된다.

2. alwaysOriginal

Custom 이미지 : 원본 이미지의 색상을 사용하므로 tintColor가 적용되지 않는다.
System 이미지 : 사람 부분에 원본 이미지 (흰색)이 적용되고, 나머지 부분에만 tintColor가 적용된다.

이상하게 System 이미지에는 tintColor가 적용된다?!

위에서 살펴본대로 alwaysOriginal을 사용하면 원래는 template image를 만들지 않으므로
이미지에 tintColor가 적용되지 않아야 하지만..

SF Symbol을 활용한 system 이미지는 자체 template image가 있어서

tintColor가 나타나는 거라고 예상된다.

3. alwaysTemplate

원본 이미지의 색상을 무시하고, tintColor를 적용할 수 있는 template image를 만든다.

Custom 이미지 : 원본 이미지의 색상이 모두 무시되므로 이미지 전체 영역에 tintColor가 적용되어 이미지가 날아간다.
System 이미지 : 일반/Tab Bar에서 모두 tintColor가 잘 적용된다.

참고 - Assets에서 Rendering Mode 설정하기

특정 이미지에 대한 Rendering Mode를 직접 설정할 수 있다.

- Reference

예제 코드 > GitHub Repo
Apple Developer Documentation > UIImage.RenderingMode
Apple Developer Documentation > Article - Providing images for different appearances
Apple Developer Documentation > UIImageView - tintColor

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[mailto] 기본 메일 앱 및 이메일 템플릿 띄우기 (간단)

Applecider — Thu, 22 Dec 2022 07:00:35 +0900

대부분의 상용 앱에는 My 탭 또는 설정 탭의 '문의하기' 항목이 있다.

문의하기를 누르면 Mail 앱 (시스템 기본 앱)을 띄우면서 이메일을 작성하도록 사용자를 유도할 수 있는데,

이때 수신자 메일주소, 제목, 내용에 미리 원하는 값을 채워서 이메일 템플릿을 만들 수 있다.

private func showEmailWithTemplate(subject: String, body: String) {
    // ✅ 이메일 템플릿 설정
    var components = URLComponents()
    components.scheme = "mailto" 
    components.path = "whatWeEat_help@gmail.com" // 메일 주소
    components.queryItems = [
          URLQueryItem(name: "subject", value: subject), // 메일 제목
          URLQueryItem(name: "body", value: body)        // 메일 내용
    ]
    
    guard let url = components.url else { return }

    // ✅ 현재 앱에서 기본 이메일 앱을 띄움
    if UIApplication.shared.canOpenURL(url) {
        UIApplication.shared.open(url, options: [:], completionHandler: nil)
    }
}

// 사용부
let subject = "Menu Inquiry"
let body = """
              Hello! Please fill out the following template.
           """ + "\n\n"
       +   """
              1. Menu Name
              2. User Email
              3. Inquiry
           """ 

showEmailWithTemplate(subject: subject, body: body)

AppStore 앱 또는 Settings 앱을 띄우는 것과 비슷하게

UIApplication.shared.canOpenURL()로 이동이 가능한지 확인하고,
UIApplication.shared.open()으로 앱을 띄우는 방식이다.

위 코드로 Mail 앱을 띄웠을 때 나타나는 내용은 아래와 같다.

친절하게 Mail 앱에 이미 키보드 처리가 되어있기 때문에 별도로 키보드 올림/내림 처리를 할 필요가 없다.

검색 키워드 - ios mailto scheme

Launch Apple Mail App from within my own App?

- Reference

Stackoverflow > Launch Apple Mail App from within my own App?

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[attributedString] UILabel의 텍스트 커스텀하기 - font, underline, strike, alignment, lineHeight, paragraphStyle

Applecider — Wed, 21 Dec 2022 07:00:57 +0900

나중에 복붙해서 사용하려고UILabel의 attributedString 설정값을 간단히 정리해봤다.

private lazy var customLabel: UILabel = {
    let label = UILabel()
    label.translatesAutoresizingMaskIntoConstraints = false
    label.numberOfLines = 0

    let paragraphStyle = NSMutableParagraphStyle()
    paragraphStyle.lineBreakMode = .byTruncatingTail
    paragraphStyle.lineBreakStrategy = .hangulWordPriority
    paragraphStyle.alignment = .center
    paragraphStyle.minimumLineHeight = 21

    // ✅ NSMutableAttributedString 및 paragraphStyle 활용
    let fullText = "안녕하세요. 애플사이다의 iOS 개발일지 블로그에 오셨네요. 메리 크리스마스. 저는 이따 아바타2 보러가요. 그럼 이만!"
    let attributedText = NSMutableAttributedString(
        string: fullText,
        attributes: [.foregroundColor: UIColor.darkGray,
                     .font: UIFont.systemFont(ofSize: 18, weight: .bold),
                     .underlineStyle: NSUnderlineStyle.single.rawValue,
//                     .strikethroughStyle: NSUnderlineStyle.single.rawValue,
//                     .strikethroughColor: UIColor.systemRed,
                     .paragraphStyle: paragraphStyle])

    // ✅ 텍스트 일부에 효과주기
    attributedText.addAttribute(.font,
                                value: UIFont.systemFont(ofSize: 11),
                                range:(fullText as NSString).range(of: "그럼 이만!"))

    label.attributedText = attributedText
    return label
}()

- Reference

예제 코드 > GitHub Repo
Apple Developer Documentation > UILabel
관련 포스트
- [줄바꿈] lineBreakMode 및 lineBreakStrategy 차이점
- [줄바꿈] UILabel attributedText에 lineBreak 설정

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[줄바꿈] UILabel attributedText에 lineBreak 설정 - paragraphStyle.lineBreakMode

Applecider — Tue, 20 Dec 2022 07:00:25 +0900

지난 포스트 [줄바꿈] lineBreakMode 및 lineBreakStrategy 차이점을 작성하면서

UILabel에 attributedText를 사용하는 경우에는

label.lineBreakMode가 무시되고,

attributedText의 paragraphStyle.lineBreakMode를 설정해야 한다는 걸 봤다.

근데 실험해보니 잘못된 정보였음..

둘 다 사용했을 때 마지막에 설정한 값으로 적용되는 것을 확인했다.

아래처럼 2개 방법으로 코드를 작성해서 비교해봤다.

방법-1. label.lineBreakMode 먼저 -> paragraphStyle.lineBreakMode 나중에 설정
방법-2. paragraphStyle.lineBreakMode 먼저 -> label.lineBreakMode 나중에 설정

private func setupKoreanLayout() {
    // 방법-1. 먼저
    hangulKoreanLabel.lineBreakMode = .byTruncatingMiddle // ✅
    hangulKoreanLabel.lineBreakStrategy = .pushOut

    let paragraphStyle = NSMutableParagraphStyle()
    paragraphStyle.lineBreakMode = .byTruncatingTail // ✅
    paragraphStyle.lineBreakStrategy = .hangulWordPriority

    let text = "이 프로퍼티는 줄임표(…)로 잘라내거나 텍스트를 크으으을리핑하는 등 텍스트 시스템이 해당 컨테이너에 맞지 않는 줄을 배치하는 방법을 제어합니다. 이 속성은 줄임표(…)로 잘라내거나 텍스트를 클리핑하는 등 텍스트 시스템이 해당 컨테이너에 맞지 않는 줄을 배치하는 방법을 제어합니다. 하하."
    let attributedText = NSMutableAttributedString(
        string: text,
        attributes: [.foregroundColor: UIColor.darkGray,
                     .font: UIFont.systemFont(ofSize: 14),
                     .underlineStyle: NSUnderlineStyle.single.rawValue,
                     .paragraphStyle: paragraphStyle])
    hangulKoreanLabel.attributedText = attributedText

    // 방법-2. 나중에
    // hangulKoreanLabel.lineBreakMode = .byTruncatingMiddle // ✅
    // hangulKoreanLabel.lineBreakStrategy = .pushOut
}

방법-1 결과

나중에 호출된 paragraphStyle.lineBreakMode의 설정값이 적용됐다.

방법-2 결과

나중에 호출된 label.lineBreakMode의 설정값이 적용됐다.

공식문서에 따르면 시스템이 label.lineBreakMode를 무시해서 방법-1과 동일한 결과가 나올 거라고 예상했는데

아니었음..

결론

둘 다 사용했을 때 마지막에 설정한 값으로 적용되는 것을 확인했다.

UILabel - lineBreakStrategy 공식문서에 보면

attributedString이 있는 경우, 시스템은 label.lineBreakMode를 무시하므로
attributedString의 paragraphStyle.lineBreakMode를 설정해야 한다고 설명하고 있는데..

공식문서가 틀린 것 같다..?

아니면 예제 코드에서 NSParagraphStyle 대신 NSMutableParagraphStyle을 써서 그렇거나.. (아마 이게 이유인듯)

개인적으로 혼동을 막기 위해 attributedString을 사용할 때는 paragraphStyle.lineBreakMode를 사용하도록

통일하는 게 좋은 방법인 것 같다.

검색 키워드 : label attributedText lineBreak

- UILabel attributedText with multiple line break modes

- Reference

예제 코드 > GitHub Repo
Apple Developer Documentation > NSParagraphStyle - lineBreakMode
Apple Developer Documentation > NSParagraphStyle - lineBreakStrategy
Apple Developer Documentation > UILabel - lineBreakMode
Apple Developer Documentation > UILabel - lineBreakStrategy

[줄바꿈] lineBreakMode 및 lineBreakStrategy 차이점 - 둘 다 필요할지도

Applecider — Sun, 18 Dec 2022 07:00:32 +0900

lineBreakMode, lineBreakStrategy는 둘 다 필요할까?

결론부터 말하자면 원하는 스타일에 따라 둘 다 필요할 수도 있다.

UILabel의 텍스트가 길어질 때
한글 단어 기준으로 줄바꿈하기 위해 lineBreakStrategy = .hangulWordPriority를 사용한 적이 있었는데,

이때 lineBreakStrategy가 lineBreakMode를 대체 가능한 거라고 착각했다.

근데 아니었음..

둘의 차이점을 알아보자.

결론

아래 같은 스타일로 구현하고 싶다면

lineBreakMode, lineBreakStrategy 둘 다 필요하다.

1. lineBreakMode

공식문서를 보자.

NSParagraphStyle - lineBreakMode

음? 공식문서에 첫 문단에 정답이 있었다.

linebreakMode는 텍스트가 컨테이너보다 넘칠 때, 텍스트를 배치하는 방법을 조절한다.
예를 들면 텍스트 끝부분을 ...으로 자르거나, 텍스트를 자르는 방법이 있다.
lineBreakStrategy와 다른데,
lineBreakStrategy는 줄바꿈을 문단 중 어디에 배치할지를 조절한다.

직접 Label에 Enum - NSLineBreakMode 를 적용해보면 쉽게 이해할 수 있다.

예제 코드를 작성해봤다.

모두 numberOfLine = 3으로 설정했다.

byWordWrapping : 영단어 (Word) 단위로 감싸서 줄바꿈을 한다. 줄바꿈으로 인해 영단어가 쪼개지지 않도록 한다는 뜻
byCharWrapping : 문자 (Charactor) 단위이므로 줄바꿈으로 인해 영단어가 쪼개진다.
byTruncatingTail : 텍스트 끝부분을 ...으로 자른다. 그리고 영단어가 쪼개지지 않는다.
그래서 이커머스 앱의 상품목록 화면에서 이 값을 주로 사용한다. ✨✨✨
엥.. 원래 한글 단어는 쪼개지는 문제가 생겼었는데 애플이 업데이트해준 건가.. 왜 멀쩡하지?
byTruncatingMiddle : 컨테이너 마지막 줄에서 중간 부분을 ...으로 표시한다.
byClipping : 영단어가 쪼개지지 않고, ... 없이 텍스트가 끊기는 곳에서 문자가 잘린다.

UILabel의 default lineBreakMode값은 뭘까?

NSLineBreakMode 문서를 뒤져봐도 안나왔는데, 알고 보니 UILabel - lineBreakMode 문서가 따로 있었다.

attibutedText 미사용 시 : lineBreakMode가 text 프로퍼티의 문자열 전체에 직접 적용된다.
attributedText 사용 시 : lineBreakMode가 attributedText 프로퍼티의 문자열 전체에 직접 적용된다.
일부 문자열에만 적용하려면 별도의 attributedText를 생성하고 lineBreakMode를 적용해야 한다.
NSParagraphStyle 프로퍼티는 단어가 아니라 문단 전체에 적용된다.
- ParagraphStyle 설정값이 text/attributedText 설정값보다 우선시된다는 뜻인듯?
- ParagraphStyle : attributedText에 적용되는 문단 스타일이다.
default는 .byTruncatingTail이다.

2. lineBreakStrategy

위에서 설명했듯이 lineBreakStrategy는 줄바꿈을 문단 중 어디에 배치할지를 조절한다.

공식문서 NSParagraphStyle - lineBreakStrategy를 보자.

lineBreakMode와의 차이점을 다시 설명한다.
lineBreakMode가 multiple lines를 지원하지 않는 .byClipping인 경우, lineBreakStrategy를 무시한다.
default값은 none이라고 되어있는데, UILabel - lineBreakStrategy을 보면 default값은 .standard이다.

lineBreakStrategy의 종류는 enum이 아니라 structure 및 static 프로퍼티로 구현되어있다.

lineBreakStrategy가 비교적 최근에 추가돼서 그런듯?

Structure - NSParagraphStyle.LineBreakStrategy를 보자.

이것도 예제 코드를 보면 쉽다.

.hangulWordPriority : 줄바꿈으로 인해 한글 단어가 쪼개지지 않도록 한다.
lineBreakMode의 byTruncatingTail (default)만 쓰면, 영단어는 쪼개지지 않지만 한글 단어가 쪼개지는 문제가 있었다.
그래서 애플이 친절하게 이걸 추가해줬다. 당연히 한글을 쓰는 대부분의 상용 앱에서 활용한다. ✨✨✨
.pushOut : 마지막 줄에 남겨진 단어가 동떨어지는 것을 방지하기 위해 개별 line을 밀어낸다.

3. lineBreakMode + lineBreakStrategy 둘 다 쓰기

그렇다면 lineBreakMode = .byWordWrapping / .byTruncatingTail / .byTruncatingMiddle에다가

모두 lineBreakStrategy = .hangulWordPriority를 적용하면 어떻게 될까?

당연히 모두 한글 단어를 쪼개지 않은 채로 줄바꿈된다.
원하는 스타일에 따라 사용하면 될듯
.byWordWrapping + .hangulWordPriority : 텍스트 끝이 ... 처리되지 않는다.
.byTruncatingTail + .hangulWordPriority : 텍스트 끝이 ... 처리된다.
.byTruncatingMiddle + .hangulWordPriority : 컨테이너 마지막 줄에서 텍스트 중간이 ... 처리된다.

예제 코드는 GitHub repo에 업데이트했다.

참고로 검색하면서 UILabel에 attributedText를 사용하는 경우에는

label.lineBreakMode가 무시되고,

attributedText의 paragraphStyle.lineBreakMode를 설정해야 적용된다는 걸 봤다.

다음에 포스팅할 예정이다.

- 검색 키워드 : label attributedText lineBreak

- UILabel attributedText with multiple line break modes

- Reference

예제 코드 > GitHub Repo
Apple Developer Documentation > NSParagraphStyle - lineBreakMode
Apple Developer Documentation > NSParagraphStyle - lineBreakStrategy
Apple Developer Documentation > UILabel - lineBreakMode

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[PTR] RefreshControl 및 ImageView에 Gif 이미지 넣기

Applecider — Sat, 10 Dec 2022 15:51:07 +0900

PTR (Pull To Refresh) 기능을 구현할 때 기본 RefreshControl을 사용할 수도 있지만 이번에는 Gif 파일을 넣어서 만들어봤다.

Gif 이미지 처리에 대한 포스팅이 별로 없어서 기록해본다.

이건 Apple에서 제공하는 default RefreshControl이다.

Gif를 적용한 RefreshControl을 아래처럼 만들어봤다.

RefreshControl의 목적은 "지금 Loading 중임. 잠시만 기다려" 이므로 좀 더 Loading 효과스러운 Gif를 써도 된다.

이번에는 애니메이션을 설명하려고 호머 심슨 Gif를 가져왔다.

3단계만 있으면 된다. 매우 간단하다.

1. Gif를 넣어서 ImageView 초기화

2. RefreshControl에다가 Gif 올리기

3. CollectionView에다가 RefreshControl 넣기

1. Gif를 넣어서 ImageView 초기화

먼저 Gif 파일을 드래그해서 Bundle에 넣는다.

이제 UIImageView initializer를 생성한다.

Asset 이미지를 활용할 때 UIImageView(named:) 형태로 초기화하니까

네이밍을 비슷하게 UIImageView(gifNamed: "Simpson")로 하는 게 이쁠 것 같다.

extension UIImageView {
    convenience init?(gifNamed: String, animationDuration: Double = 1.0) { 
        // ✅ gifURL = 사용할 gif 파일의 경로
        // ✅ CGImageSourceCreateWithData = gif 데이터를 통해 CGImageSource를 만들겠다
        guard let gifURL = Bundle.main.url(forResource: gifNamed, withExtension: "gif"), 
              let gifData = try? Data(contentsOf: gifURL),
              let source =  CGImageSourceCreateWithData(gifData as CFData, nil) else { 
            return nil
        }
        
        var images = [UIImage]()
        // Finder에서 gif 파일을 열면 여러 장의 이미지가 들어있다
        // ✅ gif 파일을 구성하는 이 이미지들의 개수 == CGImageSourceGetCount
        let imageCount = CGImageSourceGetCount(source)
        
        for index in 0..<imageCount {
            // ✅ for문을 통해 개별 이미지에 접근할 거다 (타입 변환 CGImage => UIImage)
            if let image = CGImageSourceCreateImageAtIndex(source, index, nil) {
                images.append(UIImage(cgImage: image))
            }
        }
        
        // ✅ gif 이미지들을 담고 있는 UIImageView를 만든다
        // duration == gif 애니메이션이 지속될 시간 (1초가 적당한듯)
        let animatedImage = UIImage.animatedImage(with: images, duration: animationDuration)
        self.init(image: animatedImage)
    }
}

UIImageView extension으로 initializer를 추가한다.
초기화 과정에서 gif 파일이 유효하지 않은 등 초기화에 실패할 수 있으므로 실패가능한 이니셜라이저로 만들었다.
맨 위의 guard문부터 보자.
사용할 gif 파일의 경로를 받아서 -> gif 파일을 Data 타입으로 만들고 -> 그걸로 CGImageSource를 만든다.
보통 Finder에서 gif 파일을 열면 애니미이션을 구성하는 여러 장의 이미지가 들어있다.
그 이미지들이 CGImageSource라고 보면 된다.
CGImageSource의 개수 (imageCount)만큼 for문을 돌린다.
그래서 개별 이미지에 접근해서 CGImage를 우리가 사용할 UIImage로 바꾸고, images 배열에 넣어준다.
그래서 만든 images 배열을 UIImage의 animatedImage에 넣어서 애니메이션으로 만들고,
그걸 UIImageView의 image 프로퍼티에 넣어주면 된다.
네이밍만 보면 image 프로퍼티에 1개 이미지만 넣어야할 것 같은데 아니었음
animatedImage를 만들 때 duration을 지정해주는데, "애니메이션 1 cycle이 지속될 시간"이라고 보면 된다.
즉, 첫번째 이미지부터 마지막 이미지까지를 몇 초 이내에 보여줄지이다. (해보니까 완전히 딱 떨어지지는 않음)
RefreshControl에 넣을 거면 1초가 적당하다.

2. RefreshControl에다가 Gif 올리기

위에서 만든 ImageView를 RefreshControl에다가 올려주자.

final class SimpleRefreshControl: UIRefreshControl { // UIRefreshControl 상속
    override init() {
        super.init()
        
        configureLayout()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    func configureLayout() {
        // ✅ 위에서 만든 UIImageView init 활용
        // bundle에 넣은 gif 파일이름 입력 ("simpson")
        guard let loadingImageView = UIImageView(gifNamed: "simpson") else { return }
        
        // ✅ RefreshControl의 subview로 추가
        addSubview(loadingImageView) 
        loadingImageView.snp.makeConstraints { make in
            make.center.equalToSuperview()
            make.width.equalTo(63.0)
            make.height.equalTo(45.0)
        }
    }
}

Custom RefreshControl 클래스를 만든다.
위에서 만든 UIImageView initializer를 활용한다.
gif 파일이름 "simpson"을 넣어서 loadingImageView를 초기화했다.
그다음 RefreshControl 위에 addSubview를 하고, constraints를 설정한다.
imageView 크기가 너무 크지 않으면 center 정렬로 맞추면 된다.

3. CollectionView에다가 RefreshControl 넣기

ScrollView 또는 CollectionView에 이미 refreshControl 프로퍼티가 있다.

그래서 refreshControl을 만들어서 거기에 넣어주면 끝! 매우 간단하다.

ActivityControl과 다르게 startAnimating 같은 걸 호출할 필요도 없다.

사용자가 최상단에서 스크롤을 내리면 자동으로 실행된다.

실행을 멈출 때 refreshControl.endRefreshing() 만 호출하면 끝!

final class MainViewController: UIViewController {
    // ✅ 아까 만든 custom refreshControl
    private lazy var refreshControl: SimpleRefreshControl = {
        let refreshControl = SimpleRefreshControl()
        refreshControl.addTarget(self, action: #selector(pulledToRefresh), for: .valueChanged) 
        return refreshControl
    }()
    
    private lazy var mainCollectionView: UICollectionView = {
        let flowLayout = createListFlowLayout()
        let collectionView = UICollectionView(frame: .zero, collectionViewLayout: flowLayout)
        collectionView.refreshControl = refreshControl // ✅ 참 쉽죠?
        collectionView.dataSource = self
        collectionView.register(MainCell.self, forCellWithReuseIdentifier: "MainCell")
        return collectionView
    }()
    
    // ✅ pull 했을 때 할 일
    @objc private func pulledToRefresh() {
        print("!!!Refresh!!!")
        
//        mainViewModel.reset() // ViewModel 통해 API 재요청 (코드 생략)
        didReceiveResponse()    // API 호출 완료됨 (가정)
    }
    
    func didReceiveResponse() {
        // ViewModel 통해 API response 확인한 시점에 숨기기 (코드 생략)
        // ✅ API 요청 후 3초 뒤 response가 도착함 (가정)
        DispatchQueue.main.asyncAfter(deadline: .now() + 3.0) { [weak self] in 
            // 애니메이션 1cycle을 1초로 설정했으므로 약 3cycle이 실행됨
            self?.refreshControl.endRefreshing() 
        }
    }
}

RefreshControl을 CollectionView에 넣고, PTR에 할 일을 pulledToRefresh()에 구현하면 된다.
보통 PTR할 때 ViewModel을 통해 API를 재요청하고,
API Response가 도착하면 refreshControl.endRefreshing()을 호출해서 숨겨준다.
didReceiveResponse 메서드를 보자.
예제에서 API를 구현하지 않았기 때문에 DispatchQueue의 asyncAfter 메서드를 임시로 호출했다.
deadline 매개변수로 .now() + 3.0을 넣어줬는데
UIImageView에서 animationDuration을 1초 (애니메이션 1cycle = 1초)로 설정했으므로
refreshControl이 1번 나타날 때 애니메이션은 약 3cycle이 실행된다. (해보니까 실제로는 3.5 cycle 정도 실행됨)

전체 코드는 GitHub Repo를 참고

만약 imageURL로 Gif 띄우기 등을 하고 싶다면

kaishin/Gifu 라이브러리가 유명한듯

구글링 키워드 : load gif image on refreshControl

Stack overflow - Add animated Gif image in Iphone UIImageView

Stack overflow - How to load GIF image in Swift?

- Reference

예제 코드 > GitHub Repo
Apple Developer Documentation > UIRefreshControl
Stack overflow - How to load GIF image in Swift?
Stack overflow - Add animated Gif image in Iphone UIImageView
GitHub > kaishin/Gifu 라이브러리

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Redirect] 설정 앱을 띄워서 특정 앱의 설정 변경하기 (간단)

Applecider — Mon, 14 Nov 2022 07:00:08 +0900

대부분 앱의 설정 화면에서, 또는 특정 기능을 사용하기 직전에

사용자가 Push Notification, 광고 추적 허용 등의 설정값을 변경할 수 있도록 기본 설정 앱 (Settings 앱)을 띄워준다.

덕분에 사용자가 설정 앱을 열고, 특정 앱을 찾아볼 필요가 없다.

구글링으로 간단히 찾을 수 있었다.

설정 앱에서 특정 앱 확인하기

검색 키워드 : ios how to show settings app

Stack overflow > Opening the Settings app from another app에 나온 대로 해보니 잘 실행된다.

    private func showAppSettings() {
        guard let settingsURL = URL(string: UIApplication.openSettingsURLString) else { return }
        UIApplication.shared.open(settingsURL)
    }

보통 redirect할 때 UIApplication.shared.canOpenURL() 메서드로 확인하는 절차를 거치지만,
설정 앱 (Settings 앱)은 아이폰 기본 앱이므로 생략했다.

코드 중 settingsURL을 생성하는 부분에서 사용된 타입 프로퍼티 openSettingsURLString를 살펴보자.

원하던 내용이 모두 설명되어있다.

만약 해당 앱이 출시 이전이라서 AppStore를 통해 설치한 게 아니라면, 설정 앱으로 이동하는 것까지만 한다.

참고 - Stack overflow 내용 중 prefs를 설정해서 이동하는 방법도 있는데,
이 방법을 사용하면 Apple이 앱을 reject 시킨다고 한다.

- Reference

Stack overflow > Opening the Settings app from another app
Apple Developer Documentation > openSettingsURLString

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Redirect] 업데이트 버튼 탭하면 사용자에게 AppStore 앱 띄우기 (간단)

Applecider — Fri, 11 Nov 2022 07:00:51 +0900

대부분 앱의 설정 화면에서 현재 설치된 버전 정보를 알 수 있다.

그리고 해당 앱의 최신버전이 나왔다면 업데이트 버튼을 탭했을 때, 사용자에게 AppStore 화면을 띄워준다.

덕분에 사용자가 AppStore에서 해당 앱을 직접 검색할 필요가 없다.

구글링을 통해 간단히 방법을 찾을 수 있었다.

예시 - 당근마켓 설정화면

검색 키워드 - ios how to link appstore

Stack overflow > How to link to apps on the app store에서 시킨대로 했더니 잘 된다.

    @objc private func updateButtonTapped() {
        let appID = "1234"
        let appStoreURL = "itms-apps://itunes.apple.com/app/id\(appID)"
        guard let appStoreURL = URL(string: appStoreURL),
              UIApplication.shared.canOpenURL(appStoreURL) else { return }
        UIApplication.shared.open(appStoreURL)
    }

- Reference

Stack overflow > How to link to apps on the app store

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

책 <함께 자라기> 리뷰 - 팀과 함께 학습하는 방법

Applecider — Mon, 7 Nov 2022 00:06:01 +0900

김창준 저 <함께 자라기>를 읽었다. (도서 링크)

회사에서 자기 계발에 대해 얘기하다가 팀 리더의 추천으로 책을 읽게 되었다.

이 책에서 저자는 애자일의 핵심은 함께 자라기, 즉 ‘학습’과 ‘협동’이라고 말한다. 팀원들과 신뢰를 쌓고, 팀이 함께 학습하고 현업에 성공적으로 적용하기 위해 필요한 것들을 설명하며, 다양한 성공/실패 예시를 담고 있다.

먼저 한국인이라면 익숙할 여러 교육 철학을 저자가 정면으로 비판해서 웃겼다. 처음에 무조건 도인이 시키는 대로 따라 하다 보면 내공이 쌓이고, 결국 도인의 비법을 전수받아 득도한다는 유명한 이야기가 사실은 허무맹랑한 판타지이고, 이 메타포로 인해 많은 교육적 문제가 생겼고, 심지어 이 미명 하에서 교육적 폭력이 자행되어왔다는 내용이 있는데, 크게 공감이 갔고 동시에 씁쓸했다. 이어지는 좋은 학습의 방법과 난이도에 대한 설명이 유익했다.

이외에도 주니어 개발자로서 가지고 있었던 조급함을 내려놓는 데도 큰 도움을 받았다. 당장 성과를 내는 것보다 장기적으로 성장하는 것이 중요하다는 것 (아래의 학습 프레임과 실행 프레임 챕터 참고), 그리고 개발 조직은 실수를 바탕으로 성장하는 문화라는 것 (아래의 실수는 예방하는 것이 아니라 관리하는 것이다 챕터 참고)에서 용기를 얻었다.

요약과 개인적인 감성이 뒤섞인 리뷰를 남겨봤다. (책에서 인용한 문장은 “”로 표시했다.)

1부. 자라기

야생 학습

‘학교 학습’과 상반된 개념으로 ‘야생 학습’이 있다. 저자가 이 책에서 설명하는 학습은 ‘야생 학습’이다. 여러 명의 멘토가 상반된 조언을 한다면, 현실과 비슷한 문제 상황을 맞닥뜨렸다고 생각해야 한다. 오히려 상반된 의견과 정보 속에서 스스로 생각하는 훈련을 할 기회로 삼아야 한다.

이외에도 야생 학습의 특징은 아래와 같다.

협력적이다. 비순차적이다. 참고 자료가 무한하다.
명확한 평가가 없고, 정답이 없다.
목표가 불분명하고 바뀌기도 한다.

"불확실성이 높은 환경일수록 야생 학습이 중요하다."

경력과 성과의 상관관계

소프트웨어 엔지니어의 실력은 겉으로는 기술자격, 학력 등이 결정하는 것 같아 보이지만 사실상 ‘경험’이라는 요소가 가장 결정적인 역할을 한다. 이때 ‘경험’이란 질적으로 얼마나 폭넓고 다양했는지를 의미한다.

“경력이 10년인 개발자가 2년인 개발자보다 더 우수하지 않았다. 경력과 생산성은 아무 상관관계가 없었다. 단, 언어를 접한 경험이 6개월 미만인 개발자들은 전반적으로 나머지 개발자들보다 성적이 저조했다. (...) 즉, 최소한도의 경험치만 넘어가면 경력 연수와 실제 직무 성과의 상관성이 생각보다 낮다."

잘 뽑는 것 이상으로 뽑은 사람을 성장시키는 것이 중요하다. “최근 일주일 동안 업무 능력 향상을 위해 얼마나 시간을 쓰는지 물었는데, 이 시간의 양과 직무 성과 간에 통계적으로 유의미한 양의 상관성이 있었다. 그들이 자주 하는 수련으로는 ‘머릿속에서 시뮬레이션하기 (클라이언트와 어려운 대화 상황을 머릿속에 그리고, 가능한 시나리오를 탐색해 봄)’, ‘피드백 요청하기’ 등이 있었다.

몇 년 전 ‘1만 시간 법칙’이 유행했었다. 여기서 말하는 1만 시간은 종종 경력/근무시간으로 오인되기도 하는데, ’자신의 기량을 향상시킬 목적으로 하는 의도적인 수련’을 한 시간을 말한다.

하지만 업무를 하면서도 의도적 수련을 할 수 있는 방법이 있다. “피드백을 짧은 주기로 얻는 것”, 그리고 “실수를 교정할 기회가 있는 것”이다. 이 환경에서 학습 효과가 훨씬 좋다.

자기계발은 복리로 돌아온다

주기적인 회고가 중요한데, 이때 자기계발을 얼마나 했는지 되짚어봐야 한다. “현재 나에게 무엇을 투자했느냐가 1년, 혹은 2년 후의 나를 결정한다고 느끼기 때문이다.”

“잡코리아의 2012년 조사에 따르면 직장인의 하루 평균 자기계발 시간은 1~2시간이 54%, 1시간 미만 34%, 2~3시간 9%, 3시간 이상 3% 수준이었다. (…) 하루 평균 1시간도 투자하지 않는 사람은 자기계발이란 면에서 직장인의 하위 1/3에 속하는 셈이다. 무서운 사실은 이게 축적이 되면 엄청난 차이를 만들 거라는 점이다. 자기가 습득한 지식이나 능력은 복리로 이자가 붙기 때문이다.”

비슷한 맥락에서 저자는 일반적 조직과 학습하는 조직의 차이를 아래 그림으로 나타냈다.

“내가 만든 결과물을 나의 일부로 만들어서 다음 단계에 보탬이 되도록 이용해먹는 것이다. 결과물이 다음 단계의 도구가 된다.”

왼쪽 - 일반적인 조직 / 오른쪽 - 복리 조직

학습 프레임과 실행 프레임 ✨

무작위로 2개 그룹을 나누고, 그림 그리는 활동에 대해 다르게 안내하는 실험을 진행했다.

실행 프레임: 당신이 얼마나 그림을 잘 그리는지, 창의성을 평가하여 점수를 매길 것이라는 안내

학습 프레임: 평소에 안그려봤던 방식을 실험해보는 시간이라는 안내

즉, 실행 프레임은 ‘잘하기’에 초점을 맞추고, 학습 프레임은 ‘자라기’에 초점을 맞춘다. (…) 결과적으로 학습 정도를 비교하면 학습 프레임의 실험자들이 훨씬 학습 효과가 좋다. 이 결과는 사회학, 심리학, 교육학 등 여러 분야에서 여러 연구를 통해 거듭 발견된 현상이다.

“여기서 말하는 실행 프레임은 사람들이 현재 주어진 과업이 뭔가 좋은 성과를 내는 걸로 생각하는 틀을 말한다. 학습 프레임은 현재 주어진 과업이 내가 얼마나 배우느냐로 여기게 되는 틀을 말한다. 업무 중에 실행 프레임으로만 세상을 보는 사람들은 아마 내가 인정받아 다음 단계로 올라가냐 아니냐에 관심이 많을 것이다. 만약 다음 단계로 가지 못하고 떨어지면 자신이 속한 곳에서의 학습 기회를 보기보다 다른 경쟁체제와 다른 타이틀, 다른 자리에 관심을 둘 것이다. 실행 프레임은 당신의 목표가 학습을 통한 성장이라면 불리한 선택이다.”

주니어 개발자로서 빨리 조직에 기여하고 싶다는 조급함과 초조함을 느끼고 있었는데, 이 내용을 보고 마인드셋을 바꾸게 되었다. 장기적으로 성장하는 것이 나에게도, 조직에도 나은 길이라는 확신을 갖게 되었다.

생각해보면 절대 실수가 발생해서는 안 되는 현장 (건설 현장, 병원, 군대 등)에서는 실수 예방 문화가 형성될 수밖에 없다. 실수가 곧 인명 사고로 이어질 수 있기 때문이다. 그래서 위계적인 문화, 군대 문화, 수직적인 문화, 태움 문화 등의 수식이 따라붙는다.

그래서 인명 피해로 이어질 위험이 낮은 IT 기업의 개발 조직은 상대적으로 실수에 대해 관대할 수 있다.

가장 학습하기 힘든 직업이 살아남는다

“우리의 일자리가 인공지능에 대체되지 않으려면, 아래처럼 학습하기 힘든 환경에서 학습하기 힘든 주제들을 골라야 하는 상황이 됐다.

목표가 모호하고 주관적이고 동적이다. 매 순간 선택지가 불확실하다.
내가 목표에 얼마나 근접했는지 알기 어렵다.
열린 시스템 속에서 일한다.
과거의 선택과 결과에 대한 구조화된 기록이 별로 없다.

이런 환경은 소위 ‘암묵지’, ‘직관’ 같은 것들이 작동하는 회색 영역이다. 자신이 왜 이런 선택을 했는지 쉽게 설명할 수 없는 것들이다.“

컴퓨터화에 병목이 되는 카테고리는 지각/조작, 창의적 지능, 사회적 지능이다.

우리는 내가 하는 일의 명칭이 무엇인지가 아니라 내가 실제로 매일 하는 일이 어떤 성격인지 주목해야 한다.

“현재 자신의 업무 상황 속에서 창의적으로, 사회적으로 (다른 사람의 생각과 마음에 관심을 갖고, 그들을 설득하고 협상하는 것) 일하지 않는 기간이 계속된다면 결국 자신의 커리어에 막대한 손해가 될 수 있다는 점이다. 혼자서 딱 정해진 일만 할 수 있는 환경이 축복이 아니라 저주가 될 수 있다.” 결론적으로 미래에는 암묵지와 직관을 잘 학습하는 사람이 높은 경쟁력을 가질 것이다.

당신이 제자리걸음인 이유

“의도적 수련이 가능하게 하려면 나의 실력과 작업의 난이도가 비슷해야 한다."

"아래 그림의 C부분에서 사람은 몰입을 경험하고, 학습 능력이 최대치가 된다. 교육학의 인지부하 이론도 이와 유사한데, 핵심은 적절한 난이도를 설정하는 것이다.”

현재 A (실력은 높은데 작업 난이도는 낮아서 지루함)라면 2개 방법이 있다. 실력을 낮추는 것 (평소 일하며 사용하던 보조 툴을 의도적으로 사용하지 않기, 컴파일 주기를 30초에서 5분으로 늘리기), 일의 난이도를 높이는 것 (하루 종일 걸리는 일을 1시간 내에 하기, 익숙한 작업을 새로운 언어로 진행해보기, 리팩터링하기, 자동화 테스트 달기, 직접 나만의 도구를 개발하기 ex. C파일에 로그를 삽입해서 스레드/프로세스의 동작을 쉽게 분석해주는 도구) 이렇게 안 해도 되는 업무를 자발적으로 했을 때 업무 성과와 직무 만족도가 높고, 번아웃을 적게 경험한다.

현재 C (실력은 낮은데 작업 난이도가 높아서 불안함)라면 마찬가지로 2개 방법을 쓰면 된다. 실력을 높이는 것 (스터디 참가, 교육 수강, 다른 전문가에게 도움 요청, 라이브러리 등 툴을 활용), 일의 난이도를 낮추는 것 (맡은 일의 가장 간단한 버전을 첫 번째 목표로 삼는 것)이다.

한 연구에서 피실험자를 A/B 그룹으로 나누어 어려운 문제, 쉬운 문제 순을 다르게 설정하여 코딩 테스트를 진행했다. 결과적으로 쉬운 문제를 먼저 푼 그룹의 결함률이 50% 이상 낮았다. 낮이도를 낮춘 결과 학습 효과, 동기 강화, 스트레스 감소, 자기 효능감 증가 등의 긍정적인 효과가 나타난 것이다.

위 전략을 취하려면 메타인지가 필요하다. 즉, 스스로 자신의 상태를 알아차려야 한다. (mindfulness)

프로그래밍 언어 배우기의 달인

저자는 “적극적 읽기”를 권한다. 무언가를 읽을 때 구체적인 질문이나 목적을 가지고 읽는 방법이다. 예를 들어 튜토리얼을 읽다가 이 정도면 프로그램을 작성할 수 있겠다는 생각이 들면 읽기를 멈추고, 코딩을 시작하는 방식이다.

프로그래머가 실제 업무할 때 남의 코드를 읽는 시간이 자신이 코드를 쓰는 시간보다 훨씬 많다. 따라서 좋은 코드를 많이 봐야 하며, 특히 표준 라이브러리 소스코드를 통해 해당 언어의 문화와 스타일을 익히는 것이 좋다.

주변에 있는 전문가를 활용하는 방법도 있다. 이때 구체적인 사건에 대해 말하도록 유도해야 한다. 예를 들어 특정 언어를 익힌 과정을 시간대별로 짚어가며 어떤 행동을 했는지, 암묵적인 의사결정과 상황판단이 무엇이었는지 추출해야 한다.

실수는 예방하는 것이 아니라 관리하는 것이다 ✨

이 챕터도 주니어 개발자로서 많은 위로를 받았다.

마이클 프레제는 회사의 실수 문화를 “실수 예방” 문화와 “실수 관리” 문화로 구분했다.

실수 예방은 행동에서 실수로 가지 않도록 요구한다. 즉 실수를 저지르지 말라고 요구한다.

하지만 이것은 불가능에 가깝다. “전문가도 1시간에 평균 3~5개의 실수를 저지른다.”

따라서 실수 관리의 관점은 이렇다. “실수는 어떻게든 할 수밖에 없다. (코딩하다가 == 대신 =을 작성) 대신 그 실수가 나쁜 결과 (서버가 죽음)가 되기 전에 일찍 발견하고 빨리 고치면 된다.”

실수 관리 문화에서는 실수를 한 사람을 비난하지 않고, 오히려 실수를 공개하고, 서로 실수가 빨리 회복되도록 돕고, 실수에 대해 서로 이야기하며 배우는 분위기가 형성된다.

“보통 회사가 실수 관리 문화에 가까울수록 회사의 수익성이 좋고, 혁신 정도가 더 높다. 실수가 없으면 학습하지 못하기 때문이다.”

나 홀로 전문가에 대한 미신

“어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요하다. 설사 나 혼자 하는 실천법이라 해도 그렇다. 예컨대 상사가 내가 하는 일을 보고 반대한다면 그를 설득해야 하며, 하다가 모르는 것이 생기면 주변에 물어봐야 하기 때문이다.”

“사회적 기술에서 ‘음의 기술’을 가진 사람도 존재한다. 예컨대 커뮤니케이션할수록 신뢰가 깨지는 사람을 말한다.”

“뛰어난 소프트웨어 개발자일수록 타인과 인터렉션에 더 많은 시간을 쓰며, 초보개발자들에게 조언할 때 사회적인 측면이 포함된다. 기술적인 조언만 하는 게 아니라는 뜻이다.

2부. 함께

신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가

2명의 디자이너가 광고를 디자인할 때, 피드백을 주고받는 방법에 따라 어떤 영향을 받았는지 실험을 했다.

작업을 공유하는 방식은 3개였다. (1) 1개 디자인을 만들고 1개를 공유, (2) 3개 디자인을 만들고 그중 본인이 가장 잘한 것을 골라서 1개를 공유, (3) 여러 개의 디자인을 만들고 여러 개를 공유

1번, 2번의 경우 작업 공유가 오히려 부정적인 결과를 낳았다. 공유에 대한 기대감보다 불안감을 가지게 되며, 상대방의 작업에 대해 솔직한 피드백을 내는 것을 조심스러워하고, 또 부정적인 평가를 받았을 때 보다 방어적인 태도를 갖게 됐기 때문이다. “상대가 부정적으로 들릴 만한 의견을 주면 그건 곧 나의 전문성에 대한 도전이 되는 것이다. 나의 작품이 하나밖에 없으니 ‘작업물 = 나’가 되는 것이다. 나름 방어를 해낸다고 해도 자기효능감이 떨어지기 쉽다.”

하향식 접근의 함정

“인공지능 연구에선 이 세상의 문제를 두 종류로 나눈다. 잘 정의된 문제 (well-defined)와 잘 정의되지 않은 문제 (ill-defined) (…)

전문가들은 잘 정의되지 않은 문제를 접하면 탑다운과 바텀업을 섞어서 쓴다. 비전문가는 탑다운이나 바텀업 중 한 가지에만 억지로 집착하려고 한다. (ex. 이번 문제는 복잡하니까 더 철저하게 계획하고 설계해야겠다.)”

“다음 그림은 엘리베이터 설계 시 전문가들의 문제해결 흐름을 보여주고 있다. 엘리베이터 설계에서 추상성이 높은 것은 알고리즘이나 기능 등이 될 테고, 추상성이 낮은 것은 모터의 가속도 제어나 회로 차원이 될 것이다. 전문가는 추상성의 정도를 오르락내리락거리고, 특히 탑다운과 바텀업의 방향이 전환되는 시점들에서 ‘아하 순간’이 찾아왔다.”

“비전문가일수록 자신이 애초에 세운 계획에 집착했다. 전문가일수록 자신의 계획을 수정한 횟수가 많았다.”

“한 번에 처리되는 일의 양 (batch size)을 줄여야 한다. 배치 사이즈를 줄여서 지속적 흐름을 만들고, 짧은 시간 내에 탑, 바텀을 오가게 한다.”

“흔히들 말하는 개발의 5단계도 비슷하다. 분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간에 얼마씩 배치할까로 고민하지 말고, 어떻게 해야 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다 갔다 할 수 있을까를 고민해야 할 것이다.“

구글이 밝힌 탁월한 팀의 비밀

구글은 뛰어난 팀의 특징을 찾기 위해 2년간 노력했다. 2015년 구글이 공개한 연구 결과의 일부는 아래와 같다.

팀에 누가 있는지 (전문가, 내향/외향, 지능 등)보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
5가지 성공적인 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이었다. 심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음을 말한다.
팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다. 단순히 우리팀의 현상황에 대해 열린 대화를 시작하는 것만으로 변화가 시작될 수 있다.

3부. 애자일

“애자일”은 불확실성이 클 때 우리가 어떻게 해야 하는지를 고민한 결과물이다. (…) 좀 더 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 더 일찍 피드백을 받는 것으로 정의할 수 있다.”

“학습과 협력이 애자일이 불확실성을 다루는 핵심적인 구동원리이다. (…) 불확실성이 높을수록 이동하면서 계속 배워나가야 한다.”

애자일의 씨앗

애자일의 핵심을 한 문장으로 표현하면 “고객에게 매일 가치를 전하라.”인데, 이 문장으로 여러 질문을 해볼 수 있다.

우리의 진짜 고객은 누구인가?
어떻게 점진적으로 가치를 전할 것인가? 어떻게 보다 일찍, 그리고 보다 자주 가치를 전할 것인가?
무엇이 가치인가? 지금 우리가 하고 있는 일이 정말 가치를 만드는 일인가?
지금 가장 높은 가치는 무엇인가?
비슷한 수준의 가치를 더 값싸게 전달하는 방법은?
가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가? 고객이 정말 가치를 얻고 있는가?

“성공하는 조직들에는 항상 뛰어난 애자일 코치가 있었다.”

코치의 특징 중 성장 사고관이 있다. 내가 노력만 하면 뭐든지 더 잘할 수 있다고 믿는 것이다. 고정 사고관과 상반되는 개념이다.

- Reference

YES24 > 김창준 저 <함께 자라기>

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[UserDefaults] object(forKey:) 및 bool(forKey:), string(forKey:)의 차이점은?

Applecider — Sun, 6 Nov 2022 07:00:02 +0900

UserDefaults 관련 코드를 보다가 UserDetaults.standard.string(forKey:) 메서드를 봤는데,

object(forKey:) 메서드와의 차이점이 궁금해서 검색해봤다.

UserDefaults, 기본적인 key-value pair와의 차이점에 대한 기본적인 설명은 생략했다.

UserDefaults 관련 메서드는 이렇게 다양한데,

저장값을 string, bool, integer, double 등 타입별로 구분하면 번거로우니까

한 방에 퉁쳐서 저장할 수 있는 object를 쓰는 게 낫지 않을까? 하는 생각을 했다.

-> 결론적으로 아니었음

UserDefaults 관련 메서드

공식문서

우선 공식문서를 살펴봤다.

대표적인 메서드인 object(forKey:) / bool(forKey:) / string(forKey:) 3개만 살펴보자.

일단 API가 추가된 시점은 모두 iOS 2.0으로 동일하다.

보통 더 최근에 나온 걸 많이 쓰니까.. 꼼수 쓰기 실패

각 메서드의 반환타입을 살펴보자.

object 메서드는 옵셔널 타입 Any?,

bool 메서드는 none-옵셔널 타입 Bool,

string 메서드는 옵셔널 타입 String?

직관적으로 옵셔널 타입을 반환하는 object / string 메서드는 특정 key에 저장된 값이 없으면 nil을 반환,

none-옵셔널 타입을 반환하는 bool 메서드는 다른 방식일 것을 예상할 수 있다.

공식문서를 확인해보니 예상대로였다. 웬일로..?

저장값이 없는 경우, bool 메서드는 false를 반환하고,

integer, double 메서드는 0을 반환한다.

또 신기한 점이 integer/double 메서드는 저장값이 true/false이면 각각 1/0을 반환한다. (반대로 bool 메서드로는 숫자값을 반환 불가)

직관적이지 않으므로 현업코드에서 실제로 사용할 것 같지는 않지만..

구글링 - bool 및 object 메서드의 차이점

공식문서를 봤으니 이제 구글링을 해보자.

- 검색 키워드 : when use userdefaults string(forKey:), how to store string in UserDefaults

CocoaCasts의 How to Check if a Value Exists in User Defaults in Swift 포스트가 유용했다.

bool(forKey:) 메서드는 특정 key에 저장된 값이 없거나, 저장된 값이 bool 타입이 아니면 false를 반환하므로

특정 key에 대한 값이 존재하는지 여부를 알고 싶을 때 적절하지 않다.

(반환값으로 false를 받았을 때, 이게 내가 저장한 값인지, 해당 key가 존재하지 않는지 구분이 불가하므로)

그래서 해결책으로 bool 메서드 쓰지 말고 object 메서드를 쓰라고 권한다.

object 메서드는 저장된 값이 없을 때 친절하게 nil을 반환해주기 때문이다.

예제 코드

이 아티클을 기반으로 예제 코드를 작성해봤다.

// 1️⃣ 저장
UserDefaults.standard.set(true, forKey: "KeyForBool")

// 2️⃣ 저장한 값 꺼내보기
let value = UserDefaults.standard.bool(forKey: "KeyForBool")
let value2 = UserDefaults.standard.object(forKey: "KeyForBool")
let typeCastedValue2 = value2 as? Bool

print(value)  // true
print(value2) // optional(1) <- ✅ true가 아님. Any? 타입이라서 type casting 필요함 
print(typeCastedValue2) // optional(true)

// 3️⃣ 저장하지 않은 값 꺼내보기
let invalidValue = UserDefaults.standard.bool(forKey: "InvalidKey")
let invalidValue2 = UserDefaults.standard.object(forKey: "InvalidKey")

print(invalidValue)  // false <- ✅ 주의. 저장된 key가 없으면 false 반환 (nil이 아니라서 혼동됨)
print(invalidValue2) // nil

KeyForBool 이라는 key에다가 bool 값을 저장했고, 해당 key로 저장된 값을 다시 꺼내봤다.
bool 메서드로 꺼내면 true가 반환되고, object로 꺼내면 Any? 타입이므로 optional(1)이 나온다.
그래서 as? Bool로 타입캐스팅해야 optioanl(true)를 얻을 수 있다.
유효하지 않은 key로 저장된 값을 꺼내보면,
bool 메서드는 false를 반환하므로 주의해야 한다. 내가 저장한 값인지, 해당 key가 존재하지 않는지 구분이 불가하기 때문이다.
object 메서드는 nil을 반환하므로 존재하지 않는 값임을 알 수 있다.

구글링 - string 및 object 메서드의 차이점

그럼 이제 bool은 봤으니까 string 메서드만 확인하면 된다.

동일한 블로그에서 이 질문에 대한 답도 얻을 수 있었다.

CocoaCasts의 How to Store a String In User Defaults In Swift 포스트를 참고

UserDefaults에 문자열 값을 저장하고, 다시 이 값을 꺼낼 때 string, object 둘 다 써도 된다.

그렇다면 어떤 상황에서 string / object 메서드를 쓰는 게 좋을까?

결론부터 말하면 string을 쓰는 게 좋다. 타입캐스팅이 필요 없고, 가독성이 좋기 때문이다.

- 본론: I'm sure you agree that the string(forKey:) method is the more elegant option and easier to read and understand.

예제 코드

// 1️⃣ 저장
UserDefaults.standard.set("저장할 문자열", forKey: "KeyForString")

// 2️⃣ 저장한 값 꺼내보기
let value3 = UserDefaults.standard.string(forKey: "KeyForString")
let value4 = UserDefaults.standard.object(forKey: "KeyForString")
let typeCastedValue4 = value4 as? String

print(value3)  // Optional("저장할 문자열")
print(value4)  // Optional(저장할 문자열) 
print(typeCastedValue4) // Optional("저장할 문자열")

// 3️⃣ 저장하지 않은 값 꺼내보기
let invalidValue3 = UserDefaults.standard.string(forKey: "InvalidKey")
let invalidValue4 = UserDefaults.standard.object(forKey: "InvalidKey")

print(invalidValue3) // nil ✅
print(invalidValue4) // nil ✅

위에서 본 bool 메서드와 달리 string 메서드는 key에 저장된 값이 없으면 nil을 반환하므로 헷갈리지 않는다.

결론

결론적으로 UserDefaults 메서드 중에서 반환타입이 옵셔널인 메서드인 string, array, dictionary, url 등은

가독성이 좋고, 타입캐스팅이 필요 없으므로 object 메서드 대신 사용하는 게 좋다.

반면 반환타입이 none-옵셔널인 메서드인 bool, integer, double 등은

key에 저장된 값이 없을 때 nil을 반환할 수 없어 혼동될 수 있으므로 object 메서드로 대체하는 것이 좋다.

- Reference

Apple Developer Documentation > UserDefaults > object(forKey:)
Apple Developer Documentation > UserDefaults > string(forKey:)
Apple Developer Documentation > UserDefaults > bool(forKey:)
Blog > CocoaCasts > How to Check if a Value Exists in User Defaults in Swift
Blog > CocoaCasts > How to Store a String In User Defaults In Swift

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Kingfisher] 이미지 처리 라이브러리의 소스코드 뜯어보기 (1/2)

Applecider — Sat, 5 Nov 2022 16:24:01 +0900

주니어 개발자 면접을 보면서 이미지 처리에 대한 질문을 꽤 많이 받았다.

앱 출시 프로젝트 때는 서버에서 자체적으로 적당한 크기의 이미지를 저장하도록 수작업..했었기 때문에 대응이 어려웠다..

-> 현업에서도 이미지를 서버에서 일괄 관리하는 게 이상적이라고 한다. 즉, 서버가 특정 화면에 맞는 크기의 이미지를 미리 알아뒀다가 보내주는 방식이다. 클라이언트 단의 로직을 최소화할 수 있고, 서비스 운영 측면에서 보다 안정적이다.

현업에서는 대용량 이미지 처리, 특히 캐싱을 위해 Kingfisher 라이브러리를 쓴다고 한다.

Kingfisher의 주요 기능은 URL을 넣으면 비동기로 이미지를 다운로드하고 캐싱 처리해주는 것이다.

이번 기회에 Kingfisher 소스코드를 뜯어보자.

공식문서로 Kingfisher 기능 이해하기

Kingfisher GitHub 페이지부터 읽어보자.

Swift 언어로 웹의 이미지를 다운로드 및 캐싱 (Caching)하는 데 사용하는 라이브러리라고 설명하고 있다.

Kingfisher - GitHub README

주요 기능

그 다음 Features 항목 중에 눈에 띄는 게 많았다. 유용할 듯..

이미지 비동기 처리 (Asynchronous)
이미지 processors & filters를 제공
메모리 및 디스크 캐싱을 위한 Multiple-layer hybrid cache (?)
캐싱 정밀 조정 (expiration date, size limit 설정 등)
성능 향상을 위한 다운로드 취소 기능, 기존 데이터 재사용 (캐싱이니까 당연함..), 이미지 prefetching
다운로딩, 캐싱, 이미지 처리 기능을 독립적으로 사용 가능
URL만 넣으면 이미지를 넣어주는 기능 (UIImageView, UIButton 등 익스텐션)
이미지 셋팅 시 애니메이션 효과 (ex. fade-in)
이미지 로딩 시 custom placeholder, activity indicator
Low data 모드 지원

기본 사용방법

Kingfisher 101 항목에서 친절하게 사용방법을 안내하고 있다.

아래처럼 매우 간단하다. Kingfisher의 UIImageView 익스텐션을 통해 URL만으로 이미지를 다운받아 나타낸다.

그리고 자동으로 메모리 및 디스크 캐싱이 된다.

import Kingfisher

let url = URL(string: "https://example.com/image.png")
imageView.kf.setImage(with: url)  // Kingfisher의 UIImageView 익스텐션을 통해 이미지가 적용됨

아래 예시를 보자. 사용방법이 아주 간단하다.

(이외에도 UIImageView 익스텐션 대신 KF builder를 활용하면 SwiftUI로 변환이 아주 쉽다.)

let url = URL(string: "https://example.com/high_resolution_image.png")
let processor = DownsamplingImageProcessor(size: imageView.bounds.size) // ✅ Downsamples it to match the image view size.
             |> RoundCornerImageProcessor(cornerRadius: 20) // Makes it round cornered with a given radius.
imageView.kf.indicatorType = .activity // ✅ Shows a system indicator while downloading.
imageView.kf.setImage(
    with: url,
    placeholder: UIImage(named: "placeholderImage"), // Shows a placeholder image while downloading.
    options: [
        .processor(processor),
        .scaleFactor(UIScreen.main.scale),
        .transition(.fade(1)), // When prepared, it animates the small thumbnail image with a "fade in" effect.
        .cacheOriginalImage // ✅ The original large image is also cached to disk for later use, to get rid of downloading it again in a detail view.
    ])
{
    // A console log is printed when the task finishes, either for success or failure.
    result in
    switch result {
    case .success(let value):
        print("Task done for: \(value.source.url?.absoluteString ?? "")")
    case .failure(let error):
        print("Job failed: \(error.localizedDescription)")
    }
}

자세한 내용은 본문에서 제공하는 Cheat Sheet를 참고해보자.

Kingfisher 소스코드 뜯어보기

라이브러리의 소스코드를 확인하려면 항상 Sources 폴더를 보면 된다.

1. Cache

먼저 Cache 부분을 뜯어보자.

소스코드만 봤는데 이해가 안 돼서.. Cheat Sheet의 Cache 부분을 먼저 살펴보자..

"URL" 자체가 cache key가 된다. (cache key를 바꾸고 싶다면 ImageResource를 사용해서 지정할 수 있다.)

cache type은 .memory, .disk, .none 세 가지가 있다.

이미지를 다운받을 때 processor를 사용했다면, processed 이미지가 캐싱된다. (setImage 메서드 매개변수로 processor를 전달)

메모리 관리를 위해 캐싱 삭제 정책이 있다. (NSCache 문서 내용과 매우 비슷하다!)

메모리 저장과 관련해서 totalCostLimit, countLimit을 설정할 수 있다.

default로 기기 전체 메모리의 25%를 메모리 캐시의 totalCostLimit으로 설정하고, countLimit은 없다.

디스크 저장과 관련해서 파일시스템의 저장공간인 sizeLimit을 설정할 수 있다.

메모리 및 디스크 캐싱 모두 expiration (만료 기간)을 설정 가능하다.

default로 메모리 캐시는 접근 이후 5분 뒤 만료되며, 디스크 캐시는 1주 뒤 만료된다.

(전체/일부 이미지에 대해 만료되지 않도록 설정하는 것도 가능하다.)

대략적인 Kingfisher의 Cache 기능에 대해 이해한 것 같다.. 이제 드디어 코드를 뜯어보자.

1) Cache - MemoryStorage

먼저 익숙한 MemoryStorage 폴더를 보자.

public enum MemoryStorage {
    public class Backend<T: CacheCostCalculable> {
        let storage = NSCache<NSString, StorageObject<T>>()
        // Keys trackes the objects once inside the storage.
        var keys = Set<String>()

        private var cleanTimer: Timer? = nil
        private let lock = NSLock()

        public var config: Config {
            didSet {
                storage.totalCostLimit = config.totalCostLimit
                storage.countLimit = config.countLimit
            }
        }

        /// Creates a `MemoryStorage` with a given `config`.
        public init(config: Config) {
            self.config = config
            storage.totalCostLimit = config.totalCostLimit
            storage.countLimit = config.countLimit

            cleanTimer = .scheduledTimer(withTimeInterval: config.cleanInterval, repeats: true) { [weak self] _ in
                guard let self = self else { return }
                self.removeExpired()
            }
        }
 // ...

예상했듯이 storage 타입이 NSCache이다. 위에서 cache key를 URL String으로 쓰고 있기 때문에
NSCache의 key 타입이 NSString으로 되어있다.
NSCache 밖에서 캐시 기능을 구현하고 있기 때문에 NSLock을 통해 thread-safe하게 처리를 해주고 있다.
init으로 전달하는 Config 타입을 보면 totalCostLimit, countLimit을 프로퍼티로 가진다.

        /// Removes the expired values from the storage.
        public func removeExpired() {
            lock.lock()
            defer { lock.unlock() }
            for key in keys {
                let nsKey = key as NSString
                guard let object = storage.object(forKey: nsKey) else {
                    keys.remove(key) // 유효하지 않은 key이므로 keys에서 제거함
                    continue
                }
                if object.isExpired { // 만료됐다면 storage에서 제거함
                    storage.removeObject(forKey: nsKey)
                    keys.remove(key)
                }
            }
        }
        
        /// Stores a value to the storage under the specified key and expiration policy.
        public func store(
            value: T,
            forKey key: String,
            expiration: StorageExpiration? = nil)
        {
            storeNoThrow(value: value, forKey: key, expiration: expiration)
        }
        
        func storeNoThrow(
            value: T,
            forKey key: String,
            expiration: StorageExpiration? = nil)
        {
            lock.lock()
            defer { lock.unlock() }
            let expiration = expiration ?? config.expiration
            // The expiration indicates that already expired, no need to store.
            guard !expiration.isExpired else { return }
            
            let object: StorageObject<T>
            if config.keepWhenEnteringBackground {
                object = BackgroundKeepingStorageObject(value, expiration: expiration)
            } else {
                object = StorageObject(value, expiration: expiration)
            }
            storage.setObject(object, forKey: key as NSString, cost: value.cacheCost) // 저장
            keys.insert(key)
        }

storage 및 keys에서 만료된 이미지를 삭제하고, 새로운 이미지를 저장하는 기능이다.

        /// Gets a value from the storage.
        public func value(forKey key: String, extendingExpiration: ExpirationExtending = .cacheTime) -> T? {
            guard let object = storage.object(forKey: key as NSString) else {
                return nil
            }
            if object.isExpired {
                return nil
            }
            object.extendExpiration(extendingExpiration)
            return object.value
        }

        /// Whether there is valid cached data under a given key.
        public func isCached(forKey key: String) -> Bool {
            guard let _ = value(forKey: key, extendingExpiration: .none) else {
                return false
            }
            return true
        }

value 메서드를 통해 메모리에 캐싱되어 있는 이미지를 얻는다.
만료된 이미지라면 nil을 반환한다.
isCached 메서드를 통해 특정 URL 이미지의 캐싱 여부를 확인 가능하다.
이외에도 Config 타입을 보면 default로 expiration은 .seconds(300) == 5분, keepWhenEnteringBackground는 false (앱이 백그라운드로 넘어가자마자 메모리 캐시를 삭제함), cleanInterval = 120 등 세부사항을 알 수 있다.

2) Cache - Storage

맨 마지막에 있던 StorageExpiration 타입이 궁금했는데, Cache > Storage 파일에 있다.

StorageExpiration 열거형에는 5개 case (never, seconds, days, date, expired)가 있다.

    func estimatedExpirationSince(_ date: Date) -> Date {
        switch self {
        case .never: return .distantFuture
        case .seconds(let seconds):
            return date.addingTimeInterval(seconds)
        case .days(let days):
            let duration: TimeInterval = TimeInterval(TimeConstants.secondsInOneDay) * TimeInterval(days)
            return date.addingTimeInterval(duration)
        case .date(let ref):
            return ref
        case .expired:
            return .distantPast
        }
    }
    
    var estimatedExpirationSinceNow: Date {
        return estimatedExpirationSince(Date())  // Date() == 현재 시각
    }

현재로부터 예상 만료기간을 구하기 위해 위 코드가 작성됐다. 가독성 좋은 코드이다..

ExpirationExtending 열거형은 특정 이미지에 접근했을 때 expiration 기간을 연장시킬지 여부를 관리하기 위한 타입이다.

/// Represents the expiration extending strategy used in storage to after access.
public enum ExpirationExtending {
    /// The item expires after the original time, without extending after access.
    case none
    /// The item expiration extends by the original cache time after each access.
    case cacheTime
    /// The item expiration extends by the provided time after each access.
    case expirationTime(_ expiration: StorageExpiration)
}

none이면 해당 이미지에 접근했더라도 만료기한을 연장하지 않는다.

3) Cache - ImageCache

Cache > ImageCache 파일이다.

유효기한 만료, 최대저장용량 초과 등 캐시 삭제 정책에 의해 디스크 캐시가 비워졌을 때 아래의 Notification이 post된다.

extension Notification.Name {
    public static let KingfisherDidCleanDiskCache =
        Notification.Name("com.onevcat.Kingfisher.KingfisherDidCleanDiskCache")
}

CacheType에는 .none, .memory, .disk가 있다.

/// Represents a hybrid caching system which is composed by a `MemoryStorage.Backend` and a `DiskStorage.Backend`.
open class ImageCache {
    public static let `default` = ImageCache(name: "default")  // 싱글톤 사용
    
    public let memoryStorage: MemoryStorage.Backend<KFCrossPlatformImage>
    public let diskStorage: DiskStorage.Backend<Data>
    
    private let ioQueue: DispatchQueue  // 비동기 처리 목적

hybrid caching system이라길래 대단한 건 줄 알았는데 그냥 메모리 캐싱 + 디스크 캐싱 둘 다 된다는 뜻이었다..
비동기 처리를 위해 DispatchQueue를 사용한다.

드디어 이미지 저장 기능을 하는 store 메서드...!를 보자.

    // MARK: Storing Images
    open func store(_ image: KFCrossPlatformImage,
                    original: Data? = nil,
                    forKey key: String,
                    options: KingfisherParsedOptionsInfo,
                    toDisk: Bool = true,
                    completionHandler: ((CacheStoreResult) -> Void)? = nil)
    {
        let identifier = options.processor.identifier
        let callbackQueue = options.callbackQueue
        
        let computedKey = key.computedKey(with: identifier)
        // Memory storage should not throw.
        memoryStorage.storeNoThrow(value: image, forKey: computedKey, expiration: options.memoryCacheExpiration)
        
        guard toDisk else {
            if let completionHandler = completionHandler {
                let result = CacheStoreResult(memoryCacheResult: .success(()), diskCacheResult: .success(()))
                callbackQueue.execute { completionHandler(result) }
            }
            return
        }
        
        ioQueue.async {
            let serializer = options.cacheSerializer
            if let data = serializer.data(with: image, original: original) {
                self.syncStoreToDisk(
                    data,
                    forKey: key,
                    processorIdentifier: identifier,
                    callbackQueue: callbackQueue,
                    expiration: options.diskCacheExpiration,
                    writeOptions: options.diskStoreWriteOptions,
                    completionHandler: completionHandler)
            } else {
                guard let completionHandler = completionHandler else { return }
                
                let diskError = KingfisherError.cacheError(
                    reason: .cannotSerializeImage(image: image, original: original, serializer: serializer))
                let result = CacheStoreResult(
                    memoryCacheResult: .success(()),
                    diskCacheResult: .failure(diskError))
                callbackQueue.execute { completionHandler(result) }
            }
        }
    }

생각보다 별 게 없다..
메모리 캐시에 저장 : memoryStorage.storeNoThrow 메서드를 통해 (Cache > MemoryStorage 파일 참고)
특정 key에 대한 이미지 value를 expiration 옵션으로 저장한다.
매개변수 toDisk가 true이면 completionHadler를 통해 뭔가를 실행하는데..
completionHandler에 무슨 값이 올지 확인해봐야 할 것 같다.
일단 CacheStoreResult에다가 메모리 캐시, 디스크 캐시 모두 success 했다고 보낸다.
디스크 캐시에 저장 : cacheSerializer를 통해서 특정 이미지와 원본 이미지 데이터가 있으면,
이 데이터를 디스크에다가 저장해서 동기화 (sync)하는 작업을 진행한다.
데이터가 없으면 diskError를 생성해서 failure에 담고 다시 CacheStoreResult에 보낸다.
(위에서 success라고 처리했는데, serialize 과정에서 문제가 생겼으니까 다시 failure로 바꿔주는 듯)
이 라이브러리를 직접 써봐야 더 확실히 알 것 같다.

2. Processor

이미지 처리 기능은 어떤 게 있는지 보자. (Cheat Sheet 참고)

// Round corner
let processor = RoundCornerImageProcessor(cornerRadius: 20)

// Downsampling
let processor = DownsamplingImageProcessor(size: CGSize(width: 100, height: 100))

// Cropping
let processor = CroppingImageProcessor(size: CGSize(width: 100, height: 100), anchor: CGPoint(x: 0.5, y: 0.5))

// Blur
let processor = BlurImageProcessor(blurRadius: 5.0)

RoundCornerImageProcessor : 모서리 둥글게 처리
DownSamplingImageProcessor : 샘플이미지 다운
CroppingImageProcessor : 이미지 크롭
BlurImageProcessor : 블러 처리
이외에도 overlay, tint color 등 여러 가지가 있음

README 예시에서 봤던 것처럼 DownSamplingImageProcessor를 통해

고해상도 이미지를 다운받을 때, 메모리에 로딩하기 전에 썸네일 이미지를 만들어서 UIView 크기에 맞게 사용하도록 한다.

이 기능이 정말 유용할 듯..

성능 효율을 위한 팁

CollectionView에서 빠르게 스크롤되면서 화면에서 사라지는 Cell의 이미지는 didEndDisplaying 메서드에서 다운로드 작업을 cancel 시킨다.

Cache 내용이 방대해서 포스트가 길어졌는데, 다음에 다른 기능에서 더 다뤄보면 좋을 것 같다.

- Reference

GitHub > onevcat/Kingfisher > CheatSheet

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[APNs] Push Notification 보내기 (1/2) - 관련 공식문서 요약

Applecider — Mon, 17 Oct 2022 00:10:25 +0900

앱이 Background 상태에 있더라도 사용자에게 알림을 띄우는 기능인 Push Notification에 대해 알아보자.

*Notification의 디자인은 HIG 문서 요약본 포스트를 참고

이번 포스팅에서는 공식문서를 훑어보고,

다음 포스팅에서 Notification 관련 4가지 주체에 대해 정리하면서, 예제 코드를 작성해볼 계획이다.

Push Notification이란?

특정 앱에서 사용자에게 알림을 띄우는 것을 말하는데,

아래 화면처럼 잠금 화면, 알림 센터, 배너, 사운드, 배지 등의 형태가 있다.

설정 > 알림 > 특정 앱

여기서 배지 (Badge)란 아래처럼 앱 우상단에 빨간 점으로 표시되는 형태이다.

참고 - What is a badge?

APNs란?

APNs는 Apple Push Notification service를 말한다.

third party 개발자 (ex. Push Server)가 앱에 Notification을 보낼 수 있도록 Apple에서 만든 알림 서비스이다.

User Notifications 공식문서들

대략적인 개념을 정리했으니 이제 공식문서를 읽어보자.

Push Notification 관련 최상위 공식문서는 Framework - User Notifications이다.

Framework라고 되어있으니까 나중에 import 어쩌구 해서 사용할 거라고 유추할 수 있다.

Framework - User Notifications (링크)

요약 : 사용자 기기에게 notifications를 push한다. 이 notifications를 remote 서버로부터 보내거나, notifications 자체를 앱으로부터 local하게 생성해서 띄울 수 있다.
Push user-facing notifications to the user’s device from a server, or generate them locally from your app.

User Notifications - 알림 센터 (왼쪽), 배너 (오른쪽)

Overview를 한 줄씩 읽어보자.

앱의 사용자에게 중요한 메시지를 전달할 때 notification을 사용할 수 있는데, 앱이 실행 중인지와 상관없이 가능하다.
즉, 앱이 Foreground에 있어도 Background에 있어도 notification을 띄울 수 있다는 의미이다.

예를 들어 스포츠앱은 사용자에게 어떤 팀의 게임 스코어를 알려줄 수 있다. 이때 notification은 특정 앱에게 데이터를 다운 받아서 인터페이스를 업데이트하도록 알릴 수 있다.

notification은 alert를 표시하거나, 사운드를 내거나, 배지를 설정하는 형태로 나타난다.

notification은 앱으로부터 local하게 생성할 수도 있고, 개발자가 관리하는 서버로부터 remote하게 생성할 수도 있다.

local notification : 앱 자체적으로 notification의 content 및 condition을 설정한다. 이때 condition (= 알림을 trigger할 조건)으로 time, location 등을 설정할 수 있다.
remote notification : 회사의 백엔드 서버가 push notification을 생성하면, APNs가 notification을 관리하고 있다가 사용자의 기기에 해당 notification을 전달한다.
-> 앱 대부분 이 방식에다가 FMC (Firebase의 Cloud Messaging)을 추가적으로 활용한다.

User Notifications Framework는 아래의 목적으로 활용하면 된다.

앱이 지원하는 notifications의 타입을 정의한다. (사운드, 배지, 알림 센터 등을 말하는 듯)
notification과 관련된 custom action을 정의한다.
local notification을 스케쥴링한다.
이미 전달된 notification을 처리한다.
user-selected action에 대응한다. (사용자가 알림의 특정 옵션을 선택했을 때를 말하는 듯)

시스템은 local/remote notification을 정해진 시점에 전달하기 위해 최대한 노력하겠지만, 전달이 보장되지는 않는다. (delivery isn’t guaranteed)

엥.. 이유는 모르겠지만.. notification이 설정한 대로 전달되지 않을 수 있는 가능성을 염두에 두어야 할 듯

PushKit framework가 특정한 타입의 notification에 대해서는 시간을 더 잘 지키는 전달 메커니즘을 제공한다. 예를 들어 VoIP 및 watchOS를 합쳐서 사용하는 경우가 그렇다.

이제 공식문서 하단의 Topics에서 읽어볼 만한 것을 추려보자.

최상단의 Essentials, Notification Management 항목은 당연히 읽어야 하고,

대부분 FCM을 활용한 remote notification을 구현하므로 Remote Notifications도 읽으면 될 것 같다.

시간이 있으면 Notification Categories and User Actions, Notification Responses도 보면 좋을 듯

Article - Asking Permission to Use Notifications (링크)

요약 : notification에 대응하고자 alerts/sound/badge를 표시하려면, 사용자에게 permission을 요청해야 한다.
문서의 permission = authorization

local/remote notification을 받으면 사용자가 볼 수 있게 alerts/sound/badge를 표시하게 되는데, 이러한 interaction은 앱이 실행 중이지 않거나, background에 있을 때 발생한다. (앱이 foreground에 있을 때는 시스템이 알아서 안 띄운다는 뜻인가???)

Requesting permission

Explicitly Request Authorization in Context

let center = UNUserNotificationCenter.current()  // 싱글톤

// ✅ options에 요청할 iteraction type을 명시
center.requestAuthorization(options: [.alert, .sound, .badge]) { granted, error in  
    // ✅ granted : 사용자가 alert에 대해 allow 했다면 true, not allowed 했다면 false 
    // error: 에러가 발생했다면 error info, 에러가 없었다면 nil
    
    if let error = error {
        // Handle the error here.
    }
    
    // Enable or disable features based on the authorization.
}

UNUserNotificationCenter : 싱글톤 객체이고, notification 관련 activities를 관리한다.
사용자에게 permission을 요청하기 위해 requestAuthorization 메서드를 호출한다.
- 위 코드에서는 요청할 iteraction type으로 .alert, .sound, .badge를 설정했다.
앱이 최초로 authorization을 요청할 때, 시스템이 위 사진처럼 alert를 띄워서 allow 할지 말지를 사용자에게 묻고, 사용자 응답을 기록한다. 그래서 이후로는 사용자에게 묻지 않는다.
문맥상 왜 notification 기능이 필요한지 사용자가 이해할 수 있게 하면 좋다.
예를 들어 task-tracking 앱이라면, 첫 번째 task를 생성한 시점에 request를 띄우도록 한다.
(앱을 최초 실행했을 때 요청하는 것보다 UX 측면에서 낫다.)

Use Provisional Authorization to Send Trial Notifications

사용자 입장에서는 앱의 notification을 사용해보기도 전에 permission 요청에 대해 응답해야 한다.

따라서 사용자가 써보고 결정할 수 있도록 체험판 (provisional) authorization을 활용하면 좋다.

provisional notification은 시스템이 알림 센터에만 띄운다. (sound, 배지, 잠금화면에 나타나지 않는다.)

그리고 사용자는 버튼을 통해 notification을 유지할지 끌지 결정할 수 있다.

알림 센터에 뜬 provisional notification

Keep 버튼 : prominent/quiet notification 선택지를 보여준다.
- prominent : notification permission을 얻은 상태가 되어 alert/sound/badge를 띄울 수 있다.
  (엄밀히는 provisional request에 포함된 항목들을 띄울 수 있다.)
- quiet : 알림 센터에서만 띄울 수 있다.
Turn off 버튼 : authorization을 거부하려는 사용자의 선택을 재확인하는 절차를 거친다.

provisional authorization을 요청하는 건 쉽다.

위에서 본 requestAuthorization 메서드의 options 매개변수에 .provisional만 추가하면 된다.

let center = UNUserNotificationCenter.current()
center.requestAuthorization(options: [.alert, .sound, .badge, .provisional]) { granted, error in  // options에 .provisional만 추가됨
    
    if let error = error {
        // Handle the error here.
    }
    
    // Provisional authorization granted.
}

위에서 봤던 explicitly requesting authorization과 달리,
provisional authorization 코드는 사용자에게 permission을 요청하는 alert를 띄우지 않는다.
대신, 메서드를 최초 호출하는 시점에 자동으로 권한이 부여된다.
사용자가 Keep/Turn off 버튼을 탭할 때까지 authorization status는 .provisional 상태가 된다.
provisional authorization을 사용하면 앱을 최초 실행하는 시점에 authorization을 요청할 수 있다. ???
-> 뭐지... 방금 alert 안 띄우고 자동으로 권한 부여한다며... 확인 필요
사용자가 notification을 계속 사용할지 말지는 notification을 받은 이후에나 설정할 수 있다.

Customize Notifications Based on the Current Authorizations

local notification을 스케쥴링하기 전에 앱의 authorization status를 항상 확인해야 한다.

사용자는 언제든 특정 앱의 authorization 설정과 interation type을 변경할 수 있다.

getNotificationSettings 메서드를 호출하면 현재 notification 설정을 알아낼 수 있고,
이 설정값을 바탕으로 custom notification을 만들 수 있다.

let center = UNUserNotificationCenter.current()
center.getNotificationSettings { settings in  // 현재 설정값을 가져옴
    guard (settings.authorizationStatus == .authorized) ||
          (settings.authorizationStatus == .provisional) else { return }

    if settings.alertSetting == .enabled {
        // Schedule an alert-only notification.
    } else {
        // Schedule a notification with a badge and sound.
    }
}

이 코드는 guard문을 통해 authorization status가 .authorized 또는 .provisional일 때만, 특정 notification을 스케쥴링하도록 했다.
또한 if문에서 interaction type에 따라 notification을 구성했다.

일부 interaction에 대한 권한이 없더라도 alert/sound/badge를 띄울 수 있다.
만약 UNNotificationSettings의 notificationCenterSetting 프로퍼티를 .enabled로 설정하면, 시스템은 알림 센터에 alert를 띄울 수 있다.

또한 notification center delegate의 userNotificationCenter(_:willPresent:withCompletionHandler:) 메서드를 통해 앱이 foreground에 있을 때 도착한 notification을 처리할 수 있다.

*참고로 notification center delegate의 userNotificationCenter(_:didReceive:withCompletionHandler:) 메서드를 통해 사용자가 반응한 notification action (user-selected action)을 처리할 수 있다.

Class - UNUserNotificationCenter (링크)

요약 : notification 관련 activities를 관리한다.

네이밍에서 알 수 있듯이 notification을 관리하는 중심 역할을 한다.

User Notification 문서의 Topics에서도 대부분 볼 수 있는 내용이다.

UNUserNotificationCenter 싱글톤 객체를 사용해야 하는 상황은 아래와 같다.

alerts/sound/badge를 표시할 수 있도록 사용자에게 authorization 요청
notification type 및 custom action을 선언
notification 스케쥴링
APNs를 거쳐서 전달된 remote notification의 payload를 처리
이미 전달되어 알림 센터에 떠있는 notification 관리
custom notification type과 관련된 user-selected action을 처리
앱에 대한 notification 관련 설정

incoming notifications and notification-related actions을 처리하려면, UNUserNotificationCenterDelegate을 채택한 객체가 필요하다.

여러 스레드에서 동시에 notification center에 접근했다면 (싱글톤 객체이므로) 접근한 순서대로 작업을 처리한다.

Article - Setting Up a Remote Notification Server (링크)

요약 : notification을 생성하고 사용자 기기에 띄운다.

✨ 대부분 FCM을 활용하므로 이 문서가 중요하다.

remote notification의 주요 요소는 아래와 같다.

회사 서버 (provider server)
APNs (Apple Push Notification service)
사용자 기기
앱 (사용자 기기에 설치된 상태)

remote notification은 회사 서버에서 시작하는데, 먼저 어떤 notification을 언제 보낼지 정한다.

해당 시점이 되면 (1) notification 데이터와 (2) 사용자 기기 identifier를 포함한 request를 생성한 뒤, request를 APNs로 보낸다.

APNs는 notification을 사용자 기기에 전달하는 것을 관리한다.

사용자 기기가 notification을 받으면, 기기 OS가 모든 사용자 interaction을 처리하고 notification을 앱으로 전달한다.

remote notification의 전달 과정

개발자는 provider server를 준비하고, 앱에서 notification을 처리하도록 구성해야 한다.

앱이 remote notification을 처리하는 방법은 Registering Your App with APNs 문서를 참고해야 한다.

Build Custom Infrastructure for Notifications

remote notification server를 셋업하려면 몇 가지 task가 필요하다.

이러한 task를 어떻게 구현할지는 회사의 infrastructure에 따라 다르며, 적절한 기술을 활용하면 된다.

앱 인스턴스로부터 device token을 얻고, 이 token을 앱 사용자 계정에 연동시킨다.
See Registering Your App with APNs
사용자에게 언제 notification을 보낼지 정하고, notification payloads를 생성한다.
See Generating a remote notification
HTTP/2 and TLS ???를 사용해서 APNs에 연결하는 것을 관리한다.
See Sending Notification Requests to APNs
payload를 포함한 POST request를 생성하고, request를 HTTP/2 연결을 통해 전송한다.
See Sending Notification Requests to APNs
token-based authentication을 위해 정기적으로 token을 재생성한다.
See Establishing a Token-Based Connection to APNs

Establish a Trusted Connection to APNs

provider server와 APNs 간의 소통은 secure connection 하에서 이루어져야 한다.

따라서 connection을 생성하려면 AAA Certificate Services root certificate이 필요하다.

notification을 보내려면 provider server는 반드시 token-based or certificate-based trust with APNs 둘 중 하나가 필요하다.

-> 둘의 장단점은 나중에 더 찾아보자...

Understand What APNs Provides

APNs를 사용하면 UX에 좋다.

사용자 기기에 대해 인증된, 암호화된, 영구적인 IP 연결을 관리한다.
사용자 기기가 offline 상태일 때 전달된 notification을 저장해뒀다가, 기기가 online이 되면 포워딩한다.
기기의 power가 낮거나 offline일 때 등 notification이 즉시 전달되지 않았다면, 동일한 bundleID에 대한 notifications를 병합 (coalesce) 할 수 있다.

Remote notification 관련 문서를 더 읽어보자..

Article - Registering Your App with APNs (링크)

요약 : APNs와 통신하고, 앱을 식별하는 device token을 받는다.

APNs는 사용자 기기의 주소를 알아야 한다. (notification의 도착점)

이 주소는 device/app에 대해 고유한 값인 device token 형태이다.

앱을 실행 (launch)할 때 앱이 APNs와 통신해서 device token을 받아오면, provider server에다가 전달하게 된다.

provider server는 notification을 전달할 때마다 이 token을 넣어서 보낸다.

Enable the Push Notifications Capability

Xcode의 Capabilities에다가 Push Notification을 enable해야 한다.

개발자 계정에서 AppID에다가 push notification service도 enable 시켜야 한다.. 귀찮지만 인증서 필요..

Register Your App and Retrieve Your App's Device Token

APN에 앱을 등록하고, device token을 받는다.

provider server는 이 token을 가지고 있어야 notification을 보낼 수 있다.

앱을 실행 (launch)할 때마다 앱을 등록해서 device token을 받아와야 한다. -> 굳이 왜 매번 발급하는지 궁금하다면 이유는 아래에

이때 registerForRemoteNotifications() 메서드를 활용해서 앱을 등록하고,

App Delegate의 application(_:didRegisterForRemoteNotificationsWithDeviceToken:) 메서드를 통해 device token을 받아온다.

등록에 실패할 경우에 대비해서 application(_:didFailToRegisterForRemoteNotificationsWithError:) 메서드를 구현한다.

func application(_ application: UIApplication,
           didFinishLaunchingWithOptions launchOptions:
           [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
   // Override point for customization after application launch.         
   UIApplication.shared.registerForRemoteNotifications()  // ✅ 앱을 APNs에 등록
   return true
}

func application(_ application: UIApplication,
            didRegisterForRemoteNotificationsWithDeviceToken 
                deviceToken: Data) {  // ✅ 앱이 등록되면 APNs가 device token을 보내줌
   self.sendDeviceTokenToServer(data: deviceToken)  // ✅ token을 provider server에 저장
}

func application(_ application: UIApplication,
            didFailToRegisterForRemoteNotificationsWithError  // ✅ 앱 등록에 실패했을 때 처리
                error: Error) {
   // Try again later.
}

*왜 APNs를 앱을 실행할 때마다 device token을 갱신할까? -> Important 항목에 답이 있다.

로컬 저장소에 device token을 cache하면 안 된다. APNs는 사용자가 백업으로부터 장치를 복원할 때, 사용자가 앱을 새로운 기기에 설치할 때, 사용자가 OS를 재설치할 때 새로운 token을 발급한다. 매번 시스템에서 token을 제공하도록 요청하면, token이 항상 최신 상태임을 보장받을 수 있다.

-> 결론 : APNs가 token을 자주 갱신하기 때문에 앱을 실행할 때마다 새로 받는 게 낫다는 뜻..

Forward Tokens to Your Provider Server

token을 받으면 사용자 계정 정보와 연결시키고, 암호화시켜서 provider server로 보낸다.

provider server는 notification을 보낼 때 기기 정보가 필요하다.

따라서 provider server에서는 token을 사용자 계정 데이터에다가 함께 저장해야 한다.

사용자가 여러 개의 기기를 사용할 가능성이 있으므로 사용자 계정에 여러 개의 token이 저장될 수도 있다.

Article - Generating a remote notification (링크)

요약 : JSON payload를 통해 사용자 기기에 notification을 보낸다.

remote notification은 JSON payload의 형태로 사용자에게 전달된다.

payload는 user interaction (alert/sound/badge)를 지정하고, notification에 대응할 custom 데이터를 포함한다.

기본적인 payload는 Apple에서 정의한 key와 custom value로 구성되고,

custom key와 value를 추가할 수 있다.

APNs는 payload의 최대 용량을 제한하고 있다.

Voice over Internet Protocol (VoIP) notifications : 5KB
그 외 remote notification : 4KB

Create the JSON payload

JSON dictionary를 사용해서 payload를 지정한다.

아래처럼 aps key에 대한 value로 dictionary가 들어있다.

그리고 이 dictionary는 1개 이상의 Apple-defined key로 구성된다. (이 key에다가 alert/sound/badge/silent를 넣는다.)

silent를 사용하면 background에서 조용히 시스템이 notification을 처리하도록 할 수 있다.

아래의 payload는 사용자를 game에 초대하기 위해 alert를 띄운다.

category key가 UNNotificationCategory에 등록되어 있다면, 시스템은 alert에 대한 action 버튼을 추가해준다.

그리고 사용자가 게임에 참가할 수 있도록 custom key/value (gameID)를 추가했다.

{
   "aps" : {
      "alert" : {
         "title" : "Game Request",
         "subtitle" : "Five Card Draw",
         "body" : "Bob wants to play poker"
      },
      "category" : "GAME_INVITATION"
   },
   "gameID" : "12345678"
}

이 부분은 백엔드 서버에서 관리하기 때문에 iOS 개발자는 신경 쓸 필요가 없다.

아래 payload는 badge, sound를 띄운다.

sound 파일은 사용자 기기에 이미 존재하는 상태 (app bundle 또는 Library/Sounds 폴더)여야 한다.

그리고 notification을 만들어낸 message를 식별할 수 있도록 custom key/value (messageID)를 추가했다.

{
   "aps" : {
      "badge" : 9,
      "sound" : "bingbong.aiff"
   },
   "messageID" : "ABCDEFGHIJ"
}

Localize your alert messages

remote notification의 컨텐츠를 localize (지역화)하는 2개 방법이 있다.

payload에 직접 localized strings를 포함시키는 방법
- provider server에서 사용자의 preferred language를 추적해야 함
- 사용자 기기에 저장된 preferred language 정보를 이용하면 되니까 서버가 몰라도 되는 거 아닌가???
app bundle에다가 localized message strings를 추가하고, 시스템이 어떤 문자열을 사용할지 선택하게 하는 방법
- title-loc-key, subtitle-loc-key, loc-key 등의 payload keys를 사용한다.

{
   "aps" : {
      "alert" : {
         "loc-key" : "GAME_PLAY_REQUEST_FORMAT",
         "loc-args" : [ "Shelly", "Rick"]
      }
   }
}

Payload key reference

본문 table을 통해 aps dictionary에 들어갈 수 있는 key/value 정보를 확인할 수 있다.

Article - Sending Notification Requests to APNs (링크)

요약 : payload 및 device token을 APNs에 전송한다.

provider server는 POST request를 구성해서 APNs에 보내야 한다.

request에 포함시켜야 할 정보는 아래와 같다.

JSON payload
device token
어떻게 notification을 전달할지를 지정하는 Request-header fields
token-based authentication을 위한 provider server의 현재 authentication token

APNs가 request를 받으면, authentication token 또는 서버의 certificate을 통해 request를 validate한다.

validate하다고 판단하면 APNs는 device token을 활용해서 사용자 기기를 식별하고, payload를 기기에 보낸다.

Establish a Connection to APNs

HTTP/2 and TLS 1.2를 사용해서 provider server를 development/production server 중 하나에 연결시킨다.

development server는 테스트용, production server는 상용앱 목적으로 사용한다.

Create and Send a POST Request to APNs

HTTP/2 and TLS를 이용해서 POST notification을 APNs에다가 보낸다.

POST notification을 만들려면 아래의 정보가 필요하다.

device token
current authentication token (only if you’re using token-based authentication)
JSON payload

그리고 header fields를 추가해야 하는데, 본문 table을 참고하면 된다. (required = 필수사항)

APNs는 HPACK (header compression for HTTP/2)을 사용하도록 하는데, header key/value가 중복 저장되는 것을 막아준다.

header를 특정 방식에 따라 encoding 해야 한다.

POST request 예시는 아래와 같다. (authentication token을 활용)

HEADERS
  - END_STREAM
  + END_HEADERS
  :method = POST
  :scheme = https
  :path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0
  host = api.sandbox.push.apple.com
  authorization = bearer eyAia2lkIjogIjhZTDNHM1JSWDciIH0.eyAiaXNzIjogIkM4Nk5WOUpYM0QiLCAiaWF0I
		 jogIjE0NTkxNDM1ODA2NTAiIH0.MEYCIQDzqyahmH1rz1s-LFNkylXEa2lZ_aOCX4daxxTZkVEGzwIhALvkClnx5m5eAT6
		 Lxw7LZtEQcH6JENhJTMArwLf3sXwi
  apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b
  apns-push-type = alert
  apns-expiration = 0
  apns-priority = 10
  apns-topic = com.example.MyApp
DATA
  + END_STREAM
  { "aps" : { "alert" : "Hello" } }

위와 마찬가지로 이 부분은 백엔드 서버에서 관리하기 때문에 iOS 개발자는 신경 쓸 필요가 없다.

Article - Handling Notification Responses from APNs (링크)

요약 : APNs server가 반환해주는 status code에 대응한다.

provider server가 APNs에게 POST request를 전달하면,

다시 APNs는 provider server에게 response를 준다.

response는 header를 포함하는데, 여기에는 response status를 나타내는 fields가 들어있다.

request에 성공했다면 response body는 비어있고,

에러가 발생했다면 body에 에러 정보를 담고 있는 JSON dictionary가 들어있다.

본문 표를 통해 header response의 의미를 파악할 수 있다.

request에 성공했다면 status code는 200이다.

payload 용량이 너무 큰 경우는 413이다.

request에 성공한 경우 response 예시는 아래와 같다.

HEADERS
  + END_STREAM
  + END_HEADERS
  apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b
  :status = 200

Article - Handling Notifications and Notification-Related Actions (링크)

요약 : 사용자 interation에 대응한다.

사용자가 notification을 확인하고 interaction한 것에 대해 앱이 대응할 수 있다.

대응할 수 있는 사용자 interaction은 아래를 말한다.

시스템의 notification interface에 대한 user-selected action
앱이 foreground에서 실행 중일 때 도착한 notification
silent notification

Handle User-Selected Actions

actionable notification은 아래처럼 1개 이상의 버튼을 제공한다.

사용자가 특정 버튼을 탭하면, 선택된 action이 앱에게 전달된다. 이때 app은 foreground에 올라오지 않는다.

선택된 action을 처리하려면 UNUserNotificationCenter delegate가 필요하다.

사용자가 특정 action을 선택하면, 시스템은 앱을 background에서 실행하고,

delegate의 userNotificationCenter(_:didReceive:withCompletionHandler:) 메서드를 호출한다.

func userNotificationCenter(_ center: UNUserNotificationCenter,
            didReceive response: UNNotificationResponse,
            withCompletionHandler completionHandler: 
               @escaping () -> Void) {
   // ✅ Get the meeting ID from the original notification.
   let userInfo = response.notification.request.content.userInfo
        
   if response.notification.request.content.categoryIdentifier ==
              "MEETING_INVITATION" {
      // Retrieve the meeting details.
      let meetingID = userInfo["MEETING_ID"] as! String
      let userID = userInfo["USER_ID"] as! String
            
      switch response.actionIdentifier {  // ✅ 사용자가 선택한 action에 따라 분기처리
      case "ACCEPT_ACTION":
         sharedMeetingManager.acceptMeeting(user: userID, 
               meetingID: meetingID)
      case "DECLINE_ACTION":
         sharedMeetingManager.declineMeeting(user: userID, 
               meetingID: meetingID)
      case UNNotificationDefaultActionIdentifier,  // ✅ 사용자가 앱을 실행하거나 notification을 dismiss했을 때
           UNNotificationDismissActionIdentifier:
         // Queue meeting-related notifications for later
         //  if the user does not act.
         sharedMeetingManager.queueMeetingForDelivery(user: userID,
               meetingID: meetingID)
      default:
         break
      }
   }
   else {
      // Handle other notification types...
   }
        
   completionHandler()  // 처리가 끝났음을 시스템에게 알리기 위해 호출함
}

Handle Notifications While Your App Runs in the Foreground

notification이 전달됐을 때 앱이 foreground 상태라면, 시스템은 notification을 직접 앱에게 전달한다.

notification을 받으면 payload를 통해 원하는 작업을 할 수 있다.

예를 들어 payload에 들어있는 특정 데이터를 사용해서 앱의 interface를 업데이트할 수 있다.

그다음 예약된 alert를 숨기거나 수정할 수 있다.

앱이 foreground 상태일 때 notification이 도착하면

시스템은 UNUserNotificationCenter delegate의 userNotificationCenter(_:willPresent:withCompletionHandler:) 메서드를 호출한다.

이 메서드를 활용해서 notification을 처리하면 된다.

func userNotificationCenter(_ center: UNUserNotificationCenter,
         willPresent notification: UNNotification,
         withCompletionHandler completionHandler: 
            @escaping (UNNotificationPresentationOptions) -> Void) {
   if notification.request.content.categoryIdentifier == 
            "MEETING_INVITATION" {
      // Retrieve the meeting details.
      let meetingID = notification.request.content.
                       userInfo["MEETING_ID"] as! String
      let userID = notification.request.content.
                       userInfo["USER_ID"] as! String
            
      // Add the meeting to the queue.
      // ✅ 앱의 interface를 업데이트하는 custom method
      sharedMeetingManager.queueMeetingForDelivery(user: userID,
            meetingID: meetingID)

      // ✅ Play a sound to let the user know about the invitation.
      completionHandler(.sound)
      return
   }
   else {
      // Handle other notification types...
   }

   // ✅ Don't alert the user for other types.
   completionHandler(UNNotificationPresentationOptions(rawValue: 0))
}

Article - Declaring Your Actionable Notification Types (링크)

요약 : notification interface에다가 action 버튼을 추가한다.

actionable notification을 사용하려면 아래 작업이 필요하다.

앱 실행 시점에 1개 이상의 notification categories를 선언한다.
notification categories에 action을 할당한다.
등록한 action을 처리한다.
notification을 생성할 때 payload에다가 category identifiers를 할당한다.

아래는 ation을 등록하는 예시 코드이다.

// Define the custom actions.
let acceptAction = UNNotificationAction(identifier: "ACCEPT_ACTION",
      title: "Accept", 
      options: [])
let declineAction = UNNotificationAction(identifier: "DECLINE_ACTION",
      title: "Decline", 
      options: [])
// Define the notification type
let meetingInviteCategory = 
      UNNotificationCategory(identifier: "MEETING_INVITATION",
      actions: [acceptAction, declineAction], 
      intentIdentifiers: [], 
      hiddenPreviewsBodyPlaceholder: "",
      options: .customDismissAction)
// Register the notification type.
let notificationCenter = UNUserNotificationCenter.current()
notificationCenter.setNotificationCategories([meetingInviteCategory])

생각보다 공식문서 양이 많았는데, 비슷한 내용이 반복되기 때문에 그렇게 오래 걸리지 않았다.

다음 포스팅에서 상용앱에서 대부분 활용하는 FCM (Firebase Cloud Messaging) 등의 중계 서비스를 포함한

Notification 관련 4가지 주체에 대해 정리하면서, 예제 코드를 작성해보자.

- Reference

기존 포스팅 - [HIG] Notifications - title, content, actions 설정 시 고려사항
Apple Developer Documentation > Framework -User Notifications
Apple Design > Human Interface Guidelines > System experiences > Notifications
YouTube > iOS Academy - Push Notifications Tutorial (2022)

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[HIG] Notifications - title, content, actions 설정 시 고려사항

Applecider — Mon, 3 Oct 2022 00:54:21 +0900

APNs (Apple Push Notification service)를 스터디하다가 오랜만에 HIG 문서를 읽게 됐다.

참고 - Notifications HIG 문서

요약

Notification은 사용자에게 적당한 시간에 (timely), 중요한 정보를, 한눈에 (at a glance) 전달한다.

사용자에게 notification을 보내기 전에 반드시 사용자의 동의 (consent)를 얻어야 한다.

사용자가 동의한 이후, 대부분의 사용자는 설정 앱을 통해 notification 스타일과 notification의 중요도에 따른 알림 시간을 정한다.

Anatomy

플랫폼에 따라 notification의 다양한 스타일을 활용할 수 있다.

배너 : 잠금 화면 (lock screen), 홈 화면, 데스크탑
배지 : 앱 아이콘
알림 센터 (notification center)

Best practices

최대한 간략하게 notification을 구성한다.
사용자가 반응하지 않더라도 동일한 항목에 대해 여러 개의 notification을 보내지 않는다.
✅ 사용자에게 특정 작업을 수행하도록 할 목적으로 notification을 사용하지 않는다.
- 앱을 열어서 할 작업을 notification에 나타내면, notification이 꺼졌을 때 사용자가 내용을 잊어버리기 쉽다.
- 사용자가 앱을 열지 않고도 할 수 있는 간단한 작업이라면 notification actions 기능을 활용한다.
에러 메시지를 나타내려면 notification이 아니라 alert를 사용한다.
✅ 앱이 foreground에 있을 때는 notification이 튀지 않도록 한다.
- 앱이 스크린에 띄워진 상태에서는 notification이 나타나지 않지만, 앱은 계속해서 데이터를 받는다. (?)
- ex. 사용자가 메일함을 스크린에 띄운 상태에서 새로운 메일이 도착했다면,
notification을 띄우는 것이 불필요하고 몰입을 방해할 수 있으므로 단순히 읽지 않은 메일 목록에 추가되도록 하는 게 좋다.
사용자 개인정보를 notification에 띄우지 않는다.

Content

notification의 title을 설정하면, 시스템이 해당 내용을 가장 눈에 잘 띄는 위치인 맨 윗 줄에 나타낸다.

직접적인 커뮤니케이션 기능과 관련된 notification인 경우, 시스템이 자동으로 발신자의 이름을 title area에 나타낸다.

커뮤니케이션과 관련 없는 notification인 경우, title이 없다면 시스템이 앱의 이름을 나타낸다.

title은 짧은 것이 좋다.
- 커뮤니케이션과 관련 없고, 세부적인 title을 제공할 수 없는 경우 (ex. New Document) 차라리 앱 이름을 title로 두는 게 낫다.
- title-style capitalization을 사용하고, 마침표를 찍지 않는다.
content는 간략하고 가독성 있게 작성한다.
- complete sentence를 사용한다.
- 메시지를 truncate (잘림 처리)할 필요가 없다. 필요하면 시스템이 알아서 해준다.
✅ notification 미리보기가 불가할 때 나타낼 설명 텍스트를 제공한다.
- 사용자가 설정에서 모든 앱에 대한 미리보기를 감추도록 할 수 있다. 이때 시스템은 notification에 앱 아이콘과 default title만 나타낸다.
- 사용자가 notification 전체 내용을 볼지 말지 결정할 수 있도록 간결한 body text를 작성한다.
(ex. “Friend request,” “New comment,” “Reminder,” “Shipment”)
- hiddenPreviewsBodyPlaceholder 프로퍼티에다가 설정하면 된다.
시스템이 알아서 보여주는 앱 아이콘, 앱 이름을 포함시키지 않는다.
sound를 제공할지 고려한다.
- 앱마다 고유의 custom sound를 설정 가능하므로 사용자는 화면을 보지 않고도 특정 앱의 notification을 인지할 수 있다.

Notification actions

notification에는 custom detail view를 나타내는 기능이 있는데,
최대 4개까지 버튼을 통해 사용자가 앱을 열지 않고도 특정 action을 수행한다.

예를 들어 Calendar event notification은 이벤트 알람을 몇 분간 연기할 수 있는 Snooze 버튼을 제공한다.

notification의 context에 맞는 actions를 제공한다.
- 일반적이고, 시간을 절약할 수 있는 작업을 설정하면 좋다.
- 버튼에는 title-case의 짧은 텍스트를 사용한다.
notification을 탭하면 앱이 열리기 때문에 앱을 여는 목적의 action button은 만들지 않는다.
✅ destructive action은 피한다.
- 사용자가 의도치 않게 선택할 수 있다.
action 버튼에 가독성 좋은 interface 아이콘을 제공한다.
- 이 아이콘은 action title의 trailing side에 표시된다.
- SF Symbols 참고

Badging

배지는 사용자가 읽지 않은 notification의 개수를 나타내기 위해 사용된다.

앱 아이콘에 숫자를 나타낸다.

notification과 관련 없는 숫자를 나타내지 않는다.
사용자는 배지를 사용하지 않도록 설정할 수 있다.
- 중요한 정보는 사용자가 앱을 열자마자 확인 가능하도록 해야 한다.
배지를 지속 업데이트한다.
- 사용자가 확인한 notification을 반영해서 배지의 숫자를 업데이트한다.
- ✅ 배지 개수를 0으로 설정하면, 알림 센터의 notification이 모두 사라진다.
custom 이미지 등으로 배지의 형태나 동작을 모방하는 것을 지양한다.
- 설정에서 배지를 사용하지 않도록 설정했는데, 배지가 보이면 안 된다.

Platform considerations

각 플랫폼에 따라 고려할 사항이다.

구체적인 내용은 일단 iPhone 위주로 보고 있으므로 패스

WatchOS : notification을 2개 stage로 구분한다. (short/long look)

- Reference

Apple Developer Documentation > Framework -User Notifications
Apple Design > Human Interface Guidelines > System experiences > Notifications

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[iOS] GitHub Action으로 Xcode 테스트 자동화하기 - CI/CD

Applecider — Mon, 29 Aug 2022 07:00:44 +0900

개발자가 설정한 특정 상황이 발생하면 자동으로 실행할 동작을 미리 정해두는 기능이 있다.

예를 들어 특정 branch에 merge 또는 PR을 요청했을 때 테스트가 실행되도록 하는 것이다.

Git Flow 기능과 함께 사용하면 더욱 유용하다.

*Git Flow 설명은 지난 포스트 참고 - [Git] Git Flow로 브랜치 관리하기

이렇게 테스트 코드를 실행하거나, 새로운 버전을 release 하기 전에 TestFlight를 실행할 수 있는데

이러한 자동화 기능을 CI/CD라고 한다.

CI/CD를 위한 툴은 Jenkins, fastlane, Buildkite 등 다양한데,

오늘은 GitHub Action을 알아보자.

CI/CD란?

CI : Continuous Integration (지속적 통합)
CD : Continuous Deployment (지속적 배포) 또는 지속적인 서비스 제공(Continuous Delivery)

CI는 빌드/테스트 자동화 과정이다.

코드 변경사항에 대해 정기적인 테스트가 실행되므로 코드 충돌을 방지할 수 있다.

CD는 배포 자동화 과정이다.

GitHub Action이란?

Git에 코드를 올리는 것만으로 빌드/테스트, 배포를 자동으로 실행하는 기능이다.

GitHub의 Understanding GitHub Actions 페이지에 친절히 설명되어 있다.

The components of GitHub Actions

Events : 특정 상황이 발생한다면 (ex. 특정 branch에 Push 했을 때)
WorkFlows : 이 작업들을 실행시키겠다.
Jobs : WorkFlows에 명시된 1개의 작업이다. (ex. Unit Test를 실행)
- 여러 개의 Jobs는 병렬적 (동시 다발적)으로 실행된다.
- Job 내부에서 순차적으로 실행할 내용을 Step으로 구분한다.
Actions : 자주 사용하는 명령을 Action에 정의해뒀다가 Step에서 사용할 수 있다. (재사용성 높음)
Runners : Job을 실행하는 주체이다. (VM 개념)
- 각각의 Job은 독립적인 Runner를 가진다.

*전반적인 설명은 GitHub의 소개 영상을 참고
*Event, Workflows, Jobs, Actions, Runners에 대한 자세한 설명은 GitHub 링크를 참고

GitHub Action 사용하기 - 테스트 코드 자동 실행

이제 yml 파일을 추가해서 CI를 구현해보자.

먼저 GitHub의 Actions 탭에서 Swift 항목의 Actions를 생성한다. 아래 캡쳐 참고

(Swift Package를 빌드/테스트해야 하기 때문)

이제 아래처럼 yml 파일에 원하는 자동화 조건을 작성할 수 있다.

*우측의 MarketPlace에 xcodebuild 등 명령어를 검색하면 자세한 사용 방법이 나온다.

yml에 작성한 코드를 살펴보자.

yml 예시

// Workflow 이름
name: Run Test

// ✅ 트리거 조건 (push 하거나 PR 하면 하단의 jobs를 실행하겠다는 뜻)
on:
  push:
    branches: [ develop ]  // develop branch로 push한 상황
  pull_request:
    branches: [ develop ]  // develop branch로 PR 생성한 상황

// ✅ 트리거 발생 시 실행할 작업들 
jobs:
  // ✅ 이번 예시에서는 "build"라는 1개 작업만 진행
  build:  

    runs-on: macos-latest  // iOS 플랫폼에서 실행한다는 뜻

    // ✅ job 내부에서 순차적으로 실행할 내용
    steps:
    - uses: actions/checkout@v3  // repository에 체크아웃해서 job이 접근 가능하게 한다는 뜻 (Github Actions에서 미리 정의한 명령)
    - name: Build Xcode  // 실행할 작업 이름
      run: |  // 여러가지 명령어를 사용할 때 "|" 입력
        xcodebuild clean test -project WhatWeEat.xcodeproj \
        -scheme WhatWeEat \
        -destination 'platform=iOS Simulator,name=iPhone 13,OS=latest'
        // Xcode로 특정 환경에서 clean 및 test를 진행하겠다는 뜻
        // ❗-project WhatWeEat/WhatWeEat.xcodeproj를 쓰면 경로를 못찾는 문제 발생 가능
        // ❗-destination '...,OS=14.1'를 쓰면 OS 버전이 안맞는 문제 발생 가능

on에서 트리거 조건을 설정하고,
jobs에서 트리거 발생 시 실행할 작업들을 설정하고,
steps에서 job에서 실행할 일을 설정한다.

이 예시에서는 develop branch로 merge하거나 PR을 생성하는 시점에 테스트 코드를 실행하도록 자동화했다.
(이외에도 새로운 Issue가 생성됐을 때, 특정 Label이 추가됐을 때 등의 시점으로도 설정 가능하다.)

❗로 표시한 부분에 주의하자..

(~~에러를 해결한~~ 삽질 과정은 아래에 기록했다.)

uses 키워드

steps의 uses 키워드 를 통해

GitHub Action에서 미리 정의한 명령을 가져와서 편리하게 사용할 수 있다.

위 코드의 actions/checkout@v3 명령은 뭘 의미할까?

"repository에 체크아웃해서 job이 접근 가능하게 한다"는 뜻이다.

*체크아웃 개념이 궁금하다면 이 링크를 참고

run 키워드

코드 하단의 run 키워드에는 이런 내용이 들어있다.

-project 플래그 : test 할 프로젝트이다.
-scheme 플래그 : 빌드할 scheme 이다.
-destination 플래그 : 빌드 시 사용할 플랫폼, 기기, iOS 버전이다.

CocoaPods을 사용했다면

만약 SPM 대신 CocoaPods을 사용했다면 에러가 발생한다.

pod install, project 대신 workspace로 실행해야 하기 때문이다.

따라서 run 부분을 아래 코드로 바꿔야 한다.

// CocoaPods 사용 시
run: |
  pod install --repo-update --clean-install --project-directory=HappyChuseok/
  xcodebuild clean test -workspace HappyChuseok/HappyChuseok.xcworkspace -scheme HappyChuseok -destination 'platform=iOS Simulator,name=iPhone 11 Pro,OS=latest'
        
// 참고 - SPM 사용 시
run: | 
  xcodebuild clean test -project WhatWeEat/WhatWeEat.xcodeproj -scheme WhatWeEat -destination 'platform=iOS Simulator,name=iPhone 13 Pro,OS=14.1'

이외에도 원하는 swift-version을 명시하는 것도 가능하다.

*GitHub의 Building and testing Swift 페이지를 참고

Workflow 작동 확인하기

아래처럼 yml 파일을 추가하면서 commit하면 된다.

Actions 탭에 들어갔는데 아무 일도 일어나지 않았다.

아래처럼 Run Test라는 WorkFlow는 추가됐지만, 아직 작동 (Run)되지 않은 것을 볼 수 있다.

원인은 트리거 조건이 발생하지 않았기 때문이다.

(develop branch에 Push/PR하는 게 트리거 조건이었는데, 위에서 master branch에 커밋했음)

그리고 생각해보니 Unit Test를 추가하지 않았다;

다시 Unit Test를 추가하고,

새로운 branch를 생성한 뒤 develop branch로 PR을 생성했더니 아래처럼 실패 메시지가 생겼다.

PR 생성 후 하단에 뜬 메시지 (실패)

아래처럼 Actions 탭에서 상세내용을 확인 가능하다.

에러 메시지에 "xcodebuild: error: 'WhatWeEat/WhatWeEat.xcodeproj' does not exist." 내용이 있다.

*참고 - 아래처럼 현재 Unit Test 파일이 들어있는 디렉토리는 분리되어 있다.

검색해보니 디렉토리를 못찾을 수 있어서 working-directory를 추가하라는 내용이 있었다.

(검색 키워드 : GitHub Action, ios, exit code 66)

Process completed with exit code 66 during setup of Github Actions iOS project

working-directory에 WhatWeEatTests 디렉토리를 넣어봤지만 그래도 안됨..

그래서 경로 설정에 문제가 있다고 판단하여

-project WhatWeEat/WhatWeEat.xcodeproj -> WhatWeEat.xcodeproj로 바꿔봤는데 exit code 66 문제가 해결됐다!!!

근데 다른 에러가 생김..

157번 줄에 "xcodebuild: error: Unable to find a destination matching the provided destination specifier:"라는 내용이 있다.

162번 줄 아래로 available destination을 보여주는데 전부 OS: 15.2로 되어있다.

이유는 모르겠지만 최신 버전의 OS를 써야하는듯..?

그래서 -destination 'platform=iOS Simulator,name=iPhone 13 Pro,OS=14.1' -> OS=latest로 변경했다.

근데 그래도 실패

169번 줄에 "Reason: Cannot test target “WhatWeEatTests” on “iPhone 13 Pro”:

iPhone 13 Pro’s iOS Simulator 15.2 doesn’t match WhatWeEatTests’s iOS Simulator 15.5 deployment target." 라는 내용이 있다.

WhatWeEat의 deployment target은 14.0으로 설정했고,

엥.. WhatWeEatTests의 deployment target은 따로 정한 적이 없는데..?

근데 WhatWeEatTests Target의 Build Settings를 확인해보니.. 15.5로 설정되어 있었다;; 에러 메시지가 맞았다.

Tests Target의 iOS deployment target 설정을 꼭 확인하자

그래서 WhatWeEatTests의 iOS deployment target을 14.0 (WhatWeEat Target과 동일하게)로 변경하고 재시도했다.

이번에는 성공!!!

테스트에 15분이나 걸렸다.

(중간중간 codesign 내용도 있던데.. 트리거 조건에 master branch가 있어서 그런가?)

PR 생성 후 하단에 뜬 메시지 (성공!!)

README에 Badge 추가하기

아래처럼 Workflow의 성공 여부를 나타내는 Badge를 만들 수 있다. (맨 오른쪽)

Badge 에시

Actions 탭에서 Workflow를 선택한 뒤

우상단의 ... 버튼을 탭하고, Create status badge를 탭한다.

그럼 Markdown 소스코드가 나오는데, 그걸 README에 복붙하면 된다.

Badge 생성하는 방법

Badge를 만드는 코드를 아래에 남겨본다.

![iOS 14.0](https://img.shields.io/badge/iOS-14.0-lightgrey?style=flat&color=181717)
[![Swift 5.6](https://img.shields.io/badge/Swift-5.6-F05138.svg?style=flat&color=F05138)](https://swift.org/download/) 
[![Xcode 13.4](https://img.shields.io/badge/Xcode-13.4-147EFB.svg?style=flat&color=147EFB)](https://apps.apple.com/kr/app/xcode/id497799835?mt=12) 
[![Run Test](https://github.com/just1103/WhatWeEat/actions/workflows/test_on_develop.yml/badge.svg)](https://github.com/just1103/WhatWeEat/actions/workflows/test_on_develop.yml)

- Reference

GitHub > Understanding GitHub Actions
GitHub > Building and testing Swift
Blog > CI/CD란?
Blog > Github Actions 를 이용한 xcode build & test 자동화
YouTube > 드림코딩 - 제발 깃허브 액션 모르는 개발자 없게해 주세요

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Keychain] 키체인 사용하기 (예제 코드)

Applecider — Sat, 27 Aug 2022 00:26:19 +0900

저번 포스팅 [Keychain] 공식문서 읽는 방법 - 공식문서만으로 키체인을 이해해보자 에서 Keychain 이론을 다뤘다.

이제 간단한 예제를 통해 Keychain을 사용해보자.

*이 예제에서는 비밀번호를 저장하지만, 실제로는 사용자 인증 등 토큰을 저장하는 형태로 흔히 사용한다.

1. Keychain에 비밀번호 추가 (등록)하기

먼저 Keychain에 저장할 데이터 타입을 정의하자.

이번 예제에서는 password만 저장하지만, 다른 프로퍼티를 추가/저장하는 것도 가능하다.

struct Credentials {
//    var username: String  // 이번에는 필요 없음
    var password: String
}

Keychain 관련 Error 타입도 정의하자.

enum KeychainError: Error {
    case noPassword
    case unexpectedPasswordData
    case unhandledError(status: OSStatus)
}

이제 Keychain 타입을 정의하고, Keychain에 비밀번호를 추가하는 메서드를 구현하자.

struct Keychain {
    static func addItemsOnKeyChain(with password: String) {
        let credentials = Credentials(password: password)  // 저장할 비밀번호
        let password = credentials.password.data(using: String.Encoding.utf8)!  // pw를 암호화시킨 것

        // query (질의)를 통해 개발자는 keychain에게 질문을 함 
        // "이걸 Keychain에 보관해줄래?"
        // "kSecClassGenericPassword (일반적인 비밀번호)라는 query인데, 암호화해서 보관할 데이터는 password야"
        let query: [String: Any] = [kSecClass as String: kSecClassGenericPassword,
//                                    kSecAttrAccount as String: account,  // 이번에는 필요 없음
                                    kSecValueData as String: password]  
        
        let status = SecItemAdd(query as CFDictionary, nil) 
        // "query를 던질건데 pw는 신경쓰지 않겠다, nil 대신 item에 담아서 서버로 보내겠다"
        // 기밀정보가 많다면, data 중에서 뭘 필요로 할지 필터링할 수 있도록 한 것

        if status == errSecSuccess {
            print("add success")
        } else if status == errSecDuplicateItem {
            print("keychain에 Item이 이미 있음")
        } else {
            print("add failed")
        }
    }
}

iOS에서는 번들마다 keychain을 부여한다. (번들은 앱이 가지고 있는 주머니)
위에서 정의한 addItemsOnKeyChain 메서드를 통해 keychain의 kSecClassGenericPassword에 value가 추가된다.
한 번 추가되면 동일한 내용을 다시 저장할 수 없다. (errSecDuplicateItem라는 OSStatus status가 발생한다.)
저번 포스트의 공식문서에서 봤듯이 ❗query (질의)는 Keychain에 저장할 Item이 어떤 종류의 정보인지 등을 나타낸다.
Keychain에 Item을 add 할 때는 add에 맞는 질의를 하고, search를 할 때는 search에 맞는 질의를 해야 한다.
완성된 query는 SecItemAdd 함수의 attributes 매개변수로 전달됐다.
result 매개변수에는 nil이 전달됐다. SecItemAdd 메서드의 반환값이 필요 없다는 의미이다.

2. Keychain에 등록한 비밀번호 검색하기

static func searchItemFromKeychain() throws -> String? {
    let query: [String: Any] = [kSecClass as String: kSecClassGenericPassword,
//                                kSecMatchLimit as String: kSecMatchLimitOne,
                                kSecReturnAttributes as String: true,  // search query에 Attribute가 있어야 원하는 값을 찾을 수 있음
                                kSecReturnData as String: true]

    var item: CFTypeRef?
    let status = SecItemCopyMatching(query as CFDictionary, &item)  // &item: 키체인 참조가 아님! 복사값을 넘김
    guard status != errSecItemNotFound else { throw KeychainError.noPassword }
    guard status == errSecSuccess else { throw KeychainError.unhandledError(status: status) }

    guard let existingItem = item as? [String : Any],  // 검색해서 찾은 Item을 타입 캐스팅해서 사용하면 됨
          let passwordData = existingItem[kSecValueData as String] as? Data,
          let password = String(data: passwordData, encoding: String.Encoding.utf8) else {
              throw KeychainError.unexpectedPasswordData
          }

    return password
}

완성된 search query를 SecItemCopyMatching 메서드의 query 매개변수에 전달했다.
result 매개변수에는 &item이 전달됐다.
검색 결과 Keychain에 저장된 Item을 찾았다면, 변수 item에 할당된다.
item을 타입 캐스팅하여 값에 접근할 수 있다.

3. Keychain에 등록한 비밀번호 업데이트하기

// Item을 업데이트한 뒤 결과에 따라 Alert를 띄울 예정
static func updateItemOnKeyChain(with password: String) -> UIAlertController { 
    let previousQuery: [String: Any] = [kSecClass as String: kSecClassGenericPassword]  // search query

    let newPW = password.data(using: .utf8)
    let updateQuery: [String: Any] = [kSecValueData as String: newPW]  // 업데이트할 Item
    let status = SecItemUpdate(previousQuery as CFDictionary, updateQuery as CFDictionary)

    if status == errSecSuccess {
        print("update complete")
        return AlertPresenter.showAlert(message: "비밀번호가 변경되었습니다")
    } else {
        print("not finished update")
        return AlertPresenter.showAlert(message: "주의 - 비밀번호 변경 중에 오류가 발생했습니다")
    }
}

마찬가지로 update query가 필요하다.
SecItemUpdate 메서드를 활용한다.

- Reference

관련 포스트
- [Keychain] 공식문서 읽는 방법 - 공식문서만으로 키체인을 이해해보자 (긴글 주의)
Apple Developer Documentation > Keychain Services
Apple Developer Documentation > Article - Adding a Password to the Keychain
Apple Developer Documentation > SecItemAdd(_:_:)
Apple Developer Documentation > Article - Searching for Keychain Items
Apple Developer Documentation > SecItemCopyMatching(::)
Apple Developer Documentation > Article - Updating and Deleting Keychain Items
Apple Developer Documentation > SecItemUpdate(::)

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Keychain] 공식문서 읽는 방법 - 공식문서만으로 키체인을 이해해보자 (긴글 주의)

Applecider — Fri, 26 Aug 2022 23:53:37 +0900

공식문서를 읽다 보면 링크를 타고 다른 문서를 읽게 되고,
또 그 안에 링크를 타고 다른 글을 읽어야 하고... 가 반복되기 때문에 지칠 때가 있다.

이번 포스트에서는 공식문서들을 효율적으로 떠돌아다니는 방법을 소개하고자 한다.

다른 키워드에 비해 Keychain에 대한 공식문서 양이 (그나마) 방대하지 않아서 (← 수박 조언 감사해요)

오직 공식문서만으로 Keychain을 이해해보는 시도를 했다.

아래의 떠돌이 과정 (빨간색 글씨 참고)을 통해 공식문서의 중요도를 판단하는 데 도움이 되었으면 한다.

1. 최상단의 문서 - Keychain Services

Keychain에 대한 설명이 시작되는 문서는 Keychain Services이다.

요약 : Keychain service란 사용자 대신 작은 데이터 덩어리(small chunks of data)를 안전하게 저장하기 위한 기능이다.
이게 왜 필요할까? 사용자가 비밀번호 등의 데이터를 일일이 기억하는 것이 번거롭기 때문이다.
Keychain service API는 앱에게 작은 데이터를 Keychain에 저장할 수 있는 메커니즘을 제공한다.
Keychain (열쇠고리)은 작은 데이터를 저장하는 “암호화된 데이터베이스” (encrypted database)이다.
작은 데이터란 비밀번호, 신용카드 정보, 짧은 메모 등의 기밀 정보, 그리고 사용자가 인지하지 못하는 암호키 (cryptographic keys), 인증서 등을 말한다.

*다음은 문서 하단 Topics의 API Components의 3개 링크를 따라가 읽으면 된다.

2. API Components

2-1) Keychain Item

요약 : Keychain에 Data (기밀 정보)를 저장할 때, Data를 포장해서 Item 형태로 저장한다.
Data와 Attribute를 함께 포장해서 1개의 Item으로 만든다. Attribute를 통해 Data를 검색/접근한다.
Keychain service는 무슨 일을 할까? Data를 암호화하고, Keychain에 Item을 저장하는 것을 관리한다. (Keychain은 디스크에 저장된 “암호화된 데이터베이스”이다.)
나중에 “승인된 프로세스” (authorized processes)를 통해 Keychain service를 사용하여 Item을 찾고 Data의 암호를 해제한다.

*문서 하단 Topics에 First Steps 항목이 있다면 반드시 읽어야 한다. 기초 개념을 다루기 때문이다.
*아래의 Adding Keychain Items, Keychain Item Search, Keychain Item Modification 항목도 중요해보인다.
(Legacy 어쩌구 주제들은 '과거에 이 방식을 사용했구나' 하고 넘어가면 된다.)
*일단 1번 문서와 연결된 나머지 링크들을 먼저 읽자.

2-2) Keychains

요약 : macOS의 전체 Keychain을 생성하고 관리한다.
iOS Keychain과 macOS Keychain의 특성이 다르다.
iOS
- 여러 앱들은 single Keychain에 접근할 수 있다.
  *single Keychain이란?
  앱마다 개별적인 Keychain을 가지는 게 아니라, 여러 앱들이 동일한 열쇠고리를 공유한다는 의미이다.
- 아이폰의 잠금/잠금 해제 상태에 따라 Keychain도 자동으로 아이폰과 동일한 잠금/잠금 해제 상태가 된다.
- 여러 앱들이 동일한 Keychain을 공유하고 있지만, 1개 앱이 Keychain에 들어있는 모든 Item들에 접근할 수 있는 것이 아니다. 특정 앱은 자신이 가진 Keychain Item에만 접근 가능하다.
  (앱이 소속된 group이 있는 경우, 해당 group의 Item에는 접근 가능하다.)
macOS
- 여러 개의 Keychain을 가질 수 있다.
- 맥북의 Keychain Access 앱을 통해 사용자가 직접 Keychain을 관리할 수 있고, iOS와 마찬가지로 default Keychain으로 암시적으로 작업할 수 있다.
- 그럼에도 Keychain service API는 개발자가 직접 Keychain을 조작 (생성/수정)할 수 있도록 함수를 제공한다.
  ex. 특정 앱 전용의 Keychain을 생성/관리할 수 있다.
- ”강력한 접근 제어 메커니즘”은 일반적으로 “키 체인 접근 utility”를 복제하려는 앱 이외의 다른 앱에 대해 이것 (Keychain 조작)을 불필요하게 만든다.

*요약 부분을 때 'macOS에 대한 내용이니까 당장 앱 개발할 때는 필요 없겠구나'를 알 수 있다.
*문서 하단 Topics를 훑어보며 'Creation and Deletion, Search 등이 있구나'를 체크하고 넘어가면 된다.

2-3) Access Control Lists (AC List)

요약 : macOS에서 Keychain Item에 접근 가능한 앱을 제어한다.
macOS에서 1개 Keychain Item은 Access 인스턴스를 가진다.
(Access 인스턴스에는 “AC List”가 들어있다. AC List는 여러 개의 “Entry(항목)”로 구성된다.)
Entry에는 Operations 배열 및 (해당 item을 사용하여 operations를 수행할 수 있음을 신뢰할 수 있는) Trusted app 배열이 들어있다.
AC List는 해당 Keychain Item에 대한 접근 가능성 (Accessibility)을 제어한다.
이러한 AC List는 어떻게 사용될까?
특정 앱이 문서에 서명 (sign) 하기 위해 Keychain Item에 접근하려 한다면, 시스템은 AC List를 뒤져서 원하는 operation을 갖고 있는 Entry를 찾아낸다.
- 만약 해당 Entry가 없으면 시스템은 접근을 거부한다. (거부 당한 앱은 다른 작업을 시도하거나, 사용자에게 알림을 줄 수 있다.)
- 해당 Entry가 있으면 시스템은 Entry의 Trusted app 배열에 그 앱이 있는지 확인한다.
  - 만약 앱이 있으면 시스템은 접근권한을 부여 (grants access)한다.
  - 앱이 없으면 시스템은 사용자에게 확인 메시지를 표시한다. 사용자는 Deny, Allow, Always Allow 등을 선택할 수 있다. 사용자가 접근을 허용하면, 시스템은 그 앱을 Entry의 Trusted app에 추가한다.
Important: AC List는 iOS, 그리고 iCloud Keychain을 사용하는 macOS 앱에는 사용 불가하다.
이러한 환경에서 Keychain Item을 공유하려면, Access Group을 사용해야 한다.
(Sharing Access to Keychain Items Among a Collection of Apps 링크를 훑어보면, “하나의 개발 팀”에서 개발한 family apps가 있고, 그 앱들이 동일한 사용자 정보를 활용하는 상황이라면, Access Group을 지정해서 사용자 정보 (Keychain Items)를 공유할 수 있다는 내용이 나온다.)

*문서 하단 Topics에 Access Creation, Access Query 등이 있음을 훑고 넘어간다.
*여기까지 1번 문서 Topics의 API Components를 모두 읽었다. 이제 다시 2-1번 문서에서 봤던 First Steps 링크를 보러간다.

3. Article - Using the Keychain to Manage User Secrets

요약 : 사용자의 작은 기밀정보를 Keychain에 보관하여 사용자가 일일이 기억할 필요가 없게 하자.
Keychain service를 통해 사용자는 암호화된 저장소에 쉽게 접근할 수 있다.
ex. 인터넷 비밀번호를 저장하기 위해 Keychain Item을 사용한 프로세스 예시
- 아래는 사용자의 인터넷 비밀번호가 인증되면 (End 단계), 네트워크 접근을 할 수 있음을 나타내는 그림이다.
- 비밀번호가 들어있는 Keychain Item을 Add 또는 Modify하거나 비밀번호를 인증하는 과정을 설명한다.
  - SecItemCopyMatching을 사용하여 Item을 검색한다. Item이 없으면 SecItemAdd를 통해 Item을 Add한다.
  - Item이 있으면 Authenticate(인증)을 진행한다. 인증에 실패하면 SecItemUpdate 을 통해 Item을 Modify한다.

Involve the User When Needed (필요시에만 사용자를 통해 입력값을 받음)
- 앱이 최초로 Credentials (자격 증명)을 필요로 할 때는 Keychain에 저장된 비밀번호가 없다.
- 이 경우 앱은 사용자에게 메시지를 표시하여 Credentials를 입력받는다. (위 그림의 오른쪽 Flow 참고)
- 앱은 SecItemAdd 함수를 통해 이 사용자 입력값을 저장한다. 이제 앱은 네트워크 접근을 이어갈 수 있다.
  (본문 링크는 중요하므로 꼭 확인해야 한다.)
  - 참고 - 오른쪽 Flow에서 사용자 입력값에 대한 Authenticate (인증)이 필요한 이유는?
    - 이 상황에서 '인증'이란 사용자의 id/pw가 일치하는지 서버에게 물어보는 것이다.
    - mac에서 사용하던 웹사이트를, 처음으로 앱에서 로그인할 때, id/pw는 있고, 키체인은 없을 때 오른쪽 Flow를 탄다.
    - 제대로 된 사용자 입력값을 받을 때까지 Item Add를 하지 않는다.
- 나중에 서버가 재인증 (reauthentication)을 요구할 때, 앱은 사용자를 거치지 않고 Keychain에 저장한 Credentials를 꺼내올 수 있다.
- Keychain에 Item을 추가하는 방법은 Adding a Password to the Keychain 문서를 확인하면 된다.
  (마찬가지로 본문 링크이므로 꼭 확인해야 한다.)
Avoid Bothering the User in the Common Case
- 사용자로부터 비밀번호를 입력받거나, 새 비밀번호를 설정하는 등의 interaction을 최소화하는 것이 좋다.
  따라서 일반적으로 가운데 Flow를 따른다.
- 사용자가 앱을 오랜만에 사용했을 때 등의 상황에서 Secure network resource는 주기적으로 reauthentication을 요구한다.
- 이에 대응하기 위해 앱은 SecItemCopyMatching 함수를 통해 Keychain에서 해당 비밀번호를 찾는다.
  이 비밀번호로 인증이 성공하면 사용자 interaction이 필요 없어서 좋다.
Handle Changes Gracefully
- 가끔 사용자가 앱 영역 밖에서 비밀번호를 수정할 수 있다. (ex. 웹사이트에서 사용자가 비밀번호를 변경하는 경우)
- 이때 앱의 subsequent keychain item을 찾아서 얻은 비밀번호는 수정 이전의 비밀번호이므로 인증에 실패하게 된다.
- 이 경우 사용자를 통해 새로운 비밀번호를 받고, SecItemUpdate 함수를 통해 기존 저장값을 수정한다.
  (위 그림의 왼쪽 Flow 참고)
- SecItemDelete 함수를 통해 Keychain에서 비밀번호를 완전히 삭제할 수 있다.

*문서 하단 Topics의 Item Creation and Modification의 3개 링크가 중요해 보인다. (2-1번 문서의 상위 Topic에도 있었던 링크)
*See Also의 First Steps 링크를 먼저 보는 것이 좋다. 더 기초적인 개념일 테니..
(위 링크를 따라가도 좋지만, 어차피 본문에 First Steps 링크가 들어있다.)

4. Class - SecKeychainItem

요약 : Keychain을 나타내는 opaque 타입이다.
*opaque 타입이란?
반환타입이 Opaque 타입인 함수는 반환 정보를 외부에 숨길 수 있다.
예를 들어 함수의 반환타입이 Opaque 타입이라면, "A 프로토콜을 채택한 타입"이면 모두 가능하도록 설정할 수 있다.
Keychain에 저장된 certificate (인증서)에 대한 SecKeyChainItem 객체는 SecCertificate로 안전하게 캐스팅될 수 있다.
(본문 링크인 SecCertificate을 훑어보면, 특정 인증서를 나타내는 CoreFoundation 추상 타입의 객체임을 알 수 있다.)
*인증서 관련 개념은 나중에 찾아보기로 하고 일단 패스...
(Apple은 네이밍을 신경 쓴다. 클래스 이름을 먼저 확인하자. 클래스 요약을 보면 이 내용은 OS, 네트워크 프로토콜 관련 내용이므로 일단 패스해도 된다고 유추할 수 있다.)

*문서 하단 Topics에 또 First Steps가 있다. 젠장...
그래도 하나는 이미 읽은 링크이고, 하나는 2번 문서의 First Steps 마지막 링크와 일치하니까 다행이다..

이제 이 마지막 링크를 보자.

5. Function - SecKeychainItemGetTypeID()

요약 : Keychain Item 객체가 속한 Opaque 타입의 identifier를 반환한다.
이 함수의 반환값을 CFTypeID identifier와 비교할 수 있다. CFTypeID identifier는 CFGetTypeID(_:) 함수의 반환값이다.
(본문 링크를 훑어보면 CFTypeID는 UInt의 typealias이고, Core Foundation에서 타입 identifier를 정의하며, 타입 identifier란 CoreFoundation 객체가 "속해 있는" Opaque 타입을 식별하는 UInt 값임을 알 수 있다. 대충 넘어가자..)
이 함수의 반환값은 release 마다, platform 마다 변경될 수 있다.

*문서 하단 See Also의 First Steps는 이미 읽은 링크들이다.
이제 3번 문서의 Item Creation and Modification의 링크를 따라간다. 이게 본론인 듯. 드디어 코드가 나온다..

6. Article - Adding a Password to the Keychain

요약 : 사용자를 대신해서 Keychain에 네트워크 Credentials (자격 증명)을 추가하는 방법을 설명한다.
Keychain service를 사용하면 사용자 비밀번호를 간단히 저장할 수 있다.

(1) Get Set Up (설정하기)

앱에서 사용할 Credentials 정보를 저장할 구조체를 정의해라.
그다음, Keychain 접근 결과를 나타내기 위한 Error 열거형을 정의해라.
그리고 앱의 서버를 입력해라.

struct Credentials {
    var username: String
    var password: String
}
enum KeychainError: Error {
    case noPassword
    case unexpectedPasswordData
    case unhandledError(status: OSStatus)
}
static let server = "www.example.com"

(2) Create an Add Query

위에서 정의한 Credentials 구조체의 인스턴스, server 상수를 사용하여 Add query를 생성해라.

let credentials = Credentials(username: "Applecider", password: "1234")
let account = credentials.username
let password = credentials.password.data(using: String.Encoding.utf8)!  // 비밀번호는 Data 타입으로 인코딩함
var query: [String: Any] = [kSecClass as String: kSecClassInternetPassword,
                            kSecAttrAccount as String: account,
                            kSecAttrServer as String: server,
                            kSecValueData as String: password]

위 코드의 query 딕셔너리를 자세히 보자.
첫 번째 key-value : kSecClass가 있는 key-value는 “Item이 어떤 종류의 정보인지” 나타낸다.
예시의 value인 kSecClassInternetPassword는 "Item이 Internet password (인터넷 비밀번호)임"을 나타낸다.
→ ❗Keychain service는 이것을 보고, Data가 기밀 정보이고 암호화를 필요로 한다고 추론한다. 또한 Item이 Attribute를 가지는 것을 보장한다. 여기서 Attribute는 다른 인터넷 비밀번호와 이 Item을 구별하는 역할을 한다.
(다른 인터넷 비밀번호의 Attribute와 이 Item의 Attribute가 구별된다는 뜻인 듯)
This also ensures that the item has attributes that distinguish it from other Internet passwords, such as the server and account to which it applies.
두세 번째 key-value : 위에서 말한 Attribute 정보를 제공하고 있다.
(상수 account를 통해 사용자의 이름을, 상수 server를 통해 도메인 이름을 첨부한다.)
가장 중요한 비밀번호는 Data 인스턴스로 인코딩하여 query에 넣는다.
Note: Keychain service는 관련된 kSecClassGenericPassword 를 제공한다. Generic password (일반적인 비밀번호, 제네릭 타입 아님)는 Internet password와 비슷하지만, remote access와 관련된 Attribute가 없다. kSecAttrServer 등의 Attribate가 필요 없을 때 사용하면 된다.
- (본문 링크를 타고 kSecClassGenericPassword 를 훑어보면, 일반적인 비밀번호 Item을 나타내는 “값”이며, 전역 변수임을 알 수 있다. 아래의 Attribute들은 이 클래스의 Item에 적용된다. 그리고 이 전역변수의 타입은 CFString 클래스인데, Core Foundation에 속한다. iOS 개발에 대부분 사용되는 Foundation 프레임워크의 Definition을 뜯어보면 이 Core Foundation을 import하고 있다.)
- 참고 - 접두어 k- 는 왜 붙일까? (참고: What does the 'k' prefix indicate in Apple's APIs?)
  - The k means “constant” in hungarian notation. (Hungarian noun “konstans” means “constant”.)
  - macintosh 프로그래밍 초기부터 사용한 네이밍 컨벤션이다.

(3) Add the Item

let status = SecItemAdd(query as CFDictionary, nil)
guard status == errSecSuccess else { throw KeychainError.unhandledError(status: status) }

query가 완성되면 SecItemAdd 함수에 전달하면 된다.
*본문 링크는 중요하니까 SecItemAdd 함수에 대한 본문 링크를 먼저 확인해보자. (7번 문서 요약 참고)
일반적으로 Add operation의 두 번째 argument에서 참조 형태로 제공되는 return data를 무시한다.
하지만 함수의 return status를 확인하여 operation이 성공했는지 항상 확인하는 것이 좋다.
ex. 주어진 Attribute를 가진 Item이 이미 존재하는 경우 Add operation이 실패할 수 있다.

(4) Ensure Searchability

나중에 Item을 검색하려면, Attribute를 활용해야 한다.
위 예시에서 server 및 account는 Item을 다른 Item과 구별하는 특징이다.
server와 같은 constant attribute는 검색하는 동안 동일한 값을 사용하지만, account는 런타임 때 사용자가 제공한 값을 가지고 있으므로 dynamic attribute이다.
앱이 다양한 Attribute를 가지는 유사한 Item을 추가할 일이 없다면, dynamic attribute를 search 매개변수에서 생략할 수 있다.
*뒷부분은 나중에 보자...

*(본문 링크 SecItemAdd 함수를 봤다면) Add Item을 다 봤으니 Search Item 부분을 읽어보자. (9번 문서 요약 참고)

7. Function - SecItemAdd(_:_:)

func SecItemAdd(_ attributes: CFDictionary, 
              _ result: UnsafeMutablePointer<CFTypeRef?>?) -> OSStatus

요약 : 1개 이상의 Item을 Keychain에 추가한다.
문서가 길지만.. 침착히 매개변수 attributes, result 그리고 반환타입을 알아보자.
attributes 매개변수
- 타입은 딕셔너리 (CFDictionary)이다. (CFDictionary 클래스는 immutable 딕셔너리 객체에 대한 참조이다.)
- 딕셔너리의 역할은 Keychain에 추가할 Item을 설명하는 것이다. query가 이 매개변수에 전달된다.
- ✅ query에는 Item의 class, data, atrribute 정보가 담겨있다.
  1. Item의 Class
    - Items의 Classes에 따라 다른 Attribute와 behavior이 활용된다. kSecClass라는 key에 대한 value는 무엇을 의미할까? ✅ value는 Keychain service에게 “저장할 Data가 어떤 종류인지” 알려주는 역할을 한다. 저장할 Data가 비밀번호인지, certificate인지, cryptographic key인지 나타낼 수 있다. (ex. kSecClassGenericPassword는 저장할 데이터가 일반적인 비밀번호임을 알려준다.)
    - 본문 링크의 kSecClass를 보면, 딕셔너리의 key이고 value는 Item의 Class를 나타내는 전역 변수임을 알 수 있다.
    - Item Class Keys and Values를 보면, Keychain Item의 종류 (비밀번호, certificate 등)에 따라 Class를 지정해야 함을 알 수 있다.
      *문서 하단 Topics의 Item Class의 Key와 Value로 들어갈 수 있는 k- 상수들을 확인할 수 있다!
      훑어보니 중요한 문서인 듯 (8번 문서 요약 참고)
  2. Data
    - ✅ 암호화시켜서 저장하게 될 데이터를 의미한다. kSecValueData라는 key를 사용하고, key의 value에 저장할 Data (ex. 비밀번호)를 넣는다. Keychain service는 Item의 종류에 따라 이 Data를 암호화할지 말지를 결정한다. Item이 기밀정보라면 (즉, 비밀번호 타입이거나 private key를 포함하고 있는 경우) Data를 암호화한다.
    - 본문 링크의 kSecValueData를 보면, 이 딕셔너리 key의 value는 CFData 타입이다.
  3. Attribute (optional)
    - Attribute key 정보를 말한다. ✅ 이 key는 나중에 Item을 검색할 수 있게 해주고, Data가 사용되거나 공유되는 방법을 나타낸다. 원하는 만큼 Attribute를 추가할 수 있지만, Item Class에 따라 추가할 수 있는 Attribute의 종류가 정해져 있다.
    - 본문 링크의 Item Attribute Keys and Values를 보면, Attribute 정보를 나타내기 위한 key/value를 확인할 수 있다. (ex. 아래의 Topics의 Password Attribute Keys를 보면 저장할 Data가 비밀번호인 경우에 사용 가능한 Attribute key들이 나와있다.)
  4. 반환 타입 (optional)
    - 1개 이상의 반환 타입 key를 말한다. 이 key가 의미하는 것은 ✅ 성공적으로 완료되면 (SecItemAdd 메서드를 통한 Add Operation이 완료되면) 반환되도록 할 Data가 무엇인지이다.
      → 이걸 언제 사용할까?
      “Keychain”에 Item을 추가하는 것 (Add Operation)과 별개로 “서버”에도 정보를 보내서 저장하게 할 수도 있다. 이때 서버에 보내는 작업을 할 때 정보를 result 매개변수에 담아서 보내면 된다. (Keychain을 통해 암호화한 비밀번호를 result에 담아서 서버에게 보낸다는 뜻이다.) 그리고 서버에 정보를 보낼 때 Item에 담긴 기밀정보를 모두 보내도 되지만, 기밀정보가 많다면 원하는 정보만 필터링해서 보낼 수도 있다. 보통 SecItemAdd 함수의 반환값을 무시하는데, 이때는 result 매개변수에 반환값 key를 넣을 필요가 없다.
    - 본문 링크의 Item Return Result Keys를 보면, SecItemAdd 함수는 result 매개변수를 통해 Item의 Data 및 Attribute를 반환하고, 이 result 매개변수에게 pointer를 제공한다. (???) query 딕셔너리에 Item result key를 사용하여 result를 어떤 형태 (format)로 나타낼지 지정한다. (???)
      *이 부분을 이해하기 힘들었다. 이 함수의 result 매개변수를 먼저 보는 것이 좋겠다.
result 매개변수
- 타입은 UnsafeMutablePointer<CFTypeRef?>? 이다.
- CFTypeRef는 AnyObject의 typealias이다.
  (Core Foundation에서 정의된 base 타입이다. polymorphic 함수 (???)의 반환(타입)으로 사용된다.)
- UnsafeMutablePointer는 Generic Structure @frozen struct UnsafeMutablePointer<Pointee> 이다.
  이 인스턴스를 사용하여 메모리에 있는 특정 타입 (Pointee 타입)의 데이터에 접근할 수 있다.
- 반환 시 (SecItemAdd 메서드의 반환) 새롭게 추가된 Item에 대한 참조이다. 이 매개변수의 정확한 타입은 attribute 매개변수의 특정 value에 따라 결정된다. (attribute 매개변수의 4. 반환 타입 key의 value를 말하는 듯)
- result가 필요 없으면 nil을 할당하고, 만약 필요하면 앱 내부에서 참조한 객체를 메모리에서 해제해줘야 한다. (???)
- 참고 - result는 왜 포인터/참조 사용할까?
  사실 정답이 없는 문제이다. 값을 전달해도 되지만, 여기서는 참조를 넘겨주도록 구현했을 뿐이다.
반환값
- “result code”라고만 설명되어 있다.
- 타입은 OSStatus 이다. (근데 이상하게도 OSStatus 타입은 링크가 없다..)
- 본문 링크의 Security Framework Result Codes를 보면, Evaluate result codes common to many Security framework functions... 보안 관련 기능인가..?
- OSStatus을 구글링하면, 특정 함수의 “result code”라고 나온다. Keychain 관련 오류라고 봐도 될 듯?
- OSStatus 의미를 찾아주는 사이트: https://www.osstatus.com/
Discussion
- Keychain에 여러 Item을 한꺼번에 추가하려면, kSecUseItemList key를 사용하고, value에 딕셔너리들의 배열을 넣으면 된다. 단, 비밀번호가 아닌 Item만 가능하다.
- Xcode는 application-identifier entitlement (자격)을 앱 bundle에 추가한다. Keychain service는 이 entitlement를 사용하여 앱의 Keychain Item에 대한 접근권한을 부여한다.

*이제 attributes 매개변수 부분의 본문 링크인 Item Class Keys and Values를 살펴보자.

8. Item Class Keys and Values

요약 : Keychain Item의 Class를 지정해라.
Keychain Item의 종류 (ex. 비밀번호, certificate 등)에 따라 Class를 지정해야 한다.
Item의 Class는 무엇을 의미할까? 적용할 Attribute를 정하고, 시스템에게 저장할 Data를 암호화할지 말지를 결정하게 한다.
(ex. 비밀번호는 암호화하고, certificate은 암호화하지 않는다.)
key와 아래 목록의 value를 사용하여 새로 추가할 Item의 Class를 지정한다. (Item을 추가하려면 SecItemAdd 함수를 호출하면서 attributes 매개변수에 key/value 딕셔너리를 전달하면 된다.) ← 이렇게 보니 공식문서가 친절하긴 하다...
나중에 Item을 검색 (search)할 때는 query 딕셔너리의 동일한 key/value를 사용하면 된다. 이때 SecItemCopyMatching(_:_:), SecItemUpdate(_:_:), SecItemDelete(_:) 함수 중 하나를 호출한다.

*아래 Topics의 Item Class의 Key와 Value로 들어갈 수 있는 k- 들을 확인할 수 있다!

9. Article - Searching for Keychain Items

요약 : 개발자가 지정한 검색 criteria (기준)에 따라 Keychain Item을 검색한다.
Keychain Item을 검색하려면 query 딕셔너리를 사용하면 된다. ❗query 딕셔너리는 Keychain service API에게 어떤 Item Attribute를 검색할지, match (일치하는 항목)을 찾으면 무엇을 반환할지 알려준다.
- Attribute가 있어야 data를 찾을 수 있다!
  정확히는 Keychain Item이 아니라 ”search query에 Attribute가 있어야” 제대로 반환된다.
또한 검색을 구체화하기 위해 개발자는 query 딕셔너리를 통해 추가적인 매개변수를 지정할 수 있다.
ex. 문자열 Attribute를 match하거나, 일치 항목의 개수를 제한하고 싶은 경우, case sensitivity (대소문자 구분 여부) 등을 제어하면 된다.
Keychain에 비밀번호를 추가하는 저번 예시를 생각해보자. 사용자는 네트워크 서비스에 대한 Credentials (앱에 저장됨)를 제공하고, 앱을 사용하다가 다른 작업으로 넘어간다. 사용자가 다시 앱을 사용할 때, 앱이 계속 작동하려면 서버에서 reauthenticate이 필요할 수 있다. 이때 앱은 Keychain을 통해 비밀번호를 load한다.

(1) ❗Create a Search Query

let query: [String: Any] = [kSecClass as String: kSecClassInternetPassword,
                            kSecAttrServer as String: server,  // 이 Attribute를 가지는 Item을 검색하겠음
                            kSecMatchLimit as String: kSecMatchLimitOne,  // 검색 결과를 limit함
                            kSecReturnAttributes as String: true,  // Item을 찾으면 Attribute와 Data를 꺼내겠음
                            kSecReturnData as String: true]

query 딕셔너리를 구성하여 검색을 시작한다.
이 query는 server attribute가 일치하는 인터넷 비밀번호 Item을 검색한다. (10번 문서 요약 참고)
kSecMatchLimit라는 search 매개변수를 통해 result (검색 결과로 나온 Item)를 single value로 제한한다.
이 경우 keychain에서 찾은 첫 번째 항목만 얻게 된다.
*SecItemCopyMatching 메서드 참고 - query 매개변수의 구성요소 중 search 매개변수가 있다.
이 query는 Item의 Attribute 및 Data를 모두 요구하고 있다.
둘 다 필요한 이유는 kSecAttrAccount attribute가 사용자 name을 포함하고 있고, Item의 Data가 비밀번호 자체를 가지고 있기 때문이다. (Item Add query에서 사용한 Attribute를 말함)

(2) Initiate the Search

var item: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &item) // add 함수와 달리 result 매개변수가 nil이 아님
guard status != errSecItemNotFound else { throw KeychainError.noPassword } // 비밀번호를 저장한 적이 없는 경우 발생하는 error
guard status == errSecSuccess else { throw KeychainError.unhandledError(status: status) }

SecItemCopyMatching 함수를 호출하여 검색을 시작한다. *본문 링크를 따라 이 함수를 먼저 알아보자. (10번 문서 요약 참고)
먼저 반환된 status 값을 테스트해야 한다. match되는 Item이 없으면 error가 발생할 수 있다.
ex. 주어진 server에 비밀번호를 이전에 추가하지 않은 경우
이 경우 error가 발생하면 errSecItemNotFound result를 얻게 된다.
이 error를 통해 앱의 로그인 Flow를 처음 진행하고 있음을 감지할 수 있다.
검색에 성공하면 SecItemCopyMatching 메서드는 item 매개변수를 통해 result (검색 결과)를 제공한다.
반환된 Item의 타입은 query의 특성에 따라 다르다.

(3) Extract the Result

검색할 때 여러 반환 타입을 요청했고 (Item의 Attribute 및 Data를 요청했음), single result로 제한했으므로 result가 딕셔너리일 것을 예상해야 한다.
result를 [String: Any] 타입으로 타입 캐스팅하면, 검색해서 찾은 Item에 접근할 수 있다.
kSecAttrAccount key와 관련된 attribute 값으로부터 username을 복구할 수 있다.
kSecValueData key를 사용하여 비밀번호 Data를 추출할 수 있다. (추출해서 String 타입으로 인코딩하면 된다.)

guard let existingItem = item as? [String : Any],
    let passwordData = existingItem[kSecValueData as String] as? Data,
    let password = String(data: passwordData, encoding: String.Encoding.utf8),
    let account = existingItem[kSecAttrAccount as String] as? String 
else {
    throw KeychainError.unexpectedPasswordData
}
let credentials = Credentials(username: account, password: password)

*위에서 말했듯이 SecItemCopyMatching 함수를 알아볼 차례이다.

10. Function - SecItemCopyMatching(::)

요약 : search query와 match되는 1개 이상의 Keychain Item을 반환하거나, 특정 Item의 Attribute를 복사한다.
query 매개변수
- SecItemAdd 메서드와 구조가 유사하다. CFDictionary 타입이다.
  1. Item의 Class (SecItemAdd 메서드와 동일하므로 생략)
  2. Attribute
    - 검색할 Item이 가져야 할 Attribute를 지정하여 검색 범위를 좁힌다!
  3. Search 매개변수
    - 다양한 방법으로 검색의 조건을 설정한다. ex. result (검색 결과)를 특정 개수의 Item으로 제한할 수 있다.
    - Search Attribute Keys and Values 문서를 통해 특정 조건을 설정하기 위한 key/value를 확인 가능하다.
  4. 1개 이상의 반환 타입
    - 검색할 대상이 무엇인지 나타낸다. 이때 대상은 the item’s attributes, the item’s data, a reference to the data, a persistent reference to the data, or a combination of these 등으로 지정할 수 있다.
      → 검색할 대상이 항상 Data가 아닐 수 있고, 2번의 검색 범위를 좁히는 Attribute를 활용해서 Item을 찾고, 그 내부의 다른 Attribute를 반환하도록 할 수 있다는 뜻
      → Item에 든 내용이 많을 수도 있는데, 그중에 원하는 값들을 선별해서 받아올 수 있다.
    - Item Return Result Keys 문서를 통해 적절한 key/value를 확인 가능하다.
    - 만약 1개 이상의 반환 타입을 지정하면, 검색 결과로 요청한 타입들을 가지고 있는 딕셔너리를 반환해준다.
    - 만약 여러 개의 result를 검색하도록 허용했다면, Item 배열 형태로 반환된다.
result 매개변수
- UnsafeMutablePointer<CFTypeRef?>? 타입이다.
- 반환 시 (SecItemCopyMatching 메서드의 반환), 검색하여 찾은 Item에 대한 참조이다.
  (찾은 Item의 주소를 가리키는 포인터 타입)
  - 아래 코드를 보자.
  - 첫째 줄 : 변수 item의 타입은 CFTypeRef? 이다. 참조 (주소)를 저장하겠다는 뜻이다.
  - 둘째 줄 : SecItemCopyMatching 메서드를 통해 검색하여 찾은 Keychain Item의 참조를 변수 item에 할당한다. 근데 왜 item 앞에 &가 붙어있을까? (포인터가 가리키는) 참조를 나타내기 위해서이다.
    → 이때 Data이든 Attribute이든 “복사값” (참조가 아니라)을 반환한다는 게 중요하다. &item의 원본은 키체인에 있다!
    키체인 참조를 직접 주면 함부로 수정할 수 있어서 위험하기 때문이다.

var item: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &item)

반환값
- OSStatus 타입이다. result code이다.
Discussion
- default로 첫 번째로 match된 Item을 반환한다.
  *나머지 내용은 다음에...

*아까 보기로 했던 링크를 확인해보자.

11. Article - Updating and Deleting Keychain Items

요약 : 사용자 데이터가 변경됐을 때 Keychain Item을 수정한다.
Overview
- 사용자가 앱 외부에서 비밀번호를 변경 (ex. 웹 사이트에서 변경)하면, 앱 Bundle에 저장된 Keychain의 비밀번호와 일치하지 않으므로 로그인에 실패하게 된다. 이 경우 사용자로부터 새로운 Credentials를 입력받아 Keychain에 변경사항을 반영해야 한다.
- 이때 SecItemAdd 메서드를 사용하면 안 된다. (기존에 Keychain에 등록해둔 Item과 동일한 Attributes를 가지는 Item은 공존할 수 없기 때문이다.) 기존의 Item을 업데이트해야 한다.

(1) Prepare a Search Query and New Attributes

// search query
let query: [String: Any] = [kSecClass as String: kSecClassInternetPassword,  
                            kSecAttrServer as String: server]

// 업데이트할 새로운 Item
let account = credentials.username
let password = credentials.password.data(using: String.Encoding.utf8)! // String->Data로 전환한 비밀번호
let attributes: [String: Any] = [kSecAttrAccount as String: account,   
                                 kSecValueData as String: password]

Item을 업데이트하려면 두 가지가 필요하다.
먼저 1) search query를 통해 Item을 찾아야 한다.
(이건 implicit search이고, SecItemCopyMatching 메서드는 explicit search라고 부름)
위 예시는 kSecClass, kSecAttrServer 두 가지에 부합하는 Item을 검색하도록 했다.
그다음 2) 업데이트할 새로운 Item 정보가 담긴 딕셔너리를 준비해야 한다.
이때 사용자의 Credentials 중에서 account 정보는 동일하고, password만 바꾸는 것도 가능하다.

(2) Execute an Update

let status = SecItemUpdate(query as CFDictionary, attributes as CFDictionary)
guard status != errSecItemNotFound else { throw KeychainError.noPassword }
guard status == errSecSuccess else { throw KeychainError.unhandledError(status: status) }

이제 SecItemUpdate 메서드를 호출하면, 작성한 Attribute에 해당하는 모든 Item이 업데이트된다. (12번 문서 요약 참고)
마찬가지로 반환된 OSStatus를 확인해야 한다.

(3) Delete Items That You No Longer Need

let status = SecItemDelete(query as CFDictionary)
guard status == errSecSuccess || status == errSecItemNotFound else { throw KeychainError.unhandledError(status: status) }

필요 없는 Item은 Keychain에서 삭제하면 된다. (ex. 사용자가 앱에서 서버 로그아웃할 때)
Item 업데이트할 때 사용한 search query를 사용해서 SecItemDelete 메서드를 호출하면 된다. (13번 문서 요약 참고)
default로 Keychain service는 search query에 match되는 모든 Item을 삭제한다.
특정 Item만 삭제하려면 search query에 kSecMatchItemList key를 추가하면 된다.

*마지막으로 update / delete 관련 메서드를 보자.

12. Function - SecItemUpdate(::)

요약 : search query에 match되는 Item을 수정한다.
query 매개변수
- (Item을 add/search하는 메서드와 마찬가지로) CFDictionary 타입이다.
- 업데이트하려는 Keychain Item에 대한 search query이다.
attributesToUpdate 매개변수
- CFDictionary 타입이다.
- 1) 업데이트하려는 값에 대한 Attribute, 2) 새로운 값을 포함하는 딕셔너리이다.
- meta Attribute (???)는 이 딕셔너리에 넣을 수 없다.
반환값
- result code이다.

13. Function - SecItemDelete(_:)

요약 : search query에 match되는 Item을 삭제한다.
query 매개변수
- 삭제하려는 Keychain Item에 대한 search query이다.
반환값
- result code이다.
Discussion
- default로 search query에 해당하는 모든 Item을 삭제한다.
- key를 추가하면 특정 조건의 Item만 삭제하도록 변경할 수 있다.

- Reference

Apple Developer Documentation > Keychain Services
Apple Developer Documentation > Keychain Item
Apple Developer Documentation > Keychains
Apple Developer Documentation > Access Control Lists
Apple Developer Documentation > Article - Using the Keychain to Manage User Secrets
Apple Developer Documentation > Class - SecKeychainItem
Apple Developer Documentation > SecKeychainItemGetTypeID()
Apple Developer Documentation > Article - Adding a Password to the Keychain
Apple Developer Documentation > SecItemAdd(_:_:)
Apple Developer Documentation > Item Class Keys and Values
Apple Developer Documentation > Article - Searching for Keychain Items
Apple Developer Documentation > SecItemCopyMatching(::)
Apple Developer Documentation > Article - Updating and Deleting Keychain Items
Apple Developer Documentation > SecItemUpdate(::)
Apple Developer Documentation > SecItemDelete(_:)

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[SwiftLint] SPM으로 SwiftLint 설치 - Homebrew 필요 (SPM으로 못함)

Applecider — Tue, 16 Aug 2022 01:05:02 +0900

SwiftLint란?

SwiftLint는 라이브러리이다.

이걸 설치하면 Xcode에서 코딩 컨벤션 관련 오류를 알아서 잡아내는 맞춤법 검사기 기능을 한다.

SwiftLint 설치 방법은?

SwiftLint를 설치하는 방법은 크게 CocoaPods를 사용할 건지, 사용하지 않을 건지로 나뉜다.

개인적으로 나는 최근 CocoaPods보다 SPM (Swift Package Manager)을 더 활발하게 사용하고 있다.

별도로 pod install을 할 필요가 없고, 코드리뷰를 할 때 리뷰어도 추가 작업 없이 코드를 확인할 수 있다는 장점이 너무 크기 때문이다.

*그래도 CocoaPods으로 설치하고 싶다면 Zeddios님 링크를 참고

두 방법 모두 설치과정은 SwiftLint 공식문서에 다 나와있으므로 이걸 참조하는 게 가장 좋다.

하지만 나는 헤맸으므로.. 그 과정을 기록해본다.

먼저 아래 과정이 필요하다

1. brew 설치

Homebrew 설치방법은 이 링크를 참고

2. brew를 통해 SwiftLint 설치

이 링크는 번역본이라 조금 쉽다. 여기에 나온 대로 터미널에서 아래 코드만 넣으면 된다.

brew install swiftlint

3. Xcode 프로젝트에 적용

바로 될 줄 알았지만 Xcode가 SwiftLint를 찾지 못하는 문제가 발생한다.

많은 사람들이 겪은 문제라서 해답이 있다. 이 작업만 하면 끝난다.

https://github.com/realm/SwiftLint/issues/3734

Targets > 프로젝트 폴더 > 상단의 Build Phases > + 버튼 > New Run Script Phase > Run Script에 아래 코드를 복붙하면 된다.
brew path에 위치한 SwiftLint를 찾아가도록 하는 명령어이다.

Target의 Build Phases에서 Run Script를 추가해야 한다

+ 버튼을 클릭하고 New Run Script Phase를 클릭하면 "Run Script"가 생긴다

if test -d "/opt/homebrew/bin/"; then
  PATH="/opt/homebrew/bin/:${PATH}"
fi

export PATH

if which swiftlint >/dev/null; then
  swiftlint
else
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

4. .swiftlint.yml 파일 생성

맞춤법을 검사할 때 적용할 규칙을 정하는 파일이다.

새 파일 > iOS > Other 항목의 Empty 파일을 선택하고 파일명을 .swiftlint.yml 로 입력한다.

주의 - Documentation 항목의 Empty 파일을 하면 안 된다.

그럼 아래처럼 경고창이 뜨는데, Use "."을 클릭하면 된다.

5. 정상 작동하는지 확인

위 과정을 마치면 컴파일러가 경고 메시지를 우수수 띄우는 것을 확인할 수 있다.

아래 컴파일러가 경고 메시지를 띄운 건 의미 없는 줄바꿈을 2번 이상했기 때문이다.

SwiftLint가 코드 컨벤션 규칙을 위반했다고 알려준다

*이 규칙을 적용하고 싶지 않으면?
.swiftlint.yml 파일에 경고 메시지 맨 뒤에 표시된 vertical_whitespace를 넣으면 된다.

6. 규칙 추가/제거

내가 주로 사용하는 커스텀 룰을 적어봤다.

아까 만든 .swiftlint.yml 파일에 작성하면 된다.

나머지 규칙은 검색하면 다양하게 나온다.

disabled_rules:  // 아래 룰은 검사 대상에서 제외하겠다는 뜻
- trailing_whitespace
- xctfail_message
- function_parameter_count
- legacy_constructor
- force_cast
- trailing_comma
- force_try
- identifier_name

type_body_length: 250  // 타입/함수/파일 등의 코드길이 제한을 변경하겠다는 뜻
line_length: 120
function_body_length: 50
file_length: 500

- Reference

GitHub > SwiftLint
Swift.org > SPM
기타 링크는 본문 참고

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[인디 앱개발] ✨ 앱 기획부터 출시까지 참고한 링크 - 앱 기획, 디자인, 개발, 배포 준비

Applecider — Wed, 20 Jul 2022 17:47:13 +0900

최근 2개월 동안 개발했던 앱을 출시하게 됐다.

기획부터 시작해서 디자인, 서버 개발, iOS 개발에 직접 관여하며 진행했던 프로젝트인 만큼 재밌었고 배운 게 많았다.

그 과정에서 단계별로 고려했던 점과 유용한 사이트를 공유하려고 한다.

✏️ 기획

프로젝트 실행 목적과 목표를 설정한다.
이때 목적은 취준용 앱 출시 경험일 수도, 평소 만들고 싶었던 서비스를 구현하는 것일 수도 있다.
팀원, 진행 기간, 출시 목표일정, 타깃 사용자 등을 설정한다.
개발자 지인이 있다면 기술 난이도에 대해 조언을 구한다.
앱 출시 이후 업데이트를 진행해도 되므로 일단 최소한의 기능을 담은 MVP를 고민한다.
과욕을 부리면 나중에 꼭 후회하게 된다. 최소한의 기능만 구현해도 예상보다 오래 걸린다.
디스코드 채널 개설, Notion, 구글 스프레드시트, 구글 드라이브, HackMD (다중커서 작업 가능)을 통해 팀의 소통 창구를 만든다.
히스토리 관리가 어려운 카카오톡은 비추
앱의 복잡도에 따라 와이어프레임 (필수), 정보구조도, WBS, 프로토타입 등을 활용한다.
기능이 복잡하지 않다면 Figma를 사용하여 와이어프레임만 나타내도 충분하다.
프로토타입은 프로토파이가 유명하다고 한다.
기획문서의 종류는 이 블로그, 앱 설계서 작성방법은 이 블로그, 화면설계 및 프로토타이핑 툴의 종류는 이 블로그를 참고

예시 - 우리뭐먹지 프로젝트 Figma

UX / UI 디자인

<'네이버웹툰' 모바일 서비스 UX를 분석해보자> 시리즈 : 네이버웹툰 앱을 예시로 UX 관련 고려사항을 쉽게 설명한다.
Apple의 HIG 문서 (Human Interface Guidelines) : Apple의 디자인 원칙을 설명하는 문서이며, 디자이너/기획자/개발자 모두 읽어야 한다.
디자인 툴은 Figma (무료), AdobeXD (유료) 등을 많이 사용한다.
앱의 주요 기능을 고려해서 먼저 대략적인 컨셉을 정한다.
게임 앱이라면 컴포넌트를 둥글고, 포인트 컬러를 2~3개 사용하는 귀여운 컨셉으로
이커머스 앱이라면 선이 얇고, 미니멀한 디자인을 사용하는 세련된 컨셉으로 잡는 것이 좋다.
컨셉을 정했다면 컴포넌트, 탭바, 네비게이션바 등의 구체적인 형태를 잡는다.
비슷한 앱을 여러 개 다운받아서 살펴보거나, Pinterest에서 이미지를 검색해보자.
(검색 키워드 : App design, Mobile app UX/UI 등)
포인트 컬러를 정할 때 Pinterest에서 Color palette로 검색하면 유용하다.
컴포넌트가 너무 밋밋해 보이거나, 특정 버튼을 강조하고 싶다면 그림자 효과를 주면 좋다.
기본 한글 폰트가 구려 보여서 커스텀 폰트를 사용하고 싶다면 구글 무료 폰트, 네이버 무료 폰트를 사용하면 된다.
애니메이션은 Lottie가 유용하다.

예시 - 우리뭐먹지 프로젝트 AdobeXD

서버 개발

흔한 아이디어인데 출시된 앱이 별로 없다면, 그만한 이유가 있을 수 있다.
대표적인 이유는 DB 또는 서버 API가 구축이 안되어 있는 경우이다.
우리뭐먹지 프로젝트의 경우에도 처음부터 메뉴 DB를 구축하고, 추천 알고리즘을 설계하고, 서버 API를 만드는 작업을 모두 해야 해서 시간이 오래 걸렸다.
아이디어를 구상하는 단계에서 이미 만들어진 Open API 목록을 살펴보고 영감을 얻는 게 좋다.

iOS 개발

작업을 세부적으로 구분하여 STEP별 명세서를 작성한다.
개발 도중에 디자인이나 서버 API가 변경되는 경우가 빈번하므로 디자이너 및 기획자와 긴밀히 소통하고,
개발 과정에서도 기능 변화에 대비하여 유지보수가 용이하고 가독성이 좋은 코드를 작성한다.
StyleShare, 에어비앤비 등의 Code Convention을 참고한다.
프로젝트 개발기간 동안 MacOS, Xcode가 자동 업데이트되지 않도록 설정한다.
Xcode 버전은 팀원과 동일한 것이 안전하고, Minor 버전이 0인 것은 피한다.
GitHub의 PR 기능을 통해 Feature마다 배경, 작업 내용, 테스트 방법, 리뷰 노트, 스크린샷을 남겨두면 협업에 큰 도움이 된다.
GitHub의 Wiki 기능을 통해 프로젝트 일정 및 아카이브 문서를 관리하면 좋다.
브랜치 관리는 Git Flow를 추천한다.
Git Flow 사용방법은 지난 포스트 Git Flow로 브랜치 관리하기를 참고
개발 중에 UX/UI 관련 커스텀 컴포턴트 또는 애니메이션 등을 고민할 때도 Pinterest가 유용하다.
(검색 키워드 : Tinder like swipe, Card swipe animation 등)
난이도가 있는 작업은 누군가 이미 구현해서 공개해뒀을 가능성이 높다.
GitHub에서 여러 라이브러리의 소스코드를 뒤져보면 힌트를 얻을 수 있다.
(검색 키워드 : Menu underbar, Underline menu bar, Custom segmentedcontrol 등)

예시 - 우리뭐먹지 프로젝트 PR

배포 준비 (AppStore 심사 체크리스트)

Apple 공식문서의 AppStore 심사지침 : Apple이 민감하게 심사하는 요소를 알 수 있다.
*심사지침 요약은 지난 포스트 헬스케어 기능에도 민감하다를 참고

개발자 계정 (개인 $99, 팀 $299) : 1~4번은 AppStore Connect 사이트를 통해 생성한다.
*상세 내용은 이 블로그를 참고
인증서 (개발용, 배포용)
App ID
Provisioning Profile (개발용, 배포용)
개인정보 처리방침 : 개인정보보호포털 사이트에서 생성한다. URL을 제출해야 하므로 Notion으로 만드는 것을 추천한다.
Test Flight (생략 가능)
앱 아이콘 (로고)
- 1024*1024 이미지 1개 (png만 가능)를 준비한다.
- Xcode 14 미만인 경우, 또는 크기별로 이미지 디테일을 다르게 표현하고 싶은 경우에는 11개의 크기별 이미지를 준비한다.
*이미지 세트를 자동 생성해주는 사이트 참고
- Apple이 알아서 모서리를 둥글게 만들어주므로 배경이 정사각형 형태여야 한다.
AppStore 미리보기 영상 및 스크린샷
- 영상은 생략 가능하고, 스크린샷은 필수이다.
- Simulator 화면의 캡쳐본을 제출해도 되고, MockUp 툴을 활용해서 화면별 기능을 설명해주는 이미지를 만들어 제출해도 된다.
- 이미지 크기 때문에 심사 탈락하는 경우가 많다고 한다. Apple 공식문서의 스크린샷 사양을 꼭 확인하자.
- iOS만 지원한다면 총 2개 세트 (아래 1~2번), iOS/iPad를 모두 지원한다면 총 4개 세트 (아래 1~4번)를 준비해야 한다.
*요구사항 항목에 "앱이 iPhone에서 실행되는 경우 필요"라고 되어있으면 필수적으로 제출해야 한다는 뜻이다.
1) iPhone 6.5형 예시 : iPhone 13 Pro Max, 1284 x 2778 픽셀, 실기기처럼 홈버튼이 아닌 노치가 있으면 통과한다.
2) iPhone 5.5형 예시 : iPhone 8 Plus, 1242 x 2208 픽셀, 실기기처럼 홈버튼이 있으면 통과한다.
3) iPad 12.9형 예시 : iPad Pro(4세대, 3세대), 2048 x 2732 픽셀
4) iPad 12.9형 예시 : iPad Pro(2세대), 2048 x 2732 픽셀
App 기본 정보 : 앱 이름, 부제, 카테고리, 가격 등급, 개발자 연락처
AppStore 마케팅 문구 : 프로모션 텍스트, 설명 (더보기 항목), 등록 키워드 등이 필요하다.
- 마케팅 경험이 없다면 여기서 시간 소요가 크다. 주변 문과 친구들의 도움을 받으면 좋다.
*상세 내용은 이 블로그를 참고
앱 사용방법을 나타낸 영상을 참고하면 보다 신속하게 심사결과를 받을 수 있다. (생략 가능)
실기기로 앱을 실행화면을 녹화한 영상을 제출했었는데 심사요청 10분 만에 승인을 받을 수 있었다.

Configuring your app icon | Apple Developer Documentation

Add app icon variations to represent your app in places such as Settings, search results, and the App Store.

developer.apple.com

Configuring your app icon | Apple Developer Documentation

Add app icon variations to represent your app in places such as Settings, search results, and the App Store.

developer.apple.com

AppStore에 출시된 우리뭐먹지 앱 (iOS/iPad)

홍보 / 마케팅

출시 직후 단기간에 다운로드 수가 높아야 AppStore 추천 앱에 언급될 수 있다.

오픈카톡, 디스코드, IT서비스 관련 SNS 등 개발자 커뮤니티를 통해 홍보해야 한다.

홍보에 크게 신경 쓰지 못하더라도 ASO (앱스토어 최적화), SNS 마케팅은 해야 하는 것 같다.

디스콰이엇 : IT 서비스 메이커들의 소셜 네트워크이다. 앱을 게시하거나, 기획자/디자이너/투자자 등과 소통할 수 있다.
앱스토어 최적화(ASO) 알아보기 포스트
iOS 개발자 커뮤니티의 추천앱 탭
앱 출시 후 홍보에 대한 생각 포스트, 9가지 앱 마케팅 전략 포스트

- Reference

본문의 링크 참고
관련 포스트
- [인디 앱개발] Apple의 App Store 심사지침 요약 - 헬스케어 기능에도 민감하다
- [Git] Git 브랜치 이름은 어떻게 정할까? - Git Flow로 브랜치 관리하기
우리뭐먹지 - 프로젝트 GitHub WiKi
우리뭐먹지 - 앱 다운로드 링크

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Dictionary] value에 nil을 저장하려면? - nil의 타입을 명시

Applecider — Mon, 18 Jul 2022 16:10:00 +0900

Dictionary의 value 타입을 옵셔널로 지정하고, value에 nil을 할당하려면 어떻게 해야 할까?

궁금해서 구글링 해봤는데, StackOverFlow에서 간단히 답을 찾을 수 있었다.

- 검색 키워드 : how to save nil at dictionary value in swift

- Reference : How to add nil value to Swift Dictionary?

Dictionary 기본 문법

일반적으로 Dictionary는 이렇게 다룬다.

// Dictionary 생성
var juices: [String: String] = ["Apple": "Applecider", "Lemon": "Lemonade"]

// ✅ key/value pair 삭제
juices["Lemon"] = nil

// ✅ key/value pair 추가
juices["Grape"] = "Grape Juice" 

print(juices)  // ["Apple": "Applecider", "Grape": "Grape Juice"] 출력

삭제 : Dictionary의 value에 nil을 할당하면, key "Lemon"과 value "Lomonade"가 삭제된다.
주의 - key "Lemon"의 value로 nil을 저장하는 것이 아니다.
추가 : 새로운 key "Grape"와 value "Grape Juice"를 Dictionary에 추가한다.

위와 같이 Dictionary의 value에 nil을 할당하면, 해당 key/value pair가 삭제된다.

그런데 value에 nil을 저장하려면 어떻게 해야 할까?

Dictionary의 value 타입을 옵셔널로 지정하고, 다시 nil을 할당해보자.

var juices: [String: String?] = ["Apple": "Applecider", "Starfruit": nil]

juices["Apple"] = nil  // 기존 key - key/value pair 삭제됨
juices["Plum"] = nil   // 새로운 key - key/value pair 추가 안됨

print(juices)  // ["Starfruit": nil] 출력

맨 위부터 한 줄씩 살펴보자.
Starfruit : Dictionary를 생성할 때, value에 nil을 할당하면 정상적으로 저장된다.
Apple : 기존에 있던 key인 "Apple"에 nil을 할당하면, key/value pair가 삭제된다. (value로 nil이 저장되지 않음)
Plum : 기존에 없던 새로운 key인 "Plum"에 nil을 할당하면, key/value pair가 추가되지 않는다. (value로 nil이 저장되지 않음)

nil이 저장되지 않고, 여전히 key/value pair가 삭제된다.

따라서 아래 세 가지 방법을 활용해야 한다.

방법-1. nil을 할당할 때 String? 타입임을 명시한다.

var juices: [String: String?] = ["Apple": "Applecider", "Starfruit": nil]

//   String? 타입의 nil을 할당
juices["Apple"] = nil as String?  // 기존 key - nil이 저장됨
juices["Plum"] = nil as String?   // 새로운 key - nil이 저장됨

print(juices)  // ["Starfruit": nil, "Apple": nil, "Plum": nil] 출력

Dictionary의 value로 nil as String? 을 할당한다는 것은 nil이 String? 타입임을 명시한다는 뜻이다.
Apple : 기존에 있던 key인 "Apple"에 상수 nilAsValue를 할당하면, value로 nil이 저장된다!
Plum : 기존에 없던 새로운 key인 "Plum"에 nil을 할당하면, key/value pair가 추가되고 value로 nil이 저장된다!

방법-2. updateValue 메서드를 사용한다.

var juices: [String: String?] = ["Apple": "Applecider", "Starfruit": nil]

//   updateValue 메서드를 호출
juices.updateValue(nil, forKey: "Apple")  // 기존 key - nil이 저장됨
juices.updateValue(nil, forKey: "Plum")   // 새로운 key - nil이 저장됨

print(juices)  // ["Starfruit": nil, "Apple": nil, "Plum": nil] 출력

Dictionary의 updateValue 메서드를 호출한다.
updateValue를 자동 완성했을 때 컴파일러가 타입 유추를 통해 value가 String? 타입임을 예상하기 때문에 nil 할당이 가능하다.
따라서 value에 nil이 저장된다.

방법-3. nil을 상수/변수에 할당하고, 해당 상수/변수를 value에 할당한다.

var juices: [String: String?] = ["Apple": "Applecider", "Starfruit": nil]

//   nil을 상수에 할당하고, 해당 상수를 value로 할당
let nilAsValue: String? = nil
juices["Apple"] = nilAsValue  // 기존 key - nil이 저장됨
juices["Plum"] = nilAsValue   // 새로운 key - nil이 저장됨

print(juices)  // ["Starfruit": nil, "Apple": nil, "Plum": nil] 출력

Dictionary의 value로 nil 자체를 바로 할당하지 않는다.
nil을 별도의 상수 nilAsValue에 할당하고, 해당 상수를 Dictionary의 value에 할당한다.
이를 통해 컴파일러는 value가 String? 타입임을 알 수 있게 된다. 따라서 value에 nil이 저장된다.

- Reference

Swift Language Guide > Collection Types
StackOverFlow > How to add nil value to Swift Dictionary?

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[AppleWatch] 애플케어 리뷰 - 생활기스로 리퍼받은 애플워치 상태

Applecider — Fri, 17 Jun 2022 14:05:33 +0900

애플워치5를 쓰다가 스크린에 너무 기스가 많아서 애플케어 보증기한을 1개월 앞두고 센터를 찾았다.

애플워치의 보증기간은 아이폰에서 Watch 앱 > 일반 > 정보 탭에 들어가면 확인할 수 있다.

공인 센터에 미리 예약을 하고 방문해야 한다.

애플워치 리퍼 신청

스크린이 박살난 게 아니라서 생활 기스만으로 리퍼가 가능할지 긴가민가 했었는데,

의외로 제품 교환이 가능하다는 답변을 받았다.

자부담금은 8만원이었다. (2021년 11월 이후부터 무상교환이 안된다.)

*리퍼 관련 상세 내용은 여기를 참고

애플워치는 고장 나면 부분 수리가 불가하고, 무조건 새 제품으로 교환이 원칙이라고 한다.

그리고 "리퍼 제품으로 교환"이라고 안내를 받았는데,

센터에 여쭤보니 교환 목적의 리퍼 제품이라는 게 따로 없고, 애플워치의 부품 특성상

실질적으로 완전히 새 제품으로 교환해준다고 보면 된단다.

*애플 커뮤니티에도 동일하게 나와있다.

교환 접수가 된 애플워치 상태

센터에 가져갔던 애플워치 상태 - 스크린

센터에 가져갔던 애플워치 상태 - Crown 버튼

스크린에 잔 기스가 많고, 옆쪽의 Crown 버튼도 패어 있다.

접수일로부터 13일 후에 제품을 수령했다.

새로운 제품을 받고 지금까지 6개월 정도 사용했는데 아무 이상이 없다.

희안한 점이 하나 있는데, 똑같은 애플워치5인데 새로 받은 제품은 막 다뤘는데도 생활 기스가 전혀 안 난다는 거다.

두 제품의 스펙이 완전히 동일하다면...

기존 제품은 수영장 대리석 바닥에서 여러 번 떨어트렸는데, 이게 충격이 컸던 것으로 추측된다.

결론 : 애플케어 신청하는 게 좋고, (조금 심한) 생활기스로도 제품 교환이 가능하다.

- Reference

Apple > 애플케어

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[AutoLayout] CHCR이란? Label의 default CHCR 값은? - 공식문서 오류 정정

Applecider — Thu, 16 Jun 2022 13:12:26 +0900

CHCR은 Compression-Resistance 및 Content-Hugging를 뜻한다.

화면에 여러 가지 View를 나타내는 경우, 이 CHCR 값을 조정하게 되는데

(특히 StackView 내부에 여러 가지 View를 ArrangedSubviews로 올리는 경우)

관련 개념을 알아보다가 공식문서에서 몇 몇 오류를 발견해서 정리해봤다.

Intrinsic Size란?

원래는 View의 위치 및 크기 (Origin 및 Size)를 모두 지정해줘야 하는데,

일부 View는 View 내부의 컨텐츠에 따라 자체적으로 Size를 가지도록 되어있다.

이 걸 Intrinsic Size (내재적인 크기, 자체적인 크기)라고 부른다.

예를 들어 Button의 Intrinsic Size는 뭘까?
“Button 내부의 텍스트 + default margin” 크기가 Button의 Intrinsic Size 이다. (font 등의 영향을 받는다.)

Apple Archive의 Anatomy of a Constraint에 Intrinsic Size 목록이 나와있다.

View 종류별 Intrinsic Size

UIView : 없음
Slider : 높이만 가능 (iOS) ← width는 오타인듯 (공식문서 오류)
Label, Button, Switch, Text Field : 높이/너비 가능 (위치만 정해주면, 크기는 자동으로 반영된다는 뜻)
TextView / ImageView : 상황에 따라 다름. 스크롤이 없으면 가능

Intrinsic Size를 왜 도입했을까?

View를 화면에 나타낼 때, 모든 View에 대해 Origin 및 Size를 일일이 설정할 필요가 없어지므로

관리할 constraint 개수가 줄어들어서 편리하다.

CHCR이란?

CHCR은 Compression-Resistance 및 Content-Hugging를 의미한다.

Intrinsic Content Size를 활용하여 Layout을 설정하려면 CHCR 조정이 필요하다.

예를 들어 화면에 여러 가지 View를 올리는 경우, Device Screen 크기에 따라 유동적으로 나타내기 위해

특정 ImageView는 Screen 너비만큼 늘어나게 하고, 특정 Label은 텍스트가 짤리지 않도록 설정해야 할 때가 있다.

이때 CHCR은 어떻게 사용할까?

이렇게 ImageView가 늘어나도록 하는 것은 Content-Hugging 우선도를 감소시키고,
Label이 잘리지 않도록 하는 것은 Compression-Resistance 우선도를 증가시켜서 구현하면 된다.

CHCR을 정확히 정의해보자.

CHCR 설명

Compression-Resistance (압축 저항) : 외부 압력에 의해 콘텐츠가 잘리지 않도록 버티는 힘
Content-Hugging (컨텐츠 허깅) : Intrinsic Content Size와 딱맞게 줄어들려고 하는 힘

둘은 반대 개념이 아니며, 다른 constraint와 마찬가지로 CHCR에도 우선도가 적용된다.

우선도 (Constraint Priority)

constraint를 동일한 영역에 대해 중복으로 설정할 수 있는데, 이때 우선순위가 높은 constraint에 따라 배치한다.
(화면에 나타낼 때 우선순위가 낮은 constraint는 무시된다.)

우선도는 1~1000 사이에서 조절할 수 있다.

CHCR 값을 설정하는 방법

View의 CHCR 값을 설정하는 방법은 두 가지가 있다.

1. UILayoutPriority의 타입 프로퍼티 활용

간단하게 사용할 수 있도록 .defaultLow, .defaultHigh, .required 가 있다.

rawValue는 각각 1000, 750, 250 이다.

// 타입 프로퍼티 활용
label.setContentHuggingPriority(.required, for: .horizontal)
label.setContentHuggingPriority(.defaultHigh, for: .horizontal)  
label.setContentHuggingPriority(.defaultLow, for: .horizontal)  

// 프로퍼티별 rawValue
.required    == 1000
.defaultHigh ==  750
.defaultLow  ==  250

검색 키워드 : ios chcr required rawvalue

when-to-use-uilayoutpriority-required-in-setcontentcompressionresistanceprior

2. UILayoutPriority의 init(rawValue: Float) 활용

우선도는 1~1000의 범위 내에서 원하는 값을 지정할 수 있다.

// rawValue 활용
label.setContentHuggingPriority(.init(rawValue: 150), for: .horizontal)

공식문서 오류 - default CHCR 값

공식문서 내용 중에서 잘못된 정보는 아래와 같다.

오류 - Name Label의 Hugging은 251로 표기되어 있음 (실제로는 250)

위 표처럼 Label의 default Hugging은 251이라고 표기되어 있지만,

실제로는 250이다.

이것 때문에 StackView에 여러 개의 Label을 넣고, CHCR 값을 조정하는 과정에서 삽질을 많이 했다...

Debug View Hierarchy 탭에서 Label의 Hugging 값을 직접 확인해봤다.

Label의 default CHCR

왼쪽에 표시한 아이콘을 탭하면 Debug View Hierarchy를 볼 수 있다.
화면에서 원하는 Label을 클릭하면, 우측에서 관련 정보를 확인할 수 있다.
현재 선택된 Label (5% 텍스트가 들어있는 Label)의 CHCR 값을 따로 지정하지 않았으므로 default 값으로 설정되어 있다.
Label의 default Hugging은 Horizontal, vertical 모두 250이다.

예제코드 - CHCR priority 설정하기

참고로 5% 텍스트가 들어있는 Label은 아래 코드로 생성했다.

priority를 .defaultHigh로 변경하면 Hugging 값이 250에서 750으로 바뀐다.

private let bargainRateLabel: UILabel = {
    let label = UILabel()
    label.translatesAutoresizingMaskIntoConstraints = false
    label.textAlignment = .right
    label.font = Design.bargainRateLabelFont
    label.textColor = Design.bargainRateLabelTextColor
    // ✅ Hugging 값이 250 (default) -> 750 (.defaultHigh)으로 변경됨
    label.setContentHuggingPriority(.defaultHigh, for: .horizontal)  
    return label
}()

setContentHuggingPriority, setContentCompressionResistancePriority 메서드를 통해 CHCR priority를 설정한다.

- Reference

예제코드 전체 : GitHub > MVVM-RX-OpenMarket
Apple > Documentation Archive > AutoLayout Guide > Anatomy of a Constraint
Apple > Documentation Archive > AutoLayout Guide > Views with Intrinsic Content Size

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[CollectionView] 배너 하단에 PageControl 구현 - FooterView에 넣기

Applecider — Wed, 15 Jun 2022 01:30:51 +0900

저번 포스팅 [CollectionView] Diffable DataSource 이해하기 (3/3) - 상품 배너/목록/상세 화면을 구현한 예제코드에서 이미 다뤘지만,

글이 너무 길어져서 이 부분만 따로 포스팅하려고 한다.

아래 화면처럼 배너 하단에 PageControl을 구현해보자.

배너를 왼쪽 <-> 오른쪽으로 Scroll 하면, PageControl이 바뀌는 것을 볼 수 있다.

배너를 Scroll 하면 PageControl이 바뀜

이번 예제코드에서는 CompositionalLayout, orthogonalScrollingBehavior, PageControl, RxSwift를 활용했다.

첫째, 배너를 Horizontal Scroll할 때 화면에 보이는 "현재 페이지 index"를 PageControl에 전달하는 작업,

그리고 둘째, PageControl의 위치를 잡는 것이 관건이다.

실패 기록 - scrollViewWillEndDragging 메서드는 못쓴다

화면을 보면 위의 banner section은 horizontal scroll을, 아래의 list section은 vertical scroll을 할 수 있다.

1개 CollectionView 내에서 Scroll 방향이 여러 가지인 것이다.

따라서 banner와 list 2개 section을 모두 구현하려면 scrollViewWillEndDragging 메서드를 쓸 수 없다.

scrollViewWillEndDragging에 아래처럼 코드를 작성하면,

의도했던 Horizontal Scroll 뿐만 아니라 Vertical Scroll을 할 때도 호출되기 때문에 PageControl이 비정상적으로 작동한다.

extension ProductDetailViewController: UICollectionViewDelegate {
    func scrollViewWillEndDragging(_ scrollView: UIScrollView,
                                   withVelocity velocity: CGPoint,
                                   targetContentOffset: UnsafeMutablePointer<CGPoint>) {
        let sideInset: CGFloat = 30
        let page = Int(targetContentOffset.pointee.x / (view.frame.width - sideInset))
        productDetailScrollView.imageNumberPageControl.currentPage = page  // PageControl에 현재 페이지 index를 전달함
      }
}

실패 기록 - Cell이 PageControl을 갖도록 하면 나쁜 UX가 된다

처음에는 Cell에서 PageControl을 생성하고, ViewController가 Cell에게 페이지 수 및 현재 페이지를 전달하는 방법을 생각했었다.

하지만 Cell을 Scroll할 때, PageControl이 고정되어 있지 않고 Cell과 함께 이동하는 형태가 되어 어색하게 느껴졌다.

따라서 ViewController에서 PageControl을 생성하고,
그 PageControl을 banner section의 footerView에 넣는 게 적절하다고 판단했다.

따라서 PageControl을 FooterView에 배치하고,

section.visibleItemsInvalidationHandler에 클로저에서 배너의 현재 페이지를 받아오도록 했다.

코드로 하나씩 살펴보자.

1. FooterView 추가

import UIKit
import RxSwift
import RxCocoa

final class FooterView: UICollectionReusableView {
    // MARK: - Properties
    private let bannerPageControl: UIPageControl = {
        let pageControl = UIPageControl()
        pageControl.translatesAutoresizingMaskIntoConstraints = false
        pageControl.pageIndicatorTintColor = .systemGray2
        pageControl.currentPageIndicatorTintColor = CustomColor.darkGreenColor
        pageControl.currentPage = 0
        pageControl.isUserInteractionEnabled = false
        return pageControl
    }()
    
    private let disposeBag = DisposeBag()
    
    // MARK: - Initializers
    override init(frame: CGRect) {
        super.init(frame: frame)
        configureUI()
    }
    
    @available(*, unavailable)
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    // MARK: - Methods
    func bind(input: Observable<Int>, indexPath: IndexPath, pageNumber: Int) {
        bannerPageControl.numberOfPages = pageNumber
        if indexPath.section == 1 {
            self.isHidden = true
        } else {
            input
                .subscribe(onNext: { [weak self] currentPage in
                    // ✅ pageControl의 현재 페이지를 조정
                    self?.bannerPageControl.currentPage = currentPage  
                })
                .disposed(by: disposeBag)
        }
    }
    
    private func configureUI() {
        addSubview(bannerPageControl)
        NSLayoutConstraint.activate([
            bannerPageControl.topAnchor.constraint(equalTo: topAnchor),
            bannerPageControl.bottomAnchor.constraint(equalTo: bottomAnchor),
            bannerPageControl.leadingAnchor.constraint(equalTo: leadingAnchor),
            bannerPageControl.trailingAnchor.constraint(equalTo: trailingAnchor)
        ])
    }
}

custom header / footer를 생성할 때는 UICollectionReusableView를 상속받도록 한다.
footer 내부에서 PageControl을 생성하고, footer의 subview로 올렸다.
bind 메서드를 통해 ViewController에서 변경된 현재 페이지 index (currentPage)를 받도록 했다.

2. CollectionView Layout에 FooterView 위치 잡기

import UIKit
import RxSwift
import RxCocoa

final class ProductListViewController: UIViewController {
    // MARK: - Nested Types
    private enum SupplementaryKind {
        static let header = "header-element-kind"
        static let footer = "footer-element-kind"
    }
        
    // MARK: - Properties
    // ✅ footer에 전달될 정보
    private let currentBannerPage = PublishSubject<Int>()  
    
    private func createLayout() -> UICollectionViewLayout {
    let layout = UICollectionViewCompositionalLayout { [weak self] sectionIndex, _ -> NSCollectionLayoutSection? in
        // section 정보에 접근
        guard let sectionKind = SectionKind(rawValue: sectionIndex) else {
            self?.showUnknownSectionErrorAlert()
            return nil
        }
        
        // item 설정
        // Cell 내부 컨텐츠의 높이를 알아서 계산하여 반영하는 estimatedHeight를 적용
        let screenWidth = UIScreen.main.bounds.width
        let estimatedHeight = NSCollectionLayoutDimension.estimated(screenWidth)
        let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: estimatedHeight)
        let item = NSCollectionLayoutItem(layoutSize: itemSize)

        // group 설정
        let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: estimatedHeight)
        let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize,
                                                       subitem: item,  
                                                       count: sectionKind.columnCount)  // 1개 group에 나타낼 item 개수를 설정
        // section 설정
        let section = NSCollectionLayoutSection(group: group)
        section.orthogonalScrollingBehavior = sectionKind.orthogonalScrollingBehavior()  // Section별 Scroll 방향을 할당       
        section.visibleItemsInvalidationHandler = { [weak self] _, contentOffset, environment in
            let bannerIndex = Int(max(0, round(contentOffset.x / environment.container.contentSize.width)))
            if environment.container.contentSize.height == environment.container.contentSize.width {
                self?.currentBannerPage.onNext(bannerIndex)
            }
        }

        // ✅ header 및 footer 설정
        let sectionHeader = NSCollectionLayoutBoundarySupplementaryItem(
            layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: estimatedHeight),
            elementKind: SupplementaryKind.header,
            alignment: .top
        )
        let sectionFooter = NSCollectionLayoutBoundarySupplementaryItem(
            layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: estimatedHeight),
            elementKind: SupplementaryKind.footer,
            alignment: .bottom
        )
        section.boundarySupplementaryItems = [sectionHeader, sectionFooter]
        return section
    }
    return layout
}

header / footer 이외 코드는 생략했다.
custom footer를 CollectionView에 연결하기 위해
section.boundarySupplementaryItems 프로퍼티에 header / footer를 할당한다.
이때 alignment를 header는 .top, footer는 .bottom으로 설정한다.

검색 키워드 : collectionView, pageControl, banner, currentPage

how-to-show-page-indicator-with-compositional-layout

3. visibleItemsInvalidationHandler 활용

위 코드 중에서 visibleItemsInvalidationHandler와 관련된 내용을 자세히 보자.

// 위의 createLayout 메서드에 포함된 코드 
section.visibleItemsInvalidationHandler = { [weak self] _, contentOffset, environment in
    // 비교용 - Device의 Screen 크기
    print("=== Screen Width/Height :", UIScreen.main.bounds.width, "/", UIScreen.main.bounds.height)

    // ✅ contentOffset은 CollectionView의 bound를 기준으로 Scroll 결과 보여지는 컨텐츠의 Origin을 나타냄
    // 배너 및 목록화면의 경우, Scroll하면 어디서 클릭해도 0부터 시작
    // 상세화면의 경우, Scroll하면 어디서 클릭해도 약 -30부터 시작 (기기마다 다름, CollectionView의 bound를 기준으로 cell(이미지)의 leading이 왼쪽 (-30)에 위치하므로 음수임)
    print("OffsetX :", contentOffset.x)

    // ✅ environmnet는 collectionView layout 관련 정보를 담고 있음
    // environment.container.contentSize는 CollectionView 중에서 현재 Scroll된 Group이 화면에 보이는 높이를 나타냄
    print("environment Width :", environment.container.contentSize.width)   // Device의 스크린 너비와 동일
    print("environment Height :", environment.container.contentSize.height) // Horizontal Scroll하면 스크린 너비와 같고, Vertical Scroll하면 그보다 커짐

    let bannerIndex = Int(max(0, round(contentOffset.x / environment.container.contentSize.width)))  // 음수가 되는 것을 방지하기 위해 max 사용
    if environment.container.contentSize.height == environment.container.contentSize.width {  // ❗Horizontal Scroll 하는 조건
        self?.currentBannerPage.onNext(bannerIndex)  // 클로저가 호출될 때마다 pageControl의 currentPage로 값을 보냄
    }
}

visibleItemsInvalidationHandler에 할당되는 클로저를 뜯어보자.
Horizontal Scroll 했을 때 바뀐 Banner 페이지의 index를 pageControl의 currentPage로 지정하는 기능이다.
contentOffset, environment.container.contentSize에 대한 이해가 필요하다. 직접 프린트를 찍어보면 쉽다.
- contentOffset은 CollectionView의 bound를 기준으로 Scroll 결과 보여지는 컨텐츠의 Origin을 나타낸다.
  오른쪽으로 Horizontal Scroll 하면, contentOffset.x의 값은 계속해서 커진다.
- environment.container.contentSize는 공식문서에 명확히 나와있지 않아서 실험이 필요했다.
  일단 environmnet는 collectionView layout 관련 정보를 담고 있다.
  environment.container.contentSize는 CollectionView 중에서 현재 Scroll된 Group이 화면에 보이는 높이를 나타낸다.
  이 contentSize의 height를 찍어보면 Horizontal Scroll할 때는 스크린 너비와 같고, Vertical Scroll할 때는 그보다 커진다.
  (아래 gif 참고)
  -> 따라서 이 특징을 활용하여 if문의 조건으로 Horizontal Scroll하는 경우를 찾은 뒤, PageControl에 현재 페이지를 보내줬다.

Scroll 방향에 따라 달라지는 offSetX 및 environment height 확인

검색 키워드 : orthogonalScrollingBehavior, page control
How can I detect orthogonal scroll events when using `UICollectionViewCompositionalLayout`?

(근데 이 클로저도 Vertical Scroll할 때 호출되므로 한계가 있어 보였지만,다른 해결방법을 찾지 못했다.)

4. FooterView 등록 및 DataSource에 연결

Custom Footer를 등록하고, DataSource에 연결시키면 된다.

Custom Cell을 처리하는 과정과 비슷하다.

// ✅ typealias 활용
private typealias HeaderRegistration = UICollectionView.SupplementaryRegistration<HeaderView>  
private typealias FooterRegistration = UICollectionView.SupplementaryRegistration<FooterView>

private func configureSupplementaryViewRegistrationAndDataSource() {
    // ✅ header, footer 등록
    let headerRegistration = HeaderRegistration(elementKind: SupplementaryKind.header) { view, _, indexPath in
        view.apply(indexPath)
    }
    let footerRegistration = FooterRegistration(elementKind: SupplementaryKind.footer) { [weak self] view, _, indexPath in
        guard let self = self else { return }
        view.bind(input: self.currentBannerPage.asObservable(),
                  indexPath: indexPath,
                  pageNumber: Content.bannerCount)
    }

    // ✅ dataSource에 header, footer 연결
    dataSource.supplementaryViewProvider = { [weak self] _, kind, index in
        switch kind {
        case SupplementaryKind.header:
            return self?.collectionView.dequeueConfiguredReusableSupplementary(using: headerRegistration,
                                                                               for: index)
        case SupplementaryKind.footer:
            return self?.collectionView.dequeueConfiguredReusableSupplementary(using: footerRegistration,
                                                                               for: index)
        default:
            return UICollectionReusableView()
        }
    }
}

SupplementaryRegistration의 제네릭 매개변수로 Custom header / footer 타입 (HeaderView / FooterView)을 전달한다.
header / footer를 등록하고, dataSource에 연결하면 끝이다.
dataSource를 snapshot에 반영하는 과정은 생략했다.
전체 코드는 GitHub 링크를 참고

- Reference

예제코드 전체 : GitHub > MVVM-RX-OpenMarket
Apple > Collection View > Sample Code - Updating Collection Views Using Diffable Data Sources
Apple > WWDC 2019 > Advances in UI Data Sources
Stackoverflow > how-can-i-detect-orthogonal-scroll-events-when-using-uicollectionviewcompositio
Blog > how-to-show-page-indicator-with-compositional-layout
관련 포스트
- [CollectionView] Diffable DataSource 이해하기 (3/3) - 상품 배너/목록/상세 화면을 구현한 예제코드

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[CollectionView] estimatedHeight 사용 시 is stuck in its update/layout loop 에러 발생

Applecider — Mon, 13 Jun 2022 13:02:51 +0900

CollectionView의 CompositionalLayout에서 estimatedHeight를 사용해봤다.

Item / Group의 크기를 고정하지 않고,

Cell 내부 컨텐츠의 높이를 알아서 계산하여 반영해주므로 매우 유용하다.

*예제코드는 [CollectionView] Diffable DataSource 이해하기 (3/3) - 상품 배너/목록/상세 화면을 구현한 예제코드 포스트를 참고

그런데 약 iOS 15.0~15.3에서 crash가 발생했다.

에러 문구는 아래와 같다.

is stuck in its update/layout loop. This can happen for many reasons, including self-sizing views whose preferred attributes are not returning a consistent size. To debug this issue, check the Console app for logs in the "UICollectionViewRecursion" category.'

확인해보니 특정 버전에서 estimatedHeight와 관련한 버그가 발생한 게 원인이었다.

https://stackoverflow.com/questions/70213395/self-sizing-collection-view-enters-a-recursive-loop-in-ios-15

검색 키워드 : is stuck in its update/layout loop

버그 해결 방법

iOS 15 미만, iOS 15.4 이상에서는 문제가 없음을 확인했다.

아래 코드를 추가하면 해결된다는 코멘트도 있었다.

override func shouldInvalidateLayout(
    forPreferredLayoutAttributes preferredAttributes: UICollectionViewLayoutAttributes,
    withOriginalAttributes originalAttributes: UICollectionViewLayoutAttributes
) -> Bool {
    return true
}

버그 대응 예제코드

이 버그에 어떻게 대응하는 게 좋을까?

사용자의 기기 버전이 iOS 15.0~15.3인 경우, 에러가 발생하므로 아래처럼 Alert를 띄우도록 구현했다.

// ViewController에 정의한 메서드
private func checkIOSVersion() {
    // ✅ 사용자 기기의 현재 iOS 버전 정보를 받아옴
    let versionNumbers = UIDevice.current.systemVersion.components(separatedBy: ".")
    let major = versionNumbers[0]
    let minor = versionNumbers[1]
    let version = major + "." + minor

    guard let systemVersion = Double(version) else { return }
    let errorVersion = 15.0..<15.4
    // ✅ 해당 버전만 버그가 발생하므로 Alert로 업데이트 권고
    if  errorVersion ~= systemVersion {
        showErrorVersionAlert()
    }
}

checkIOSVersion 메서드를 추가하여 사용자 기기의 현재 iOS 버전 정보를 받아오고,
버그가 발생하는 특정 버전이면 Alert를 띄워서 업데이트 권고하도록 구현했다.
Alert를 띄우는 메서드를 분리했다.

기타 코드는 아래를 참고

private func showErrorVersionAlert() {
    let okAlertAction = UIAlertAction(title: Content.okAlertActionTitle, style: .default)
    let alert = AlertFactory().createAlert(title: Content.versionErrorTitle,
                                           message: Content.versionErrorMessage,
                                           actions: okAlertAction)
    present(alert, animated: true)
}

private enum Content {
    static let versionErrorTitle = "기기를 iOS 15.4 이상으로 업데이트 해주세요"
    static let versionErrorMessage = "애플이 잘못했어요"
    static let okAlertActionTitle = "OK"
}

// 참고 - AlertFactory
struct AlertFactory {
    func createAlert(style: UIAlertController.Style = .alert,
                     title: String? = nil,
                     message: String? = nil,
                     actions: UIAlertAction...) -> UIAlertController {
        let alert = UIAlertController(title: title, message: message, preferredStyle: style)
        actions.forEach { action in
            alert.addAction(action)
        }
        
        return alert
    }
}

AlertFactory를 추가해서 코드 재사용성을 개선했다.
중첩 타입 (Nested Type)으로 Content 열거형을 추가하여 문자열 상수를 분리했다.

- Reference

예제코드 전체 : GitHub > MVVM-RX-OpenMarket
Stackoverflow > self-sizing-collection-view-enters-a-recursive-loop-in-ios-15
관련 포스트
- [CollectionView] Diffable DataSource 이해하기 (3/3) - 상품 배너/목록/상세 화면을 구현한 예제코드 포스트

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[CollectionView] Diffable DataSource 이해하기 (3/3) - 상품 배너/목록/상세 화면을 구현한 예제코드

Applecider — Sun, 12 Jun 2022 23:29:29 +0900

DiffableData을 처음 들어봤다면,

[CollectionView] Diffable DataSource 이해하기 (1/3) - Advances in UI Data Sources (WWDC19) 포스팅을 참고

[CollectionView] Diffable DataSource 이해하기 (2/3) - 흔히 하는 실수, Modern Collection Views 예제코드 포스팅을 참고

orthogonalScrollingBehavior을 처음 들어봤다면,

[CollectionView] Section마다 다른 Scroll Direction 설정하기, Carousel Paging 구현하기 (feat. AppStore) 포스팅을 참고

이전 포스팅에서 다룬 내용을 써먹어보자.

CollectionView의 DiffableDataSource, CompositionalLayout, orthogonalScrollingBehavior을 활용하는 예제코드를 작성해봤다.

총 2개 화면이다.

화면-1 : 상품 배너와 상품 목록을 보여준다.

화면-2 : 사용자가 배너 또는 목록의 상품을 탭하면, 해당 상품의 상세 화면을 띄운다.

상품 배너 및 목록 예제코드

먼저 배너와 상품 목록을 구현해보자.

위의 banner section은 horizontal scroll을, 아래의 list section은 vertical scroll을 할 수 있다.

그리고 1개 CollectionView 내에서 "Section마다 Scroll Direction을 다르게" 지정하고 있으므로

compositionalLayout의 orthogonalScrollingBehavior 프로퍼티를 활용하면 된다.

상품 목록을 좀 더 자세히 보면, 상단의 메뉴 버튼을 통해 Grid 형태와 Table 형태 2개 종류로 나타냈다.

이를 위해 2개 종류의 Cell 타입 (GridCell, TableCell)을 사용했다.

메뉴 버튼을 구현할 때, 버튼에 UnderLine을 만들고, 버튼을 탭할 때 UnderLine의 위치가 이동하도록 했는데
이 내용은 별도로 포스팅할 예정이다.

1. CollectionView의 Section 및 Layout 설정

먼저 CollectionView에 나타낼 Section의 종류를 정의하고, compositionalLayout을 잡아준다.

private enum SectionKind: Int {
    // Section 종류
    case banner
    case list

    // ✅ 한 줄에 보여줄 item의 개수를 설정 
    var columnCount: Int {
        switch self {
        case .banner:
            return 1
        case .list:
            if ProductListViewController.isGrid {
                return 2  // grid 형태면 한 줄에 2개의 item을 나타냄
            } else {
                return 1  // table 형태면 한 줄에 1개의 item을 나타냄
            }
        }
    }

    // ✅ banner section은 horizontal scroll, list section은 vertical scroll로 설정
    func orthogonalScrollingBehavior() -> UICollectionLayoutSectionOrthogonalScrollingBehavior {
        switch self {
        case .banner:
            return .groupPagingCentered
        case .list:
            return .none
        }
    }
}

SectionKind는 배너, 목록 2개 종류로 구분했다.
이때 선택지를 한정 짓는 상황이므로 enum으로 선언했다.
columnCount 프로퍼티를 통해 상품 목록을 나타낼 때, 한 줄 (row)에 보여줄 item의 개수를 설정한다.
한 줄에 Grid 형태는 2개씩, Table 형태는 1개씩 나타낸다.
orthogonalScrollingBehavior 메서드에서 각 Section 마다 어떤 형태로 Scroll 할지 지정한다.
banner는 horizontal scroll을 하므로 .groupPagingCentered를, list section은 vertical scroll을 해야하므로 .none으로 설정했다.

private func createLayout() -> UICollectionViewLayout {
    let layout = UICollectionViewCompositionalLayout { [weak self] sectionIndex, _ -> NSCollectionLayoutSection? in
        // section 정보에 접근
        guard let sectionKind = SectionKind(rawValue: sectionIndex) else {
            self?.showUnknownSectionErrorAlert()
            return nil
        }
        
        // item 설정
        // ✅ Cell 내부 컨텐츠의 높이를 알아서 계산하여 반영하는 estimatedHeight를 적용
        let screenWidth = UIScreen.main.bounds.width
        let estimatedHeight = NSCollectionLayoutDimension.estimated(screenWidth)
        let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: estimatedHeight)
        let item = NSCollectionLayoutItem(layoutSize: itemSize)

        // group 설정
        let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: estimatedHeight)
        let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize,
                                                       subitem: item,  
                                                       count: sectionKind.columnCount)  // 1개 group에 나타낼 item 개수를 설정
        // section 설정
        let section = NSCollectionLayoutSection(group: group)
        section.orthogonalScrollingBehavior = sectionKind.orthogonalScrollingBehavior()  // ✅ 여기서 Section별 Scroll 방향을 할당       
        section.visibleItemsInvalidationHandler = { [weak self] _, contentOffset, environment in
            let bannerIndex = Int(max(0, round(contentOffset.x / environment.container.contentSize.width)))
            if environment.container.contentSize.height == environment.container.contentSize.width {
                self?.currentBannerPage.onNext(bannerIndex)
            }
        }

        // header 및 footer 설정
        let sectionHeader = NSCollectionLayoutBoundarySupplementaryItem(
            layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: estimatedHeight),
            elementKind: SupplementaryKind.header,
            alignment: .top
        )
        let sectionFooter = NSCollectionLayoutBoundarySupplementaryItem(
            layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: estimatedHeight),
            elementKind: SupplementaryKind.footer,
            alignment: .bottom
        )
        section.boundarySupplementaryItems = [sectionHeader, sectionFooter]
        return section
    }
    return layout
}

// ✅ createLayout 메서드의 반환값은 CollectionView의 collectionViewLayout 프로퍼티에 할당함
// 아래의 두 형태 모두 가능
collectionView = UICollectionView(frame: .zero, collectionViewLayout: createLayout()) 
collectionView.collectionViewLayout = createLayout()

createLayout 메서드에서 item / group / section, header / footer에 대한 레이아웃을 설정한다.
estimatedHeight를 사용하면 Cell 내부 컨텐츠의 높이를 알아서 계산하여 반영해주므로 매우 유용하다.
이때 itemSize와 groupSize에 모두 적용해야 작동한다.
.fractionalWidth / .fractionalHeight은 화면 크기에 대한 상대적인 크기를 적용하므로 다양한 기기에 유연하게 대응 가능하다.
section의 orthogonalScrollingBehavior 프로퍼티로 Section마다 Scroll 방향을 설정한다.
section의 boundarySupplementaryItems 프로퍼티로 header 및 footer를 설정한다.
alignment를 header는 .top, footer는 .bottom으로 설정한다.
createLayout 메서드의 반환값은 CollectionView의 collectionViewLayout 프로퍼티에 할당한다.
CollectionView를 초기화할 때 할당하는 것, 초기화한 이후에 할당하는 것 모두 가능하다.
❗배너의 좌우로 다른 item이 보이게 하려면?
item의 fractionalWidth는 1.0, group의 fractionalWidth는 0.7 정도로 설정하고,
item의 contentInsets을 약 10으로 설정하면 된다. (아래의 상세화면 코드에서 설명)

참고 - 배너 하단에 PageControl 구현하기

*자세한 설명은 [CollectionView] 배너 하단에 PageControl 구현 포스트를 참고

예제처럼 PageControl을 구현하려면 추가적인 작업이 필요하다.

배너를 Horizontal Scroll을 했을 때 현재 페이지의 index를 구한 다음 PageControl의 currentPage에 할당해야 한다.

이 작업은 어디서 처리했을까?

createLayout 메서드의 section 부분에 visibleItemsInvalidationHandler로 클로저를 할당하여 처리했다.

(예제에서 PageControl을 FooterView에 배치했는데, 이 부분은 별도로 포스팅할 예정이다.)

참고 - scrollViewWillEndDragging 메서드에 이 코드를 작성하면,

의도했던 Horizontal Scroll 뿐만 아니라 Vertical Scroll을 할 때도 호출되기 때문에 PageControl이 비정상적으로 작동한다.

// 위의 createLayout 메서드에 포함된 코드 
section.visibleItemsInvalidationHandler = { [weak self] _, contentOffset, environment in
    // 비교용 - Device의 Screen 크기
    print("=== Screen Width/Height :", UIScreen.main.bounds.width, "/", UIScreen.main.bounds.height)

    // ✅ contentOffset은 CollectionView의 bound를 기준으로 Scroll 결과 보여지는 컨텐츠의 Origin을 나타냄
    // 배너 및 목록화면의 경우, Scroll하면 어디서 클릭해도 0부터 시작
    // 상세화면의 경우, Scroll하면 어디서 클릭해도 약 -30부터 시작 (기기마다 다름, CollectionView의 bound를 기준으로 cell(이미지)의 leading이 왼쪽 (-30)에 위치하므로 음수임)
    print("OffsetX :", contentOffset.x)

    // ✅ environmnet는 collectionView layout 관련 정보를 담고 있음
    // environment.container.contentSize는 CollectionView 중에서 현재 Scroll된 Group이 화면에 보이는 높이를 나타냄
    print("environment Width :", environment.container.contentSize.width)   // Device의 스크린 너비와 동일
    print("environment Height :", environment.container.contentSize.height) // Horizontal Scroll하면 스크린 너비와 같고, Vertical Scroll하면 그보다 커짐

    let bannerIndex = Int(max(0, round(contentOffset.x / environment.container.contentSize.width)))  // 음수가 되는 것을 방지하기 위해 max 사용
    if environment.container.contentSize.height == environment.container.contentSize.width {  // ❗Horizontal Scroll 하는 조건
        self?.currentBannerPage.onNext(bannerIndex)  // 클로저가 호출될 때마다 pageControl의 currentPage로 값을 보냄
    }
}

visibleItemsInvalidationHandler에 할당되는 클로저를 뜯어보자.
Horizontal Scroll 했을 때 바뀐 Banner 페이지의 index를 pageControl의 currentPage로 지정하는 기능이다.
contentOffset, environment.container.contentSize에 대한 이해가 필요하다. 직접 프린트를 찍어보면 쉽다.
- contentOffset은 CollectionView의 bound를 기준으로 Scroll 결과 보여지는 컨텐츠의 Origin을 나타낸다.
  오른쪽으로 Horizontal Scroll 하면, contentOffset.x의 값은 계속해서 커진다.
- environment.container.contentSize는 공식문서에 명확히 나와있지 않아서 실험이 필요했다.
  일단 environmnet는 collectionView layout 관련 정보를 담고 있다.
  environment.container.contentSize는 CollectionView 중에서 현재 Scroll된 Group이 화면에 보이는 높이를 나타낸다.
  이 contentSize의 height를 찍어보면 Horizontal Scroll할 때는 스크린 너비와 같고, Vertical Scroll할 때는 그보다 커진다.
  (아래 gif 참고)
  -> 따라서 이 특징을 활용하여 if문의 조건으로 Horizontal Scroll하는 경우를 찾은 뒤, PageControl에 현재 페이지를 보내줬다.

Scroll 방향에 따라 달라지는 offSetX 및 environment height 확인

검색 키워드 : orthogonalScrollingBehavior, page control
How can I detect orthogonal scroll events when using `UICollectionViewCompositionalLayout`?

(근데 이 클로저도 Vertical Scroll할 때 호출되므로 한계가 있어보였지만, 다른 해결방법을 찾지 못했다.)

2. Custom Cell 생성

CollectionView에 나타내기 위해 총 3개 종류의 Custom Cell을 생성한다.

배너에 1개 (BannerCell), 목록에 2개 (GridListCell, TableListCell) 종류가 필요하다.

StackView를 추가하고, 내부에 필요한 UI를 addArrangedSubview 메서드로 넣어서 배치한다.

3. DiffableDataSource 생성 및 SnapShot 적용

이제 DiffableDataSource를 사용하는 4단계 STEP을 따라가 보자.

Connect a diffable data source to your collection view.
Implement a cell provider to configure your collection view’s cells.
Generate the current state of the data.
Display the data in the UI.

STEP 1~2로 Cell을 등록하고, DiffableDataSource를 생성하고, ViewController와 연결한다.

아래처럼 typealias를 활용하면 가독성을 개선할 수 있다.

private typealias DiffableDataSource = UICollectionViewDiffableDataSource<SectionKind, UniqueProduct>  
// ❗제네릭 매개변수로 SectionIdentifier, ItemIdentifier를 설정

private typealias BannerCellRegistration = UICollectionView.CellRegistration<BannerCell, UniqueProduct>
private typealias TableListCellRegistration = UICollectionView.CellRegistration<TableListCell, UniqueProduct>
private typealias GridListCellRegistration = UICollectionView.CellRegistration<GridListCell, UniqueProduct>

private typealias HeaderRegistration = UICollectionView.SupplementaryRegistration<HeaderView>
private typealias FooterRegistration = UICollectionView.SupplementaryRegistration<FooterView>

Section 및 Item의 타입 (SectionIdentifier, ItemIdentifier)은 모두 Hashable 해야 한다.
Section 타입인 SectionKind는 위 코드에 있고, Item 타입인 UniqueProduct는 내부에 UUID 타입의 id 프로퍼티를 갖고 있다.

private var collectionView = UICollectionView(frame: .zero, collectionViewLayout: UICollectionViewLayout())
private var dataSource: DiffableDataSource!

private func configureCellRegistrationAndDataSource() {
    // ✅ Cell 등록
    // ❗제네릭 매개변수로 Item 타입을 지정해주면 알아서 Item 데이터가 전달됨 (기존의 indexPath가 필요 없음)
    let bannerCellRegistration = BannerCellRegistration { cell, _, uniqueProduct in
        cell.apply(imageURL: uniqueProduct.product.thumbnail, productID: uniqueProduct.product.id)  // Cell에 데이터를 전달하여 화면에 나타냄
    }
    let tableListCellRegistration = TableListCellRegistration { cell, _, uniqueProduct in
        cell.apply(data: uniqueProduct.product)
    }
    let gridListCellRegistration = GridListCellRegistration { cell, _, uniqueProduct in
        cell.apply(data: uniqueProduct.product)
    }

    // ✅ DiffableDataSource 생성
    dataSource = DiffableDataSource(collectionView: collectionView,
                                    cellProvider: { collectionView, indexPath, product in
        guard let sectionKind = SectionKind(rawValue: indexPath.section) else {
            return UICollectionViewCell()
        }

        // 3개 종류의 Cell을 각각 dequeque 하도록 설정
        switch sectionKind {
        case .banner:
            return  collectionView.dequeueConfiguredReusableCell(using: bannerCellRegistration,
                                                                 for: indexPath,
                                                                 item: product)
        case .list:
            switch ProductListViewController.isGrid {
            case true:
                return collectionView.dequeueConfiguredReusableCell(using: gridListCellRegistration,
                                                                    for: indexPath,
                                                                    item: product)
            case false:
                return collectionView.dequeueConfiguredReusableCell(using: tableListCellRegistration,
                                                                    for: indexPath,
                                                                    item: product)
            }
        }
    })
}

3개 종류의 Custom Cell을 사용하므로 모든 Cell을 등록하고, DataSource를 생성한다.

header 및 footer도 비슷하게 처리하면 된다.

UICollectionReusableView을 상속받아 Custom View를 생성하여 등록하고, DataSource에 연결시키면 된다.

private func configureSupplementaryViewRegistrationAndDataSource() {
    // ✅ header 및 footer 등록
    let headerRegistration = HeaderRegistration(elementKind: SupplementaryKind.header) { view, _, indexPath in
        view.apply(indexPath)
    }
    let footerRegistration = FooterRegistration(elementKind: SupplementaryKind.footer) { [weak self] view, _, indexPath in
        guard let self = self else { return }
        view.bind(input: self.currentBannerPage.asObservable(),
                  indexPath: indexPath,
                  pageNumber: Content.bannerCount)
    }

    // ✅ DiffableDataSource에 반영
    dataSource.supplementaryViewProvider = { [weak self] _, kind, index in
        switch kind {
        case SupplementaryKind.header:
            return self?.collectionView.dequeueConfiguredReusableSupplementary(using: headerRegistration,
                                                                               for: index)
        case SupplementaryKind.footer:
            return self?.collectionView.dequeueConfiguredReusableSupplementary(using: footerRegistration,
                                                                               for: index)
        default:
            return UICollectionReusableView()
        }
    }
}

STEP 3~4로 전체 데이터를 전달해서 초기 Snapshot을 만들고 DiffableDataSource에 적용한다.

예제에서는 초기화면을 구현할 때, 서버에서 20개의 상품 데이터를 받아서 Snapshot을 만들고 apply 했다.

사용자가 Vertical Scroll로 아래로 이동하면, 추가로 20개의 데이터를 받아서 기존 Snapshot에 append하고 apply 했다.

먼저 Inital Snapshot을 구성하는 코드이다.

private var snapshot: NSDiffableDataSourceSnapshot<SectionKind, UniqueProduct>!

private func configureInitialSnapshotWith(listProducts: [UniqueProduct], bannerProducts: [UniqueProduct]) {
    // ✅ 새로운 snapshot 생성
    snapshot = NSDiffableDataSourceSnapshot<SectionKind, UniqueProduct>()

    // ✅ Section 및 Item에 순서대로 데이터를 append
    snapshot.appendSections([.banner])
    snapshot.appendItems(bannerProducts)
    snapshot.appendSections([.list])
    snapshot.appendItems(listProducts)
    
    // ✅ 현재 snapshot을 적용하여 View를 그림
    dataSource.apply(snapshot, animatingDifferences: true)
}

추가 데이터를 받아서 Snapshot을 업데이트할 수 있도록 snapshot 프로퍼티를 생성했다.
appendSections(), appendItems()를 통해 각 Section마다 원하는 Item 데이터를 넣어준다.
Snapshot을 만든 뒤에 apply 메서드를 호출한다.

마지막으로 snapshot을 업데이트하는 코드를 보자.

private func applySnapshotWith(listProducts: [UniqueProduct]) {
    // ✅ snapshot을 업데이트 - list section에만 특정 데이터를 추가함
    snapshot.appendItems(listProducts, toSection: .list)
    
    // ✅ "DiffiableDataSource야, 업데이트한 snapshot을 apply해서 View를 다시 그려줘"
    dataSource.apply(snapshot, animatingDifferences: true)
}

서버에서 추가로 받아온 상품 데이터를 list section에 append하는 작업이다.
appendItems(_:toSection:) 메서드로 데이터를 추가할 특정 Section을 지정한다.
위의 configureInitialSnapshotWith 메서드에서 생성한 snapshot에 다시 apply하여 View를 새로 그린다.

상품 상세화면

상세화면 코드도 가져와봤다.

여러 이미지를 Scroll할 때 1칸씩 Paging 되도록 구현했다.

상품 상세화면

이미지가 들어 갈 위치를 잡아서 CollectionView와 PageControl을 올리고, Custom Cell을 등록하고,

상품 배너 및 목록 화면과 마찬가지로 작업을 하면 된다.

상세화면의 이미지는 고정적이므로 DiffableDataSource를 사용하지 않았다.

// CollectionView 생성
private let imageCollectionView: UICollectionView = {
    let collectionView = UICollectionView(frame: .zero,
                                          collectionViewLayout: UICollectionViewLayout())
    collectionView.translatesAutoresizingMaskIntoConstraints = false
    collectionView.heightAnchor.constraint(equalTo: collectionView.widthAnchor, multiplier: 0.85).isActive = true
    collectionView.backgroundColor = CustomColor.backgroundColor
    collectionView.isScrollEnabled = false
    return collectionView
}()

// PageControl 생성
private let imagePageControl: UIPageControl = {  // 참고 - numberOfPages를 지정은 별도 메서드에서 처리
    let pageControl = UIPageControl()
    pageControl.translatesAutoresizingMaskIntoConstraints = false
    pageControl.pageIndicatorTintColor = .systemGray
    pageControl.currentPageIndicatorTintColor = CustomColor.darkGreenColor
    pageControl.currentPage = 0
    pageControl.isUserInteractionEnabled = false
    pageControl.hidesForSinglePage = true
    return pageControl
}()

// Cell 등록 (1개 이미지가 들어감)
private func configureCollectionView() {
    imageCollectionView.register(ProductDetailImageCell.self,
                                 forCellWithReuseIdentifier: String(describing: ProductDetailImageCell.self))
    imageCollectionView.collectionViewLayout = createCollectionViewLayout()
}

// Compositional Layout 설정
private func createCollectionViewLayout() -> UICollectionViewLayout {
    let layout = UICollectionViewCompositionalLayout { _, _ -> NSCollectionLayoutSection? in
        let screenWidth = UIScreen.main.bounds.width
        let estimatedHeight = NSCollectionLayoutDimension.estimated(screenWidth)
        let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),
                                              heightDimension: estimatedHeight)
        let item = NSCollectionLayoutItem(layoutSize: itemSize)
        item.contentInsets = NSDirectionalEdgeInsets(top: 0, leading: 10, bottom: 0, trailing: 10)  // ✅ item contentInsets 설정

        let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.85),
                                               heightDimension: estimatedHeight)
        let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize, subitem: item, count: 1)

        let section = NSCollectionLayoutSection(group: group)
        section.orthogonalScrollingBehavior = .groupPagingCentered  // ✅ 여기서 설정
        section.visibleItemsInvalidationHandler = { [weak self] _, contentOffset, environment in
            let bannerIndex = Int(max(0, round(contentOffset.x / environment.container.contentSize.width)))
            self?.imagePageControl.currentPage = bannerIndex   // PageControl에 현재 페이지를 반영시킴
        }
        return section
    }
    return layout
}

orthogonalScrollingBehavior에 .groupPagingCentered을 할당했다.
❗배너의 좌우로 다른 item이 보이게 하기 위해
item의 fractionalWidth는 1.0, group의 fractionalWidth는 0.85로 설정하고,
item contentInsets으로 leading 및 trailing에 10을 설정했다.

그리고 이때 아래 사진처럼 Cell이 겹치는 문제가 발생한다면,

Cell의 contentView가 아니라 self에 대해 constraint를 적용해야 한다.

// 문제 발생 - Cell이 겹침
private func configureUI() {
    addSubview(productImageView)
    NSLayoutConstraint.activate([
        productImageView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor),
        productImageView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor),
        productImageView.topAnchor.constraint(equalTo: contentView.topAnchor),
        productImageView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor)
    ])
}

// 해결
private func configureUI() {
    addSubview(productImageView)
    NSLayoutConstraint.activate([
        productImageView.leadingAnchor.constraint(equalTo: self.leadingAnchor),
        productImageView.trailingAnchor.constraint(equalTo: self.trailingAnchor),
        productImageView.topAnchor.constraint(equalTo: self.topAnchor),
        productImageView.bottomAnchor.constraint(equalTo: self.bottomAnchor)
    ])
}

왼쪽 : Cell이 겹치는 문제 -> 오른쪽 : 해결

쓰다 보니 글이 길어졌지만, 한 번 예제코드를 작성해보면 생각보다 간단하다.

전체 코드는 GitHub 링크를 참고

- Reference

예제코드 전체 : GitHub > MVVM-RX-OpenMarket
Apple > Collection View > Sample Code - Updating Collection Views Using Diffable Data Sources
Apple > WWDC 2019 > Advances in UI Data Sources
관련 포스트

[CollectionView] Section마다 다른 Scroll Direction 설정하기, Carousel Paging 구현하기 (feat. AppStore) - orthogonalScrollingBehavior

Applecider — Wed, 8 Jun 2022 22:13:57 +0900

아래의 AppStore처럼 화면을 구현하려면 어떻게 할까?

일반적인 E-commerce 앱에서도 "상품 배너"와 "상품 목록" 화면을 이런 형태로 구현한 것을 자주 볼 수 있다.

화면을 살펴보면 ✅ 맨 위의 Section은 Horizontal Scroll을, 그 아래 Section들은 Vertical Scroll을 하도록 되어있다.

즉, 동일한 CollectionView 내에서 "Section마다 Scroll Direction을 다르게" 지정하고 있다.

그리고 ✅ Horizontal Scroll을 할 때, Cell이 한 칸씩 일정하게 움직이고, 양옆의 Item이 살짝 보인다.

AppStore 화면

이렇게 Cell이 한 칸씩 일정하게 Scroll되는 화면을 뭐라고 부를까?

Paging, Pagination, Carousel Paging, Snap Paging 등 다양하게 불린다.

어떻게 검색할지 모르겠을 때는 AppStore like horizontal scroll 등의 키워드로 찾아보면 된다.

이런 화면을 구현하는 방법은 여러 가지가 있다.

원래는 방법-2가 흔했는데, 애플에서 편하게 쓰라고 방법-1을 만들어준 것 같다.

방법-1. orthogonalScrollingBehavior 프로퍼티 활용

결론부터 말하면, orthogonalScrollingBehavior 프로퍼티를 설정할 때

첫 번째 Section은 .groupPagingCentered, 두 번째 Section은 .none으로 바꿔주면 된다.

'orthogonal'은 수직 방향을 의미한다.

CollectionView의 layout axis를 기준으로 수직 방향이라는 뜻이다.

(위 화면처럼 CollectionView의 layout axis가 vertical이라면 -> orthogonal은 horizontal이다.)

orthogonalScrollingBehavior 프로퍼티의 default는 .none이다.

그래서 아무것도 설정하지 않을 때는 vertical scroll이 되는 것이다.

✅ horizontal scroll을 하려면 .continuous, .paging, .groupPagingCentered 등 .none이 아닌 걸로 설정해주면 된다.

✅ 이때 Horizontal Scroll을 하면서 양옆의 Item이 살짝 보이도록 하려면 .groupPagingCentered으로 하면 된다.

scrollDirection 프로퍼티와 orthogonalScrollingBehavior 프로퍼티의 차이점은?

기본적으로 CollectionView의 Item을 Scroll 하는 방향은 어떻게 결정될까?

CollectionView의 Layout configuration의 scrollDirection 프로퍼티에 vertical 또는 horizontal을 할당하면 된다.

하지만 이렇게 하면 CollectionView의 "모든 Section"의 Scroll 방향에 일괄 적용된다.

그래서 동일한 CollectionView 내에서 "Section마다 Scroll Direction을 다르게" 지정하려면,

section의 orthogonalScrollingBehavior 프로퍼티를 설정해야 한다.

CollectionView 공식문서

CollectionView 공식문서 하단의 Topics를 잘 살펴봤다면 금방 찾을 수 있다.

CollectionView > Layouts > Section > Specifying Scrolling Behavior - orthogonalScrollingBehavior
CollectionView > Layouts > UICollectionLayoutSectionOrthogonalScrollingBehavior

공식문서는 아래처럼 친절하게 그림으로도 설명해준다.

UICollectionLayoutSectionOrthogonal 공식문서 그림

Modern Collection Views 예제코드

Modern Collection Views 예제코드 중에도 관련 내용이 있다.

*기본적인 예제는 Diffable DataSource 이해하기 (2/3) - 흔히 하는 실수, Modern Collection Views 예제 코드 포스트 참고

Compositional Layout 폴더 > Advanced Layouts View Controllers 폴더 > OrthogonalScrollBehaviorViewController 파일이다.

groupPagingCentered 외에도 continuous, continuousGroupLeadingBoundary, paging, groupPaging 등

orthogonalScrollingBehavior 종류별로 어떤 형태로 Scroll 되는지 볼 수 있다.

Orthogonal Scroll Behavior 예제코드

enum SectionKind: Int, CaseIterable {
    case continuous, continuousGroupLeadingBoundary, paging, groupPaging, groupPagingCentered, none

    // ✅ orthogonalScrollingBehavior 종류
    func orthogonalScrollingBehavior() -> UICollectionLayoutSectionOrthogonalScrollingBehavior {
        switch self {
        case .none:
            return UICollectionLayoutSectionOrthogonalScrollingBehavior.none
        case .continuous:
            return UICollectionLayoutSectionOrthogonalScrollingBehavior.continuous
        case .continuousGroupLeadingBoundary:
            return UICollectionLayoutSectionOrthogonalScrollingBehavior.continuousGroupLeadingBoundary
        case .paging:
            return UICollectionLayoutSectionOrthogonalScrollingBehavior.paging
        case .groupPaging:
            return UICollectionLayoutSectionOrthogonalScrollingBehavior.groupPaging
        case .groupPagingCentered:
            return UICollectionLayoutSectionOrthogonalScrollingBehavior.groupPagingCentered
        }
    }
}
    
func createLayout() -> UICollectionViewLayout {

    let config = UICollectionViewCompositionalLayoutConfiguration()
    config.interSectionSpacing = 20

    let layout = UICollectionViewCompositionalLayout(sectionProvider: {
        (sectionIndex: Int, layoutEnvironment: NSCollectionLayoutEnvironment) -> NSCollectionLayoutSection? in
        guard let sectionKind = SectionKind(rawValue: sectionIndex) else { fatalError("unknown section kind") }

        // ✅ leadingItem의 contentInsets을 할당
        let leadingItem = NSCollectionLayoutItem(layoutSize: NSCollectionLayoutSize(
            widthDimension: .fractionalWidth(0.7), heightDimension: .fractionalHeight(1.0)))
        leadingItem.contentInsets = NSDirectionalEdgeInsets(top: 10, leading: 10, bottom: 10, trailing: 10)

        // ✅ trailingItem
        let trailingItem = NSCollectionLayoutItem(layoutSize: NSCollectionLayoutSize(
            widthDimension: .fractionalWidth(1.0), heightDimension: .fractionalHeight(0.3)))
        trailingItem.contentInsets = NSDirectionalEdgeInsets(top: 10, leading: 10, bottom: 10, trailing: 10)
        let trailingGroup = NSCollectionLayoutGroup.vertical(layoutSize: NSCollectionLayoutSize(
            widthDimension: .fractionalWidth(0.3), heightDimension: .fractionalHeight(1.0)),
                                                   subitem: trailingItem,
                                                   count: 2)

        let orthogonallyScrolls = sectionKind.orthogonalScrollingBehavior() != .none
        let containerGroupFractionalWidth = orthogonallyScrolls ? CGFloat(0.85) : CGFloat(1.0)
        // ✅ group의 fractionalWidth를 1.0 보다 작게 설정
        let containerGroup = NSCollectionLayoutGroup.horizontal(
            layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(containerGroupFractionalWidth),
                                               heightDimension: .fractionalHeight(0.4)),
            subitems: [leadingItem, trailingGroup])  // 주의 - trailingItem이 아니라 trailingGroup
            
        let section = NSCollectionLayoutSection(group: containerGroup)
        // ✅ orthogonalScrollingBehavior 설정
        section.orthogonalScrollingBehavior = sectionKind.orthogonalScrollingBehavior()

        // section header 설정
        let sectionHeader = NSCollectionLayoutBoundarySupplementaryItem(
            layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),
                                               heightDimension: .estimated(44)),
            elementKind: OrthogonalScrollBehaviorViewController.headerElementKind,
            alignment: .top)
        section.boundarySupplementaryItems = [sectionHeader]
        return section

    }, configuration: config)
    return layout
}

예제코드답게 SectionKind는 orthogonalScrollingBehavior 종류별로 여러 개가 있다.
enum의 orthogonalScrollingBehavior 메서드에서 각 Section 마다 어떤 형태로 Scroll 할지 지정한다.
이중에서 .groupPagingCentered 방식을 가장 유용하게 쓰고 있다.
createLayout 메서드의 반환값은 CollectionView의 collectionViewLayout 프로퍼티에 할당된다.
❗양옆으로 다른 item이 보이게 하려면?
item의 fractionalWidth는 1.0, group의 fractionalWidth는 0.7 정도로 설정하고,
item의 contentInsets을 좌우 약 10으로 설정하면 된다.

예제코드를 보면 Cell 크기가 큰 것, 작은 것이 섞여있어서 처음 볼 때는 약간 헷갈릴 수 있다.

그래서 아래처럼 단순화시킨 화면의 코드도 공유해본다.

예제코드를 단순화한 화면

// ✅ 0번 = leadingItem, 1번/2번 = nestedGroup
//   +-----------------------------------------------------+
//   | +---------------------------------+  +-----------+  |
//   | |                                 |  |           |  |
//   | |                                 |  |           |  |
//   | |                                 |  |     1     |  |
//   | |                                 |  |           |  |
//   | |                                 |  |           |  |
//   | |                                 |  +-----------+  |
//   | |               0                 |                 |
//   | |                                 |  +-----------+  |
//   | |                                 |  |           |  |
//   | |                                 |  |           |  |
//   | |                                 |  |     2     |  |
//   | |                                 |  |           |  |
//   | |                                 |  |           |  |
//   | +---------------------------------+  +-----------+  |
//   +-----------------------------------------------------+

func createLayout() -> UICollectionViewLayout {
    let config = UICollectionViewCompositionalLayoutConfiguration() 
    config.interSectionSpacing = 20

    // 매개변수 sectionProvider, configuration
    let layout = UICollectionViewCompositionalLayout(sectionProvider: {
        (sectionIndex: Int, layoutEnvironment: NSCollectionLayoutEnvironment) -> NSCollectionLayoutSection? in
        guard let sectionKind = SectionKind(rawValue: sectionIndex) else { fatalError("unknown section kind") }

        // ❗양옆으로 다른 item이 보이게 하는 방법
        // item의 fractionalWidth는 1.0, group의 fractionalWidth는 0.7로 설정하고,
        // item의 contentInsets을 주면 됨
        let leadingItem = NSCollectionLayoutItem(layoutSize: NSCollectionLayoutSize(
            widthDimension: .fractionalWidth(1.0), heightDimension: .fractionalHeight(1.0)))
        leadingItem.contentInsets = NSDirectionalEdgeInsets(top: 10, leading: 10, bottom: 10, trailing: 10)

        // ✅ trailingItem을 사용하지 않고 단순화시킴
//        let trailingItem = NSCollectionLayoutItem(layoutSize: NSCollectionLayoutSize(
//            widthDimension: .fractionalWidth(1.0), heightDimension: .fractionalHeight(0.3)))
//        trailingItem.contentInsets = NSDirectionalEdgeInsets(top: 10, leading: 10, bottom: 10, trailing: 10)
//        let trailingGroup = NSCollectionLayoutGroup.vertical(layoutSize: NSCollectionLayoutSize(
//            widthDimension: .fractionalWidth(0.3), heightDimension: .fractionalHeight(1.0)),
//                                                             subitem: trailingItem,
//                                                             count: 2)

        // group의 width를 .fractionalWidth(0.7)로 주면 양옆으로 다른 item들이 보임 (centerPaging)
        let containerGroup = NSCollectionLayoutGroup.horizontal(
            layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.7),
                                               heightDimension: .fractionalHeight(0.4)),
            subitems: [leadingItem])
//          subitems: [leadingItem, trailingGroup])
        let section = NSCollectionLayoutSection(group: containerGroup)
        section.orthogonalScrollingBehavior = sectionKind.orthogonalScrollingBehavior() // section별로 scroll direction을 다르게 설정!!!

        // header 설정
        let sectionHeader = NSCollectionLayoutBoundarySupplementaryItem(
            layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),
                                              heightDimension: .estimated(44)),
            elementKind: OrthogonalScrollBehaviorViewController.headerElementKind,
            alignment: .top)
        section.boundarySupplementaryItems = [sectionHeader]
        return section
    }, configuration: config)
    return layout
}

방법-2. scrollViewWillEndDragging 메서드 활용

ScrollViewDelegate의 scrollViewWillEndDragging 메서드를 사용해도 된다.

스크롤할 때 Dragging이 끝나기 직전에 호출되는 메서드이다.

이 방법은 이 블로그에서 친절하게 설명해주고 있다.

코드만 보면 이렇다.

var currentIndex: CGFloat = 0  // 현재 화면에 보이는 페이지의 index

func scrollViewWillEndDragging(_ scrollView: UIScrollView, withVelocity velocity: CGPoint, targetContentOffset: UnsafeMutablePointer) {
    // item의 사이즈와 item 간 간격을 구해서 하나의 item 크기로 설정
    let layout = self.collectionView.collectionViewLayout as! UICollectionViewFlowLayout
    let cellWidthIncludingSpacing = layout.itemSize.width + layout.minimumLineSpacing

    // ✅ targetContentOffset 이용하여 x좌표가 얼마나 이동했는지 확인
    // ✅ 이동한 x좌표값과 item 크기를 비교하여 몇 번째 index로 이동할지 구함
    var offset = targetContentOffset.pointee
    let index = (offset.x + scrollView.contentInset.left) / cellWidthIncludingSpacing
    var roundedIndex = round(index)

    // ✅ scrollView, targetContentOffset의 좌표 값으로 스크롤 방향을 알 수 있음
    // index를 반올림 (round)하면 item의 절반 크기만큼 스크롤해야 페이지가 넘어감
    // 스크롤 방향을 체크하여 올림 (ceil), 내림 (floor)을 사용하면 좀 더 자연스러운 페이징 효과가 나옴
    if scrollView.contentOffset.x > targetContentOffset.pointee.x {
        roundedIndex = floor(index)
    } else if scrollView.contentOffset.x < targetContentOffset.pointee.x {
        roundedIndex = ceil(index)
    } else {
        roundedIndex = round(index)
    }

    if isOneStepPaging {
        if currentIndex > roundedIndex {
            currentIndex -= 1
            roundedIndex = currentIndex
        } else if currentIndex < roundedIndex {
            currentIndex += 1
            roundedIndex = currentIndex
        }
    }

    // 위 코드를 통해 이동할 페이지의 좌표값을 targetContentOffset에 대입하면 됨
    offset = CGPoint(x: roundedIndex * cellWidthIncludingSpacing - scrollView.contentInset.left, y: -scrollView.contentInset.top)
    targetContentOffset.pointee = offset
}
// 출처: https://jintaewoo.tistory.com/33

이렇게 공식문서를 참고해서 아래 화면처럼 상품 배너 및 목록을 구현해봤다.

코드는 이 포스팅을 참고 (링크 추가 예정)

Section 구분 - 배너, 목록

- Reference

예제코드 : Apple > Collection View > Sample Code - Implementing Modern Collection Views
Apple > WWDC 2019 > Advances in UI Data Sources
Apple Developer Documentation > CollectionView > Layouts > Section > Specifying Scrolling Behavior - orthogonalScrollingBehavior
Apple Developer Documentation > CollectionView > Layouts > UICollectionLayoutSectionOrthogonalScrollingBehavior
Blog > CollectionView paging 해보기

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[CollectionView] Diffable DataSource 이해하기 (2/3) - 흔히 하는 실수, Modern Collection Views 예제 코드

Applecider — Mon, 30 May 2022 10:05:03 +0900

저번에는 [CollectionView] Diffable DataSource 이해하기 (1/3) - Advances in UI Data Sources (WWDC19) 포스팅에서

Diffable DataSource의 장점과 기초 개념을 알 아봤다.

이번에는 Implementing Modern Collection Views 예제 코드를 보면서 이해도를 높여보자.

흔히 하는 실수-1

Diffable DataSource는 간단해 보이지만 막상 써보면 막히는 부분이 있는데,

보통 프로젝트에서는 여러 종류의 Section을 사용하거나, 여러 종류의 Custom Cell을 쓰기 때문인 것 같다.

특히 처음 사용할 때 가장 흔히 발생하는 문제가

❗ "여러 Section에 동일한 Item을 반영하는 것" 때문이다.

이 경우 컴파일은 되지만, View를 보면 마지막 Section에만 Item이 나타나게 된다.

그리고 콘솔 로그에 아래의 오류 문구가 뜬다..!

[UIDiffableDataSource] Diffable data source detected an attempt to insert or append 5 item identifiers that already exist in the snapshot. The existing item identifiers will be moved into place instead, but this operation will be more expensive. For best performance, inserted item identifiers should always be unique. Set a symbolic breakpoint on BUG_IN_CLIENT_OF_DIFFABLE_DATA_SOURCE__IDENTIFIER_ALREADY_EXISTS to catch this in the debugger. Item identifiers that already exist: ( // 중복 Item 정보 )

"snapshot에는 동일한 item이 들어갈 수 없다"는 내용이다.

공식문서에서 Section 타입 (Section identifier)과 Item 타입 (Item identifier)은 모두 Hashable해야 한다고 했던 게 이 때문이다.

*그럼에도 불구하고 View에 동일한 콘텐츠를 나타내고 싶다면?

item identifier가 중복되지 않도록 Item 타입에 UUID 등 identifier 프로퍼티를 추가해서 다른 item인 척해야 한다.

흔히 하는 실수-2

DiffableDataSource를 사용할 때 Custom Cell에 데이터를 전달하는 방법도 낯설다.

기존에는 DataSource 역할을 하는 items 배열이 있고, items[indexPath.row] 형태로 데이터에 접근한다.

하지만 DiffableDataSource에서는 indexPath가 필요 없다.

❗Cell register를 할 때 제네릭 매개변수로 Item 타입을 지정해주면 알아서 Item 데이터가 전달된다.

snapshot을 통해 Item 데이터를 전달받는데, 이때 모든 Item이 Hashable하기 때문에 가능한 것이다.

// 제네릭 매개변수 ItemIdentifier에다가 Product 타입을 전달
let bannerCellRegistration = BannerCellRegistration<BannerCell, Product> { cell, indexPath, product in
//  cell.titleLabel.text = products[indexPath.row]  // 잘못된 예시
    cell.titleLabel.text = product  // cellProvider의 product (itemIdentifier)를 전달받음
}

이런 오류를 피하려면 애플이 만들어준 예제 코드를 자세히 살펴봐야 한다.

Implementing Modern Collection Views 예제 코드

3개 예제 코드를 살펴볼 텐데, 큰 틀은 모두 똑같다.

1️⃣ Cell을 등록하고, 2️⃣ Diffable DataSource를 생성하고, 3️⃣ Snapshot을 만들어 적용하면 된다.

예제를 볼 때, 가장 먼저 DataSource와 Snapshot의 제네릭 매개변수 <section, item>를 통해 타입을 확인하면 쉽다.

*위 과정이 이해되지 않는다면 이전 포스팅을 참고

Compositional layout도 중요한 주제인데 별도로 포스팅할 예정이다.

예제 종류-1. 새로운 Snapshot을 생성하여 적용 (1개 Section)

Diffable 폴더의 MountainsViewController 파일이다.

Section 종류도 1개이고, Item 및 Cell 타입도 1개 종류 를 사용하는 가장 기본적인 예제이다.

처음에는 전체 데이터를 보여주도록 View를 그렸다가,

사용자 이벤트를 받으면 일부 데이터만 보이도록 View를 업데이트한다.

Mountains 예제코드

코드에서 2개만 확인하면 된다.

먼저 전체 Mountains 데이터를 하나씩 Cell에 담아 나타낸다.
-> 전체 데이터로 inital snapshot을 생성
상단의 SearchBar에 사용자가 문자를 입력할 때마다, 입력값을 포함하는 검색결과만 필터링하여 View를 업데이트한다.
-> 데이터를 필터링하여 새로운 snapshot을 생성

// Mountains 데이터 (Raw Data)
let mountainsRawData = """
Mount Everest,8848
K2,8611
Kangchenjunga,8586
Lhotse,8516
//...
"""

// ✅ Section 타입 (SectionIdentifier)
enum Section: CaseIterable {
    case main
}

// ✅ Item 타입 (ItemIdentifier)
struct Mountain: Hashable {
    let name: String
    let height: Int
    let identifier = UUID()  // Item identifier는 unique해야 하므로
    
    func hash(into hasher: inout Hasher) { // dataSource가 snapshot이 달라진 것 인식하기 위해 필요함
        hasher.combine(identifier)
    }
    static func == (lhs: Mountain, rhs: Mountain) -> Bool {
        return lhs.identifier == rhs.identifier
    }
    func contains(_ filter: String?) -> Bool {
        guard let filterText = filter else { return true }
        if filterText.isEmpty { return true }
        let lowercasedFilter = filterText.lowercased()  // 기존 데이터, 입력값 모두 소문자로 전환하여 비교
        return name.lowercased().contains(lowercasedFilter)
    }
}

class MountainsViewController: UIViewController {
    var mountainsCollectionView: UICollectionView!
    var dataSource: UICollectionViewDiffableDataSource<Section, MountainsController.Mountain>!
    
    func configureDataSource() {
        // 1️⃣ Cell 등록
        let cellRegistration = UICollectionView.CellRegistration
        <LabelCell, MountainsController.Mountain> { (cell, indexPath, mountain) in
            // Populate the cell with our item description.
            cell.label.text = mountain.name
        }
        
        // 2️⃣ DiffableDataSource 생성
        dataSource = UICollectionViewDiffableDataSource<Section, MountainsController.Mountain>(collectionView: mountainsCollectionView) {
            (collectionView: UICollectionView, indexPath: IndexPath, identifier: MountainsController.Mountain) -> UICollectionViewCell? in
            return collectionView.dequeueConfiguredReusableCell(using: cellRegistration, for: indexPath, item: identifier)
        }
    }
}

// 3️⃣ Snapshot 생성 및 적용
// 1) 화면을 띄울 때 (viewDidLoad), 2) SearchBar 입력값이 바뀔 때 (textDidChange) 호출됨
func performQuery(with filter: String?) {
    // SearchBar 입력값을 포함하는 item만 필터링
    let mountains = mountainsController.filteredMountains(with: filter).sorted { $0.name < $1.name }

    // ✅ 새로운 snapshot 생성
    var snapshot = NSDiffableDataSourceSnapshot<Section, MountainsController.Mountain>() 
    snapshot.appendSections([.main])
    snapshot.appendItems(mountains)  // 필터링된 item만 snapshot에 반영시킴  
    
    // ✅ "DiffiableDataSource야, 업데이트한 snapshot을 apply해서 View를 다시 그려줘"
    dataSource.apply(snapshot, animatingDifferences: true) 
}

자세한 설명은 이전 포스팅을 참고

예제 종류-2. 2개 종류의 Section을 사용 (동일한 Item 타입)

다음은 Diffable 폴더의 WiFiSettingsViewController 파일이다.

설정 앱의 WiFi 탭과 비슷하다.

첫번째 Section은 WiFi 연결 상태 (ON/OFF, 현재 연결된 네트워크), 두번째 Section은 연결 가능한 네트워크를 보여준다.

WiFi 예제코드

이번에는 Section이 2개 종류이고, Item 및 Cell은 1개 종류를 사용한다.

어떻게 여러 Section을 구현하고, 각각 원하는 Item을 넣는지 보자.

// Section 타입 (2개 종류)
enum Section: CaseIterable {
    case config, networks  
}

// Item 타입
struct Item: Hashable {
    let title: String
    let type: ItemType
    let network: WiFiController.Network?
}

class WiFiSettingsViewController: UIViewController {
    let tableView = UITableView(frame: .zero, style: .insetGrouped)
    var dataSource: UITableViewDiffableDataSource<Section, Item>! = nil
    var currentSnapshot: NSDiffableDataSourceSnapshot<Section, Item>! = nil
    
    // 1️⃣ Cell 등록
    func configureTableView() {
        tableView.register(UITableViewCell.self, forCellReuseIdentifier: WiFiSettingsViewController.reuseIdentifier)
        //...
    }
    
    // 2️⃣ DiffableDataSource 생성
    func configureDataSource() {
        self.dataSource = UITableViewDiffableDataSource<Section, Item>(tableView: tableView) { [weak self] (tableView: UITableView, indexPath: IndexPath, item: Item) -> UITableViewCell? in
            guard let self = self, let wifiController = self.wifiController else { return nil }
            let cell = tableView.dequeueReusableCell(withIdentifier: WiFiSettingsViewController.reuseIdentifier, for: indexPath)
            // cell의 상태 (isNetwork / isConfig)에 따라 Layout을 변경함 (생략)
        }   
    }
    
    // 3️⃣ snapshot 생성 및 적용
    func updateUI(animated: Bool = true) {
        guard let controller = self.wifiController else { return }
        let configItems = configurationItems.filter { !($0.type == .currentNetwork && !controller.wifiEnabled) }

        currentSnapshot = NSDiffableDataSourceSnapshot<Section, Item>()
        currentSnapshot.appendSections([.config])  // ✅ 1번 Section 및 Item 설정
        currentSnapshot.appendItems(configItems, toSection: .config)

        // wifi가 연결되면 2번 Section이 나타남
        if controller.wifiEnabled {
            let sortedNetworks = controller.availableNetworks.sorted { $0.name < $1.name }
            let networkItems = sortedNetworks.map { Item(network: $0) }
            currentSnapshot.appendSections([.networks])  // ✅ 2번 Section 및 Item 설정
            currentSnapshot.appendItems(networkItems, toSection: .networks)
        }

        self.dataSource.apply(currentSnapshot, animatingDifferences: animated)
    }
}

appendSections(), appendItems()를 통해 각 Section마다 원하는 Item 데이터를 넣어준다.
앞의 예제 코드와 뭐가 다를까?
이 번에는 Section 종류가 여러 개라서 appendItems(_:toSection:) 메서드로 특정 Section을 지정하여 Item을 넣는다.
또한 호출 순서도 중요하다.
appendSections([.section1]) - appendItems(items1, toSection: .section1) - appendSections([.section2]) - appendItems(items2, toSection: .section2) 순으로 호출해야 한다.
(appendSections([.section1]) - appendSections([.section2]) 등으로 호출하면 안된다는 뜻)

✨ 예제 종류-3. Section마다 다른 Cell 타입을 사용

Compositional Layout 폴더의 Basics View Controllers 폴더의 DistinctSectionsViewController 파일이다.

이번에는 Section이 3개 종류이고, Cell은 2개 종류를 사용한다.

그리고 Section 마다 Item의 Layout을 다르게 설정했다.

Distinct Sections 예제코드

코드에서 2개만 확인하면 된다.

Section마다 다른 Cell 타입을 사용했다.
-> 첫번째 Section은 List 형태 (ListCell 타입)로, 두/세번째 Section은 Grid 형태 (TextCell 타입)로 dequeue한다.
또한 Section 마다 한 줄에 몇 개의 Item을 보여줄지 다르게 설정했다.
-> 첫번째 Section은 한 줄에 Item이 1개, 두번째 Section은 5개, 세번째 Section은 3개씩 배치된다.

// Section별로 다른 Layout을 사용
enum SectionLayoutKind: Int, CaseIterable {
    case list, grid5, grid3  // rawValue가 각각 0,1,2로 지정됨

    // createLayout()에서 호출되며, 1개 row에 몇 개의 item이 들어갈지 설정함
    var columnCount: Int {  
        switch self {
        case .grid3:
            return 3
        case .grid5:
            return 5
        case .list:
            return 1
        }
    }
}

class DistinctSectionsViewController: UIViewController {
    var dataSource: UICollectionViewDiffableDataSource<SectionLayoutKind, Int>! = nil
    var collectionView: UICollectionView! = nil

    func configureDataSource() {
        // 1️⃣ Cell 등록 
        // 2개 종류의 Cell Type을 사용 (ListCell / TextCell)
        let listCellRegistration = UICollectionView.CellRegistration<ListCell, Int> { (cell, indexPath, identifier) in
            cell.label.text = "\(identifier)"
        }

        let textCellRegistration = UICollectionView.CellRegistration<TextCell, Int> { (cell, indexPath, identifier) in
            cell.label.text = "\(identifier)"
            //...
        }
        
        // 2️⃣ DiffableDataSource 생성
        // ✅ 주의 - dataSource 프로퍼티를 2개로 나누지 않음!
        dataSource = UICollectionViewDiffableDataSource<SectionLayoutKind, Int>(collectionView: collectionView) {
            (collectionView: UICollectionView, indexPath: IndexPath, identifier: Int) -> UICollectionViewCell? in
            // 일반적인 dataSource를 사용할 때처럼 화면에 보이는 Cell의 개수만큼 호출됨
            // ✅ Setion이 .list이면 ListCell 타입, .grid5, .grid3이면 TextCell 타입으로 dequeue
            return SectionLayoutKind(rawValue: indexPath.section)! == .list ?
            collectionView.dequeueConfiguredReusableCell(using: listCellRegistration, for: indexPath, item: identifier) :
            collectionView.dequeueConfiguredReusableCell(using: textCellRegistration, for: indexPath, item: identifier)
        }

        // 3️⃣ snapshot 생성 및 적용
        // initial data
        let itemsPerSection = 10
        var snapshot = NSDiffableDataSourceSnapshot<SectionLayoutKind, Int>()
        SectionLayoutKind.allCases.forEach {
            snapshot.appendSections([$0])
            // ✅ Section마다 다른 Item을 지정 - Section1은 1~9, Section2는 10~19, Section3은 20~29로 구성
            let itemOffset = $0.rawValue * itemsPerSection
            let itemUpperbound = itemOffset + itemsPerSection
            snapshot.appendItems(Array(itemOffset..<itemUpperbound))
        }
        dataSource.apply(snapshot, animatingDifferences: false)
    }
}

dequeue 메서드가 호출되는 시점은 언제일까?
초기화면에서는 일반적인 dataSource를 사용할 때처럼 "화면에 보이는 Cell의 개수만큼" 호출된다.
이때 Setion이 .list이면 ListCell 타입, .grid5, .grid3이면 TextCell 타입으로 dequeue한다.
Cell 타입이 다르다고 dataSource를 여러 개 만들면 안된다. dataSource는 1개여야 한다.
Snapshot을 생성하는 부분은 2번 예제와 비슷하지만 살짝 다르다.
appendSections(), appendItems() 메서드를 사용한다. (appendItems(_:toSection:) 메서드를 쓰지 않았음)
이 예제에서 Section에 들어가는 Item의 타입은 모두 Int이다.
만약 Section마다 다른 타입의 Item을 넣어주고 싶다면?
해당 Item들을 추상화 (프로토콜 타입)해서 사용해야 한다.

참고 - Compositional Layout을 사용하여 Item의 배치 형태를 설정하는 코드는 아래와 같다.

func createLayout() -> UICollectionViewLayout {
    // ✅ sectionProvider를 통해 CollectionView 관련 정보를 받아서 활용함 (cellProvider와 비슷)
    let layout = UICollectionViewCompositionalLayout { (sectionIndex: Int,
        layoutEnvironment: NSCollectionLayoutEnvironment) -> NSCollectionLayoutSection? in

        guard let sectionLayoutKind = SectionLayoutKind(rawValue: sectionIndex) else { return nil }  // section의 rawValue로 column을 찾아둠
        let columns = sectionLayoutKind.columnCount  // ✅ Section 종류별로 column 개수가 다름

        // The group auto-calculates the actual item width to make
        // the requested number of columns fit, so this widthDimension is ignored.
        let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),
                                             heightDimension: .fractionalHeight(1.0))
        let item = NSCollectionLayoutItem(layoutSize: itemSize)
        item.contentInsets = NSDirectionalEdgeInsets(top: 2, leading: 2, bottom: 2, trailing: 2)

        let groupHeight = columns == 1 ?
            NSCollectionLayoutDimension.absolute(44) :
            NSCollectionLayoutDimension.fractionalWidth(0.2)
        let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),
                                              heightDimension: groupHeight)
        let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize, subitem: item, count: columns) // ✅ count의 매개변수로 전달됨

        let section = NSCollectionLayoutSection(group: group)
        section.contentInsets = NSDirectionalEdgeInsets(top: 20, leading: 20, bottom: 20, trailing: 20)
        return section
    }
    return layout
}

예제 종류-4. Header / Footer 구현

Compositional Layout 폴더의 Basics View Controllers 폴더의 SectionHeadersFootersViewController 파일이다.

마지막으로 Header 와 Footer를 구현한 코드를 보자.

아주 간단하다. 1️⃣ Cell을 등록하고, 2️⃣ Diffable DataSource 에 끼워넣기만 하면 된다.

위에서 Item에 들어갈 Cell을 등록했듯이 Header/Footer에 들어갈 Cell을 등록하면 된다.

이때 Cell은 UICollectionReusableView를 상속받도록 한다.

Headers/Footers 예제코드

// ✅ Custom Header/Footer Cell 타입
class TitleSupplementaryView: UICollectionReusableView {
    let label = UILabel()
    //...
}
    
class SectionHeadersFootersViewController: UIViewController {
    static let sectionHeaderElementKind = "section-header-element-kind"
    static let sectionFooterElementKind = "section-footer-element-kind"

    var dataSource: UICollectionViewDiffableDataSource<Int, Int>! = nil
    var collectionView: UICollectionView! = nil

    func configureDataSource() {
        // 1️⃣ Header Cell 등록 
        let headerRegistration = UICollectionView.SupplementaryRegistration
        <TitleSupplementaryView>(elementKind: SectionHeadersFootersViewController.sectionHeaderElementKind) {
            (supplementaryView, string, indexPath) in
            supplementaryView.label.text = "\(string) for section \(indexPath.section)"
            //...
        }
        
        // 1️⃣ Footer Cell 등록 
        let footerRegistration = UICollectionView.SupplementaryRegistration
        <TitleSupplementaryView>(elementKind: SectionHeadersFootersViewController.sectionFooterElementKind) {
            (supplementaryView, string, indexPath) in
            supplementaryView.label.text = "\(string) for section \(indexPath.section)"
            //...
        }
            
        dataSource = UICollectionViewDiffableDataSource<Int, Int>(collectionView: collectionView) {
            (collectionView: UICollectionView, indexPath: IndexPath, identifier: Int) -> UICollectionViewCell? in
            return collectionView.dequeueConfiguredReusableCell(using: cellRegistration, for: indexPath, item: identifier)
        }
        
        // 2️⃣ DiffableDataSource에 끼워넣기
        dataSource.supplementaryViewProvider = { (view, kind, index) in
            return self.collectionView.dequeueConfiguredReusableSupplementary(
                using: kind == SectionHeadersFootersViewController.sectionHeaderElementKind ? headerRegistration : footerRegistration, for: index)
        }

        // Snapshot 생성 및 적용 (다른 예제와 동일함)
        // initial data
        let itemsPerSection = 5
        let sections = Array(0..<5)
        var snapshot = NSDiffableDataSourceSnapshot<Int, Int>()
        var itemOffset = 0
        sections.forEach {
            snapshot.appendSections([$0])
            snapshot.appendItems(Array(itemOffset..<itemOffset + itemsPerSection))
            itemOffset += itemsPerSection
        }
        dataSource.apply(snapshot, animatingDifferences: false)
    }

Custom Header/Footer Cell을 구현하고, 해당 Cell을 등록했다.
dataSource에 끼워넣을 때는 dataSource.supplementaryViewProvider 에 클로저를 전달하면 된다.

마지막으로 Compositional Layout을 생성하는 부분에서도 작업이 필요하다.

func createLayout() -> UICollectionViewLayout {
    let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),
                                         heightDimension: .fractionalHeight(1.0))
    let item = NSCollectionLayoutItem(layoutSize: itemSize)
    let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),
                                          heightDimension: .absolute(44))
    let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize, subitems: [item])
    let section = NSCollectionLayoutSection(group: group)
    section.interGroupSpacing = 5
    section.contentInsets = NSDirectionalEdgeInsets(top: 0, leading: 10, bottom: 0, trailing: 10)

    // ✅ Header/Footer 관련 설정
    let headerFooterSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),
                                                 heightDimension: .estimated(44))
    let sectionHeader = NSCollectionLayoutBoundarySupplementaryItem(layoutSize: headerFooterSize,
        elementKind: SectionHeadersFootersViewController.sectionHeaderElementKind, alignment: .top)
    let sectionFooter = NSCollectionLayoutBoundarySupplementaryItem(layoutSize: headerFooterSize,
        elementKind: SectionHeadersFootersViewController.sectionFooterElementKind, alignment: .bottom) 
    // ✅ 주의 - alignment는 Header는 .top, Footer는 .bottom으로 설정
    section.boundarySupplementaryItems = [sectionHeader, sectionFooter]

    let layout = UICollectionViewCompositionalLayout(section: section)
    return layout
}

section의 boundarySupplementaryItems에 Header 및 Footer를 넣어주면 된다.
이때 alignment는 Header는 .top, Footer는 .bottom으로 설정해야 한다.

다음 포스팅에서는 개인적으로 인디앱 개발 프로젝트를 진행하면서 Diffable DataSource를 적용했던 코드를 살펴보려고 한다.

최근 E-commerce 분야 상용앱에서 자주 보이는 화면인데,

화면 상단에 Horizontal Scroll이 가능한 배너 (Banner Section)와 Vertical Scroll이 가능한 상품 목록 (List Section)을 CollectionView로 구현해봤다.

- Reference

예제코드 : Apple > Collection View > Sample Code - Implementing Modern Collection Views
Apple > Collection View > Sample Code - Updating Collection Views Using Diffable Data Sources
Apple > WWDC 2019 > Advances in UI Data Sources
Apple > WWDC 2020 > Advances in diffable data sources

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[CollectionView] Diffable DataSource 이해하기 (1/3) - Advances in UI Data Sources (WWDC19)

Applecider — Fri, 27 May 2022 17:15:11 +0900

CollectionView / TableView와 관련해서 "Diffable DataSource" 개념이 등장했다.

러닝커브가 조금 있는 내용이라 포스팅을 남기려고 한다.

✏️ 새로운 기술을 습득하기 가장 좋은 방법은 Apple이 만든 WWDC 영상을 보는 것이다.

UIKit 담당 팀에서 직접 기술이 등장한 배경, 활용 방법에 대해 짜임새 있게 소개하기 때문이다.

그다음엔 공식문서의 예제를 따라 하면서 직접 View를 그려보면 된다.

Diffable DataSource가 뭔지 간단히 정리하고,

WWDC 세션 내용을 살펴보자.

Diffable DataSource란?

Diffable = Different + Ability

Diffable은 "달라질 수 있는 능력이 있다"는 뜻이다.

CollectionView / TableView를 그리기 위해서는 DataSource가 필요하다.
기존에는 CollectionView DataSource Protocol을 채택하고, Protocol에 구현되어 있던 메서드를 사용하는 방법을 사용했다.

사용자 이벤트를 받아서 View를 업데이트해야 하는 상황을 가정해보자.

기존 방법으로는 데이터를 변경한 뒤에 전체 View를 다시 그리도록 reloadData() 또는 performBatchUpdates()를 호출해야 했다.

Diffable DataSource는 새로운 방식의 DataSource이다.

Cell에 어떤 종류의 데이터가 들어갈지만 정해놓고, 데이터를 Snapshot 형태로 사진을 찍어서 View에 반영한다.

데이터가 바뀌면 새로운 Snapshot을 만들어서 반영시키면 된다.

View를 그릴 때 이전의 Snapshot과 새로운 Snapshot 사이에 달라진 부분을 애니메이션으로 자연스럽게 연결시켜준다.

따라서 DataSource가 변경되었을 때 View를 보다 효율적이고 dynamic하게 업데이트할 수 있고, UX 관점에서 유리하다.

Diffable DataSource와 RxSwift

기존 방법에서 RxCocoa를 사용한다면 collectionView.rx.items(cellIdentifier:cellType:) 형태로 데이터를 binding 시킨다.

이와 달리, Diffable DataSource는 snapshot을 사용하므로 RxSwift처럼 reactive하게 동작한다.

따라서 위 코드가 필요 없다.

Snapshot을 apply() 하는 부분에만 Rx를 사용하면 된다.

개인적으로 Diffable DataSource 자체가 reactive해서 RxSwift와 잘 어울리지 않는 면이 많다고 느꼈다.

예를 들어 특정 Cell을 탭하는 이벤트가 발생했을 때, 기존에는 collectionView.rx.modelSelected(CustomCellType.self).bind() 형태로 selectedCell을 받아올 수 있어서 매우 유용했는데, Diffable DataSource를 사용하면 이 메서드가 정상 작동하지 않았다.

이 부분은 다다음 포스팅에서 자세히 다뤄보려고 한다.

Advances in UI Data Sources (WWDC19)

기본적인 개념은 이렇다. 링크는 여기에

DiffableDataSource에서는 복잡한 performBatchUpdates 메서드 대신 apply 메서드를 사용한다.
이제부터 UI를 업데이트할 때 indexPath 대신 Snapshot을 사용한다. Snapshot은 "현재 UI 상태의 truth"를 뜻한다.
이때 Snapshot의 Section identifier 및 Item identifier은 모두 unique 해야 한다. (Hashable을 준수해야 한다.)
기존 DataSource는 "프로토콜" 타입, DiffableDataSource (UICollectionViewDiffableDataSource)는 "제네릭 클래스" 타입이다.
Snapshot (NSDiffableDataSourceSnapshot)은 "제네릭 구조체" 타입이다.

예제 코드

✅ DiffableDataSource를 사용하는 Implementing Modern Collection Views 예제 코드를 보자.

상단의 SearchBar에 사용자가 문자를 입력할 때마다, 입력값을 포함하는 검색결과만 필터링하여 CollectionView를 다시 그린다.

검색결과가 바뀔 때마다 애니메이션이 자동 적용된다.

Mountains Search 예제코드

CollectionView를 그리기 위해 DiffableDataSource 공식문서에 나와있는 4단계 STEP을 따른다.

Connect a diffable data source to your collection view.
Implement a cell provider to configure your collection view’s cells.
Generate the current state of the data.
Display the data in the UI.

먼저 DiffableDataSource를 생성하고, ViewController와 연결한다. (STEP 1~2번)

// Modern Collection Views 예제코드 > Diffable 폴더
class MountainsViewController: UIViewController {
    var mountainsCollectionView: UICollectionView!
    var dataSource: UICollectionViewDiffableDataSource<Section, MountainsController.Mountain>!
    
    func configureDataSource() {
        // cell register
        let cellRegistration = UICollectionView.CellRegistration
        <LabelCell, MountainsController.Mountain> { (cell, indexPath, mountain) in
            // Populate the cell with our item description.
            cell.label.text = mountain.name
        }
        
        // ✅ DiffableDataSource 생성
        dataSource = UICollectionViewDiffableDataSource<Section, MountainsController.Mountain>(collectionView: mountainsCollectionView) {
            (collectionView: UICollectionView, indexPath: IndexPath, identifier: MountainsController.Mountain) -> UICollectionViewCell? in
            return collectionView.dequeueConfiguredReusableCell(using: cellRegistration, for: indexPath, item: identifier)
        }
    }
}

// ✅ Section 타입 (SectionIdentifier)
enum Section: CaseIterable {
    case main
}

// ✅ Item 타입 (ItemIdentifier)
struct Mountain: Hashable {
    let name: String
    let height: Int
    let identifier = UUID()  // Item identifier는 unique해야 하므로
}

Cell을 등록하고, Cell 등록정보 (cellRegistration)를 활용해서 DiffableDataSource를 생성한다.
DiffiableDataSource의 이니셜라이저를 보자. 제네릭 클래스이므로 <SectionIdentifier, ItemIdentifier> 형태로 초기화하고, 매개변수로 collectionView, cellProvider를 전달한다.
이때 cellProvider는 클로저 타입의 typealias인데, 대략 (collectionView, indexPath, itemIdentifier) 형태이다.
SectionIdentifier로 enum타입을 사용한 이유는 뭘까?
연관값이 없는 enum은 항상 Hashable하기 때문이다. (모든 연관값이 Hashable하면 enum도 Hashable하다.)
ItemIdentifier 내부에 UUID 타입의 identifier 프로토콜을 만든 이유는 뭘까?
마찬가지로 Hashable해야 하기 때문이다. UUID는 임의의 고유 값이다.

그다음, 전체 데이터를 전달해서 초기 Snapshot을 만들고 DiffableDataSource에 적용한다. (STEP 3~4번)

이 예제에서는 SearchBar 입력값을 받을 때마다 Snapshot을 다시 만들고 화면을 업데이트한다.

func performQuery(with filter: String?) {
    // SearchBar 입력값을 포함하는 item만 필터링
    let mountains = mountainsController.filteredMountains(with: filter).sorted { $0.name < $1.name }

    // ✅ 새로운 snapshot 생성
    var snapshot = NSDiffableDataSourceSnapshot<Section, MountainsController.Mountain>() 
    snapshot.appendSections([.main])
    snapshot.appendItems(mountains)  // 필터링된 item만 snapshot에 반영시킴  
    
    // ✅ "DiffiableDataSource야, 업데이트한 snapshot을 apply해서 View를 다시 그려줘"
    dataSource.apply(snapshot, animatingDifferences: true) 
}

performQuery 메서드는 1) 화면을 띄울 때 (viewDidLoad), 2) SearchBar 입력값이 바뀔 때 (textDidChange) 호출된다.
Snapshot의 이니셜라이저를 보자. DiffableDataSource와 비슷하다.
제네릭 구조체이므로 <SectionIdentifierType, ItemIdentifierType> 형태로 초기화한다.
appendSections(), appendItems()를 통해 각 Section마다 원하는 Item 데이터를 넣어준다.
*이때 section이 여러 개라면?
appendSections([.section1]) - appendItems(items1) - appendSections([.section2]) - appendItems(items2) 순으로 호출해야 한다.
Snapshot을 만든 뒤에 apply 메서드를 호출하면 된다.

위 예제는 Snapshot을 생성할 때 empty snapshot을 만들고 section/item을 append하고 있다.

다른 방법으로, 현재 View의 snapshot을 그대로 가져오고 싶다면 이렇게 하면 된다.

let snapshot = dataSource.snapshot()

그리고 예제와 달리, 기존 item을 삭제하고, 새로운 item을 반영하고 싶다면 이렇게 하면 된다.

private func deleteAndApplySnapshot(newListProducts: [UniqueProduct]) {
    let previousProducts = snapshot.itemIdentifiers(inSection: .list)
    snapshot.deleteItems(previousProducts)  // 기존 item 삭제
    // snapshot.deleteAllItems()  // 이것도 가능
    snapshot.appendItems(listProducts, toSection: .list)

    dataSource.apply(snapshot, animatingDifferences: true)
}

Diffable DataSource의 장점

기존 DataSource를 쓰고 reloadData 메서드를 호출해도 되는데 뭐가 다를까?

reloadData를 쓰면 애니메이션이 끊겨서 UX에 안 좋다.

반면 DiffiableDataSource는 View를 다시 그릴 때 Snapshot의 변화를 스스로 파악하고, 그걸 똑똑하게 애니메이션으로 나타내준다!

(애니메이션이 싫다면 apply 메서드의 animatingDifferences에 false를 할당하면 된다.)

그리고 synchronization 버그, crash 발생을 예방하므로 안전하다.

기존 방법에서 자주 발생하는 synchronization 버그...

이외에도 Sectional Snapshot이라는 보완 기술을 소개한 WWDC 세션도 있는데, 나중에 다룰 예정이다.

다음 포스팅에서는 Implementing Modern Collection Views 예제 코드를 자세히 살펴보자.

웬일로 예제 코드가 다양하게 잘 나와있어서 이해하기 수월했다.

- Reference

예제코드 : Apple > Collection View > Sample Code - Implementing Modern Collection Views
Apple > Collection View > Sample Code - Updating Collection Views Using Diffable Data Sources
Apple > WWDC 2019 > Advances in UI Data Sources
Apple > WWDC 2020 > Advances in diffable data sources
블로그 > Zeddios - Diffable Datasource

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.

[Git] Git 브랜치 이름은 어떻게 정할까? - Git Flow로 브랜치 관리하기

Applecider — Wed, 25 May 2022 11:57:54 +0900

부트캠프에서는 프로젝트를 진행할 때 STEP별 명세서를 받았다.

그래서 자연스레 브랜치 이름도 step1, step2... 등으로 네이밍했었다.

근데 직접 앱을 기획해보니 브랜치 이름을 어떻게 정할지 고민이 됐다.

'Git 브랜치 이름'을 키워드로 검색했더니, 온통 "Git Flow 전략"에 대한 자료만 나왔다.

Git Flow가 뭘까?

브랜치 모델 (Branch Model)이란 브랜치 이름, 브랜치별 임무를 규정한 것이다.

이 브랜치 모델 중 가장 유명한 게 Vincent Driessen가 만든 Git Flow이다.

프로젝트를 효율적으로 관리하기 위해

master, develop, feature, release, hotfix 5개 종류로 브랜치를 구분한다.

Git Flow

당장 위의 구조도를 모두 이해할 필요는 없다.

대부분의 작업은 feature -> develop -> release -> master 순으로 merge 시켜서 관리한다는 것만 알면 된다.

feature : 새로운 기능을 개발할 때는 feature 브랜치에서 기능별 브랜치를 만들어 작업한다.
develop : 기능 개발이 완료되면 해당 feature 브랜치를 develop 브랜치에 merge 시킨다.
release : release 준비가 완료되면 develop 브랜치를 release 브랜치로 merge 시키고, release cycle을 진행한다.
master : 최종 product를 release할 때는 release 브랜치를 master 브랜치로 merge 시키고, 해당 버전에 대해 Tag를 단다.
hotfix : product release 이후 중요한 버그가 발생하면 hotfix 브랜치로 작업하고, develop 및 master 브랜치로 merge 시킨다.

Git Flow의 장점

브랜치가 자동으로 생성/삭제/merge 되어 편리하다.
브랜치 이름을 일관적으로 사용할 수 있다.
브랜치별 역할이 명확히 구분되어 있어 각 브랜치의 상태에 따라 배포 및 테스트를 진행하기에 용이하다.
- feature 브랜치를 업데이트하면 unit test를 실행
- develop에 merge request 발생 시 integration test와 slack 메시지 발송
- develop 브랜치를 업데이트하면 개발 서버 배포 및 integration test 실행
- release 브랜치 배포 시 relase 서버 배포 및 QA 팀에 메일로 전달
- master 배포 시 실 서버 배포
승인된 개발자만 코드에 접근할 수 있게 해서 안전하게 소스코드를 관리할 수 있다
feature 브랜치를 통해 기능 단위로 독립적인 개발이 가능하다.
- 이때 PR을 활용하여 기능별 히스토리를 관리할 수 있다.
feature 브랜치는 칸반 보드의 티켓과 연동되므로 기능별 추적이 쉽고, 오류 발생 시 특정 기능을 UNDO 시킬 수 있다.
multi thread(배포 버전과 개발 버전 분리)가 가능하다.

Git Flow의 단점

찾아보니 단점으로 아래의 의견도 있었다.

release 브랜치의 활용도가 낮다. (버전별 Tag가 존재하므로)
master 브랜치의 활용도가 낮다. (develop 브랜치가 역할을 대신할 수 있다.)
feature 브랜치 특성상 복수형인 features 네이밍이 적절하다.
브랜치 관리보다 적절한 커밋 단위를 설정하는 게 더 중요하다.

1. Git Flow 생성하기

Git Flow는 Git의 extension 기능이고, 별도 설치가 필요하다.

macOS 사용자는 터미널에서 아래를 입력하면 된다.

$ brew install git  // git을 미설치한 경우에만
$ brew install git-flow-avh

그다음 프로젝트 폴더 위치에서 git flow init을 입력하면 된다. (일반 git을 생성할 때 터미널에서 git init을 했듯이)

그러면 아래처럼 브랜치 이름을 입력하라는 안내가 뜨는데, 그냥 모두 Enter키로 넘기면 된다.

$ git flow init

Which branch should be used for bringing forth production releases?
   - develop
   - master
Branch name for production releases: [master]

Which branch should be used for integration of the "next release"?
   - develop
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [/Users/projects/project1/.git/hooks]

설정이 완료되고 git branch -a를 찍어보면 아래처럼 develop, master가 생성된 게 보인다.

* develop
* master
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/master

2. Git Flow 사용하기

Feature

새로운 feature를 개발할 때

git flow feature start login 을 입력하면 자동으로 develop/feature/login 브랜치를 생성해준다.

해당 feature를 팀원과 협업하여 개발한다면

git flow feature publish login (일반 git처럼 git push를 입력해도 됨)

git flow feature pull origin login (일반 git처럼 git pull를 입력해도 됨)을 입력하여 주고받기하면 된다.

기능 개발이 완료됐다면

git flow feature finish login 을 입력하면 자동으로 login 브랜치를 develop에 merge 시키고, login 브랜치를 삭제한다.

Release / HotFix

브랜치 이름은 release-어쩌구 그리고 hotfix-어쩌구 형태로 네이밍한다.

필요한 상황에 따라 명령어를 찾아 쓰기만 하면 되므로 매우 간단하다.

명령어를 요약해둔 CheatSheet를 추천한다.

구체적인 사례와 팁은 이 링크를 활용하면 된다.

특히 Git 충돌 방지를 위한 팁은 이 링크를 추천한다.

- Reference

Vincent Driessen의 A successful Git branching model
Daniel Kummer의 Git Flow CheatSheet
생활코딩 > Git Flow - 출시와 개발을 동시에 진행하는 방법
GitHub Docs > GIT을 기반으로 한 프로젝트 개발프로세스
Blog - 우아한형제들 기술블로그 > 우린 Git-flow를 사용하고 있어요
Blog - Jin의 Git Flow 사용법 요약 및 팁
Blog - CouchCoding의 충돌 없는 Git을 위해 Git Flow에 대해 알아보자

포스트가 도움이 되었다면, 공감 / 구독 / 공유 / 댓글✏️ 로 응원해주세요. 감사합니다.