Do.

데코라이크(Decorator Like)로 더 유연한 ViewController 구조 만들기

Hey_Hen — Thu, 20 Mar 2025 01:23:58 +0900

데코라이크(Decorator Like)로 더 유연한 ViewController 구조 만들기

Intro

iOS 앱을 개발하다 보면, 공통된 로직(예: 화면 전환 시 네비게이션 바/탭 바 보이기·숨기기, deinit 시점 로그 남기기 등)을 여러 개의 뷰컨트롤러에 반복해서 적용해야 하는 상황이 생깁니다. 이때 종종 가장 먼저 고려되는 방법이 바로 BaseViewController를 만드는 것이죠. BaseViewController에 공통 코드를 모아두고, 모든 뷰컨트롤러에서 이를 상속받으면 편리해 보이지만, 기능이 많아질수록 점점 덩치가 커지고 유지보수가 어려워집니다.

이 글에서는 그러한 문제를 해결하고자 “데코라이크”라는 구조를 소개하려고 합니다.

문제 상황

BaseViewController의 덩치가 커진다
- 네비게이션 바, 탭 바 제어 등 라이프 사이클에 따라 다양한 기능이 추가되다 보면 BaseViewController는 점점 비대해집니다.
- 작은 수정이 발생해도 해당 클래스를 상속하는 모든 자식 뷰컨트롤러에 영향을 미칠 수 있어, 예기치 못한 사이드 이펙트가 발생합니다.
특정 기능만 필요할 때도 전체를 상속받아야 한다
- 예를 들어 “deinit 시점 로그 찍기” 기능만 필요한데도, BaseViewController에 들어있는 다른 로직 전부를 상속받게 됩니다.
- 상속 구조가 점점 복잡해지면서, BaseViewController의 실제 동작을 예측하기 어려워 집니다.

목표

기능을 필요에 따라 선택적으로 부여
- 하단 탭 바 숨기기, 네비게이션 바 숨기기, deinit 로그 처리 등 기능들을 개별적으로 적용할 수 있게 만든다.
ViewController 라이프 사이클 기반의 확장성
- viewDidLoad, viewDidAppear, viewWillDisappear 등 각 라이프 사이클 시점에 맞춰서 동작하는 로직을 쉽게 추가/관리한다.
충분히 가볍고 간단한 구조
- 대규모 상속 트리 없이도 각 기능을 조합해서 자유롭게 사용할 수 있어야 한다.

DefaultViewController와 VCDecorator 등장

DefaultViewController

우선 DefaultViewController라는 기본 뷰컨트롤러를 한 단계 만들어둡니다.
이 컨트롤러에서는 라이프 사이클마다 호출될 콜백 형태의 핸들러를 미리 정의해둡니다. 예시로는 다음과 같습니다.

class DefaultViewController: UIViewController {
    var _viewDidLoad: (() -> Void)?
    var _viewDidAppear: (() -> Void)?
    var _viewWillDisappear: (() -> Void)?
    var _deinitBlock: () -> Void)?
    // ... 등등 필요한 콜백

    override func viewDidLoad() {
        super.viewDidLoad()
        _viewDidLoad?()
    }

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        _viewDidAppear?()
    }

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)
        _viewWillDisappear?()
    }

    deinit {
       deinitBlock?()
    }
}

이렇게 하면, DefaultViewController를 사용하는 쪽에서 각 라이프 사이클마다 실행할 로직을 옵셔널 클로저로 주입할 수 있게 됩니다.
하지만 아직까지는 이 뷰컨 하나만으로는 “옵션별 기능”을 관리하기가 조금 번거롭습니다.

VCDecorator

VCDecorator는 말 그대로 “디자인 패턴의 Decorator”처럼, 뷰컨트롤러에 필요한 기능을 데코레이션(얹어)하는 역할을 합니다. 사용 방법은 다음과 같습니다.

enum VCDecoratorOption {
    case hideTabBar
    case hideNavigationBar
    case logDeinit
    // 필요한 옵션을 자유롭게 추가
}

class VCDecorator {
    static func build(
        target: DefaultViewController,
        options: VCDecoratorOption...
    ) -> DefaultViewController {

        // 옵션별로 target에 필요한 콜백을 셋업
        for option in options {
            switch option {
            case .hideTabBar:
                // viewDidAppear 시점에 tabBar 숨기기
                let originalHandler = target._viewDidAppear
                target._viewDidAppear = {
                    originalHandler?()
                    target.tabBarController?.tabBar.isHidden = true
                }

            case .hideNavigationBar:
                // viewWillAppear 또는 viewDidAppear 시점에 네비게이션 바 숨기기
                // 혹은 viewWillDisappear 등에서 다시 표시
                // 필요 로직을 여기에서 정의
                // (데모라서 간단히 예시만 적음)
                let originalHandler = target._viewDidAppear
                target._viewDidAppear = {
                    originalHandler?()
                    target.navigationController?.setNavigationBarHidden(true, animated: false)
                }

            case .logDeinit:
                // 뷰컨 deinit 시점 로그 남기기
                // DefaultViewController deinit 안에서 처리할 수도 있지만,
                // 만약 동적으로 켜고 끄고 싶다면 별도의 방법으로 처리
                // 예: Weak 래퍼 + deinit 시점 클로저 등
                // 여기선 간단히 예시만 보여줌
                // target.deinitLogger = { print("ViewController deinit!") }
                // 같은 방식으로 구현 가능
                // 필요한 구현부를 만들어두고 연결해주는 식
                break
            }
        }

        return target
    }
}

위의 예시는 단순화된 형태이며, 실제 구현 시에는 DefaultViewController 내 deinit에서 콜백을 호출하게 하거나, 약한 참조(weak)를 사용해 안전하게 로그를 찍도록 할 수 있습니다. 중요한 점은 어떤 옵션이든 손쉽게 추가할 수 있고, 옵션이 많아져도 각각의 로직이 분리된다는 것입니다.

또 위 방식에서는 간단하게 열거형을 사용했지만, 열거형 사용시 option을 주입할 때 코드가 길어지므로 데코레이터 가능한 프로토콜을 정의하고 별개의 Dacorator 구조체를 만드는 것도 방법입니다.

// 1. 일반적으로 DefaultViewController를 하나 생성한다.
let vc = SomeDefaultViewController()

// 2. 필요한 옵션들을 조합해서 VCDecorator.build(...) 호출
let decoratedVC = VCDecorator.build(
    target: vc,
    options: .hideTabBar, .hideNavigationBar
)

// 3. 이제 decoratedVC를 화면에 표시하거나 push, present 하면
//    탭바와 네비게이션 바가 숨겨진 상태로 표시된다.
navigationController?.pushViewController(decoratedVC, animated: true)

이렇게 하면 탭바 숨기기/네비바 숨기기 등의 기능을 BaseViewController 하나로 전부 해결하는 게 아니라, 옵션을 통한 선택적 부여로 정리할 수 있게 됩니다.

장단점

장점

선택적 기능 부여: 필요한 기능만 추가로 얹어갈 수 있으므로, BaseViewController가 비대해지지 않습니다.
확장성: 새로운 공통 기능이 필요할 때, VCDecoratorOption에 case를 추가하고, VCDecorator.build 내부에서 셋업 코드를 구현하기만 하면 됩니다.
Side Effect 최소화: 전부 상속받는 구조가 아니므로, 특정 옵션을 수정해도 다른 ViewController가 영향을 받지 않습니다(해당 옵션을 사용 중이지 않은 이상).

단점

초기 세팅 복잡도: 직접 DefaultViewController를 만들고, 옵션들을 늘려가며 콜백을 주입하는 구조를 잡아야 합니다.
옵션들 간의 충돌 가능성: 두 옵션이 동일한 라이프 사이클 메서드에 서로 상반된 명령을 내릴 수 있다면, 이를 조정하는 로직이 필요해질 수 있습니다(예: .hideTabBar와 .showTabBar가 같은 시점에 동시 적용되는 경우 등).
런타임에 한 번 더 감싸는 비용: 데코라이크 구조를 쓰게 되면, 작은 성능 오버헤드가 있을 수 있으나 대개 무시해도 될 수준이긴 합니다.

마치며

BaseViewController 구조를 무작정 확장하기보다, “장식(Decorator)” 패턴을 적용해 선택적으로 필요한 기능들을 얹어갈 수 있게 만들면, 복잡도가 낮아지고 유지보수가 편리해집니다.

요약하자면, 데코라이크 구조는 ViewController에 필요한 기능을 옵션으로 선언하고, build 과정을 거치며 동적으로 주입함으로써 유연하면서도 읽기 쉬운 구조를 확보할 수 있는 좋은 방법 중 하나라고 생각합니다.

Swift 단위테스트 자동화 xcresult를 junit.xml 변환하기

Hey_Hen — Sun, 10 Sep 2023 17:34:08 +0900

xcresult 파일 생성

우선 junit.xml 포멧으로 변환하기 전에 xcresult 파일을 생성할 필요가 있습니다.

우선 xcresult는 xcode에서 바로 생성되기도 하는데요.

(xcode 14.3 기준) 심플하게 찾는 법은 Report Navigator 테스트 결과에서 Ctrl + click 하면 바로 Show in Finder를 볼 수 있습니다.

CLI

하지만 보통은 테스트 자동화는 CI/CD를 통해서 이루어 지기 때문에 CLI를 통해 test를 돌릴 필요가 있습니다.

xcodebuild -scheme PleaseAttendancePresentationLayer test -destination "platform=iOS Simulator,name=iPhone 14 Pro,OS=16.4" -resultBundlePath "./PresentationlayerTests.xcresult"

저는 PresentationLayer 단일 패키지 테스트 결과를 출력하려고 합니다.

그리고 테스트 결과가 바로 현재 디렉토리로 저장되도록 resultBundlePath를 지정합니다.

요 xcresult파일을 직접 열어보면 압축되어있어서 읽을 수는 없는데요,

xcrun xcresulttool get --format json --path <TESTFILE>.xcresult

위와 같이 xcrun과 xcresulttool(wwdc19에 소개됨)을 이용하면 json 형태로 자세한 내용을 얻을 수는 있지만 junit 형태는 아닙니다.

fastlane의 문서를 보면 xcpretty를 이용해서 junit.xml로 변환할 수 있다고 나오지만 xcpretty는 x86 cpu 기준의 gem 설치를 지원합니다. 빌드 머신의 터미널 설정 괜히 잘못건드리면 피를 볼 수 있으므로 arm architecture를 지원하는 parser 어플을 찾아봤습니다

GitHub - a7ex/xcresultparser: Parse the binary xcresult bundle from Xcode builds and testruns

xcresultparser 라는 프로그램으로 마침 최신 업데이트도 있고, 다양한 포맷팅 결과도 지원하고 있습니다

xcresultparser -o junit PrLayerTests.xcresult > ./junit_test.xml

요렇게 작성해주면

<?xml version="1.0" encoding="UTF-8"?>
<testsuites tests="2" failures="1" time="23.645">
    <testsuite name="PleaseAttendancePresentationLayerTests.xctest" tests="2" failures="1" time="0.027">
        <testcase name="test_리프레시동작시_버스리스트가져오기()" time="0.0013" classname="MyTransportationListViewModelTests"/>
        <testcase name="test_리프레시전에는_버스리스트비어있음()" time="0.025" classname="MyTransportationListViewModelTests">
            <failure message="short">XCTAssertEqual failed: ("[PleaseAttendanceDomainLayer.FavoriteBusItem(uniqueID: "E8379C4B-4692-4456-BB00-E085AC384EA9", id: "1245678", number: "5623", startLocation: "구로디지털단지역", currentLocation: "금천우체국", currentLocation2: "시흥유통센터", remainStation: 1, remainStation2: 2, remainTime: "60", remainTime2: "120", index: 0)]") is not equal to ("[]") (/Users/hoseunglee/Dev/PleaseAttendance/PleaseAttendancePresentationLayer/Tests/PleaseAttendancePresentationLayerTests/MyTransportationListViewModelTests.swift:36)</failure>
        </testcase>
    </testsuite>
</testsuites>

junit.xml과 같은 폼으로 출력되게 됩니다.

배경

xctest 를 굳이 junit으로 변환해야 할 일이 없을거라고 생각했지만, xcresultparser를 찾는 동안 생각보다 연관검색어와 비슷한 프로그램이 많다는 것에 놀랬습니다.

저는 jira에서 zephyr 를 자동으로 생성하기 위한 용도였는데 미리 구성되어 있는 스크립트가 안드로이드 팀의 테스트 결과인 junit에 맞추어져 있었기 때문에 파싱 스크립트를 두벌을 만들지 않기 위해서 변환했습니다.

Thread - Semaphores vs Mutexes

Hey_Hen — Sun, 16 Jul 2023 02:14:35 +0900

소개

두 개념 모두 생호 배제를 목적으로 한다는 것은 동일하나 이전글의 출력문을 봐서 알겠지만 다른 양상을 보입니다. 어떤 차이에 의해서 그러한 현상이 발생할까요? 이번에는 단골 질문 중 하나인 Semaphore와 Mutex의 차이에 대해서 알아보려고 합니다.

Semaphores

우선 Semaphore는 P(wait)와 V(signal)로 이루어 져 있습니다. wait 연산은 Semaphore의 값을 감소시키고, signal은 값을 증가 시킵니다. Semaphore의 값이 0일 때, wait 연산을 수행하는 모든 프로세스는 다른 프로세스가 signal 연산을 수행할 때까지 차단되게 됩니다. 이전글에서 설명했었죠?
즉 Semaphore는 사실 정수와 같습니다. 단순히 숫자를 증가시키냐 감소시키냐 와 같다는 것이죠, 해당 정수를 기반으로 Ciritical Section에서 발생하는 공유 자원에 대한 접근을 관리합니다.
Semaphore는 두가지 타입이 있습니다.

Binary Semaphore
- 기능적으로는 Mutex와 동일하다고 볼 수 있습니다. 0과 1만 존재하기 때문이죠
Counting Semaphore
- 접근에 대한 제한하는 수를 설정 가능합니다.

Mutexes

Swift에서는 NSLock, NSRecursiveLock, NSConditionLock이 존재하는데, 이것들이 Mutex와 완전히 동일한가? 에 대하여 “그렇다” 라고 서술되어 있는 공식 문서를 보지 못해서 확실하지는 않지만, Mutex의 개념인 Lock, Unlock 연산을 똑같이 사용한다는 것입니다.
Semaphore와는 달리 값을 증가 시키고 감소 시키는 개념이 아니라 잠그고, 푸는 로직이기 때문에 두번 잠궜다 한번 풀고 이런 개념이 존재하지 않습니다.

차이

그렇다면 Semaphore와 Mutex의 차이점을 설명할 수 있을 것 같습니다.
결정적으로 Mutex는 Lock을 한 주체가 Unlock을 할 수 있다는 부분입니다. 화장실 문잠그고 들어간 사람이 직접 문을 열고 나오는 것과 같죠, 직관적이고 쉽죠? 하지만 잘못 사용하게 되면 크리티컬 섹션에 진입 후 스레드가 쉬는 상태이거나, 다른 우선 순위가 높은 작업이 있는데 앞서 스레드로 인해 섹션이 잠기는 바람에 작업자체가 중단될 수 있고, CPU 주기가 낭비될 수 있습니다.
반면에 Semaphore는 여러 스레드가 동시에 크리티컬 섹션에 액세스 할 수 있도록 해줍니다. 이로 인해 훨씬 더 유연하게 Thread Safe 환경을 만들 수 있습니다.
하지만 Semaphore는 우선순위 역전이 있습니다. 스케줄링에 의해 언제든지 다른 스레드가 와서 자기 할일 하고 나갈 수 있다는 것이죠, 이 때문에 동시적인 작업 수행이 더 도드라져 보입니다.

또 Semaphore는 여러 스레드에서 접근이 가능하기 때문에 Deadlock이 발생할 수도 있습니다. 주의해서 관리할 필요가 있죠. (사실 별 이상한 방법으로 사용하지 않는이상…)
그러면 Binary Semaphore는 Mutex와 완전히 동일합니까? 라고 했을 때는 어떨까요?
Binary Semaphore라고 해도 여전히 wait과 signal을 다른 스레드에서 수행할 수 있기 때문에 잘못 사용한다면 Dead Lock, Priority Inversion은 여전히 발생할 수 있습니다.

결론

Binary Semaphore보다는 Mutex를 선택하는 것이 더 옳은 선택처럼 보일 수도 있습니다. 그러나 반대로 잘 관리하고 사용만 할 수 있다면 Mutex의 단점을 보완할 수 있는 방법이기 때문에 결론은 적재적소에 잘 사용할 수 있도록 둘간의 차이점을 이해하는것이 중요할 것 같습니다.

# Reference
https://www.geeksforgeeks.org/difference-between-binary-semaphore-and-mutex/

Difference between Binary Semaphore and Mutex - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

https://en.wikipedia.org/wiki/Lock_(computer_science)

Lock (computer science) - Wikipedia

From Wikipedia, the free encyclopedia Synchronization mechanism for enforcing limits on access to a resource In computer science, a lock or mutex (from mutual exclusion) is a synchronization primitive: a mechanism that enforces limits on access to a resour

en.wikipedia.org

https://en.wikipedia.org/wiki/Semaphore_(programming)

Race Condition / Thread Safe

Hey_Hen — Mon, 26 Jun 2023 23:31:14 +0900

Race Condition

레이스 컨디션이란 동시에 여러 스레드 또는 프로세스에서 공유 자원에 접근하고 수정하는 상황에서 발생하는 문제를 말합니다. 특별히 신경쓰지 않으면 멀티스레드 환경에서 반드시 발생할 수 있는 것이죠.
흔히 발생하는 현상으로는 결과값이 예상과는 다르게 나오거나 잘못된 순서로 데이터가 적재됩니다. 메모리를 다루는 경우에는 BAC_ACCESS와 함께 앱 크래시가 발생할 수 있는 위험한 경우입니다!
어떤 상황에서 레이스 컨디션이 발생하는지 알아보겠습니다.

Example

let concurrentQueue = DispatchQueue(label: "com.queue", attributes: .concurrent)
var sharedResource = 0
  func test_task() throws {
    for i in 1...100 {
      concurrentQueue.async {
        self.append(pass: i)
      }
    }
  }

private func append(pass: Int) {
  sharedResource += pass
  if pass == 100 {
    print(sharedResource)
  }
}

앞에서 설명한 것 처럼 레이스 컨디션은 멀티스레드 환경에서 발생합니다.
sharedResource가 있고 이를 append라는 메서드에서 접근하고 있죠, 전달받은 pass값을 sharedResource에 더하는 로직입니다.

이미 아시겠지만 만약 1 부터 100까지 모두 더한다면 100번째에는 5050이라는 값이 출력될것입니다! 하지만 test_task 에서는 append 메서드를 비동기로 호출하고 있습니다. 심지어 concurrentQueue이기 때문에 append 메서드는 수많은 스레드에서 실행될 예정입니다.
즉 위와같은 코드는 순차적으로 발생하지 않기 때문에 우리가 원하는 결과를 얻을 수 없습니다. 동시다발적으로 스케줄링이 이루어졌고 가장 먼저 작업이 수행되는게 pass 100부터 라서 1만 출력되고 아무것도 안나올 수도 있죠.
작업이 동시적으로 발생하기 때문에 이러한 경우는 레이스 컨디션 보다는 동시적 작업의 결과입니다.
예제를 조금 바꿔 보겠습니다.

let concurrentQueue = DispatchQueue(label: "com.queue", attributes: .concurrent)
var sharedResource: [Int] = []
  func test_task() throws {
    for i in 1...100 {
      concurrentQueue.async {
        self.append(pass: i)
      }
    }
  }

private func append(pass: Int) {
  sharedResource.append(pass)
}

전체를 다 보실 필요는 없습니다. sharedResource가 Int 에서 Array로 바뀐 것만 주목하시면 됩니다.
이제는 단순히 값을 더하는 것이 아니라 배열에 값을 추가하는 형태가 되었네요! 이 경우 가장 치명적인 케이스가 발생할 수 있습니다.

BAD_ACCESS가 발생했는데 이외에도 똑같은 코드에서 Out_Of_Range나 SIGABRT가 발생할 수도 있습니다.
이러한 문제가 왜 발생할까요? 이는 Swift가 Array의 용량을 확장하는 방법과 연관이 있습니다. 하지만 오늘 주제에서 다룰 내용은 아니죠!
중요한 점은 레이스 컨디션으로 인한 문제가 앱 강제종료 라는 크리티컬한 상황으로 이어질 수 있다는 것입니다.

예방하기

레이스 컨디션을 예방하는 방법에는 무엇이 있을까요?

Singleton Class 자제하기

레이스 컨디션이 발생하는 데에는 두가지 필수 조건이 있습니다. 첫번째는 멀티스레드 환경이어야 하고 두번째는 공유된 자원에 여러 곳에서 접근하는 환경 이어야 한다는 것입니다. 엄밀히 말하면 여러 스레드에서 하나의 공유된 자원에 접근하는 것이지만 iOS 환경은 기본적으로 멀티스레드 환경이기 여러곳 이라는 것은 여러 스레드와 동일할 수 있죠.
이러한 공유된 자원에 접근하는 것중 가장 흔한 케이스가 바로 싱글톤 클래스입니다. 싱글톤 클래스는 App State나 User State등 앱 전반에 걸쳐 상태를 관리하는 데에 아주 유용한 디자인 패턴이지만 레이스 컨디션이 발생하기 쉬운 위치에 노출되어 있습니다. 만약 싱글톤을 써야 한다는 각별히 주의해야 합니다.

Concurreny 자제하기

레이스 컨디션이 발생하는 대부분의 경우는 Concurrent한 작업 때문입니다. 특별히 작업이 아니라면 오히려 대부분의 작업은 작업 순서가 중요한 경우가 많은데요. 일반적인 경우는 Serial 작업으로 진행하는 것이 좋습니다.

Thread safe

각별한 주의에도 어쟀든 레이스 컨디션이 발생하는 상황을 어찌할 수는 없습니다. Singleton Class을 꼭 써야 할 수도 있고, Concurreny 작업 스케줄링이 필요할 수도 있죠, 이런 경우 레이스 컨디션이 발생하지 않도록 Thread safe 환경을 만들어야 합니다. 애플에서는 Thread safe 환경을 위한 다수의 편리한 API를 제공합니다.

Grand Central Dispatch

이하 GCD는 queue 기반의 멀티스레드 / 병럴처리 작업 API입니다. 우리가 흔히 사용하는 DispatchQueue가 바로 그것이죠.
DispatchQueue를 이용해서 레이스 컨디션을 해결하는 법은 매우 쉽습니다.

let concurrentQueue = DispatchQueue(label: "com.queue", attributes: .concurrent)
let serialQueue = DispatchQueue(label: "com.queue.serial")
var sharedResource: [Int] = []
  func test_task() throws {
    for i in 1...100 {
      concurrentQueue.async {
        self.append(pass: i)
      }
    }
  }

private func append(pass: Int) {
  serialQueue.async { [unowned self] in
    sharedResource.append(pass)
  }
}

주목할 부분은 새롭게 추가된 serialQueue입니다. DispatchQueue는 별도의 attributes를 지정하지 않으면 serial이 기본 설정입니다.
이 경우 append(pass:) 메서드는 동시적으로 발생하지만 이후 작업은 serialQueue에서 순차적으로 진행되기 때문에 sharedResource에 접근에서 발생하는 레이스 컨디션은 사라집니다. 쉽죠?

DispatchSemaphore

세마포어도 GCD의 기능 중 일부입니다. DispatchQueue는 동시적으로 공유 자원에 접근하려는 것을 직렬로 순서대로 접근하도록 만들었습니다. 반면 세마포어는 스레드간의 상호작용을 제어하는데요,

let semaphore = DispatchSemaphore(value: 1)

세마포어를 생성할때 value를 할당하는데 이 값은 semaphore가 통제할 스레드의 수 입니다.
세마포어는 wait()와 signal() 한쌍의 메서드로 이루어지는데, wait는 값을 감소시키고 signal은 값을 증가시킵니다.
wait로 값이 감소해서 0보다 작아지면 해당 작업 블럭은 대기 상태에 들어갑니다. signal이 나올때 까지요,
좀더 자세히 알아보기 위해 출력문을 좀 활용해봤습니다.

private func append(pass: Int) {
  print("start! \(#function) \(pass)")
  semaphore.wait()
  print("stop! \(#function) \(pass)")
  sharedResource.append(pass)
  print("task done! \(#function) \(pass)")
  semaphore.signal()
  print("let! \(#function) \(pass)")
}

위와 같이 작성했을 때 콘솔 로그를 보면 아래와 같습니다.

start! append(pass:) 1
start! append(pass:) 2
stop! append(pass:) 1
start! append(pass:) 4
task done! append(pass:) 1
let! append(pass:) 1
stop! append(pass:) 2
task done! append(pass:) 2
start! append(pass:) 6
let! append(pass:) 2
start! append(pass:) 8
start! append(pass:) 5
stop! append(pass:) 4
task done! append(pass:) 4
start! append(pass:) 7

pass가 1번이 들어왔을 때 작업이 끝나기도 전에 pass 2가 들어왔군요!
하지만 이때 세마포어 먼저 들어온 pass 1번에서 세마포어 wait이 먼저 발동됩니다.
그 다음 pass 4도 들어왔네요 하지만 그 각 pass에서 작업 진행사항은 pass 1번 밖에 없네요!
pass 1번만 유일하게 작업을 끝낸다음 세마포어 signal을 보냈더니 let 이 출력 됐습니다.
그 이후엔 pass 1 다음으로 start한 pass 2에서 wait이 걸렸네요.
메서드는 동시에 호출 됐지만 세마포어 signal이 나올 때 까지 다른 작업 블록을 정지 시켜 버립니다. 세마포어는 이러한 방식으로 Thread-safe 하도록 만듭니다!

NSRecursiveLock

NSRecursiveLock은 Objective-C 에서 지원하던 레거시 방법입니다. 사용법은 세마포어와 다르지 않지만 결과 양상이 조금! 다릅니다.

let lock = NSRecursiveLock()

과 같이 선언 한 뒤

private func append(pass: Int) {
  print("start! \(#function) \(pass)")
  lock.lock()
  print("stop! \(#function) \(pass)")
  sharedResource.append(pass)
  print("task done! \(#function) \(pass)")
  lock.unlock()
  print("let! \(#function) \(pass)")
}

세마포어와 똑같죠? 그럼 출력 결과는 어떨까요?

start! append(pass:) 1
stop! append(pass:) 1
task done! append(pass:) 1
let! append(pass:) 1
start! append(pass:) 4
stop! append(pass:) 4
task done! append(pass:) 4
let! append(pass:) 4
start! append(pass:) 5
stop! append(pass:) 5
task done! append(pass:) 5
let! append(pass:) 5
start! append(pass:) 6
stop! append(pass:) 6
task done! append(pass:) 6
let! append(pass:) 6
start! append(pass:) 7
stop! append(pass:) 7
task done! append(pass:) 7
let! append(pass:) 7
start! append(pass:) 10
stop! append(pass:) 10
task done! append(pass:) 10
let! append(pass:) 10

unlock을 할때 까지 작업이 뭔가 되게 순차적이지만, 사실 이건 출력문의 일부분일 뿐입니다.
전체를 놓고 보면 세마포어와 다를 바 없지만 내부적으로 조금 다른 로직으로 굴러간다는 것 정도는 알 수 있겠네요

Advanced

사실 일일이 스레드 세이프한 코드를 작성해주기는 너무나 귀찮고 까먹기 쉬운 일입니다. 좀더 편한 방법을 찾아보자면 간단한 방법이 존재하는데요!
바로 값 자체를 스레드 세이프 하게 만들어 주는 것, Swift의 위대한 property wrapper가 있습니다.

@propertyWrapper
final class Atomic<T>: NSLock {
  var wrappedValue: T {
    get {
      lock()
      defer { unlock() }
      return value
    }

    _modify {
        lock()
        var tmp: T = value

        defer {
            value = tmp
            unlock()
        }

        yield &tmp
    }
  }
  private var value: T

  init(wrappedValue: T) {
    self.value = wrappedValue
  }
}

쫘란~

Conclusion

사실 우리에겐 이런것보다 더 강력하고 모던한 swift concurrency와 함께 도입된 actor가 있습니다.
swift concurrency 공부하세요!

WWDC23 - What's new in swift

Hey_Hen — Wed, 7 Jun 2023 16:47:56 +0900

What’s new in swift

“pack”

기존에는 타입추론을 통해서 이러한 동작이 가능했습니다.

struct Request<Result> { ... }

struct RequestEvaluator {
    func evaluate<Result>(_ request: Request<Result>) -> Result
}

func evaluate(_ request: Request<Bool>) -> Bool {
    return RequestEvaluator().evaluate(request)
}

Result가 Boolean 이라서 Boolean으로 값이 출력됩니다.

만약 여러 Boolean 결과를 얻고 싶다면

let value = RequestEvaluator().evaluate(request)

let (x, y) = RequestEvaluator().evaluate(r1, r2)

let (x, y, z) = RequestEvaluator().evaluate(r1, r2, r3)

Method Overloads 패턴으로 아래와 같이 작성해줄 수 있습니다.

func evaluate<Result>(_:) -> (Result)

func evaluate<R1, R2>(_:_:) -> (R1, R2)

func evaluate<R1, R2, R3>(_:_:_:) -> (R1, R2, R3)

func evaluate<R1, R2, R3, R4>(_:_:_:_:)-> (R1, R2, R3, R4)

func evaluate<R1, R2, R3, R4, R5>(_:_:_:_:_:) -> (R1, R2, R3, R4, R5)

func evaluate<R1, R2, R3, R4, R5, R6>(_:_:_:_:_:_:) -> (R1, R2, R3, R4, R5, R6)

하지만 반복적으로 overload 하는 방법은 한계가있습니다. 만약 3개까지의 오버로드만 했다면 3개까지의 결과만 얻을 수 있죠

Swift5.9에서 제네릭 시스템은 인수 길이에 대한 추상화를 가능하게 합니다. 여러개의 별개의 파라미터를 함께 "Packed"할 수 있죠, 이 새로운 컨셉을 "Pack"이라고 부릅니다.

위에서 작성했던 메서드를 아래와 같이 each 키워드로 쓰게 되면

func evaluate<each Result>(_: repeat Request<each Result>) -> (repeat each Result)

하나의 메서드만으로 오버로딩으로 작성한 모든 코드를 커버할 수 있게됩니다.

let results = RequestEvaluator.evaluate(r1, r2, r3)

swift macros

Swift Macro는 다른 언어(C,C++)에서 존재하던 그 매크로를 그대로 가져온 것으로 컴파일 타임에 지정된 매크로 코드 블럭으로 풀어서 빌드됩니다.

assert(max(a, b) == c)

예를 들어 위와 같이 기존의 assert 코드는 조건이 실패하면 앱이 중단됩니다. 하지만 구체적으로 무엇이 문제였는지 알 수 없죠. 아래처럼 단지 실패했다고만 출력됩니다.

반면 우리가 테스트에 사용하는 XCAssertEqual은 좀더 나은 결과를 보여줍니다.

하지만 여전히 a는 뭐였고 또 b는 무엇인지 그리고 c는 무엇인지 아무것도 알 수 없습니다.

요지는 우리가 무언가 실패했을 때 로그에서 더 많은 정보를 얻길 바란다는 것입니다.

swift 5.9 이전까지는 특별히 만든 기능 없이는 이 요구사항을 충족할 수 없습니다. 매크로 없이는요!

해당 예제에서는 “hash-assert”라고 불리는 문법을 사용하고 있습니다. 기존 assert문법 앞에 #을 붙이는게 다죠

그 결과 우리는 아주 세부적인 결과를 얻을 수 있습니다. “hash-assert”는 PowerAssert 패키지안에 내장되어 있습니다.

PowerAssert는 오픈소스로 Github에서 찾을 수 있습니다.

내부 코드를 보면 “hash assert”는 하나의 함수인데요

public macro assert(_ condition: Bool)

위 사진은 대부분의 매크로가 #externalMacro를 사용하고 있고 Swift Complier와 Complier Plugin끼리 어떻게 동작하는지 보여주고 있습니다.

Freestanding macro roles

asset macro는 freestanding expression 매크로의 일종입니다.

freestanding 라고 부르는 이유가 “hash” 문법을 통해 매크로 문법을 사용하기 때문에 그렇다고 합니다!

@freestanding(expression)
public macro assert(_ condition: Bool) = #externalMacro(
    module: “PowerAssertPlugin”,
    type: “PowerAssertMacro"
)

freestanding의 또다른 좋은 예제는 SwiftUI와 SwiftData에서 사용 가능한

let pred = #Predicate<Person> {
    $0.favoriteColor == .blue
}

let blueLovers = people.filter(pred)

위 freestanding 매크로는 제네릭 인풋으로 결과를 생성하는 코드입니다.

// Predicate expression macro

@freestanding(expression) 
public macro Predicate<each Input>(
    _ body: (repeat each Input) -> Bool
) -> Predicate<repeat each Input>

Reduce Boilerplate

매크로는 또한 수많은 보일러 플레이트를 줄이는데 도움이 됩니다.

예를들어 아래와 같은 연관값이 있는 열거형의 경우

enum Path {
    case relative(String)
    case absolute(String)
}

열거형의 케이스 필터링이 필요할 때 아래와 같이 쓰고 싶을 수 있습니다.

이를 위해서는 열거형의 computed property를 생성해야 합니다.

let absPaths = paths.filter { $0.isAbsolute }

extension Path {
    var isAbsolute: Bool {
        if case .absolute = self { true }
        else { false }
    }
}

간단한 코드지만 케이스가 많아질 수록 보일러 플레이트가 증가하게 되는 구조입니다.

Swift Macro는 아래와 같은 문법으로 보일러 플레이트를 줄여줍니다.

@CaseDetection
enum Path {
    case relative(String)
    case absolute(String)
}

let absPaths = paths.filter { $0.isAbsolute }

@CaseDetection propertyWrapper 매크로를 사용하게 되면 깔끔하게 해결되죠

CaseDetection의 경우는 member에 해당되는 attached입니다.

Observation in SwiftUI

final class Person: ObservableObject {
    @Published var name: String
    @Published var age: Int
    @Published var isFavorite: Bool
}

struct ContentView: View {
    @ObservedObject var person: Person

    var body: some View {
        Text("Hello, \(person.name)")
    }
}

SwiftUI에서 Class타입의 변경을 감지하기 위해 ObservableObject를 채용하고 방출이 필요한 이벤트를 Published Wrapper로 감쌉니다. 하지만 속성이 늘어나면 이 또한 보일러 플레이트이죠

이 또한 Swift5.9 에서 지정된 매크로를 통해 아래와 같이 쓸 수 있습니다.

@Observable final class Person {
    var name: String
    var age: Int
    var isFavorite: Bool
}

struct ContentView: View {
    var person: Person

    var body: some View {
        Text("Hello, \(person.name)")
    }
}

ObservableObject 프로토콜도 쓸 필요 없고 속성마다 Published를 선언할 필요도 없죠

Observable은 아래와 같은 3가지 매크로 기능을 사용한 것입니다.

@attached(member, names: ...)
@attached(memberAttribute)
@attached(conformance)
public macro Observable() = #externalMacro(...).

실제로는 매크로를 통해 아래와 같은 코드가 완성됩니다.

@Observable final class Person {
    @ObservationTracked var name: String { get { … } set { … } }
    @ObservationTracked var age: Int { get { … } set { … } }
    @ObservationTracked var isFavorite: Bool { get { … } set { … } }

        internal let _$observationRegistrar = ObservationRegistrar<Person>()
    internal func access<Member>(
        keyPath: KeyPath<Person, Member>
    ) {
        _$observationRegistrar.access(self, keyPath: keyPath)
    }
    internal func withMutation<Member, T>(
        keyPath: KeyPath<Person, Member>,
        _ mutation: () throws -> T
    ) rethrows -> T {
        try _$observationRegistrar.withMutation(of: self, keyPath: keyPath, mutation)
    }
}

Foundation performance improve

calendar calculations: 20% faster

date formatting: 150% faster

json coding: 200-500% faster

swift copyable

example 1

struct FileDescriptor {
  private var fd: CInt

  init(descriptor: CInt) { self.fd = descriptor }

  func write(buffer: [UInt8]) throws {
    let written = buffer.withUnsafeBufferPointer {
      Darwin.write(fd, $0.baseAddress, $0.count)
    }
    // ...
  }

  func close() {
    Darwin.close(fd)
  }
}

FileDescriptor는 파일을 열고 쓰는 모델인데 실수의 여지가 있다.

작업이 끝난 이후에 명시적으로 close를 호출해야 하는데 코드를 누락할 확률이 있음

그래서 다음과 같이 수정할 수 있는데

example 2

class FileDescriptor {
  private var fd: CInt

  init(descriptor: CInt) { self.fd = descriptor }

  func write(buffer: [UInt8]) throws {
    let written = buffer.withUnsafeBufferPointer {
      Darwin.write(fd, $0.baseAddress, $0.count)
    }
    // ...
  }

  func close() {
    Darwin.close(fd)
  }

  deinit {
    close()
  }
}

클래스로 변경 후 메모리에서 해제되는 시점에 close를 호출하는 방법이 있다. 하지만 클래스로 변경되면서 발생하는 여러 오버헤드가 있음!

Copyable은 구조체에서도 클래스 처럼 deinit 호출이 가능하도록 함

struct FileDescriptor: ~Copyable {
  private var fd: CInt

  init(descriptor: CInt) { self.fd = descriptor }

  func write(buffer: [UInt8]) throws {
    let written = buffer.withUnsafeBufferPointer {
      Darwin.write(fd, $0.baseAddress, $0.count)
    }
    // ...
  }

  func close() {
    Darwin.close(fd)
  }

  deinit {
    Darwin.close(fd)
  }
}

또 다른 방법은 호출 시점에 강제하는 것인데

메서드에 consuming이라는 코드를 부착합니다.

  consuming func close() {
    Darwin.close(fd)
  }

이렇게 되면 호출할 때 호출 순서를 강제할 수 있습니다.

let file = FileDescriptor(fd: descriptor)
file.write(buffer: data)
file.close()

위 코드는 정상일 때의 예제이고 아무 문제가 발생하지 않습니다.

let file = FileDescriptor(fd: descriptor)
file.close() // Compiler will indicate where the consuming use is
file.write(buffer: data) // Compiler error: 'file' used after consuming

write전에 close를 쓰게 되면 컴파일 에러가 발생하게 됩니다.

Using C++ from swift / C++ interop

swift에서 c++를 다이렉트로 쓸 수 있는 방법이 새로 들어왔습니다.

// Person.h
struct Person {
  Person(const Person &);
  Person(Person &&);
  Person &operator=(const Person &);
  Person &operator=(Person &&);
  ~Person();

  std::string name;
  unsigned getAge() const;
};
std::vector<Person> everyone();

// Client.swift
func greetAdults() {
  for person in everyone().filter { $0.getAge() >= 18 } {
    print("Hello, \\(person.name)!")
  }
}

swift 컴파일러는 기본적으로 c++ 언어를 대다수 이해합니다. 예를들면 위 코드에서처럼 move constructors, assignment operators, destructor 등을 사용할 수 있고 vector나 map을 사용할 수 있습니다.

Using Swift from C++

반대로 C++ 에서도 Swift코드를 호출할 수 있습니다.

// Geometry.swift
struct LabeledPoint {
  var x = 0.0, y = 0.0
  var label: String = “origin”
  mutating func moveBy(x deltaX: Double, y deltaY: Double) { … }
  var magnitude: Double { … }
}

// C++ client
#include <Geometry-Swift.h>

void test() {
  Point origin = Point()
  Point unit = Point::init(1.0, 1.0, “unit”)
  unit.moveBy(2, -2)
  std::cout << unit.label << “ moved to “ << unit.magnitude() << std::endl;
}

추가로 Objective-C처럼 objc attribute를 추가할 필요도 없으며, 별도의 브리징 오버헤드 없이 Swift 타입의 모든 프로퍼티들, 메서드들, 생성자를 추가할 수 있습니다.

FoundationDB

FoundationDB는 분산 Database로 확장 가능한 거대한 key-value 솔루션입니다. macOS, Linux, Windows 환경을 지원하죠

C++로 작성된 오픈 소스이며 뭔 내용인지 잘 모르겠으므로 생략합니다. ㅎ

RxSwift - MainScheduler.instance vs MainScheduler.asyncInstance

Hey_Hen — Fri, 2 Jun 2023 14:18:46 +0900

개요

RxSwift를 사용하게 되면 View Layer에서 사용하게 될 때는 꼭 메인 스레드로 변경하도록 코드를 지정해줘야 합니다.

이때 일반적으로 저희가 사용하는 코드는

MainScheduler.instance 와 MainScheduler.asyncInstance 가 있는데, 이 둘은 근본적으로 무슨 차이가 있을까요?

우선 RxSwift 문서에 의하면 다음과 같이 설명하고 있습니다.

요약하자면 메인 큐에 작업 스케줄이 이미 된 코드라면 별도의 스케줄링 없이 바로 동작한다고 적혀있습니다.

무슨 뜻인지 좀더 확실하게 알아볼까요?

override func scheduleInternal<StateType>(_ state: StateType, action: @escaping (StateType) -> Disposable) -> Disposable {
  let previousNumberEnqueued = increment(self.numberEnqueued)

  if DispatchQueue.isMain && previousNumberEnqueued == 0 {
    let disposable = action(state)
    decrement(self.numberEnqueued)
    return disposable
  }

  let cancel = SingleAssignmentDisposable()

  self.mainQueue.async {
    if !cancel.isDisposed {
      cancel.setDisposable(action(state))
    }

    decrement(self.numberEnqueued)
  }

  return cancel
}

RxSwift에서 스캐줄링을 하게 되면 위 메서드가 실행되는데요, 조건을 보시면 아시겠지만 만약 이미 Main Queue이거나, Rx에서 자체적으로 관리하는 스케줄 number가 0이라면 별도의 스케줄링 없이 동기 코드로 즉시 실행하게 됩니다.

반면 Main Queue가 아니거나 Rx의 작업스케줄이 아직 남아있는 상태라면 main queue에 적재해서 비동기로 실행하게 됩니다.

이걸 Rx에서는 최적화라고 표현하고 있는 것이죠 즉 MainScheduler.instance는 MainScheduler의 싱글톤 인스턴스이고, Upstream의 스케줄에 따라 비동기 일 수도 있고 아닐 수도 있습니다.

MainScheduler.asyncInstance

그러면 MainScheduler.asyncInstance는 무엇일까요? MainScheduler 클래스 안에는 Instance 싱글톤 객체 말고도 asyncInstance도 있습니다.

public static let asyncInstance = SerialDispatchQueueScheduler(serialQueue: DispatchQueue.main)

그리고 asyncInstance는 SerialDisatchQueueScheduler라고 합니다.

다시 MainScheduler.Instance 코드를 유심히 보다보면 override func scheduleInternal 는 이미 override 된 함수라는 것을 알 수 있죠.

또 사실 MainScheduler라는 것은 SerialDispatcherQueueScheduler의 서브클래스라는 것도 알 수 있습니다.

그렇다면 SerialDispatchQueueScheduler의 scheduleInternal 본연의 동작은 어떻게 될까요? 타고타고 들어가면 아래 코드가 나옵니다.

func schedule<StateType>(_ state: StateType, action: @escaping (StateType) -> Disposable) -> Disposable {
  let cancel = SingleAssignmentDisposable()

  self.queue.async {
    if cancel.isDisposed {
      return
    }


    cancel.setDisposable(action(state))
  }

  return cancel
}

무조건 async 로 동작하게 됩니다. 그리고 저 queue는 앞서 asyncInstance를 생성할 때 전달한 DispatchQueue.main이죠, 즉 MainScheduler.asyncInstance는 무조건 비동기로 동작하게 됩니다.

결론은 뭐가 다른데?

넵 사실 큰 차이 없습니다. asyncInstance나 Instance나 동일한 Serial Queue이고 작업이 메인 스레드에서 동작할 수 있도록 보장해 줍니다.

다만 Instance의 경우는 그러할 필요가 없다면 Main Queue로 스케줄링 하지 않고 바로 실행한다는 부분이죠.

그래서 만약 MainScheduler.Instance가 잘 동작한다면 최적화 되고 좋은 동작 일 것입니다.

위 코드는 작업은 스케줄링 했을 때와 그렇지 않을 때 코드가 실행된 속도입니다. async가 훨씬 느리죠? RxSwift는 이 부분을 최적화 했다고 볼 수 있습니다.

But?

하지만 이는 RxSwift의 자체 스케줄러가 잘 동작했을 때 문제입니다. 만약 MainScheduler.Instance가 잘 동작한다면 MainScheduler.asyncInstance는 필요없을 겁니다. 따로 있는 이유가 무엇일까요?

func register(synchronizationErrorMessage: SynchronizationErrorMessages) {
  self.lock.lock(); defer { self.lock.unlock() }
  let pointer = Unmanaged.passUnretained(Thread.current).toOpaque()
  let count = (self.threads[pointer] ?? 0) + 1

  if count > 1 {
    self.synchronizationError(
      "⚠️ Reentrancy anomaly was detected.\n" +
      "  > Debugging: To debug this issue you can set a breakpoint in \(#file):\(#line) and observe the call stack.\n" +
      "  > Problem: This behavior is breaking the observable sequence grammar. `next (error | completed)?`\n" +
      "    This behavior breaks the grammar because there is overlapping between sequence events.\n" +
      "    Observable sequence is trying to send an event before sending of previous event has finished.\n" +
      "  > Interpretation: This could mean that there is some kind of unexpected cyclic dependency in your code,\n" +
      "    or that the system is not behaving in the expected way.\n" +
      "  > Remedy: If this is the expected behavior this message can be suppressed by adding `.observe(on:MainScheduler.asyncInstance)`\n" +
      "    or by enqueuing sequence events in some other way.\n"
    )
  }

  self.threads[pointer] = count

  if self.threads.count > 1 {
    self.synchronizationError(
      "⚠️ Synchronization anomaly was detected.\n" +
      "  > Debugging: To debug this issue you can set a breakpoint in \(#file):\(#line) and observe the call stack.\n" +
      "  > Problem: This behavior is breaking the observable sequence grammar. `next (error | completed)?`\n" +
      "    This behavior breaks the grammar because there is overlapping between sequence events.\n" +
      "    Observable sequence is trying to send an event before sending of previous event has finished.\n" +
      "  > Interpretation: " + synchronizationErrorMessage.rawValue +
      "  > Remedy: If this is the expected behavior this message can be suppressed by adding `.observe(on:MainScheduler.asyncInstance)`\n" +
      "    or by synchronizing sequence events in some other way.\n"
    )
  }
}

당연히 필요하기 때문이죠? 방출 이벤트가 너무 많아 복잡해지면 Rx의 자체적인 스캐줄링이 깨지게 되는데, 이때 asyncInstance를 사용해 달라고 경고문이 발생하게 됩니다.

이러한 문제는 얘기치 못한 결과를 낼 수 있고 이미 QA에서 테스트 중일때는 감지하기가 어렵습니다.

즉 개발자가 사전에 이를 알고 Instance를 선택할지 async Instance를 선택할지 판단하기 어렵다는 뜻입니다. 그리고 만약 Upstream의 작업 스케줄링을 잘했다면 대부분은 Main Thread가 아닐 것이기 때문에 Instance 동작을 하더라도 사실 꽤 많은 동작이 DispatchQueue.main.async로 스케줄링 된다는 뜻입니다.

MainScheduler.Instance를 호출했을 때 async 블럭을 타는지 바로 실행하는지 결과 출력

다시말해서 간단한 경우는 MainScheduler.Instance를 사용할 수 있지만 복잡한 경우는 asyncInstance를 채용하는 것이 안전한 것이죠.

결론은

Combine 쓰세요(찡긋)

@mint

iOS 개발자 부트캠프 - SeSAC(청년취업사관학교)

Hey_Hen — Wed, 3 May 2023 21:58:00 +0900

소개

개발자로 취업한지 벌써 1년이 훌쩍 지났습니다. 아직까지도 그리고 앞으로도 세상에서 가장 잘한 선택인 것은 개발자로 이직을 했다는 것입니다. 여전히 일하는게 즐겁고 또 내일이 기대되는 나날이네요.

요즘은 비전공자들을 교육 시켜서 개발자로 취업시켜주는 좋은 교육과정이 정말 많은데 저는 딱 한군데 후회하지 않을 곳을 소개시켜드리고 싶습니다.

바로 청년취업사관학교(SeSAC)의 (영등포 SW과정) iOS 앱 개발자 데뷔 과정 PLUS 입니다!
다른 좋은 교육과정보다 더 좋은곳이라고 소개하는 데에는 합당한 이유가 있어야 겠죠?

물론 제가 해당 교육과정을 통해서 취업을 할 수 있었다는 부분이 가장 크지만 그럴 수 있었던 배경에는 무엇이 있을까 생각해보면

iOS 앱 개발자 데뷔 과정 PLUS의 특장점!

진심으로 수강생이 잘 되길 바라는 마음에서 적극 지원해주는 멘토님들
아무 회사나 취업해서 단순 취업률을 늘리는 것이 목표가 아닌 내가 할 수 있는 최고의 선택할 할 수 있도록 실시하는 교육과 지도

위 두가지가 가장 컸던 것 같습니다.

6개월 동안 매일 밤새도록 공부하다 보면 힘든 나날이 평생 지속될 것 같고 취업을 못하는 거 아닌 가 라는 불안감이 들 수 있는데 그럴때 마다 할 수 있다고, 충분히 잘 하고 있다고 응원해주시는 멘토님들이 아니었으면 취업하기 어려웠을 것 같다고 생각합니다!

이외 커리큘럼이나 해당 교육과정을 통해서 얻을 수 있는 포트폴리오는 여러분이 취업할 때 필요한 수준 그 이상인 것은 당연하다고 생각하고 무엇보다 청년취업사관학교라는 정부사업? 을 통해서 진행되기 때문에 실제로 투자하는 돈은 개발에 필요한 맥북과 수료 후 돌려받는 예치금 20만원이 전부(수료 후 돌려 받을 수 있습니다.)! 한마디로 무료라는 것이죠!

신청 자격

신청 자격에 대해서도 궁금하실 것 같은데요! 일부 교육과정의 경우에는 애초에 교육과정을 듣지 않아도 취업할 수 있을 만한 스펙을 모집하고는 합니다. 하지만 청년취업사관학교의 iOS 앱 개발자 데뷔 과정 PLUS 는 단지 서울 시민이여야 한다는 것이 유일한 조건! 모집 공고에도 나와있지만 필요한 것은 학습에 대한 열정과 취업하겠다는 의지 중요하게 보니 프로그래밍에 대한 기초지식이 없더라도 충분히 도전해보는것을 추천합니다.

Swift - RxSwift의 withUnretained를 Combine에서도 쓰기

Hey_Hen — Tue, 2 May 2023 14:48:27 +0900

개요

RxSwift나 Combine 등에서 subscribe에서 escaping closure를 다룰 시 필연적으로 캡처 리스트를 통해 약한 참조를 해야할 때가 있습니다. 아주 지긋지긋 하죠? Xcode 14.3(swift 5.8) 이후 부터는 weak self를 바인딩 한번 한 이후 부터는 self를 붙일 필요가 없긴 합니다만.. 바인딩 코드를 작성하는 것도 매우 귀찮은 일..

이를 RxSwift(6.0)에서는 withUnretained라는 설탕 문법이 있습니다.

observerble
 .withUnretained(self)
 .subscribe { (owner, output) in
   owner.value = output
 }
 .dispose()

요 편리한 코드를 그대로 Combine에서 써볼려고 합니다.

구현

구현 방식은 각자 다를 것 같은데 원리는 비슷할 것 같아요!

extension Publisher {
  func withUnretained<O: AnyObject>(_ owner: O) -> Publishers.CompactMap<Self, (O, Self.Output)> {
    compactMap { [weak owner] output in
      owner == nil ? nil : (owner!, output)
    }
  }
}

요렇게 Publisher의 Extension으로 작성합니다.

내용은 심플하게 compactMap을 래핑한 Transform으로 해보았습니다.

이번 경우는 owner에 문제가 생기면 값 자체가 nil로 들어오는 패턴이고 좀더 응용을 해본다면 Error를 발생시키는 식으로 해볼 수 있을 것 같네요!

useCase
  .value
  .withUnretained(self)
  .sink { (owner, output) in
    owner.currentValue = output
  }
.store(in: &cancelablles)

위 처럼 self에 대한 바인딩 없이 subscriber를 자유롭게 사용할 수 있습니다.

iOS Framework - 네트워크 모듈 테스트 (URLSession, Unit Test)

Hey_Hen — Fri, 31 Mar 2023 02:12:18 +0900

Intro

서비스를 개발하면 반드시 네트워크에 대한 요청 및 응답 로직을 작성해야 하는데 개발하는 과정에서 로직이 간단한 경우는 최소 한두번, 복잡한 경우는 수십번은 테스트 과정에 네트워크 동작이 발생할 수 있습니다. 뿐만 아니라 몇몇 상황을 고려할 때 실제 서비스(Dev 서버라 하더라도) 를 호출하는 것은 문제점이 많습니다.

따라서 네트워크 모듈 단위 테스트를 실시할 때 어떤 방법이 있을지 알아보려고 합니다.

실제 네트워크 요청시 문제점

우선 네트워크 단위 테스트를 할 때 실제 네트워크를 요청하게 되면 어떤 문제가 있을까요?

물론 간단한 서비스의 경우는 실제 네트워크 요청이 일어나더라도 크게 문제 없을 수도 있습니다. 하지만 여러분이 하는 대부분의 서비스는 복잡하고, 무겁고 어려울 수 있습니다.

그러면 네트워크 모듈 테스트할 때 실제 네트워크를 요청하면 어떤 문제점이 있을까요?

네트워크 환경

Swift에서 사용하는 가장 기본적인 테스트 Framework는 XCTest를 사용합니다. 네트워크는 대부분? 비동기 실행이기 때문에 expectation을 선언하고 wait를 하게 됩니다. 이때 wait에 timeout 을 설정하게 되는데요, 실제 네트워크는 필연적으로 요청 및 응답에 대한 지연시간을 가지기 때문에 실제 예상되는 시간을 작성해야 합니다.

func testExample() throws {
  let exp = expectation(description: "network")
  let session = URLSession.shared
  session.dataTask(with: URLRequest(url: URL(string: "http://do-programming/index")!)) { data, response, error in
    exp.fulfill()
    XCTAssert(true)
  }.resume()

  wait(for: [exp], timeout: 0.1)
 }

간단히 비동기 테스트 코드를 작성해 보았는데요. 위 코드대로라면 0.1초 동안 해당 테스트는 지연됩니다. 그런데 만약 실제 네트워크 요청시 환경 문제로 네트워크 응답에 대한 지연시간이 0.1초 보다 크게 되면 해당 테스트는 실패하게 됩니다. 0.1초 안으로 응답이 들어오지 않았거든요.

그러면 timeout을 실제 네트워크 지연시간 만큼 늘리면 어떻게 될까요?

func testExample() throws {
  let exp = expectation(description: "network")
  let session = URLSession.shared
  session.dataTask(with: URLRequest(url: URL(string: "http://do-programming/index")!)) { data, response, error in
    exp.fulfill()
    XCTAssert(true)
  }.resume()

  wait(for: [exp], timeout: 1) // as-is 0.1 to-be 1.0
 }

그러면 안정적으로 테스트는 성공하게 되겠지만 이 테스트 케이스 한번 돌리는데 1초라는 시간이 들어갑니다.

만약 여러분이 TDD(Test Driven Development)를 하고 있다면 동일한 테스트에 대해 최소 3번의 테스트 실행 시켜야 하는데요, 그러면 3초네요, 만약 만들고자 하는 네트워크 모듈의 테스트 케이스가 총 10개라면 전체 테스트를 한번 돌리는데 무려 10초, 그리고 반복적으로 테스트를 하게 되므로 소모되는 시간이 어마무시 하죠? 따라서 네트워크 모듈에 대한 단위 테스트를 작성할 때는 실제 네트워크 서버를 이용하지 않는 것이 좋습니다.

서버 부하

실제 서버에 대한 부담이 커질 수 있습니다. 네트워크 요청이 고작 짧은 json이라면 크게 문제되지 않을 수 있지만 테스트하는 모듈이 이미지나 동영상 또한 어떤 패키지(s3 등)이라면 한번의 요청만 해도 수 메가바이트가 넘어갈 수 있죠, 마찬가지로 테스트 케이스가 많을 수록, 기능이 복잡해질 수록 서버에 대한 부담이 커집니다.

외부 요인

테스트가 외부 요인에 대해 의존하는 것 자체가 바람직 하지 못합니다. 예를들어 여러분이 테스트 작업을 하는 시간에 Dev서버가 잠시 셧다운이 될 수도 있고 (☕️) 혹은 문제가 생겨서 장시간 셧다운이 될 수도 있습니다. 이외에도 서버를 이전한다던가 하는 각종 외적인 요소들에 이해 업무에 장애가 생기는 경우가 있을 수 있습니다.
이외에도 네트워크 모듈이라 하면 다양한 성공 케이스가 있을 수 있고, 다양한 실패 케이스가 있을 수 있습니다. 예를들어 HTTP Status Code가 200, 304, 401, 408 등등에 대해 다르게 동작해야 할 수 있는데, 백엔드 엔지니어에게 상황에 맞게 변경해달라고 한다던가, 그들이 테스트 할 수 있는 API를 뚫어 준다던가 하는 의존성이 생깁니다.

따라서 상기 이유에 따라 네트워크 모듈 단위 테스트는 모의 객체(Mock Object)를 통해 이루어 져야 합니다.

또 한번 익혀두면 사실 그간 있었던 불편한 점을 모두 해결할 수 있으므로 사실 해서 손해볼 것은 없습니다,

URLProtocol

일반적으로 단위 테스트할 때 의존하는 객체에 대해서 Mock이 필요하면 의존 객체의 인터페이스를 채용하는 Mock 모델을 만들게 됩니다.

protocol UseCase {
  func fetchList() -> [String]
}

final class MockUseCase: UseCase {
  func fetchList() -> [String] {
    [
      "안녕!",
      "잘가!",
    ]
  }
}

final class TestTests: XCTestCase {

  private var sut: ViewModel!

  override func setUpWithError() throws {
    try super.setUpWithError()
    sut = ViewModel(useCase: MockUseCase())
  }

  override func tearDownWithError() throws {
    sut = nil
    try super.tearDownWithError()
  }
}

UseCase를 의존하는 ViewModel이 있으면 구체적인 UseCase를 동작하기 전에 MockUseCase를 적용하는 흔한 테스트 방법입니다.

이 경우는 UseCase를 저희가 직접 작성하기 때문에 Mock object를 손쉽게 작성할 수 있습니다.

그런데 만드는 것이 네트워크 모듈이라면 애플 환경에서는 필연적으로 URLSession을 의존하게 되죠!

Downloader -> URLSession

그러면 MockURLSession을 만들어야 하는데 어떻게 만드나요?

바로 URLProtocol 입니다.

https://developer.apple.com/documentation/foundation/urlprotocol

[URLProtocol | Apple Developer Documentation

An abstract class that handles the loading of protocol-specific URL data.

developer.apple.com](https://developer.apple.com/documentation/foundation/urlprotocol)

URLSession을 통해 Task를 수행할 때 URLProtocol 서브클래스들 내용을 따를 수 있는데요, 이를 통해서 Mock URLProtocol subcless를 만들어서 네트워크 결과를 수정할 수 있습니다.

MockURLProtocol

뭔가 큰 파일을 보내는 서비스가 있다고 가정 해보겠습니다.

이 서비스는 송신되는 데이터 사이즈를 절약하기 위해 데이터를 압축해서 보냅니다.

클라이언트에서는 이 압축된 데이터를 받아서 압축 해제하는 과정을 거치게 되죠.

여기에 추가로 데이터를 더 절약하기 위해 클라이언트에서도 데이터를 캐싱하기로 했습니다. Etag를 기반으로 캐싱한다고 가정하죠.

Etag가 일치 하는지 안하는지 서버에 요청을 보내고 일치하면 200, 일치하지 않으면 304를 받게 됩니다.

제 생각에는 클라이언트에서 압축 해제를 매번 하는 것도 디바이스에 따라 많이 부담이 되는 작업이기 때문에 서버에서 보내준 상태 코드가 200이고 패키지 내용이 바뀌었을 때만 압축 해제를 수행하고 그렇지 않을 경우에는 이미 캐싱하고 있던 압축 해제된 데이터를 사용하고 싶습니다.

그러면 이제 이 역할을 수행하는 모델을 Downloader라고 정의해보죠

이 Downloader는 Response의 StatusCode에 따라 다르게 핸들링 할 수 있도록 결과를 반환하고 싶습니다.

if statusCode == 304 {
  completion(data, .useCache, nil)
} else if statusCode == 200 {
  completion(data, .refreshCache, nil)
} else {
  completion(nil, .failure, nil)
}

다시 테스트로 돌아가보죠, 그럼 Downloader가 요청 결과에 따라 로직대로 바르게 반환하는지 테스트해 볼 수 있을 것 같네요.

각 분기가 모두 커버리지에 들어갈 수 있도록 테스트 코드를 짜야합니다!

func test_download_sucess() throws {}

테스트할 성공 케이스의 경우는 첫 번째 요청의 etag와 두 번째 요청의 etag가 다를 때, 200을 내려줘서 캐싱된 로컬 데이터가 아닌 서버 데이터르 사용하도록 해야 합니다. 이제 서버에서 반응해줄 동작을 URLProtocol을 통해 구현해보게습니다.

final class MockURLProtocol: URLProtocol {}

Tests Target쪽에 우선 MockURLProtocol 서브클래스를 만들고...

override class func canInit(with request: URLRequest) -> Bool {
  return true
}

우선 canInit(with:) 메서드를 오버라이드 합니다. 해당 메서드를 true로 반환해야지 MockURLProtocol의 동작을 수행하도록 할 수 있습니다.

그 다음은 canonicalRequest(for:) 메서드를 오버라이딩 하는데, 구현 안하면 터지기 때문에 인자의 request를 바로 반환하는 코드로 작성 해 줍니다. canonicalRequest를 어떨 때 쓸 수 있는지는 따로 문서를 읽어보는게 좋을 것 같습니다.

override class func canonicalRequest(for request: URLRequest) -> URLRequest {
  request
}

그 다음은 startLoading() 메서드를 오버라이딩 합니다. startLoading()은 request 요청에 대해 동작을 정의할 수 있습니다. 즉 테스트 용으로 서버에서 그 응답이 온 것처럼 할 수 있다는 것이죠

override func startLoading() {
  let response = HTTPURLResponse(
    url: request.url!,
    statusCode: 200,
    httpVersion: nil,
    headerFields: [:])!

  client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .allowed)
  client?.urlProtocolDidFinishLoading(self)
}

이제 어떤 요청에도 Request에 대한 응답을 200으로 내려줄 수 있습니다.

이제 이걸 응용해서 서버에서 Etag를 내려주는 것 처럼 할 수 있죠

static var serverEtag: String?

override func startLoading() {
  let response = HTTPURLResponse(
    url: request.url!,
    statusCode: 200,
    httpVersion: nil,
    headerFields: headers())!

  client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .allowed)
  client?.urlProtocolDidFinishLoading(self)
}

private func headers() -> [String: String] {
  guard let etag = Self.serverEtag else { return [:] }
  return ["Etag": etag]
}

serverEtag가 값이 있으면 서버에서 etag를 내려주는 듯한 테스트를 할 수 있습니다. 클라이언트에서는 URLSession.DataTask의 결과로 etag가 포함된 URLResponse를 받을 수 있게됩니다.

여기에 statusCode도 다르게 줘보겠습니다.

private func statusCode() -> Int {
  return Self.serverEtag == request.allHTTPHeaderFields?["Etag"] as? String ? 304 : 200
}

URLRequest에 etag가 포함되어 있고 만약 지정한 etag랑 같으면 304, 다르면 200으로 statusCode를 내려줄 수 있습니다.

만약 download의 로직에 response에 있는 etag를 저장하고 다음 request에 요청 헤더에 Etag를 잘 포함시켜서 보낸다면 아래 테스트 코드는 성공할 것입니다.

func test_download_use_cache() throws {
  let exp = expectation(description: "")
  // Given
  let etag = UUID().uuidString
  MockURLProtocol.serverEtag = etag
  // When
  sut.download(url) { [unowned self] _, _, _ in
    sut.download(url) { _, result, _ in
      exp.fulfill()
      // Then
      XCTAssertEqual(result, .useCache)
    }
  }
  wait(for: [exp], timeout: 0.1)
}

만약 첫번째 download 이후 etag를 수정하고 두번 째 download를 실시하면 etag가 달라진 상황도 테스트 할 수 있겠네요!

OHHTTPStubs

이러한 네트워크 테스트를 좀더 편하게 해주는 라이브러리가 바로 OHHTTPStubs입니다. OHHTTPStubs는 테스트 타겟 뿐만이 아니라 본 프로젝트에서도 디버그 용도로 활용하기 수월하므로 만약 네트워크 통신 테스트를 중요하게 생각하신다면 충분히 선택해볼한 라이브러리 인 것 같습니다.

Conclusion

무엇보다 클라이언트 개발자 입장에서 백엔드 API는 항상 늦게 나오는데 기능을 좀더 테스트 해보기 위해서 꼭 필요한 것 같습니다. 실제 테스트를 위해 코드에 덕지덕지 디버그용 코드를 써넣거나 백엔드 API에 의존하지 않고 기능을 마무리 지을 수 있으니까요.

Data Structure - Heap (w/Swift)

Hey_Hen — Wed, 7 Dec 2022 00:59:55 +0900

What is Heap

힙은 완전 이진 트리 기반의 자료 구조입니다. 구현 하기 위해서는 트리가 어떤 형태를 가지고 있는 자료 구조인지 미리 알면 좋을 것 같습니다.
힙은 일반적으로 두가지 힙이 있습니다. Max Heap과 Min Heap이 있습니다. 최대 힙은 말 그대로 큰 수가 가장 우선 순위가 높고, 최소 힙은 작은 수가 우선 순위가 높습니다.
우선 순위라는 말을 썼는데요!, Heap 자료 구조는 Priority Queue 자료 구조를 만들 때 활용할 수 있습니다!

힙 자료구조는 어떻게 만들고, 데이터 삽입, 출력은 어떻게 하는지 알아 보도록 하겠습니다.

Building

Heap은 우선 데이터를 삽입 하고 제거할 때, Tree 형태 자료에 맞게 재배치를 하는 과정이 필요합니다. Max-Heap 기준으로 설명하자면
데이터를 삽입하면 자신이 있어야 할 위치까지 재배치 하는 과정이 필요하다는 거죠! 예를 들어 볼게요!

remove

힙에서 제거가 어떤 식으로 이루어 지는지 먼저 봐보겠습니다. 우선 Max-Heap에서는 가장 큰 수가 먼저 나온다고 말씀드렸죠.
그러면 10이 remove 동작을 하게 될 경우 가장 먼저 나와야 합니다.

힙은 내부적으로 배열로 구현되는데요! 10을 빼겠다고 removeFirst()를 하게되면 배열을 재배치 하는 과정에서 O(n)이라는 시간이 발생하고 맙니다!

따라서 배열의 가장 마지막 요소를 제거하면 가장 빨리 제거할 수 있죠!
그래서 가장 첫번 째 요소와 가장 마지막 요소를 우선 Swap 합니다.

5와 10을 바꾸었네요!, 이제 10은 가장 마지막에 있으니 꺼내주면 됩니다.

힙에서 가장 우선 순위가 높은 값(10)을 얻었네요, 그런데 여기서 멈추면 Max-heap 구조가 무너지기 때문에 재배치 하는 과정을 거칩니다.
재배치 과정은 어렵지 않습니다. 자식 노드 두개를 비교해서 자신 보다 큰 노드와 위치를 바꿔주면 됩니다. 만약 자신 보다 자식 노드 둘다 크다면 더 큰 노드와 바꿔주면 됩니다.

즉 다음 동작은 5를 8과 4와 비교하여 더 큰값과 바꿔주면 됩니다.

8과 5를 바꾸었죠? 4는 5보다 작기 때문에 대상이 아닙니다. 이제 이 동작을 5에 대해서 더이상 교체할 노드가 없을 때 까지 반복해 주면 됩니다.
그러니까 그 다음은 5를 7과 1을 비교해서 더 큰 값과 바꿔주면 됩니다. 7과 바꿔주면 되겠네요!

이제는 더 바꿀 노드가 없으므로, 이렇게 되면 이 Heap은 다시 Max-Heap 구조가 완성 되었습니다. 이 과정을 sift-down이라고 합니다. 여기서 트리 구조만 보고서는 이게 정렬이 된건가 의아해 하실 수도 있는데요, 그 다음 큰 값을 제거 해볼까요?

8을 빼기 위해서 가장 마지막 노드와 자리를 바꿔준 다음 8을 빼줍니다. 그런 다음 3을 sift-down 해볼게요

3을 7,4와 비교해서 더 큰값인 7과 바꿔 준 다음

그 다음 3의 자식 노드인 5, 1과 비교해서 더 큰 값인 5과 변경 해줍니다.

3은 더 이상 자식 노드가 없으니 sift-down이 끝났죠?
그 다음 큰값을 빼게 되면

7과 2를 swap 하고 7을 내보 낸 뒤 2를 sift-down 합니다.
2를 5,4와 비교하여 가장 큰 값인 5와 바꿔주고, 그 다음 2의 자식인 3,1과 비교하여 더 큰값인 3과 바꿔 줍니다.

그 다음 큰 값인 5가 빠질려면 1과 swap 하게 되고 1로 sift - down을 합니다. 이 때 1의 자식인 3,4를 비교해서 더 큰 값인 4와 바꾸게 되면 1의 여정은 끝이나죠
이 과정은 노드가 다 없어질 때 까지 반복하다 보면

가장 큰 순서대로 값이 빠져나온 것을 볼 수 있습니다!

insert

값을 삽입 하는 방법은 sift-down 이 아닌 sift-up을 하면 됩니다. 마찬가지로 갑 추가는 트리의 가장 마지막 노드에 추가하고, 이를 sift-up하면서 올라가면 됩니다. sifu-up은 sift-down보다 더 쉬운데요! sift-down은 두 자식 노드 중 더 큰 값과 변경 해주는 반면, sift-up은 부모 노드가 자신 보다 더 작으면 무조건 바꿔주면 됩니다. 비교 할 대상이 하나 뿐인 것이죠 (max-heap 기준)

Implementation

이제 실제로 Swift 언어로 구현해봅시다.

struct Heap<T: Equatable> {
  private var elements: [T] = []
  private let sort: (T, T) -> Bool
  
  init(sort: @escaping (T, T) -> Bool) {
    self.sort = sort
  }
}

우선 Heap을 배열로 구현할 거라고 말씀 드렸습니다. 따라서 내부 데이터로 배열을 가지고 있을 겁니다.
타입은 제네릭 T로 표현할 것이고, sift-up, sift-down 할때 두 값을 비교해서 누가 더 큰지 알아야 했기 때문에, Equatable을 준수하는 타입으로 제약을 걸겠습니다.
sort라는 함수 타입을 통해 최대 힙인지, 최소 힙인지 구분할 수 있기 때문에 이를 생성 시점에 받도록 하겠습니다. 무슨 소리냐 하면
Sift-down 할 대 부모 노드와 자식 노드를 비교를 하잖아요? lhs값이 부모고, rhs값이 자식일 때 자식이 부모보다 클 때 즉 lhs > rhs이면 최대 힙 조건에 맞게 구성이 됐었기 때문에, sort라는 함수타입에 >를 전달해 주면 최대 힙이 되는 것이고 <를 전달해 주면 최소 힙이 되는겁니다.

Child Node Index

Heap에서 Sift-down, up 할 때 자식 노드와 부모 노드의 인덱스를 Swap 했잖아요? 즉 자식 노드와 부모노드의 인덱스를 알아낼 방법이 필요합니다.
트리는 다음과 같은 형태로 순번을 가지죠?,

예를들어 1번 노드(값 8) 를 부모 노드라고 했을 때 자식 노드의 인덱스는 3, 4입니다.
즉 왼쪽 자식 노드는 p * 2 + 1 이고 오른쪽 자식 노드는 왼쪽 자식 노드의 무조건 그 다음 이기 때문에 L + 1과도 같습니다.
따라서 다음 두 인스턴스 메서드를 추가합니다.

private func leftChildIndex(parent: Int) -> Int {
  parent * 2 + 1
}
  
private func rightChildIndex(parent: Int) -> Int {
  parent * 2 + 2
}

그 다음 가장 높은 우선 순위 값을 빼는 순서를 말씀 드렸죠.
0번과 가장 마지막 노드를 swap 한 다음 마지막 값을 빼 내고, sift-down이라는 것을 수행 하면 됩니다.

mutating
func remove() -> T? {
  guard !isEmpty else { return nil }
  elements.swapAt(0, count - 1)
    
  defer {
    siftDown(start: 0)
  }
    
  return elements.removeLast()
}

이러한 코드겠죠, swapAp을 하기 위해서는 1이상의 개수가 필요하므로 0개일 때는 조기 종료문을 써줍니다!

siftDown 메서드는 아직 작성하지 않았죠?
해당 메서드에 포함되어야 할 내용은 크게 어렵지 않습니다.
왼쪽 자식 노드와 오른쪽 자식 노드와 비교해서 더 큰값과 위치를 바꿉니다.
이 동작을 더이상 바꿀 자식 노드가 없을 때 까지 반복하면 됩니다.

mutating
private func siftDown(start: Int) {
  var parent = start
  var candidate = parent
    
  while true {
      
    let leftChild = leftChildIndex(parent: parent)
    let rightChild = rightChildIndex(parent: parent)
      
    if leftChild < count, sort(elements[leftChild], elements[candidate]) {
      candidate = leftChild
    }
      
    if rightChild < count, sort(elements[rightChild], elements[candidate]) {
      candidate = rightChild
    }
    
    if parent == candidate {
      return
    }
    
    elements.swapAt(parent, candidate)
    parent = candidate
  }
}

이제 삽입 메서드를 만들어 보겠습니다.
삽입은 말씀 드렸던 순서대로, 트리 마지막에 새 값을 추가 한뒤 sift-up이라는 동작을 수행하면 된다고 말씀드렸습니다.

mutating
func insert(_ element: T) {
  elements.append(element)
  siftUp(start: count - 1)
}

siftUp을 구현하기 전에 부모 노드의 인덱스를 알아낼 방법을 찾아보겠습니다.

이번에는 자식 노드를 기준으로 보니까 3번 노드(값 5) 를 볼까요?
3번의 부모 노드 인덱스는 1이므로 (3 - 1) / 2 를 하면 1이 나오겠네요! 4번 노드의 입장에서도 같습니다. (4 - 1) / 2을 하면 1이 나오네요!
즉 (C - 1) / 2 를 하면 부모 노드의 인덱스를 구할 수 있습니다.

private func parentIndex(child: Int) -> Int {
  (child - 1) / 2
}

요렇게 쓰면 되겠습니다!
이제 다시 sift-up을 작성하러 가볼까요!

mutating
private func siftUp(start: Int) {
  var child = start
  var parent = parentIndex(child: child)
  while child > 0, sort(elements[child], elements[parent]) {
    elements.swapAt(parent, child)
    child = parent
    parent = parentIndex(child: child)
  }
}

이제 기본 적인 모양새는 갖추었으니 실제로 써볼까요?

var heap = Heap<Int>(sort: >)

heap.insert(1)
heap.insert(7)
heap.insert(4)
heap.insert(10)
heap.insert(2)

while let value = heap.remove() {
  print(value)
}

무작위로 숫자를 넣어주고
heap을 반복해서 remove 해주면

촤란~ Max Heap이 완성 되었습니다.

Additional

있으면 좋은 추가 기능을 작성해볼려고 합니다.
임의의 노드를 제거 해볼 수 있을텐데요! 이때는 어떻게 해야 할까요?
어렵지 않습니다. 해당 노드의 인덱스를 힙의 마지막 노드의 인덱스와 swap 해 준 뒤 선택한 인덱스 위치로부터 sift-up과 sift-down을 수행해주면 됩니다.

mutating
func remove(at index: Int) -> T? {
  guard index < count else { return nil }
  if index == count - 1 {
    return elements.removeLast()
  } else {
    elements.swapAt(index, count - 1)
    defer {
      siftDown(start: index)
      siftUp(start: index)
    }
    return elements.removeLast()
  }
}

어렵지 않습니당. 그런데 제거하려는 노드가 어느 인덱스에 있는지는 어떻게 찾을까요?

루트 노드 부터 시작해서 왼쪽, 오른쪽 자식을 모두 뒤지는 수 밖에는 없습니다. 재귀 함수로 구현 해 볼게요

func index(of element: T) -> Int? {
  index(of: element, startingAt: 0)
}
  
private func index(of element: T, startingAt i: Int) -> Int? {
  if i >= count {
    return nil
  }
    
  if sort(element, elements[i]) {
    return nil
  }
    
  if element == elements[i] {
    return i
  }
    
  if let j = index(of: element, startingAt: leftChildIndex(parent: i)) {
    return j
  }
    
  if let j = index(of: element, startingAt: rightChildIndex(parent: i)) {
    return j
  }
  
  return nil
}

0번 부터 시작해서 전체를 훑을 예정입니다. 외부에 노출된 메서드에는 시작 인자는 숨겨줄게요.

Array Building

지금 까지는 힙을 만들 때 insert값을 계속해서 전달해 주었는데요, 배열로 바로 초기화 할 수는 없을까요? 시도해봅시다.

init(sort: @escaping (T, T) -> Bool, elements: [T] = []) {
  self.sort = sort
  self.elements = elements
    
  if !elements.isEmpty {
    for i in stride(from: elements.count / 2 - 1, through: 0, by: -1) {
      siftDown(start: i)
    }
  }
}

elements를 받을 수 있도록 인자를 수정하고, elements를 전달 받은 다음 힙을 조건에 맞게 섞어? 줄게요
이 때 모든 값을 sift-down 할 필요는 없습니다. 중간에서 sift-down을 실시하면 됩니다. 비교 대상이 되는 부모 노드는 전체 노드의 절반 만큼만 존재하기 때문이죠!

이제는 아래 처럼 Heap을 만들 수 있습니다.

var heap = Heap<Int>(sort: >, elements: [1,7,3,2,6,8])

while let node = heap.remove() {
  print(node)
}
//8
//7
//6
//3
//2
//1

Performence

remove: O(log n)
insert: O(log n)
search: O(n)

Reference.

kodeco / swift algorithm club

Data Structure

Hey_Hen — Tue, 6 Dec 2022 22:28:59 +0900

What is Data Structure

데이터 구조는 데이터를 저장하고 조직하는 저장소입니다. 자료 집합을 효율적으로 저장하거나 접근할 수 있도록 할 수 있습니다.

Classification of Data Structure

- 자료구조를 크게 선형 자료 구조인지, 비선형 자료 구조인지 구분할 수 있습니다.

Linear Data Structure: 데이터 요소가 순차적 또는 선형으로 구성되어 있고 이전 및 다음 인접 요소에 연결되는 데이터 구조를 선형 데이터 구조(Linear Data Structure)라고 합니다. 선형 데이터 구조의 대표적인 예로는 배열, 링크드 리스트, 큐, 스택 등이 있습니다.
- Static, Dynamic Data Structure: 정적 자료 구조 인지 동적 자료 구조인지로도 구분이 가능합니다. 정적 자료구조는 C에서 배열과 같이 고정된 메모리 크기를 가지고 있는 형태인 반면 동적 자료 구조는 런타임 중에 그 크기가 변할 수 있죠. Swift에서는 배열이 정적인 메모리 사이즈를 가지지는 않기 때문에 의미있는 구분은 아닙니다.
Non-Linear Data Structure: 비선형 자료 구조는 데이터가 순차적으로 배치되지 않은 데이터 집합을 얘기합니다. 일반적으로 트리나 그래프를 얘기합니다.

UML(Unified Modeling Language) - feat. Class Diaphragm

Hey_Hen — Tue, 15 Nov 2022 21:48:17 +0900

Intro

UML. Unified Modeling Language는 시스템 설계를 시각화 하는 표준 방법을 제공하기 위한 소프트웨어 엔지니어링 분야의 범용 개발 모델링 언어입니다.

https://en.wikipedia.org/wiki/Unified_Modeling_Language

쉽게 말하면 글자로 표현되는 코드를 그림으로 표현하기 위한 방법이죠!
UML에 대해서 정확하게 알고 사용한 것은 아니지만 정말 유용한 도구라고 생각을 해서 많이 사용했는데요.
객체간의 관계와 구조를 코드를 보지 않고도 그림으로 설명할 수 있기 때문에, UML이 있으면 코드를 일일이 분석하지 않아도 어떤식으로 구성되어 있는지 한눈에 알 수 있습니다.

레거시 코드를 유지 보수 하다 보면 코드와 실제 화면이 잘 매치가 안되기도 하고, 추상화가 많이 되어 있는 경우 코드를 파악하는데 오랜 시간이 걸리기도 합니다. 개인의 역량에 따라 다르겠지만 그럴 때 해당 모듈에 대해서 정리한 다이어그램 이 있으면 참 좋겠다고 생각했었습니다.

뿐만아니라 PR 할 때 리뷰어가 쉽게 코드 구조를 파악할 수 있게 도움을 줄 수도 있고, 코드를 작성하기 전에 구조에 대한 의논을 하기 위해서도 좋은 도구로 쓰입니다.

UML 다이어그램의 유형에는 여러가지가 있는데 그 중에서 가장 유용하게 사용했던 클래스 다이어그램에 대해서 자세히 알아보려고 합니다.

Class Diagram

클래스 다이어그램은 시스템의 Class, Property, Method, Protocol 등을 표현할 수 있고 객체간의 관계를 나타낼 수 있습니다.

Class

Class는 사각형 박스로 나타냅니다 이 때 얘기하는 클래스는 개발 언어에서 class, struct를 구분하지 않습니다.

Inheritance

Inheritance는 상속을 뜻합니다. 상속은 비어있는 화살표로 표현됩니다.

Inheritance

이 때 화살표 방향은 'A가 B를 상속하고 있다' 로 읽는 기준으로 A가 B를 향하도록 하면 됩니다.

페르시안 고양이(A)가 고양이(B)를 상속하기 때문에 위 그림처럼 나타낼 수 있습니다.

Association

Association은 다른 말로 표현하면 이해가 쉬운데 우리가 Swift에서 특정 엔티티를 작성할 때 엔티티가 가진 Property를 표현하는 것과 같습니다. 그래서 Association은 Property입니다. 그래서 표현할 때 A가 B를 가지고 있다. 로 표현할 수 있으며 화살표가 A에서 B로 향하도록 하면 됩니다. 화살표는 열린 화살표로 표현됩니다

이때 Cat이 배열 즉 Person 하나가 다수의 Cat를 가지고 있다면 1...*과 같이 표현할 수 있습니다. 코드로 보자면 [Cat]과 같은 타입인 것이죠

그렇다면 Person이 Cat을 상속한 Persian Cat을 가지고 있다고 한다면 아래 처럼 표현이 가능합니다!

Protocol

SOLID를 설명하다보면 항상 나오는 얘기가 인터페이스를 의존한다 뭐 이런얘기 많이 하는데, Swift는 그럴때 Protocol을 쓸 수 있습니다.
Protocol을 표현하는 방법은 Class와 동일한 사각형으로 표현하며 이때 Class와 구분되어야 하므로 별도로 표시 해 줍니다.

이때 <<protocol>> 과 같이 표현한 것을 UML에서는 stereotypes라고 표현합니다. 만약 클래스 다이어그램을 그릴 때 구조체랑 클래스를 명시적으로 표현하고 싶을 때 <<structure>>, <<class>> 으로 표현할 수 있겠죠! [IBM Doc]

UML stereotypes

In UML models, a stereotype is a model element that identifies the purpose of other model elements. UML 2.1 provides a standard set of stereotypes that you can apply to model elements. You can use a stereotype to refine the meaning of a model element. For

www.ibm.com

Protocol의 경우 이를 채용하는 실제 구현체가 있을텐데요! Implements Protocol은 비어있는 화살표와 점선으로 표현합니다. Swift에서 A는 B를 채용한다라고 했을 때 A가 B에게 화살표가 향하도록 비어있는 화살표와 점선으로 표현할 수 있습니다.

Implements Protocol

그래서 Person(A) 객체가 고양이를 가질 수 있도록 CatOwning(B)이라는 프로토콜을 채용하고 있다면 아래와 같이 그릴 수 있습니다.

Person이 CatOwning을 Conforms to라고도 표현하죠!

Dependency

아키텍처를 설명할때 의존관계에 대해서 정말 많이 설명하는데요! A가 B를 사용한다! 또는 A가 B를 의존한다라는 뜻으로 말할 수 있으며 열린 화살표와 점선으로 표시됩니다.
만약 A가 B를 사용(의존) 한다면 A에서 B로 화살표가 향하도록 할 수 있습니다.

Uses

예를들어 Cat의 이름은 PetOwning에 의해서 결정되기 때문에 Cat이 PetOwning을 의존하고 있습니다. 따라서 아래처럼 표현할 수 있습니다.

이외에도 상호관계를 나타내는 Aggregation과 존재하는데 반드시 필요한 관계가 있는 구성 관계 Composition가 있습니다.

Tool

작성한 코드에 대해서 손수 UML을 그릴 수도 있지만, 이를 좀더 편하게 그릴 수 있는 도구들이 존재합니다. 다양한 도구가 있는데 저는 Plant UML을 이용했습니다. 오픈소스이고, 작성이 간편해서 사용했던 것 같네요!
https://plantuml.com/ko/class-diagram

클래스 다이어그램 구문 및 기능

PlantUML 클래스 다이어그램 구문 : 당신은 정의 할 수 있습니다 인터페이스, 회원, 관계, 패키지, 제네릭, 음 ... 변경 글꼴과 색상도 가능하다.

plantuml.com

Conclusion

그간 정확하기 않은 클래스 다이어그램을 좀 그렸던거 같은데, 공통 언어이다 보니 바르게 작성해서 생각한 바를 잘 전달할 수 있도록 원칙을 지켜서 작성해야 할 것 같습니다.

Reference.

https://en.wikipedia.org/wiki/Class_diagram
https://www.ibm.com/docs/en/rsm/7.5.0?topic=models-uml-diagrams
raywenderlich - Design Patterns by Tutorials

SwiftUI - SwiftUI 환경에서 ViewController Life Cycle 사용하기

Hey_Hen — Wed, 26 Oct 2022 02:46:35 +0900

Intro

SwiftUI 프레임워크로 넘어오면서, 가장 불편했던 것 중 하나는 기존 UIViewController가 제공했던 ViewController Life Cycle이 SwiftUI View에는 없다는 것입니다.
View Modifier에도 onAppear와 onDisappear가 존재하지만 기존 LifeCycle을 대체하기에는 부정확한 동작이 많았죠

특히나 didAppear와 didDisappear의 빈자리가 비교적 크게 느껴집니다.

SwiftUI를 프로젝트에 적용하는 방법중에는 UIKit을 기반으로 HostingController를 활용하는 법과
순수 SwiftUI 베이스로 시작하는 방법이 있는데요!

이번에 설명드릴 방법은 SwiftUI 베이스에서 UIViewController의 Life Cycle 사용하는 방법입니다.

Concept

우선 컨셉부터 보여드리면, 위 그림과 같이 View가 ViewModel에 의존해서 Presentation Logic을 처리합니다. 이때 ViewController도 동시에 존재하는데요, ViewController 또한 View가 가진 동일한 ViewModel에 의존합니다. 그리고 ViewController에서는 LifeCycle을 ViewModel로 보내면, ViewModel은 그에 따른 동작을 수행해서 상태를 View로 방출하면 됩니다.

UIKit환경과는 달리 View Controller가 많은 일을 담당하지 않습니다. 단지 Life Cycle 신호를 ViewModel로 보낼 뿐이죠

Implemenation

구현은 어떻게 하면 될까요?
우선 LifeCycleController를 선언하겠습니다.

enum LifeCycle {
  case viewDidLoad
  case viewWillAppaer
  case viewDidAppear
  case viewWillDisappear
  case viewDidDisappear
}

protocol LifeCycleHandlerProtocol: AnyObject {
  var lifeCycle: PassthroughSubject<LifeCycle, Never> { get }
}

final class LifeCycleController: NiblessViewController {
  
  private weak var handler: LifeCycleHandlerProtocol?
  
  init(handler: LifeCycleHandlerProtocol) {
    self.handler = handler
    super.init(nibName: nil, bundle: nil)
  }
  
  override func viewDidLoad() {
    super.viewDidLoad()
    handler?.lifeCycle.send(.viewDidLoad)
  }
  
  override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    handler?.lifeCycle.send(.viewWillAppaer)
  }
  
  override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    handler?.lifeCycle.send(.viewDidAppear)
  }
  
  override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    handler?.lifeCycle.send(.viewWillDisappear)
  }
  
  override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)
    handler?.lifeCycle.send(.viewDidDisappear)
  }
  
  deinit {
    print(self, #function)
  }
  
  struct Representable: UIViewControllerRepresentable {
    typealias UIViewControllerType = LifeCycleController
    private let handler: LifeCycleHandlerProtocol
    
    init(handler: LifeCycleHandlerProtocol) {
      self.handler = handler
    }
    
    func makeUIViewController(context: Context) -> LifeCycleController {
      LifeCycleController(handler: handler)
    }
    
    func updateUIViewController(_ uiViewController: LifeCycleController, context: Context) {
      
    }
  }
}

LifeCycleController의 역할은 Handler에게 액션을 보내주기만 하면 되는 형태입니다.
지금은 Combine을 써서 넘겨주고 있는데 어떤 방식이든 크게 상관없습니다.

그 다음은 ViewModel 입니다. 앞에서 컨셉에서 설명드렸듯 ViewModel은 LifeCycle을 핸들링 하면 됩니다.
기존 ViewModel이 LifeCycleHandlerProtocol을 채용합니다.

extension ContentView {
  final class ViewModel: ObservableObject, LifeCycleHandlerProtocol {

    private var cancellables: Set<AnyCancellable> = []
    let lifeCycle = PassthroughSubject<LifeCycle, Never>()
    
    init() {
      bind()
    }
    
    private func bind() {
      lifeCycle
        .sink(receiveValue: { [weak self] lifeCylce in
          self?.lifeCycleHandling(lifeCylce)
        })
        .store(in: &cancellables)
    }
    
    private func lifeCycleHandling(_ lifeCycle: LifeCycle) {
      print(lifeCycle)
      switch lifeCycle {
        case .viewDidLoad:
          return
        case .viewWillAppaer:
          return
        case .viewDidAppear:
          return
        case .viewWillDisappear:
          return
        case .viewDidDisappear:
          return
      }
    }
        
    deinit {
      print(self, #function)
    }
  }
}

이런 식으로요, 지금은 블럭들이 비어있지만 실제로 사용할 때 알맞는 코드를 넣어주면 되겠죠?
그리고 이를 화면에 배치해야 비로서 ViewController의 LifeCycle 이 시작되는데요, View에 어떻게 배치하면 좋을까요?

Modifier를 이용하겠습니다.

struct LifeCycleModifier: ViewModifier {
  let handler: LifeCycleHandlerProtocol
  func body(content: Content) -> some View {
    content
      .overlay(
        LifeCycleController.Representable(handler: handler)
        	.frame(width: .zero, height, .zero)
      )
  }
}

extension View {
  func lifeCycle(handler: LifeCycleHandlerProtocol) -> some View {
    modifier(LifeCycleModifier(handler: handler))
  }
}

Modifier로 content에 overlay로 작성하게 되면 화면 배치에 영향도 없고, 아무것도 보이지 않는 Empty View가 완성됩니다.
이제 View Extension으로 lifeCycle을 호출한 다음 handler만 전달해주면 되죠!

View Content에서는 아래처럼 선언하면 이제 완성됩니다.

struct ContentView: View {
  @ObservedObject private var viewModel: ViewModel
  var body: some View {
    VStack(spacing: 0) {
      Image(systemName: "globe")
        .imageScale(.large)
        .foregroundColor(.accentColor)
      Text("Hello, world!")
    }
    .padding()
    .lifeCycle(handler: viewModel)
  }
  
  init(viewModel: ViewModel) {
    self.viewModel = viewModel
  }
}

Conclusion

저는 SwiftUI 베이스 보다는 UIKit 베이스로 SwiftUI를 더 많이 작성하긴 하는데
순수하게 해당 뷰의 ViewLifeCycle만 받고, 재사용 가능한 코드로 구성할때는 이 방법이 깔끔하고 좋은 것 같습니다.
애플에서는 onAppear왜 onDisappear 그리고 ObservableObject가 뷰의 생명주기를 컨트롤한다고 얘기하지만, 정말 단순 명료하게 VC에서 제공하던 LifeCycle이 필요할 때가 정말 많아서 생각하게 된 방법입니다!

Sample Proejct.

https://github.com/urijan44/SwiftUIViewLifeCycle

Lukas Graham - 7 years (lyrics)

Hey_Hen — Mon, 10 Oct 2022 23:44:29 +0900

Once I was seven years old my momma told me

Go make yourself some friends or you'll be lonely

Once I was seven years old

It was a big big world, but we thought we were bigger

Pushing each other to the limits, we were learning quicker

By eleven smoking herb and drinking burning liquor

Never rich so we were out to make that steady figure

Once I was eleven years old my daddy told me

Go get yourself a wife or you'll be lonely

Once I was eleven years old

I always had that dream like my daddy before me

So I started writing songs, I started writing stories

someting about that glory just always seemed to bore me

Cause only those I really love will ever really know me

Once I was twenty years old, my story got told

Before the morning sun, when life was lonely

Once I was twenty years old

I only see my goals, I don't believe in failure

Cause I know the smallest voices, they can make it major

I got my boys with me at least those in favor

and if we don't meet before I leave, I hope I'll see you later

Once I was twenty years old my story got told

I was writing about everthing, I saw before me

Once I was twenty years old

Soon we'll be thirty years old, our songs have been sold

We've traveled around the world and we're still roaming

Soon we'll be thirty years old

I'm still learning about life, my woman brought children for me

So I can sing them all my songs and I can tell them stories

Most of my boys are with me, some are still out seeking glory

And some I had to leave behind, my brother, I',m still sorry

Soon I'll be sixty years old my daddy got sixty-one

Remember life and then your life becomes a better one

I made a man so happy when I wrote a letter once

I hope my children come and visit, once or twice a month

Soon I'll be sixty years old, will I think the world is cold

Or will I have a lot of children who can warm me

Soon I'll be sixty years old

Soon I'll be sixty years old, will I think the world is cold

Or will I have a lot of children who can warm me

Soon I'll be sixty years old

Once I was seven years old my momma told me

Go make yourself some freinds or you'll be lonely

Once I was seven years old

Suzanne Vega - Luka (lyrics)

Hey_Hen — Thu, 6 Oct 2022 23:42:46 +0900

My name is Luka

I live on the second floor

I live upstairs from you

Yes, I think you've seen me before

If you hear someting late at night

Some kind of trouble, some kind of fight

Just don't ask me what it was

I think it's cause I'm clumsy

I try not to talk too loud

Maybe it's because I'm crazy

I try not to act too proud

They only hit until you cry

After that yout don't ask why

You just don't argue anymore

Just don't argue anymore

Yes, I think I'm okay

I walked into the door again

If you ask that's what I'll say

It's not your business anywhere

I guess i'd like to be alone

With notting broken, nothing thrown

Just don't ask me how I am

My nams' is Luka

I live on the second floor

I live upstairs on you

Yes, I think you've seen me before

If your hear someting late at night

Some kind of trouble, some kind of fight

Just don't ask me what it was

And they only hit until you cry

After that you don't ask why

You just don't argue anymore

just don't argue anymore

You just don't argue anymore

Architecture - Single Responsibility Principle(SRP)

Hey_Hen — Wed, 14 Sep 2022 01:33:41 +0900

Intro

SRP는 SOLID라 불리는 아키텍처 원칙 중 첫번째 글자에 해당하는 원칙입니다.
용어는 로버트 C. 마틴이 2003년 저서 Agile Software Development, Principles, Patterns, and Practices에 소개한 개념으로 OOD의 원리 라는 기사에서 소개했다고 합니다. 도서 클린 아키텍처(로버트 C. 마틴 저)에 따르면 일부 정의된 아키텍처 원칙 중 몇몇을 마이클 페더스라는 사람이 그것들을 재배열해서 나오게 된 이름이라고 하네요!

Single Responsibility Principle

SRP는 직역하면, 단일 책임 원칙 이라고 해석할 수 있는데, SOLID 원칙 중 가장 의미가 제대로 전달되지 못한 원칙 중 하나라고 합니다. 그 이유는 이름 때문이라고...(당신이 지은거 아님..?)
여기서 말하는 SRP의 설명은 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다. 라고 설명을 하고 있습니다. 동시에 모든 모듈이 하나의 일만 해야 한다. 라는 것은 잘못된 전달이라고 합니다. 그렇게 알고있는 것은 함수는 단 하나의 일만 해야 한다, (커다란 함수를 작은 함수들로 리팩터링 하는 저수준 원칙) 이며 이는 SOLID 원칙, 즉 SRP가 아니라고 설명합니다.

그러게 이름을 왜 그렇게 지어서..

여기서 말하는 SRP 의 수준은 "모듈" 로 보입니다. 모듈이란 가장 단순한 정의로는 소스파일 그 자체 라고 볼 수도 있습니다. (아닌 경우도 있다고 함?) 좁게는 클래스, 넓게는 하나의 응집된 컴포넌트 그 자체로 볼 수 있을 것 같습니다. 절대 함수와 같은 저수준 원칙을 얘기하는 것이 아닙니다!

그럼 뭔데...?

제가 이해하기로, 책에서는 Actor 라는 개념을 중요하게 얘기합니다. 모듈은 하나의 Actor에 의해서만 변경될 수 있다는 얘기입니다. 이게 무슨 말일까요?

저는 실제로 경험한 것 중 가장 적합한 예시는 바로 병합 이라고 생각합니다.
프로그램을 만들다 보면, 우리는 중복 코드를 발견하고 이를 병합 하려는 행동을 보입니다. 리팩터링 중 가장 흔하게 할 수 있는 것 중 하나죠?
그런데 병합을 할 때 가끔 우리는 잘못된 병합을 하는 것 같습니다. 잘못된 병합을 시도하고, 중복코드를 줄이고 뿌듯해 하죠! SRP 위배는 바로 여기서 발생합니다.

대체 왜 합쳐놨냐고!!!!

네, 코드를 수정하다가 무언가 수정했는데, 그로 인해서 다른 곳에서 기능이 변하는 경우죠, 이걸 대체 왜 합쳐놨지? 라고 생각이 들때가 바로 SRP를 위배한 현장을 목격한 것입니다.

이해하기 편하도록 예시 케이스를 하나 만들어 봤습니다. 실제 사건을 모티브로 각색해 보았어요!

커뮤니티 어플리케이션이 있습니다.
이 커뮤니티는 글을 쓰고 포인트를 받을 수 있는데, 회원 구분에 따라 포인트가 차등 지급 되고 있습니다.
인증회원의 경우 기본 포인트5에 활동기간 및 레벨 등의 가중치를 얻고
미인증 회원의 경우 기본 포인트만5 만 지급받는 형식입니다.
개발 초창기에는 그것 말고는 다른 케이스가 없어서 글쓰기 라는 하나의 모델에 인증/미인증 회원 두 액터가 모두 의존하고 있는 상황입니다.

여기서 포인트지급 정책이 바뀌기로 했습니다. 미인증 회원의 글쓰기 포인트가 너무 짜서, 기본 포인트를 증가 시키기로 했습니다.
그런데 여기서 한가지 문제가 발생하죠? 기본 포인트를 수정하게 되면 인증 회원의 포인트까지 증가하게 됩니다.
코드로 보면 이렇습니다.

유저 클래스

final class User {
  private(set) var certification = false
  private(set) var signUpDate = Date()
  private(set) var level = 0
  private(set) var point = 0
  
  func increasePoint(point: Int) {
    self.point += point
  }
}

게시판 모델

struct WriteBoard {
  
  private let pointCalculator = PointCalculator()
  
  func write(user: User) {
    user.increasePoint(point: pointCalculator.point(user: user))
  }
}

포인트 지급 정책 모델

struct PointCalculator {
  private let basePoint = 5
  private let levelPointWeight = 1.25
  private let signUpDatePointWeight = 2
  
  func point(user: User) -> Int {
    if user.certification {
      return basePoint * (signUpDatePoint(signUpDate: user.signUpDate) + levelPoint(level: user.level))
    } else {
      return basePoint
    }
  }
  
  private func signUpDatePoint(signUpDate: Date) -> Int {
    signUpDatePointWeight * Int(Date().timeIntervalSinceNow - signUpDate.timeIntervalSinceNow)
  }
  
  private func levelPoint(level: Int) -> Int {
    Int(levelPointWeight * Double(level))
  }
}

코드를 보면 문제가 되는 부분은 basePoint가 미인증 유저와, 인증 유저 2개의 액터에 걸쳐 있다는 것입니다. 2개의 액터 즉 SRP 위반입니다.

해결방법

이를 해결하는 방법은 다양한데, POP를 통해서 한번 해결해보도록 하겠습니다.
기존 포인트 지급 정책을 기본 포인트, 추가 포인트 정책 프로토콜로 쪼개서 가집니다.
그리고 포인트를 지급할 수 있는 인터페이스를 추가합니다.

즉 기존 포인트 계산기는 새로 생긴 프로토콜에 의존합니다.

protocol BasePointPolicy {
  var basePoint: Int { get }
}

protocol WeightPointPolicy {
  var levelPointWeight: Double { get }
  var signUpDatePointWeight: Double { get }
}

protocol PointGarentInterface {
  func point(user: User) -> Int
}

이제 이 3개를 조합해서 2개의 포인트 계산기 구현을 만들 수 있습니다.

미인증회원 포인트 지급 정책

struct InvalidateUserPointCalculator: BasePointPolicy, PointGarentInterface {
  let basePoint = 10
  
  func point(user: User) -> Int {
    basePoint
  }
}

인증회원 포인트 지급 정책

struct CertifiedUserPointCalculator: BasePointPolicy, WeightPointPolicy, PointGarentInterface {
  let basePoint = 5
  let levelPointWeight = 1.25
  let signUpDatePointWeight: Double = 2
  
  func point(user: User) -> Int {
    basePoint * (signUpDatePoint(signUpDate: user.signUpDate) + levelPoint(level: user.level))
  }
  
  private func signUpDatePoint(signUpDate: Date) -> Int {
    Int(signUpDatePointWeight * Date().timeIntervalSinceNow - signUpDate.timeIntervalSinceNow)
  }
  
  private func levelPoint(level: Int) -> Int {
    Int(levelPointWeight * Double(level))
  }
}

그래서 게시판이 하나의 포인트 계산기를 의존하지 않고 포인트 계산기 인터페이스를 의존합니다.

struct WriteBoard {
  private let pointCalculator: PointGarentInterface
  
  func write(user: User) {
    user.increasePoint(point: pointCalculator.point(user: user))
  }
}

결국 인증회원은 CertifiedUserPointCalculator에 미인증회원은 InvalidateUserPointCalculator에 각각 1:1로 의존하게 됩니다. 다르게 말하면 각 포인트 계산기는 자신이 담당하는 엑터에 의해서만 수정될 수 있습니다. 프로토콜에 의해서 포인트 지급 정책은 수정될일이 없는거죠!

결론

- SRP는 클래스의 기능, 함수의 기능이 하나이어야 된다는 뜻이 아니라 변경의 이유가 하나 이어야 한다. 즉 단 하나의 액터만 상대 해야 한다는 뜻입니다.
- SRP 위반은 주로 병합에서 나타나는 것으로 볼 수 있습니다. 무언가 병합해야 한다면 혹시 다른 액터를 가진 것을 병합하고 있지는 않는지 고민해볼 필요가 있을 것 같습니다.

Reference.

로버트 C. 마틴: 클린 아키텍처

Swift - 지금 보는 뷰 이름 알기

Hey_Hen — Sun, 4 Sep 2022 02:04:26 +0900

Introduce

회사 업무로 코딩하다 보면 정말 많이 화가날 때가 있는데, 뷰가 너무너무너무 많아서 도대체 내가 지금 보고 있는 뷰의 이름이 뭔지 모를때가 있다. 비슷하게 생긴 뷰도 워낙 많고 하니, 단순히 피그마 디자인만 보고 뷰의 이름이 추측이 안될때가 있다. 기록이나 정의해 둔 문서가 따로 있다면 좋겠지만, 아마 대부분의 회사는 없을 것 같다.

그래서 보통 쓰는 방법이, 뷰 계층 디버거를 이용해서 이름을 알아 내는 방법인데, 이게 또 프로젝트가 너무 커서 그런가, 켜지는 데 시간도 오래 걸리고, 심지어 어떨 때는 계층 디버거가 켜지지도 않는다. 이럴때 진짜 매우 섬뜩하게 화가난다. 코딩할 시간도 부족한데, 뷰 이름이나 찾고 있어야 한다는게...

그래서 어떤 방법을 이용하면 좀더 쉽고 빠르게 찾을 수 있을까 하다가, 배운적은 있지만 한번도 실용적으로 사용해본 적은 없는 Method Swizzling이 생각났다. 개념을 모르시는 분들께 간단히 설명하자면, 런타임 중에 실행되는 메서드를 바꿔치기 하는 기능이다.

예를들어 모든 UIViewController는 로드될 때 필연적으로 viewDidLoad() 를 호출하게 되는데, 이걸 내가 만든 별도의 메서드가 호출되도록 할 수 있는 것이다.

놀라워라!!!

딱기다려

그래서 어떻게 하느냐?

extension UIViewController {

  @objc func whatTheThisView() {
    print("What The This View: \(self)")
  }

}

우선 @objc 딱지가 붙은 메서드를 하나 만들 건데, UIViewController에서 이용할 예정이므로 extension으로 추가한다.

이 메서드는 지금 viewDidLoad와 교체할 메서드 이므로, 내용은 취향껏 채우자

그 다음 메서드를 스위즐링을 수행할 메서드를 만들 건데, 이 기능을 AppDelegate 시점에 DEBUG 일 때만 수행되도록 하고 싶다. 그래서 UIViewController의 타입 메서드로 만들꺼다.

static func startWhatTheThisView(mirror: Bool = false) {
    let target = #selector(viewDidLoad)
    let source = mirror ? #selector(whatTheThisViewMirrir) : #selector(whatTheThisView)

    guard
      let targetMethod = class_getInstanceMethod(UIViewController.self, target),
      let sourceMethod = class_getInstanceMethod(UIViewController.self, source)
    else { fatalError("What The This View Start Failure, Can't Find Method") }

    method_exchangeImplementations(targetMethod, sourceMethod)
}

addTarget 할때처럼 selector를 이용해 메서드를 가리켜 주면 된다.

그런 다음 class_getInstanceMetohd 를 통해 뭔갈 가져오면 되는데 신기하게도 Method 라는 타입이다. 신기해서 문서를 보니 OpaquePointer 라는 구조체의 별칭이었다. OpaquePointer는 C Pointer의 래핑이라고 문서에 써져있더라.

아무튼 그렇단 말은 Method의 참조 포인터를 가져온 다는 뜻! 즉 런타임 중에 viewDidLoad 가 올라가 있는 주소가 있고, 내가 만든 메서드 주소가 있는데, viewDidLoad로 향하게 안하고 내가 만든 주소로 향하게 해서 메서드 스위즐링 이란 것을 수행하는 것으로 추측된다.

그런 다음 수행 하는 코드는

method_exchangeImplementations(targetMethod, sourceMethod)

이름만 봐도 메서드 바꿔줄 것 같다.

이제 AppDelegate에서 방금 만든 타입 메서드를 호출한다.

#if DEBUG
    UIViewController.startWhatTheThisView(mirror: true)
#endif

그러면 이제 앱을 실행시켜서 화면을 돌아다니면 내가 만든 메서드가 호출된다.

나 같은 경우는 ViewController가 가지고 있는 (가증스러운) 멤버 까지 모두 호출 시키도록 했다. 가끔 화면에 매치된 뷰 들이랑, 뷰의 이름이 뭔지 모를 경우가 많기 때문이다,

니네 이제 다 뒤졌다?

...

물론 회사에 오래 근무하신 분들은 이미 코드들을 속속 알고 계셔서 금방 찾으시겠지만, 회사를 옮길 때 마다 이 뷰가 무슨 뷰인가 찾는 시간이 너무 아깝다고 생각했다. 그렇다고 뭘 특별히 하기에는 좀 그렇고, 간단한 코드 한 페이지 작성해서 실행 시킬 수 있으니 훨씬 작업시간이 빨라지는 것 같다.

(로그 창이 지옥으로 변하는 건 어쩔 수 없다)

Swift - Result Type 을 반환값으로 써보자

Hey_Hen — Sun, 28 Aug 2022 16:51:55 +0900

Introduce

Result Type은 Swift 5에서 도입되어 SSL(Swift Standart Library)에 포함된 문법입니다. 동작의 수행 결과를 Success 인지 Failure인지 구분해서 나은 가독성과 코드 분기를 제공해줍니다.
(개인 의견: 테스트 코드를 작성해본 사람은 알겠지만, try-catch에서 catch 아래는 코드 커버리지에 포함이 안되어서 미묘하게 킹받는데, 그런 사소한 부분을 해결해 주기도 한다.)
본 글은 Result Type을 반환값으로 쓰는 방법으로 Result Type 자체에 대한 내용은 다루지 않겠습니다.

왜 Return 값으로 Result Type을 쓰고싶었을까?

Data Layer를 작성하다보면, 해당 비즈니스 모델에는 iOS 버전이나 라이브러리를 의존하고 싶지 않은 경우가 있습니다. 기껏 Layer를 구분했는데, 라이브러리를 포함시키게 되면 유지보수나 빌드 속도에 악영향을 미칠 가능성이 높습니다.
비즈니스 모델이 iOS 버전이나 라이브러리에 의존하는 것 만큼 안좋은 선택은 없을 것 같습니다.
따라서 최소한의 의존성을 가지도록 구성하고 싶습니다.
이 얘기는 왜 하냐면, iOS13 타겟 이상이라면 사실 Combine의 Future를 사용할 수 있습니다.
또는 라이브러리에 의존하자면 PromiseKit이나 FutureKit 또는 RxSwift의 Single을 이용할 수 있겠죠.
(2022년에 네이티브한 Future-Promise 문법이 Swift에 없다는 것 자체가 좀 불만 스럽네요)
하지만 앞서 얘기했 듯 Data Layer는 아주 가볍고 민첩해야 합니다. 의존성도 낮아야 하고 말입니다.
그래서 Swift에는 이미 Result Type이 도입되었고 이를 이용해 Combine의 Future처럼 쓰고 싶다는 생각을 했습니다.

그냥 파라미터에서 escaping closure로 쓰면 안될까?

Swift 도서에서 소개된 대로 Result Type은 escaping closure를 활용해서 잘 사용할 수 있습니다. 아래처럼요

func fetchImage(completionHandler: @escaping (Result<Data, Error>) -> Void) {
  urlSession.dataTask(with: URL(string: "https://image.tmdb.org/t/p/w500/kAVRgw7GgK1CfYEJq8ME6EvRIgU.jpg")!) { data, response, error in
    if let error = error {
      completionHandler(.failure(error))
      return
    }

    if let data = data {
      completionHandler(.success(data))
      return
    }
  }
  .resume()
}

URLSession과 같은 비동기 기능에서 Result Type을 꺼내려면 escaping 을 사용하는 수 밖에는 없습니다.
이는 Swift 도서에 소개된 방법 그대로 이지만, 조금 아쉽습니다.
completionHandler 자체를 매번 파라미터로 전달하는 것도 그렇습니다. 이게 생각보다 귀찮거든요 수정에도 그렇고 결과를 받을 때도 조금 불편합니다.

configuration.fetchImage { result in
  switch result {
    case .success(let success):
      ()
    case .failure(let failure):
      ()
  }
}

fetchImage를 호출하고 바로 수행 코드를 작성해줘야 합니다. 물론 이게 편할때도 많습니다. 하지만 그렇게 쓰고 싶지 않을때도 존재합니다.
결론은 그렇게 쓰고 싶지 않을 때도 있는데 자유가 없다 정도입니다. (웃음)

그래서 Return으로 Result Type을 쓰면 어떻게 생겼는데?

configuration
  .fetchImage(name: "영화사진")
  .map { data in
    UIImage(data: data)
  }
  .sink { [weak self] result in
    switch result {
      case .success(let image):
        Task {
          self?.imageView.image = image
        }
      case .failure(let error):
        print("ERROR:\(error)")
  }
}

요렇게 쓰고 싶습니다. (Single이랑 Combine.Future랑 똑같이 생겼움)
지금은 이렇게 썼지만

let fetchResult = configuration.fetchImage(name: "영화사진")

completionHandler를 썼을 때와 다르게 바로 호출하지 않고 이렇게 저장해둘 수 있습니다. 필요한 시점에 sink를 호출해야지 비로서 네트워크 요청을 하게 됩니다.

구현

그래서 어떻게 했냐가 중요할 것 같습니다.
사실 이게 맞게 구현한 건가 잘 모르겠습니다. 이미 promise kit 이나 future kit등 좋은 예제가 있지만 우선 구현은 스스로의 힘으로 해본 뒤 라이브러리를 참고하고 싶었습니다. (밑밥 깔기)
우선 코드를 아래처럼 사용할 수 있어야 합니다.

func fetchImage(name: String) -> Future<Data, Error> {
  return Future<Data, Error> { [unowned self] promise in
    let url = imageService.makeURL(name: name)
    urlSession.dataTask(with: URL(url: url) { data, response, error in
      if let error = error {
        promise(.failure(error))
        return
      }

      if let data = data {
        promise(.success(data))
        return
      }
    }
    .resume()
  }
}

대충 이런 느낌인데, 여기서 눈 여겨 보셔야 할 부분은
1. 파라미터에 escaping closure 대신 아니라 return 이 있습니다.
2. URLSession completion handler 내부에서 그 결과를 리턴값으로 전달해야 합니다.
Future<Data, Error> 뒤에 클로져로 promise가 붙습니다. promise에 succee와 failure를 전달하면 URLSession 블록 바깥으로 값을 전달할 수 있습니다.

우선 promise에 promise(.success(value)) 와 같은 식으로 값을 전달하기 위해서 promise의 타입은 (Result<Data, Error>) -> Void 와 같은 형태일 필요가 있습니다.

그래서 생성자를 다음과 같이 만들어 줬습니다.

typealias Promise<T, E: Error> = (Result<T, E>) -> Void

private var result: (@escaping Promise<T, E>) -> Void

/// Future 생성자
/// - Parameter promise: promise 클로져 안에서 promise를 호출하고 success 또는 failure를 작성할 수 있습니다.
init(promise: @escaping (@escaping Promise<T, E>) -> Void) {
  result = promise
}

생성자를 열고 클로져 인자로 Result<T, E> -> Void 를 내보내야 하는데 풀어쓰면

init(promise: @escaping (@escaping (Result<T, E>) -> Void) -> Void) 과 같은 형태라 typealias로 감싸줬습니다.

그러면 이제 아래처럼 Result Type 자체를 반환값으로 사용할 수 있고, 그 안에서 어떤 값이 전달될 것인지 구성할 수 있습니다.

return Future<Data, Error> { promise in 
    // success
    promise(.success(data))

    // error
    promise(.failure(error))

}

앞서 생성자와 result 멤버 변수가 @escaping (@escaping Promise<T, E>) -> Void 와 같이 escaping이 두개나 붙는 기형적인 형태에 대해서 의아하실 텐데요, 저도 처음에 많이 고민했던 부분입니다.

URLSession의 completion handler는 마찬가지로 escaping clousre 이기 때문에 해당 블록 안에서 값을 탈출 시키려면 탈출되는 코드도 escaping 이어야 하는데요,
첫번째 escaping은 생성자 블록 자체를 Future의 result 멤버 변수로 전달하는데 한번 사용했고, 남는건 (Result<T, E>) -> Void 가 남는데 이건 escaping closure가 아니라서 URLsession의 escaping closure 바깥으로 가져갈 수 없습니다.
그렇기 때문에 escaping 타입 속성이 하나 더 있는거죠

이제 여기까지만 해도 Result Type을 반환값으로 사용하는 것은 목표 달성입니다만, 한번 해보고 싶었던 부분은
transform 연산입니다.

Additional

fetchResult
  .map { data in
    UIImage(data: data)
  }
  .sink { [unowned imageView] result in
    switch result {
      case .success(let image):
        Task {
          imageView.image = image
        }
      case .failure(let error):
        print("ERROR:" , error.localizedDescription)
  }
}

map과 같은 변환 오퍼레이터를 이용하고 싶은 것이죠
map 까지는 타입이 Result<Data, Error> 이고 이후에는 Result<UIImage?, Error> 입니다.

방법을 생각해보면
1. map 이후에는 새로운 Future 타입을 생성
2. 외부에서 transform을 하는 블럭을 받아서 그를 통해 Future 타입 생성

func map<N>(_ transform: @escaping (T) -> N) -> Future<N, E> {
  Future<N, E> { newPromise in
    result { newResult in
      switch newResult {
        case .success(let t):
          newPromise(.success(transform(t)))
        case .failure(let error):
          newPromise(.failure(error))
      }
    }
  }
}

요런식으로 새로운 Future를 작성해볼 수 있을 것 같습니다. 요번 포스팅의 목적 자체가 Return 에 Result Type을 사용해보고 싶은 것이었는데 해당 부분을 해결했기 때문에 이런것도 가능한 것 같습니다.
같은 요령으로 tryMap, compactMap도 만들어 볼 수 있을 것 같습니다.

Sink

sink 구현을 누락했는데요! 별거없습니다.

  /// 저장된 값을 sink를 통해서 가져올 수 있습니다.
  /// - Parameter result: result는 success, failure 두 타입이 있습니다.
  func sink(result: @escaping Promise<T, E>) {
    self.result(result)
  }

Repository

https://github.com/urijan44/ReturnResultKit

Refernece

https://en.wikipedia.org/wiki/Futures_and_promises
https://developer.apple.com/documentation/swift/result

SwiftUI 에서 MVVM 을 멈춰야 하는가?

Hey_Hen — Wed, 10 Aug 2022 02:11:14 +0900

꽤 자극적인 주제죠?
네 오늘은 SwiftUI에서 MVVM을 멈춰야 하는가에 대한 제 생각을 써보려고 합니다.

결론은 쓰세요 입니다. 반박시 여러분 말이 맞습니다.

본문에 들어가기 앞서, 민감한 주제라고 생각하기 때문에, 누가 그러한 주장을 했는지는 모두 생략하도록 하겠습니다.
본 글에서 작성하는 '여론'의 근거는 주로 iOS Developer Slack 채널 raywenderlich 웨비나, 블로그 글 등을 참고했습니다.

이제 왜 이러한 결론에 도달했는지 설명 드리겠습니다.

SwiftUI의 State와 Binding은 View Model 인가?

최근들어 iOS Developer Slack 채널이나, 온갖 뉴스레터에서 SwiftUI Framework에서는 MVVM을 쓰지 말자는 논지의 아티클을 정말 많이 본 것 같습니다. raywenderlich에서 진행한 웨비나도 있었습니다.

SwiftUI에서 MVVM을 쓰지 말자고 하시는 분들의 의견을 정리하면 아래와 같습니다.

SwiftUI에서는 View에 View Model이 통합되었습니다. (State가 ViewModel이다.) 따라서 View Model을 통한 바인딩이 필요없어졌기 때문에 ViewModel은 불필요한 레이어입니다.

저는 이 의견 말고는 다른 의견은 본적이 없습니다. 있다면 언제든 댓글/이메일 등으로 알려주시면 정정하도록 하겠습니다.

그리고 위 의견에 반대하는 의견도 있습니다.

SwiftUI View에 View Model이 통합되면, Model이 View에 보여지기 위해서는 보여주기 위한 형태로 변환하는 과정이 필요한데, View Model은 그 역할을 겸하고 있다. 그렇다면 이 보여주기 위한(Presentation) 형태로 변환하는 작업 또한 View에 포함되야 하는데, 너무 무거워 진다.

기본적으로 두 의견이 대세인 것으로 보입니다.

두 의견의 핵심을 추려서 다시 파악해 보면
SwiftUI의 State와 Binding이 ViewModel로 볼 것이냐 아니냐 에 대한 차이로 보입니다.

State, Binding의 특징은 값이 변경되면 body를 재 호출 해서 body 라는 뷰를 통째로 새로 그리게 됩니다. 즉 값이 변경되면 뷰가 즉시 반응하는 반응형 프로그래밍인 셈이죠.

ViewModel이 뭔데?

MVVM 디자인 패턴은 2005년 Microsoft의 WPF, Sliverlight의 설계자 중 한명인 John Gossman이 개발하고 블로그를 통해 공개했습니다.(1) 해당 패턴은 Martin Fowler의 PM의 아이디어를 차용했다고 밝혔는데요, 해당 블로그 글에 따르면 핵심은 ViewModel과 View의 의존 방향이며, View가 ViewModel의 값을 얻는 특이한 방법입니다.

쉽게 설명하자면, 다들 아시겠지만 MVC의 구조는 유저가 View를 보고 터치 동작과 같은 반응을 수행하면, Controller에 의존해서 이를 수행하고, Controller과 Model과 통신해서 유저 동작 수행 결과를 View에 업데이트 시킵니다. 이 과정에서 View는 Controller에 의존하면서 Controller는 또 View를 알고있는 상태가 됩니다. MVC는 이 방법을 View와 Controller의 상호 참조를 통해서 쉽게 해결합니다. 네 그렇습니다. 양방향 패턴입니다.

그러다 보니 View와 Controller가 너무 의존적이기 때문에 재사용성이 떨어지는 결과를 초래했습니다, 통제 흐름이 양방향이다 보니 리팩터링할 때 코드 찾아다니는 것도 쉽지 않습니다.

MVVM은 이러한 문제를 단방향 참조와 Binding과 같은 개념으로 민첩하게 설계할 수 있게 해줍니다.
View는 유저가 발생하는 어떤 액션을 ViewModel에 보내면, ViewModel은 해당 액션을 분석하고 Model에 의존해서 그 결과를 단순히 방출만 합니다. View를 직접 업데이트 하지 않습니다. 이 덕분에 통제 흐름이 단방향으로 흐르게 됩니다.

View는 업데이트를 어떻게 하냐 하면, 딱히 특정 ViewModel이 아니더라도 인터페이스를 통해 방출되고 있는 값을 감시하고 하고 있다가 값이 업데이트 되면 뷰 스스로를 변경하면 됩니다.

이 부분이 ViewModel이 존재하는 핵심 이유입니다. 상호 참조로 해결하냐, 값을 방출만 하냐 그 차이지만 이 차이가 생각보다 굉장히 중요합니다. 저는 경험적으로 양방향 아키텍처를 분석하는 것 보다 단방향 아키텍처를 분석하는 것이 훨씬 쉽고, 나중에 분리하기도 쉬웠습니다.
(이 부분이 사바사 일지는 잘 모르겠습니다. 의견 주시면 감사하겠습니다.)

ViewModel의 핵심을 설명하느라 좀 많이 돌아왔는데요!
그래서 State/Binding이 ViewModel을 대체할 수 있을까요?
아니요 그럴 수 없습니다.

저는 두가지 핵심 이유가 있다고 생각합니다.

State와 Binding PropertyWrapper는 모델을 사용하기에 불편하다.
수명주기가 View에 종속된다.

하나씩 설명 드리겠습니다.

State와 Binding PropertyWrapper는 객체를 사용하기에 불편하다.

우선 State와 Binding은 Class 모델을 사용하기에 조금 번거롭습니다. 무슨 뜻일까요? 애플의 설계는 State, Binding으로 감싼 객체가 변경이 되면 항상 body를 새로 그리기를 원합니다. SwiftUI에서 View는 값의 상태와 동일한 개념입니다. 값이 변경되면 (일반적으로) 항상 뷰가 변경이 됩니다. UIKit과 달리 일일이 업데이트 코드를 사용하지 않아도 되는 것이 SwiftUI의 장점이자 편리한 점이죠.

그런데 State와 Binding으로 감싼 값이 '구조체'가 아니라 '클래스'가 되면 이 규칙은 깨집니다. 구조체일 경우 mutate가 발생하고 body는 그것을 인지하고 뷰를 업데이트 합니다. 그런데 클래스의 경우 멤버가 변경되는 것을 mutate로 보지 않죠 간단합니다.

struct Book {
  var title: String
  var content: String

  init(title: String, content: String) {
    self.title = title
    self.content = content
  }
}

간단하게 Book 클래스를 만들겠습니다.

struct ContentView: View {
  @State var book = Book(title: "곰세마리", content: "")
  var body: some View {
    VStack {
      Image(systemName: "book")
        .imageScale(.large)
        .foregroundColor(.accentColor)
      TextField(
        "내용을 입력하세요",
        text: $book.content,
        axis: .vertical
      )
      .padding()
      .background {
        RoundedRectangle(cornerRadius: 8)
          .foregroundColor(.gray.opacity(0.3))
      }
      .padding()
      RedrawMonitor(count: book.content.count)
    }
  }
}

struct RedrawMonitor: View {
  let count: Int
  var body: some View {
    Text("\(count)")
  }

  init(count: Int) {
    self.count = count
  }
}

그리고 간단하게 Book의 내용을 편집할 수 있는 뷰를 마련했습니다. 여기서 TextField로 Book의 내용을 수정할 수 있고, RedrawMontior를 통해 책 content의 길이를 표시하려고 합니다. 당연히 TextField를 수정하게 되면 Book은 mutate가 발생하게 되고 뷰를 새로 그리면서 RedrawMonitor는 content 길이를 업데이트 하고 표시합니다.

그런데 만약 여기서 Book이 구조체가 아니고 클래스로 변경되면 어떻게 될까요?

final class Book {
  var title: String
  var content: String

  init(title: String, content: String) {
    self.title = title
    self.content = content
  }
}

그닥 놀라운 일은 아닙니다. RedrawMonitor가 업데이트 되지 않습니다.

물론 여기서 왜 굳이 Book이 클래스 이어야 하냐고 반문 하실 수도 있습니다. 하지만 앱을 만들다 보면 꼭 구조체만 사용할 수 없는 상황은 오기 마련입니다. 또 클래스여도 업데이트 할 방법은 있다고 하실 수 있습니다. 의도적으로 mutating을 발생시키는 State를 하나 만들면 됩니다. 하지만 그것은 값의 변화에 따라 뷰 업데이트를 신경쓰지 않겠다는 SwiftUI의 근본 개념 자체를 부정하는 행위입니다.

그래서 SwiftUI는 이러한 불편함을 해소 할 수 있는 도구가 하나 더 있습니다. 바로 ObservableObject 입니다. ObservableObject는 내부에서 objectWillChange가 호출되면 body를 다시 그리도록 하는 특성이 있습니다.
Published Property Wrapper를 사용하면 자동으로 objectWillChange를 호출하죠.

물론 Published에 클래스를 쓰게되면 자동으로 objectWillChange를 발생시키지 않습니다. State와 같은 이유 이지요.
하지만 강제적으로 뷰를 업데이트 하기 위해 State은 더미를 만들어야 하지만 ObservableObject는 의도적으로 통제할 수 있죠.

결론은 State와 Binding에는 구조체만 넣는것이 합당? 해 보이고 이는 State와 Binding을 ViewModel로 보기에는 수많은 제약이 따릅니다.

수명주기가 View에 종속된다.

SwiftUI에서 View는 Data의 파생입니다. 데이터가 변경이 되면 View는 자동으로 상태를 따라갑니다. 그런데 WWDC 내용에 따르면 View는 지역적 특성을 가집니다, View에 종속되죠. 실제로 SwiftUI 뷰를 구성하다 보면 State, Binding은 값이라는 느낌보다는 UILabel, UIButton 같은 느낌입니다. 값 보다는 뷰에 가까운 것이죠. API통신과 같은 외부의 값을 가져오는데는 많은 불편함이 있습니다.
View쪽 코드에서 어떤 값을 가져와 State에 대입해야 하죠.
코드로 보면

final class Repository {
  private let cached = Book(title: "Swift", content: "어렵다~")

  func loadBook() -> Book {
    cached
  }
}

어떤 Repository 모델이 있다고 가정 합니다. 아주 심플하게요

struct ContentView: View {
  let repository: Repository
  @State var update = false
  @State var book = Book(title: "곰세마리", content: "")
  var body: some View {
    VStack { ... } 
    .onAppear {
      let initBook = repository.loadBook()
      self.book = initBook
    }
  }
}

외부에서 가져온 값을 @State book으로 전달할려면 View의 특정 시점이나 트리거에서 가져와서 대입해야 합니다. 그런데 여기에 한술 더떠 지금은 Entity를 날것 그대로 가져오고 있는데, 만약 여기서 데이터를 가공해서 보여줘야 할때는 어떻게 해야 하나요? 데이터 가공 코드가 뷰에 들어가야 하나요? 그러지 않길 바랍니다.

해결책은 많다.

앞서 말한 케이스의 해결방법은 엄청 많습니다. Realm에서 밀고가는 MVI도 있고, TCA도 있습니다. 그런데 그거아세요?
Realm에서 말한 MVI는 Realm에 의존합니다. 웨비나에 따르면 다른 Persistent Data Base에 대한 질문이 나왔을 때 Realm 개발자 분께서는 답변을 주시지 않으셨습니다.
TCA는? TCA 그 자체라는 거대한 라이브러리에 의존합니다.

그런데 ObservableObject를 ViewModel로 쓰면 별도의 프레임워크, 라이브러리 없이 너무나 쉽게 해결 가능합니다.
물론 SwiftUI에 알맞게 사용하기 위해 많은 코드를 연구하다 보면 이건 더이상 ViewModel이 아닌 것 같은데~ 그런 생각이 들기도 하고, 어쨌든 정답은 없으니 기존 UIKit 프레임워크 위에서 쓰던 MVVM을 그대로 가져오면 또 SwiftUI의 특성을 100% 살리지 못하는 것도 사실입니다.

하지만 애초에 MVVM은 ViewModel과 View의 통신방법 (바인딩)과 의존방향(단방향) 이 핵심이라는 것을 잊지 마세요! ObservableObject는 바인딩을 하기에 매우 유용한 도구입니다.

결론

SwiftUI라고 해서 MVVM 개념이 부적절 하다는 생각은 저는 별로 좋지 않다고 생각합니다. 그렇다고 MVVM을 맹목적으로 사용하는 것도 주의해야 합니다. 하지만 MVVM을 포기하고(정확히는 MVVM의 개념)을 포기하고 굳이 다른 서드파티 프레임워크 라는 길로 돌아가지 않았으면 합니다. 중요한 것은 민첩하고 유연한 코드를 구성하는 개념 그 자체이지 어떤 디자인 패턴, 아키텍처 패턴을 선택하는 것이 아니라는 것입니다.

References

(1) https://docs.microsoft.com/en-us/archive/msdn-magazine/2009/february/patterns-wpf-apps-with-the-model-view-viewmodel-design-pattern
(2) 클린 아키텍처, 로버트 마틴
(3) raywenderlich Realm 웨비나
(4) SwiftUI 관련 WWDC

Singleton Pattern vs Dependency Injection

Hey_Hen — Tue, 28 Jun 2022 12:09:46 +0900

Intro

코드를 작성하다 보면, 특정 기능을 다른 객체에 의존해야 하는 상황이 생깁니다. 간단한 예로 TIL 앱을 만들었다고 가정했을 때, 데이터를 저장하는 객체를 DataManager 와 같은 이름으로 만들어서 쓸 수 있겠죠.
이 의존성을 받는 객체는 유저의 액션에 따라, 로직 흐름에 따라 호출이 이루어지는데요. 호출을 하는 대표적인 두 가지 방법이 바로 Singleton Pattern과 Dependancy Injection입니다.
각 개념에 대해서는 별도로 소개하지 않겠습니다.

Singleton

두 개념은 서로 반대 진영에 있는 것으로 볼 수 있는데요, 우선 Singleton은 인스턴스를 전역에 올려두고, 어디에서든 쉽고 빠르게 접근할 수 있다는 장점이 있습니다.
아래 코드는 어떤 DataSource 클래스를 간단하게 Singleton으로 구현한 것입니다.

struct DataSource {

  static let shared = DataSource()

  private init() {}

  func fetchId() -> Int {
    0
  }

  func requestRegisterCoupon() {
    // some network request
  }

  func fetchSomeData(userId: String) -> Result<Data, Error> {
    return .success(Data())
  }

  func save(with data: Data) throws {
    // save...
  }

  func edit(with data: Data) throws {
    // edit...
  }
}

Singleton은 하나의 인스턴스를 전역에 올려두고 관리하는 것이기 때문에, 일반적인 생성자는 private로 막아두고 흔히 하는 shared를 통해서 접근할 수 있도록 합니다.

그래서 실제로 사용할 때는 아래와 같이 호출합니다.

let result = DataSource.shared.fetchSomeData(userId: id)

Singleton Pattern은 위 코드에서 보았듯 구현하기도 쉽고, 어디서든 빠르고 쉽게 접근 가능하기 때문에, 자주 선호됩니다. 그리고 핵심은 하나의 인스턴스로 관리하기 때문에, 인스턴스가 둘 이상 생성되어서는 안되는 상황을 보장할 수 있습니다.
하지만 너무 쉬운 코드, 사용의 자유는 다른 불편함을 낳기도 합니다.
Singleton의 대표적인 단점은 유지보수가 어려워 진다는 점입니다. 이 부분이 사람에 따라서는 크게 와 닿지 않을 수도 있는데요.
실제 서비스에서는 코드의 관리자는 빠르게 변합니다. 신규입사자가 들어오기도 하고, 관리한지 오래된 코드를 오랜만에 다시 열어볼 수도 있습니다.
그러니까 기존 코드에 대해서 모르는 상황에서 이 Singleton 객체는 굉장히 불친절합니다.
우선 Singleton객체가 굉장히 큰 책임을 가지고 있는 경우를 생각해 볼까요?
아주 많은 메서드가 있고 그것이 접근에 제한이 없다면 (다양한 UseCase나 View에서 Singleton을 호출하기 때문에, private로 접근 제한이 되어 있지 않을 것입니다)
DataSource.shared를 입력하고 한번 더 .을 누르면 일차적으로 멘탈에 금이갑니다.
대체 어느 메서드를 호출해야 원하는 결과를 얻을 수 있을까요? 모릅니다. 알아내기 위해서는 DataSource 클래스를 열어서 코드 한줄 한줄 파악해가며 해당 메서드가 무슨 역할을 하는지 알아내야 합니다
왜냐하면 Singleton 객체는 작성자에게 너무 큰 자유를 주었기 때문에, 담당하는 기능을 만들면서 손쉽게 Singleton에 기능을 추가했을 것이고, 비슷하거나 겹치는 이름을 피해 메서드 명이 점점 기괴해지거나 길어졌기 때문입니다.
이를 해결하기 위해 Facade 패턴을 이용해 너무 큰 Singleton 객체를 분리하는 방법 도 있습니다.
그리고 기능을 개발하기 위해 Singleton 객체가 이미 존재해야 하는 불편함이 있습니다. 다른 말로 Singleton 객체와 기능이 따로 개발 될 수 없습니다. 한 사람이 한번에 개발을 해야 하죠.

Dependency Injection

Dependency Injection은 어떤 기능이 의존해야 하는 객체를 외부에서 주입하는 방법을 말합니다. 이름 그대로 의존성 주입이죠. 보통 줄여서 DI라고 부릅니다.
//some feature

  private let provider: DataSource

  init(provider: DataSource) {
    self.provider = provider
  }

DI는 위와 같이 some feature 기능에서 DataSource를 멤버로 가지게 되고, 이를 생성자를 통해서 외부에서 주입 받습니다.
이 덕분에, some feature는 DataSource에 대해서 '그다지' 자세히 알 필요가 없습니다. 외부에서 주입되기 때문에 코드 작성자가 어느 인스턴스를 호출해야 할지 '자유롭게' 생각하지 않아도 됩니다. some feature가 데이터를 가져올 떄 부를 수 있는 코드는 provider로 제한되기 때문입니다.

let result = provider.fetchSomeData(userId: userId)

DI 덕분에 의존 관계가 명확해 졌네요. 지금은 단순한 예제를 보았지만, 대형 서비스 코드들을 보고, 해당 Feature가 의존하고 있는 경우를 명백하게 분석할 수 있습니다.
한가지 더 장점은 DI의 경우 interface처리가 훨씬 편하다는 것입니다. Singleton이 기능이 비대해 져서 접근할 수 있는 범위를 제한하기 위해 Facade를 사용해서 implement를 만든다면
DI는 필요한 기능을 protocol로 간단하게 처리해 버릴 수 있습니다.
지금은 some feature가 someData를 가져올 때 DataSource라는 Concrete한 객체에 의존하지만, 나중에 DataSource 객체가 교체가 될 수도 있습니다.
또는 some feature를 작성하는 도중에 DataSource가 완성이 되지 않았을 수도 있죠.
그래서 우리는 protocol을 이용합니다.
fetchSomeData(userId:) 를 제공해주는 어떤 객체든 상관없도록 만드는 것이죠

protocol SomeViewProvider {
  func fetchSomeData(userId: String) -> Result<Data, Error>
  func saveSomeData(with data: Data)
}

프로토콜을 만들고

private let provider: SomeViewProvider

init(provider: SomeViewProvider) {
  self.provider = provider
}

생성자에서 Concrete 타입이 아니라 프로토콜을 타입으로 받습니다.
이렇게 해서 some feature를 작성하는 동안은 DataSource 작업도에 영향을 받지 않을 뿐더러, DataSource가 다른 객체로 변경되더라도 SomrViewProvider만 채용 해달라고 부탁하면 되는 것이죠
또 접근할 수 있는 메서드가 (지금의 겨웅) fetchSomeData,와 saveSomeData로 제한되기 때문에, 해당 feature에서 어떤 기능을 사용하는지 더 명백해 집니다.
그리고 위와 같은 코드 패턴은 Testable한 코드도 겸사겸사 만들게 됩니다.

Singleton VS Dependency Injection

둘 중에 뭘 쓰면 더 좋을까 하는 고민은, 큰 의미는 없습니다. 왜냐하면 각각의 장단이 있기 때문인데요, Singleton은 어쨌거나 단 하나의 인스턴스를 만들어야 하는 경우는 DI보다 더 낫습니다. DI는 주입하는 과정에서 서도 다른 인스턴스를 만들 수 있는 가능성이 충분하기 때문이죠. 만약 local에 특정 user 정보를 보관하고 있다면 이는 따로 관리 되어서는 안될 것입니다.
하지만 디바이스 성능이 갈 수록 좋아지고, 기본적인 서비스 크기가 대폭 늘어남에 따라 Singleton이 주는 편리함은 치가 떨리는 재사용성을 낳습니다. 후임자에게 의존관계 분석 지옥을 선사하죠. 그래서 사견으로는 작은 서비스, 작은 책임에서는 Singleton은 좋은 선택이지만 유지보수가 필요한 상용 서비스에서는 Singleton을 멀리하고 Dependency Injection을 가까이 하는게 낫습니다.

Swift - Dynamic member lookup

Hey_Hen — Wed, 18 May 2022 00:32:06 +0900

Intro

Swift로 된 라이브러리를 구경하다 보면, Class의 @Attribute로 dynamicMemberLookup이라는 것이 붙은 것을 본 적이 있다.

dynamicMemberLookup이 무엇인지, 어떻게 쓰이는지 알아보자

What is Dynamic member lookup

먼저 이것이 무엇인지만 간략하게 설명하자면 '실제 객체에 존재하지 않는 프로퍼티(멤버 변수)를 Dot Syntex로 접근하는 문법` 으로 몬 쌉소린가 싶습니다. 하지만 이 개념을 알고 난 뒤에는 똑같이 설명하게 되실 겁니다.

우선 당연한 예제를 하나 볼게요

struct Developer {
  let languages: [String: Int]
}

var henry = Developer(languages: [
  "swift": 5,
  "cpp": 3
])

henry.languages["swift"] // Optional 5

Developer 객체는 사용할줄 아는 언어와 그 경력이 Dictionary로 정의되어 있습니다. 만약 swift 언어 경력을 알고싶다면

`henry.languages["swift"]` 와 같이 작성해서 languages에 접근해볼 수 있곘고 결과는 Optional 5 일겁니다. 그렇죠?

당연하지만

이렇게는 못가져 올겁니다. Developer 구조체는 swift라는 멤버 변수를 가지고 있지 않기 때문이죠

Dynamic Member Lookup 문법은 이걸 가능하게 합니다.

Implementation

일단은 Developer를 아래와 같이 고쳐볼게요

@dynamicMemberLookup
struct Developer {
  var languages: [String: Int]

  subscript(dynamicMember member: String) -> Int {
    get {
      languages[member] ?? 0
    }
  }
}

하나씩 차근차근 보겠습니다.
우선 @Attribute로 @dynamicMemberLookup 이란게 붙었습니다. 해당 객체가 dynamicMemberLookup를 지원하겠다는 뜻입니다.

그 다음은 뜬금없이 subscript 문법이 들어와 있는데요, subscript문법을 통해서 languages에 바로 접근하고 있습니다.

dynamicMemberLookup 을 잠깐만 잊어볼게요, subscript문법을 작성했으니 다음과 같이 swift 경력을 얻을 수 있습니다.

henry[dynamicMember: "swift"] 그렇죠?

subscript 에서 외부 접근 레이블인 dynamicMember는 사실 dynamicMemberLookup의 구현 사항입니다. subscript문법만 놓고 생각하면 외부 레이블이 뭐든 상관 없을 겁니다.

dynamicMemberLookup은 지금까지 작성한 내용을 바탕으로 dot syntex로 swift에 접근할 수 있습니다.

아까와는 달리 컴파일이 되면서 5라는 정수가 튀어나오죠?

henry라는 Developer의 멤버 변수에는 swift는 없지만, 멤버 변수처럼 접근 할 수 있습니다. 바로 subscript 문법을 이용해서요! 이제 아시겠죠?

Point

이처럼 실제로 존재하지 않는 속성을 dot syntex로 접근하는 것은 굉장히 편리하지만, 런타임에 결과를 확인할 수 있기 때문에 신중해야 합니다.

예를들어 javascript에 경력에 대해서 접근하려고 하는데, js인가요 javascript인가요 javaScript인가요 아니면 JavaScript인가요?

let henry = Developer(languages: [
  "swift": 5,
  "cpp": 3,
  "javascript": 1
])

실제로 javascript의 경력이 있더라도 조금만 잘못 입력하면, 원하는 값이 나오지 않을 수 있습니다. 컴파일 타임에 확인이 불가능 하니 휴먼 에러가 발생할 확률이 높을 뿐더러, 어떤 식으로 프로퍼티가 존재할지 직관적이지도 않고, 자동완성 기능도 기대할 수 없습니다.

그런데 이를 보완하기 위한 방법이 있는데요

struct Point { var x: CGFloat, y: CGFloat }

@dynamicMemberLookup
struct PassthroughWrapper<Value> {
  var value: Value
  subscript<T>(dynamicMember member: KeyPath<Value, T>) -> T {
    get {
      return value[keyPath: member]
    }
  }
}

이런식으로 래퍼를 만들어서 KeyPath를 사용하면

사진 처럼 자동완성의 도움도 받을 수 있고

존재하지 않는 프로퍼티에 접근하면 컴파일 타임에 이를 확인 할 수도 있습니다.

경우에 따라서는 편리하게 사용할 수 있지만, 래퍼를 통하더라도 남용하는 것은 주의하는게 좋을 것 같습니다.

참고

https://books.apple.com/kr/book/the-swift-programming-language-swift-5-6/id881256329

Combine - 여러 요청 결과를 결합해야 하는 경우

Hey_Hen — Tue, 17 May 2022 15:18:59 +0900

Issue

서버에서 A.Request의 요청 결과를 받고 A의 결과에 따라 B.Request를 수행해야 하는 상황

Combine으로는 이를 어떻게 처리를 해야 할까 고민했습니다.

    A_Request.sink { _ in
      
    } receiveValue: { data in
      
      //processing
      
      B_Request.sink { _ in
        
      } receiveValue: { data2 in
        //processing + data2 processing
      }
    }

무식한 방법으로는 위와 같이, A_Request를 받고 내부에서 B_Request를 또 호출하는 방법이지만, 괜찮은 코드는 아닙니다. 코드 자체가 불필요한 뎁스를 가지기도 하고 가독성도 떨어지며, 두 기능을 분리하기가 쉽지 않네요.

Solution

소개 드릴 기능은 CombineLastest로 Rx를 많이들 써보셨다면 잘 아시는 결합 오퍼레이터입니다.

다양한 결합 연산자 중에 CombineLastest를 써야 하는 이유가 있는데요

다른 결합 연산자는 각 퍼블리셔의 스트림을 합쳐주는 역할을 하기는 하지만, 기존 데이터를 받고, 그거에 대해서 또 처리를 하기는 용이 하지 않습니다.

Merge, Append, Prepend등은 위와 같은 도식 형태로 Publisher를 결합하는 반면(오퍼레이터 마다 조금 다릅니다.)

CombineLastest는 퍼블리셔를 결합에 튜플로 뱉습니다.

A_Request.combineLatest(B_Request)
      .sink(receiveCompletion: { _ in }
        receiveValue: { (a, b) in
        let c = C(a: a, b: b)
        print(c)
      })

CombineLastest는 또 좋은점이 순서를 보장 해준다는 것인데요

      Timer.publish(every: 3.0, on: .main, in: .common)
        .autoconnect()
        .sink { [unowned self] _ in
          DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            self.publisher2.send("7")
          }
          DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
            self.publisher1.send("5")
          }

        }
        .store(in: &subscriptions)

위 코드 처럼 명백하게 publisher2에 값이 먼저 도착하고 publisher1에 값이 도착을 해도 결과물은

5다음 7이 들어오게 됩니다.

이 부분은 처음에 combineLastest를 할 때 publisher1뒤에 publisher2를 결합했기 때문입니다. 만약 순서를 바꾸고 싶다면, 결합하는 코드를 바꾸면 되겠죠.

이상 즐거운 컴바인이었습니다.

SwiftUI - 애니메이션 사라질 때 동작하지 않는 경우(SwiftUI Disappear transition not animated)

Hey_Hen — Tue, 10 May 2022 23:29:28 +0900

문제

SwiftUI는 withAnimation으로 간단하게 애니메이션을 할 수 있는데, 종종 사라질 때 이 애니메이션이 작용하지 않는 듯한 모습을 보입니다.

Tap을 하면 Circle은 자연스럽게 opacity Transition이 동작하는데, 글자는 나타날 때는 애니메이션이 잘 되는거 같은데, 사라질 때는 애니메이션이 동작하지 않는 것 처럼 뿅하고 사라집니다.

struct ContentView: View {
  @State var state: Bool = false
  var body: some View {
    VStack {
      Button {
        withAnimation {
          state.toggle()
        }
      } label: {
        Text("Tap \(state ? "On" : "Off")")
      }
      ZStack {
        Circle()
          .foregroundColor(state ? .blue : .clear)
        if state {
          Text("Hello Swift")
          .foregroundColor(state ? .white : .black)
          .font(.system(size: 55))
          .transition(.opacity.animation(.easeIn(duration: 1).delay(0.5)))
        }
      }
    }
  }
}

애니메이션이 되지 않는 것일까요?

아래 백그라운드에 Rectable을 검게 반만 깔아보았습니다. 검은 배경이 있는 곳은 애니메이션이 정상적으로 보이는데

하얀 배경쪽에서는 바로 사라지는 것 처럼 보입니다.

원인

원인은 ZIndex로 Text가 Transition 될 때 ZIndex가 원 보다 아래로 내려가면서 한번에 사라지는 것 처럼 보입니다. 아마 이는 명백한 버그 일 것입니다..

해결

해결법은 간단한데, Text가 Transition 될 때 강제로 ZIndex가 0이 되는 것이 문제이므로, ZIndex를 명시적으로 1로 정하거나 원의 ZIndex를 0보다 낮은 -1 등으로 정하면 해결 할 수 있습니다.

struct ContentView: View {
  @State var state: Bool = false
  var body: some View {
    VStack {
      Button {
        withAnimation {
          state.toggle()
        }
      } label: {
        Text("Tap \(state ? "On" : "Off")")
      }
      ZStack {
        Circle()
          .foregroundColor(state ? .blue : .clear)
        if state {
          Text("Hello Swift")
          .foregroundColor(state ? .white : .black)
          .font(.system(size: 55))
          .zIndex(1)
        }
      }
      .background(Rectangle().foregroundColor(.black).frame(width: UIScreen.main.bounds.width / 2), alignment: .leading)
    }
  }
}

참고

https://sarunw.com/posts/how-to-fix-zstack-transition-animation-in-swiftui/

https://stackoverflow.com/questions/57730074/transition-animation-not-working-in-swiftui

Git - 작업하던 내용 브렌치 옮기기! Git Stash

Hey_Hen — Tue, 12 Apr 2022 00:35:39 +0900

소개

이제 막 현업에서 일을 하게 되었는데, Git-flow가 아직 습관이 안되어서, Feature 브랜치에 작성 할 내용을 실수로 Develope 브랜치에서 작성 해버렸습니다. 작성 내용이 생각보다 많아서, 이를 복사해놓고, 초기화 하고 브랜치를 또 새로 파서 거기에 붙여넣고 하자니 시간이 너무 오래걸릴 것 같더라구요.

그래서 찾아보니 Stash를 통해 간단히 해결할 수 있었습니다.

Stashes

우선 Stash는 은닉이라는 뜻입니다. 커밋하기 전 내용을 로컬 저장소에 잠깐 임시저장 할 수 있는 기능이죠.

커밋 전 내용을 왜 잠시 저장해 두어야 할까요?

예를 들어서 특정 기능을 개발하고 있는데, 해당 기능 동작이 아직 완성 되지 않았는데, 다른 기능을 작성해야 한다고 합니다. 이때 다른 브랜치로 이동하거나 해야 하는데, 그렇다고 커밋을 치자니 기능이 완성이 되지 않아 커밋 룰에 어긋납니다.

잠깐 저장을 할 필요가 있죠, 물론 수동으로 할 수 있습니다. 작성한 내용을 따로 빼 두고, 내용을 초기화 합니다.

하지만 만약, 그래야 하는 내용이 너무나 많다면? 또 그 과정에서 실수가 없을까요?

하지만 Git은 Stash라는 기능을 제공해서 편하게 이 고민을 해결해 줄 수 있습니다.

우선 작업하던 내용은 저장하고 나오세요. 그리고 커밋은 하지 않습니다.

git stash

그리고 terminal에 위와 같이 입력합니다.

그러면 아래 처럼 메시지가 출력되는데, 메시지가 아래처럼 출력이 되고 나면, Modified 이어야 할 작성 하던 파일이, 편집되기 전 상태로 돌아갑니다.

Saved working directory and index state WIP on master: 780e259 git init

이 때 작업물이 사라져서 당황할 수 있지만, 다행히 작업물은 사라지지 않고, 로컬 디렉토리 어딘가에 저장되어 있는 상태입니다.

어디 있을까요?

cd .git/refs/

위 디렉토리로 이동해 보면
stash 라는 파일이 있을 겁니다. stash 파일을 읽으보면

9001f55f2bacf55a47505ae4329cef5c9669e87f

commit id 처럼 해시 값이 하나 존재하고 있는 것을 볼 수 있습니다.

이 내용을 읽어보면

git cat-file -p 9001f55

tree c05ce9e072776b110d4c2b5c6e0a1bc80b899581
parent 780e259d5d9ae0c524095a2156f50efcc265abf9
parent 84396b3b0c28fe16cf6915d85b0ca5b1ddbd0e7f
author urijan44 <teamsva360@gmail.com> 1649688251 +0900
committer urijan44 <teamsva360@gmail.com> 1649688251 +0900

뭔가 내용이 많네요

tree 해시값을 다시 봐보면

git cat-file -p c05ce9e

100644 blob ab983e11d9f77aee6ffc1f1317fa7832dc0e1ee7    README.md

해당 커밋에서 작업 된 내용을 볼 수 있습니다.
여기서 해시값을 또 읽어보면 stash했을 때 내용을 볼 수가 있습니다.

stash한 기록은

git stash list

를 통해 읽어 볼 수 있는데요

stash@{0}: WIP on master: 780e259 git init

위와 같은 형태로 나타납니다.
여기서 stash@{0}은 stash의 이름을 나타낸다고 보면 됩니다. culry brace 안에 숫자는 stash의 index를 나타내는데, 새로 들어오는 stash는 가장 빠른 Index 즉 0이 됩니다. stack 형태로 저장이 되는 겁니다.

그런데, 위 내용만 보고서는 어떤 내용을 stash했는지 알기가 어렵죠. 해시값 하나하나 읽어가며 내용을 파악하는 것은 시간 낭비가 큽니다.
따라서 Commit 할때 메시지를 같이 입력하듯, stash도 메시지를 함께 입력할 수 있습니다.

git stash push -m "main.swift write"

위와 같이 입력하면 stash 할때 메시지를 같이 전달할 수 있고, stash list를 통해 보면

stash@{0}: On master: main.swift write
stash@{1}: WIP on master: 780e259 git init

message에 쓴 내용을 볼 수가 있습니다.

Stash Apply

이제 Stash한 내용을 가져와서 적용해봅시다.

앞서 제가 Feature Branch에 작업할 내용을 실수로 Develope 브랜치에다가 작업을 했다고 했죠?

Develope 브랜치에서 작업한 내용을 우선 Stash 했다면 Feature Branch로 Checkout 합니다.

git stash apply stash@{0}

그리고 apply 명령어와 stash 이름으로 현재 브랜치에 stash 내용을 적용할 수 있습니다.

이렇게 하면 현재 브랜치의 상태가 stash에 저장한 작업하던 내용을 그대로 불러올 수 있습니다.

이를 통해서 다른 브랜치 커밋을 어지럽히거나!, 수고스럽게 파일을 초기화 했다 붙여넣을 필요가 없어졌습니다

Stash Clear

stash를 apply를 통해 작업이 끝났으면, stash를 지워주는게 좋을 것입니다.

stash list를 통째로 날려버리는 명령어는 아래와 같습니다.

git stash clear

만약 특정 stash만 지우고 싶다면

git stash -q drop stash@{0}

0에다 stash를 인덱스만 갈아 끼워넣어주면, 특정 stash를 삭제할 수 있습니다.

Reference

raywenderlich: Advanced Git

https://hyuna-tech.tistory.com/entry/github-일종의-임시저장-git-stash-사용법

SeSAC(청년취업사관학교) iOS 앱 개발자 데뷔 과정 수료+비전공자 취업 후기

Hey_Hen — Wed, 6 Apr 2022 23:20:43 +0900

소개

SeSAC(청년취업사관학교, 이하 SeSAC)에서 진행한, iOS 앱 개발자 데뷔 과정 수료 및 취업 후기를 써보고자 합니다.

결론부터 얘기하자면 수료 후 한달만에 꽤 규모있는 회사에 취업했고, 원래 있던 업계에서는 상상도 못할 대우를 받으며 회사를 다니고 있습니다.

우선 본인은 예술대학교에서 4년제를 취득한 예술학사로 배경이 개발과는 완전무관합니다. (다만 전공 특수성 때문에 이과랑 거리가 없지는 않습니다.)

졸업 후 행정 사무직으로 2년, 전공 관련 업무로 1년의 회사생활을 하면서, 비생산적인 일에 실증이 나 있었습니다. 업무를 더 잘하고 싶어서, 사무자동화와 파이썬, C/C++를 공부해서 업무에 자동화를 도입했지만, 본인의 성장과는 거리가 있었습니다.

2주 가까이 걸리던 작업을 1~2일로 시간 단축을 해냈지만, 업무 속도가 빠를 뿐 그게 제 커리어가 되지는 못했습니다. 결국은 업계에 대한 불만이지만 자세한 내용은 생략하겠습니다.

조금이나마 사용했던 개발이 가져다 주었던 성취감과 결과물은 그간 제 고민들의 출구가 되었습니다. 생산적이고, 제가 노력하는 만큼 결과와 커리어를 가져다 줄 수 있는 그런 일이요.

그렇게 퇴사를 결심했습니다.

무턱대로 퇴사를 결정한 것은 아닙니다. 개발자로 취업하는데 걸리는 시간과 비용, 학습, 취업 플랜을 (나름) 철저히 준비한 다음의 퇴사입니다.

퇴사 후

우선은 분명한 목표가 중요했는데, 첫번째는 어떤 개발자가 될 것인지 입니다.

개발자 분류

- 웹 프론트엔드

- 백엔드

- 안드로이드

- iOS

- 게임 클라이언트

- 게임 서버 개발자

위에 나열한 개발자 보다, 훨씬 더 많은 개발자 종류가 있습니다. 어떤 개발자가 있는지는 원티드에서 자세히 볼 수 있습니다.

이 중에서 비전공자 이면서, 빠르게 취업할 수 있는 직군은, 웹 프론트엔드와 안드로이드 입니다.

어느 쪽이 쉬워서 비전공자가 빠르게 취업할 수 있는 것은 아니고, 웹 프론트엔드와 안드로이드는 강의와 레퍼런스가 정말 많아서 배우기가 쉽고, 신입 채용도 비교적 많은 편입니다.

저는 그 중에서 iOS 개발자 신입을 선택했는데, 숨고에서 개발자 취업 커리어 컨설팅을 돈주고 받은 적이 있는데, iOS 개발자는 비추하시더라구요... 아무렴 앞서 웹 프론트엔드와 안드로이드를 추천한 이유와 딱 정반대의 이유를 가지고 있습니다. 강의와 레퍼런스가 부족하고, 주변에서도 잘 모를 뿐더러, 신입 수요도 진짜 없는 편입니다.

따라서 개발자 직군 선택은 여건에 맞게 선택하시면 될 것 같습니다. 주변에서 어렵다고 해도 본인이 정말 그 직군이 하고싶고, 자신이 있으시면 선택 하셔도 전혀 문제 없을 것 같습니다.

왜냐하면 여기서 다시 SeSAC 얘기가 나오는데요, 들어가서 보시면 아시겠지만, 웹 프론트부터 안드로이드, iOS(백엔드는 안보이네요) 등 양질의 교육과정이 준비 되어있습니다. 지금은 작년 사업을 종료해서 표시가 안되는 교육과정이 있는데, 관심있는 분야의 교육과정을 열릴 계획이 있는지 기관에 문의 해보는게 좋을 것 같습니다.

iOS 앱 개발자 데뷔 과정

제가 SeSAC에서 진행한 교육과정은 iOS 앱 개발자 데뷔 과정으로, 9월 27일 부터 3월 8일 까지 총 6개월 간 교육을 실시 했습니다. 지금은 교육이 종료되어서 홈페이지에서 교육과정을 볼 수 없는데, 제가 볼 때 여타 유료 교육과정과 비교해도 취업하기에 필요한 역량을 충분히 갖출 수 있는 교육과정이라고 생각했습니다.

교육 과정은 다른 사설 교육 기관(국비지원 아닌 교육기관!) 과 비교해서 보면, 얼마나 실무적인지 파악할 수 있을 것 같아요.

iOS앱 개발 교육 같은 경우는, 사설 교육비가 굉장히 비싸고, (6개월에 700정도 합니다..) 기회도 많지 않습니다. 하지만 iOS 앱 개발자 데뷔 과정은 '무료' 교육과정입니다. (처음에 15만원인가? 돈을 내고 수료하면 100% 돌려받습니다!) (대신 맥북이라는 투자금이 별도로 든다)

교육과정 합격 과정

신청은 자기소개서 제출과 코딩 테스트를 보았던 것으로 기억합니다.

서류 심사 -> 코딩 테스트 -> 면접 심사

로 총 3단계에 걸쳐 심사를 하고, 최종적으로 선발되면 교육에 참여하게 됩니다.

서류 합격 후 코딩 테스트 까지 시간이 꽤 되므로 Swift에 대해서 전혀 몰라도 충분히 합격할 수 있을 만큼 공부할 시간이 됩니다! 저는 해당 교육과정 이전에 독학으로 6개월간 iOS와 Swift를 공부했기 때문에 크게 어렵지는 않았습니다.

코딩 테스트에 합격하면 면접을 실시합니다. 저는 코로나 때문에 면접을 온라인 미팅으로 보았네요! 굉장히 무서웠습니다. 면접 준비도 꼭 따로 하시는게 좋다고 생각합니다.

교육

교육은 Swift, iOS, CS 를 주차 교육 계획에 맞게 실시했습니다. 코로나 때문에 Zoom을 통해서 수업을 진행했습니다. 오전은 Zoom으로 수업을 듣고 오후에는 당일 과제를 수행했는데 여기부터는 개인이 하는만큼 공부를 할 수 있습니다.

대학 교수가 학생들에게 수업을 가르치는 탑-다운 방식이 아니라, 스스로 공부한 만큼 멘토링을 받을 수 있는 바텀-업 방식의 교육이기 때문입니다.(교육 용어가 있었는데 기억이 안나네요!) 플립드 러닝이기도 한 것 같습니다.

만약 강사님들이 단순한 티쳐 였다면, 불가능 했을 얘기 인 것 같습니다. 저는 6개월의 독학 기간 중 가장 힘들었던 것이, 제가 지금 바른 방향으로 가고 있는지 스스로 점검할 수 없다는 점이었습니다. iOS가 아무리 강의랑 레퍼런스가 부족하다고 하지만, 사실 영어로 검색하면 다 나옵니다. 애초에 Apple에서 자기내 OS앱 만들어서 내라고 A to Z부터 다 알려줍니다. 그러니까 결국 중요한 것은 '하는 법'이 아닙니다.

9시부터 12시 까지 수업을 듣고, 점심먹고 나면 밤새도록 그날 배운거 정리하고, 디벨롭 하고, 과제를 수행합니다. 그러다 보면 이미 해 뜰 시간이고 컴퓨터 앞에서 기절하고 일어나서 수업듣고, 그렇게 공부 지옥을 6개월을 지냈네요. 어떻게 공부하고 기록했는지는 제 깃헙에서 볼 수 있습니다.

https://github.com/urijan44/SeSAC-Assignments

GitHub - urijan44/SeSAC-Assignments: SeSAC과정 Assignmnets

SeSAC과정 Assignmnets. Contribute to urijan44/SeSAC-Assignments development by creating an account on GitHub.

github.com

(지금 보면 진짜 쉬운 것 밖에 없네요! 그만큼 왠만한 개발은 다 할 수 있다는 자신감이 생겼습니다)

이 외에도 같은 수강생 끼리 별도의 코테 스터디를 진행 하기도 했고, 나중에는 팀 단위로 코드 리뷰를 하거나 협업을 하기도 했습니다.

iOS, Swift 멘토링 외에도 공부가 너무 힘들 때는 공부 멘토링을 받기도 했고 자소서, 포폴 첨삭, 모의 면접도 수차례나 받았습니다. 힘들었지만, 사설 학원에서 돈주고 받기도 힘든걸 진짜 엄청 많이 받아서, 멘토님들 한테 너무너무 감사하다는 말 전하고싶네요!

취업까지

사실 취업은 10월 쯤에 이미 최종합격을 두 군데 성공 했습니다. 교육과정을 통해서 배운 것대로 면접에서 쪽집게 처럼 나온 것도 아주 큰 역할을 한 것 같습니다.

다만 이때는, 아직 스스로 실력에 자신이 없었고 더 공부하고 싶다는 생각이 커서 입사를 거절하고 3월 최종 수료까지 진행하게 되었습니다.

2월 부터 본격적으로 취업 활동을 시작한 것 같은데, 시기가 시기인 만큼 경쟁자가 꽤 많았습니다. 당장 대학 졸업 후 취업전선에 뛰어드는 컴공생 전공자들과, 같은 수료생!

멘토님들의 도움 + 운 덕분에 추가로 4군데 더 최종 합격해서 그 중에서 가장 큰 회사로 취업 하게 되었습니다.

...

처음에 준비할 때 주변에서 iOS도 비추천 했고, 본 교육과정도 비추천 했습니다. 하지만 너무 좋은 기회였고, 잘했다는 생각이 듭니다. 최고의 6개월 이었던 것 같습니다. 비전공자 이지만 개발자로 취업 예정이 있다면 진짜 좋은 선택지라고 생각합니다. 조금이라도 생각이 있다면 망설이지 말고 꼭 도전해보셨으면 좋겠습니다.

혹시나 비전공자 인데, 개발자 취업을 준비하고 있고 고민이 있다면 댓글 남겨주세요!

LeetCode - Merge Two Sorted Lists, Swift

Hey_Hen — Sat, 26 Mar 2022 21:12:24 +0900

https://leetcode.com/problems/merge-two-sorted-lists/

Merge Two Sorted Lists - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

오랜만에 리트코드

- 두개의 `정렬된` 링크드 리스트를 하나의 정렬된 리스트로 만들어 내는 것

- 기본 알고리즘은 아래와 같다.

위와 같이 두개의 링크드 리스트가 있으면 각 리스트를 노드를 가리키는 참조 인스턴스가 있다.

Left와 Right의 CurrentNode의 Val중 누가 더 작은지 대소 비교를 해서 더 작은 노드를 Head의 next Node로 전달한다.

지금은 Left의 CurrentNode는 1이고, Right의 CurrentNode 3이므로 또 3과 1을 대소 비교 한다.

이 작업을 다음 노드가 없을 때 까지 반복 해주면 된다. 아주 간단!

코드로는 아래와 같다.

/**
 * Definition for singly-linked list.
 * public class ListNode {
 *     public var val: Int
 *     public var next: ListNode?
 *     public init() { self.val = 0; self.next = nil; }
 *     public init(_ val: Int) { self.val = val; self.next = nil; }
 *     public init(_ val: Int, _ next: ListNode?) { self.val = val; self.next = next; }
 * }
 */
class Solution {
    func mergeTwoLists(_ list1: ListNode?, _ list2: ListNode?) -> ListNode? {
        
        var leftNode = list1
        var rightNode = list2

        var head: ListNode? = ListNode(101)
        var currentNode: ListNode? = head
        while let node = currentNode {
            if leftNode != nil, rightNode != nil {
                if leftNode!.val < rightNode!.val {
                    node.next = leftNode
                    leftNode = leftNode?.next
                } else {
                    node.next = rightNode
                    rightNode = rightNode?.next
                }
            } else {
                node.next = leftNode != nil ? leftNode : rightNode
                break
            }
            currentNode = node.next
        }
        return head?.next
    }
}

BOJ1158 - 요세푸스 문제, Swift

Hey_Hen — Fri, 25 Mar 2022 23:33:34 +0900

https://www.acmicpc.net/problem/1158

1158번: 요세푸스 문제

첫째 줄에 N과 K가 빈 칸을 사이에 두고 순서대로 주어진다. (1 ≤ K ≤ N ≤ 5,000)

www.acmicpc.net

수가 작아서, remove(at:)을 써도 되는 문제, 만약 n이 커진다면, 링크드리스트나, 다른 접근 방법 필요

func boj1158() {
  let input = readLine()!.split(separator: " ").map{ Int(String($0))! }
  let (n, k) = (input[0], input[1])

  var arr: [Int] = .init(1...n)
  var count = k - 1

  var result = "<"

  while arr.count > 0 {
    count = count >= arr.count ? count % arr.count : count

    result.write("\(arr.remove(at: count)), ")
    count += (k - 1)
  }

  result.removeLast(2)
  result.write(">")
  print(result)
}

boj1158()

프로그래머스 - 등굣길, Cpp

Hey_Hen — Tue, 22 Mar 2022 01:26:25 +0900

https://programmers.co.kr/learn/courses/30/lessons/42898

코딩테스트 연습 - 등굣길

계속되는 폭우로 일부 지역이 물에 잠겼습니다. 물에 잠기지 않은 지역을 통해 학교를 가려고 합니다. 집에서 학교까지 가는 길은 m x n 크기의 격자모양으로 나타낼 수 있습니다. 아래 그림은 m =

programmers.co.kr

- 목표 지점까지 가장 빠르게 도착하는 패스가 몇 개인지 를 물어보는 문제로, 문제 유형이 DP로 이미 공개되어있어서 쉽게 접근할 수 있다.

1. 우선 m x n을 row x col 좌표로 두고, 시작점 0,0을 1로 초기화 나머지를 0으로 초기화 한다.

2. puddles이 있는 경우는 -1로 초기화 한다.

3. 문제가 오른쪽과 아래쪽으로만 움직일 수 있기 때문에, 패턴을 단순화 할 수 있다.

row/col	m1	m2
n1	1	0
n2	0	0

DP의 특성상 큰 문제를 작은 문제로 나누어서 생각해 볼 수 있는데,

row를 바깥 루프, col을 안쪽 루프로 이중 for 문을 돌면서 보면

먼저 (0,0)에서 다음 좌표는 오른쪽 또는 아래로 (1,0) 또는 (0,1)이다. 각 좌표로 갈 수 있는 방법은 방금 0,0에서 접근한 한가지 방법 뿐으로 아래처럼 된다.

row:0, col:0

row/col	m1	m2
n1	1	1
n2	1	0

그 다음 col인 (0,1)에서 다시 시작해서 다음 좌표를 보면, (1, 1) 이 유일한데

그럼 여기서 (0,1)에서 (1,1)로 접근했으로 (1,1)도 1이다.

row:0, col:1

row/col	m1	m2
n1	1	1
n2	1	1

그 다음 col이 끝났으므로 col을 다시 0으로 초기화 하고 row를 1증가 시키면

row:1, col:0

row/col	m1	m2
n1	1	1
n2	1	2

(1,0)에서 다음 좌표는 (1,1)로 갈 수 있는데,

아까 (0,1)에서 접근해서 이미 (1,1)은 1이다.

여기에 더해서 (1,0)에서 접근할 수 있기 때문에 (1,1)은 최종적으로 2가 된다.

여기서 한가지 의문점은, 모든 방법이 그럼 가장 빠른 방법일까 하는 것인데? 본 문제에서 아래-오른쪽 으로만 이동해보면, 도착 거리가 다 똑같다는 것을 알 수 있다. 따라서 앞서 한 작은 문제를 확장시켜 적용하기만 하면 문제는 풀린다.

#include <string>
#include <vector>

using namespace std;

int solution(int m, int n, vector<vector<int>> puddles) {
    const int mod = 1000000007;
    int dp[n][m];
    for (int r = 0; r < n; r++) {
        for (int c = 0; c < m; c++) {
            dp[r][c] = 0;
        }
    }
    for (int i = 0; i < puddles.size(); i++) {
        dp[puddles[i][1] - 1][puddles[i][0] - 1] = -1;
    }
    
    dp[0][0] = 1;
    int dx[2] = {0, 1};
    int dy[2] = {1, 0};
    
    for (int row = 0; row < n; row++) {
        for (int col = 0; col < m; col++) {
            if (dp[row][col] == -1) { continue; }
            for (int index = 0; index < 2; index++) {
                int nx = row + dx[index];
                int ny = col + dy[index];
                if(nx >= n || ny >= m || (dp[nx][ny] == -1)) { continue; }
                dp[nx][ny] = (dp[row][col] + dp[nx][ny]) % mod;
            }
                
        }
    }
    return dp[n-1][m-1];
}

iOS - URLCache

Hey_Hen — Mon, 21 Mar 2022 16:45:44 +0900

소개

Cache(캐시)는 컴퓨팅에서 데이터를 일시적으로 저장하는 것을 뜻한다.
어플리케이션에서 캐시는 요긴하게 쓰이는데, 예를 들어 네트워크 요청을 할 때, 한 번 요청한 결과에 대해서 캐시를 해두고, 다음에 해당 요청을 한번 더 할 때 네트워크 요청을 하지 않고 캐시에서 결과를 가져 올 수 있다. 정리하자면 아래와 같은 장점이 있다.

클라이언트에서는 요청 결과를 훨씬 더 빨리 화면에 보여줄 수 있다.
서버에서는 동일한 요청에 대해 동작을 중복 수행하지 않아도 된다.

URLCache

iOS에서 네트워크 요청을 하기 위해서는 URLSession이라는 API를 사용하는데, URLSession의 Task에는 대표적으로 몇가지 종류가 있다.

DataTask
DownloadTask

Steam이나, Socket, Upload는 예외하겠다.
두 Task는 모두 요청 결과를 받아오는 동작을 수행할 수 있는데, 조금 다른 결과를 가져온다.

DataTask: Cache정책에 따라 memory와 disk에 동시에 cache한다. 시간이 지나면 memory에서는 해제된다.
DownloadTask: 다운로드 한 파일을 메모리에 Cache하고, disk에는 cache하지 않는다. (Tep Directory에 저장하고 필요가 없어지면 지운다.)

URLSession은 고맙게도 default 구성이 cache를 자동으로 실시한다.
Cache된 데이터는 Library/Caches~ 에 저장되며, 클라이언트에서 같은 네트워크 요청이 있을 때, 별도의 코드없이 자동으로 Cache를 확인하고, 디스크에서 불러온다.
하지만 이때, 모든 데이터가 Cache되는 것은 아닌데, URLSession는 URLCache에 의존하고 있는데, URLCache가 default로 가지고 있는 메모리, 디스크 용량 제한이 있다.
이때 용량 제한은 아래와 같다.

Memory Capacity: 4MB
Disk Capacity: 20MB

별도로 지정해 주지 않으면, 큰 파일은 자동으로 Cache되지 않는다.
이를 해결하는 방법은 URLCache 인스턴스를 새로 생성해 URLSession 프로퍼티에 할당하거나, URLCache에 store메서드를 통해 저장할 수 있다.

let ownCache = URLCache(memoryCapacity: 20*1024*1024*1024, diskCapacity: 80*1024*1024*1024, directory: FileManager.default.urls(for: .cachesDirectory, in: .userDomainMask)[0].appendingPathComponent("DownloadImage"))

private lazy var session: URLSession = {
    let configuration = URLSessionConfiguration.default
    configuration.urlCache = ownCache
    return URLSession(configuration: configuration, delegate: self, delegateQueue: nil)
  }()

URLSessionConfiguration을 통해 URLCache 인스턴스를 전달할 수 있다.
이 방법은 정해진 용량 아래서, session의 데이터 받아오기가 끝나면 자동으로 Cache가 된다.
혹은 데이터 다운로드가 완료된 시점에서

ownCache.storeCachedResponse(.init(response: task.response!, data: self.data!), for: task.currentRequest!)

storeCachedResponse를 통해서 데이터를 저장할 수 있다.
만약 별도의 URLCache 인스턴스를 URLSession으로 전달하지 않았다면 URLCache는 싱글톤 인스턴스를 제공하기 때문에 이를 이용할 수 있다.

URLCache.shared.storeCachedResponse(.init(response: task.response!, data: self.data!), for: task.currentRequest!)

DownloadTask는 앞서 Cache 하지 않는다고 얘기했는데, 위와 같이 동일한 방법으로 Cache 할 수 있다. 다른 방법이라면 DownloadTask는 데이터를 디스크에 쓴 다음 Location URL을 제공하는 것만 다를 뿐이다.

DataTask vs DownloadTask

DataTask와 DownloadTask는 각각 언제 사용하는 것이 좋을까?
Cache는 언제 Cache하고, 삭제하고, 업데이트 하는지에 대한 내용은 Cache Policy를 따른다.
이게 왜 중요하냐면
URLSessionDataTask는 자동으로 Data를 Cache한다고 앞서 얘기했는데, 예를들어 Daum 검색 API를 URLSessionDataTask로 요청을 보냈다고 한다면, API는 검색 결과를 Data로 보낼 것이다.
이때 Cache 덕분에 동일한 요청 결과에 대해서는 API에 추가적으로 요청하지 않고, 클라이언트에서 빠르게 보여줄 수 있지만, 만약 잠깐 사이에 검색 결과가 변경이 되었을 가능성이 있는데, 클라이언트에서는 Cache 때문에 해당 요청에 대해 업데이트 Data를 받아오지 않고, Cache한 Data를 보여줄 수 있다.

이러한 결과가 나타내는 바는, Cache는 특정 시점을 선택하고, 시점에 따라 삭제하고 업데이트 해야 한다는 것이다. 그 시점은 특정 기간일 수도 있고, 애플리케이션이 종료되는 시점일 수도 있다. 클라이언트 입장에서 Cache는 언제 삭제되어도 이상하지 않은 기록 방법인 것이다.
반면 DownloadTask는 그 기능을 보면 알지만 더 큰 Data를 받는데 특화되어 있다. 예를들어 Background 다운로드, Data 이어서 받기와 같은...
이러한 큰 Data는 다운받은데 큰 네트워크 리소스를 사용하므로 클라이언트가 종료되었다고 삭제할 수는 없다.
또 다운로드 한 Data의 목적에 따라 저장되어야 하는 Directory가 다르기 때문에, 마찬가지로 구분 되어야 한다.

참고

HTTP Cache로 불필요한 네트워크 요청 방지

불필요한 네트워크 요청을 어떻게 피할 수 있습니까? 브라우저의 HTTP 캐시는 첫 번째 방어선입니다. 이 방법이 반드시 가장 강력하고 유연한 방법은 아니며 캐시된 응답의 수명을 제한적으로 제

web.dev

https://stackoverflow.com/questions/48516806/cache-handling-with-moya

Cache Handling with Moya

We have implemented Moya, RxSwift And Alamofire as pods in our project. Does anyone know how you gain control of the cache policies per url request using this tech? I have read through quite a ...

stackoverflow.com

https://nshipster.com/nsurlcache/

2022 KAKAO BLIND RECRUITMENT - 양궁대회

Hey_Hen — Fri, 18 Mar 2022 11:44:20 +0900

https://programmers.co.kr/learn/courses/30/lessons/92342

코딩테스트 연습 - 양궁대회

문제 설명 카카오배 양궁대회가 열렸습니다. 라이언은 저번 카카오배 양궁대회 우승자이고 이번 대회에도 결승전까지 올라왔습니다. 결승전 상대는 어피치입니다. 카카오배 양궁대회 운영위원

programmers.co.kr

- 너무 무식하게 접근했는데, 다른 사람 풀이보고 공부해야 겠다.

- 기본적으로 bfs 접근 방식이니, 라이언의 info를 set형태로 visited를 체크하면 속도는 좀 올라갈듯.

import Foundation
let scoreBoard = [10,9,8,7,6,5,4,3,2,1,0]

struct Queue {
  var leftStack: [Game] = []
  var rightStack: [Game] = []
  var appeachInfo: [Int] = []
  var maxScoreGame: [Int] = [-1]
  var maxScore: Int = -1

  var count: Int {
    leftStack.count + rightStack.count
  }

  mutating func enqueue(_ element: Game) {
    leftStack.append(element)
    maxScoreCalculating(element.info)
  }

  mutating private func maxScoreCalculating(_ lyonGame: [Int]) {
    let (appeahScore, lyonScore) = scoreCalculating(appeachInfo, lyonGame)
    let scoreDifference = lyonScore - appeahScore
    if scoreDifference > 0,
        maxScore < scoreDifference {
      maxScore = scoreDifference
      maxScoreGame = lyonGame
    } else if scoreDifference > 0, maxScore == scoreDifference {

      for (previous, new) in zip(maxScoreGame, lyonGame).reversed() {
        if new > previous {
          maxScoreGame = lyonGame
          return
        } else if new < previous {
          return
        }
      }
    }
  }

  mutating func dequeue() -> Game? {
    if rightStack.isEmpty {
      rightStack = leftStack.reversed()
      leftStack.removeAll()
    }
    return rightStack.popLast()
  }

  func scoreCalculating(_ appeach: [Int], _ lyon: [Int]) -> (appeach: Int, lyon: Int) {
    var appeachTotalScore = 0
    var lyonTotalScore = 0

    for (index, (appeachArrow, lyonArrow)) in zip(appeach, lyon).enumerated() {
      if appeachArrow != 0 && appeachArrow >= lyonArrow {
        appeachTotalScore += scoreBoard[index]
      } else if lyonArrow != 0 {
        lyonTotalScore += scoreBoard[index]
      }
    }
    return (appeachTotalScore, lyonTotalScore)
  }
}

struct Game {

  var remainArrow: Int
  var info: [Int] = .init(repeating: 0, count: 11)
  var index: Int = 0

  mutating func shot(_ amountOfArrow: Int) {
    defer {
      index += 1
    }

    guard remainArrow >= amountOfArrow,
            amountOfArrow > 0 else {
      info[index] = index == 10 ? remainArrow : 0
      return
    }
    info[index] = amountOfArrow
    remainArrow -= amountOfArrow
    return
  }

  init(remainArrow: Int) {
    self.remainArrow = remainArrow
  }

  init(game: Game) {
    self.remainArrow = game.remainArrow
    self.info = game.info
    self.index = game.index
  }
}

func solution(_ n:Int, _ info:[Int]) -> [Int] {
  var queue = Queue()
  queue.appeachInfo = info
  queue.enqueue(Game(remainArrow: n))
  for arrow in info {
    for _ in 0..<queue.count {
      guard let element = queue.dequeue() else { break }

      var shot = Game(game: element)
      var dontShot = Game(game: element)

      shot.shot(arrow + 1)
      dontShot.shot(0)

      queue.enqueue(shot)
      queue.enqueue(dontShot)
    }
  }
  return queue.maxScoreGame
}

2022 KAKAO BLIND RECRUITMENT - k진수에서 소수 개수 구하기, Swift

Hey_Hen — Tue, 15 Mar 2022 23:01:18 +0900

https://programmers.co.kr/learn/courses/30/lessons/92335

코딩테스트 연습 - k진수에서 소수 개수 구하기

문제 설명 양의 정수 n이 주어집니다. 이 숫자를 k진수로 바꿨을 때, 변환된 수 안에 아래 조건에 맞는 소수(Prime number)가 몇 개인지 알아보려 합니다. 0P0처럼 소수 양쪽에 0이 있는 경우 P0처럼 소

programmers.co.kr

1. 입력받은 숫자를 k진수로 바꾸고, 변환된 정수에서 조건에 맞는 소수를 찾아내는 문제

2. 0P0 조건을 4줄이나 설명되어 있는데, 잘 생각해보면 그냥 0을 기점으로 수를 나눠버리면 된다.

3. 소수를 구하는 가장 빠른 방법을 생각해보면 문제는 쉽게 풀린다.

import Foundation

func solution(_ n:Int, _ k:Int) -> Int {
  var result = 0
  var primeSet: Set<String> = []
  let kradix = String(n, radix: k, uppercase: true)
  var stack: String = ""

  func stackCheck(_ stack: inout String) {
    guard !stack.isEmpty else { return }
    if primeSet.contains(stack) {
      result += 1
    } else if isPrime(stack) {
      result += 1
      primeSet.insert(stack)
    }
    stack = ""
  }

  for number in kradix {
    if number != "0" {
      stack.write(String(number))
    } else {
      stackCheck(&stack)
    }
  }
  stackCheck(&stack)
  return result
}

func isPrime(_ number: String) -> Bool {
  let number = Int(number)!
  return number.isPrime
}

extension Int {
  var isPrime: Bool {
    guard self >= 2 else { return false }
    guard self != 2 else { return true  }
    guard self % 2 != 0 else { return false }
    return !stride(from: 3, through: Int(sqrt(Double(self))), by: 2).contains { self % $0 == 0 }
  }
}

2022 KAKAO BLIND RECRUITMENT - 주차요금 계산하기, Swift

Hey_Hen — Mon, 14 Mar 2022 22:33:21 +0900

https://programmers.co.kr/learn/courses/30/lessons/92341?language=swift

코딩테스트 연습 - 주차 요금 계산

[180, 5000, 10, 600] ["05:34 5961 IN", "06:00 0000 IN", "06:34 0000 OUT", "07:59 5961 OUT", "07:59 0148 IN", "18:59 0000 IN", "19:09 0148 OUT", "22:59 5961 IN", "23:00 5961 OUT"] [14600, 34400, 5000]

programmers.co.kr

1. 차량 출입과 그 시간을 계산하는게 핵심

2. 해당 차량의 총 주차장 이용 시간은 PlainTime(시:분 이 아니라 분으로 총 환산)만 계산해주면 어렵지 않다. 예를들어 6시 40분에 출입해서 7시 30분에 나갔다면 총 이용시간은 50분인데, 6시 40분을 PlainTime으로 환산하면 400분 과 같고, 7시 30분은 450분으로 결국 두 시각의 차이는 50분으로 동일하다.

import Foundation

final class ParkingTime: CustomStringConvertible {
  enum InOut {
    case `in`
    case out
  }

  private var currentInTime: Int = 0
  var totalUsedTime: Int = 0

  func setTime(_ time: String, type: InOut) {
    let plainTime = timeConvert(time)
    switch type {
      case .in:
        currentInTime = plainTime
      case .out:
        totalUsedTime += plainTime - currentInTime
        currentInTime = 0
    }
  }

  private func timeConvert(_ time: String) -> Int {
    let convert = time.components(separatedBy: ":")
    let hour = Int(convert[0])! * 60
    let minute = Int(convert[1])!
    return hour + minute
  }

  var description: String {
    totalUsedTime.description
  }
}

final class Parking {
  private var baseTime: Int = 0
  private var baseFee: Int = 0
  private var unitTime: Int = 0
  private var unitFee: Int = 0

  private var currentCarList: [String: ParkingTime] = [:]
  private var remain: Set<String> = []

  init() { }

  var feeList: [Int] {
    let sorted = currentCarList.sorted { lhs, rhs in
      lhs.key < rhs.key
    }

    return sorted.map {
      let totalTime = $0.value.totalUsedTime
      return feeCaculate(totalTime)
    }
  }

  private func feeCaculate(_ time: Int) -> Int {
    if time > baseTime {
      return baseFee + Int(ceil(Double(time - baseTime) / Double(unitTime))) * unitFee
    } else {
      return baseFee
    }
  }

  func setRecored(_ records: [String]) {
    records.forEach {
      let (time, carNumber, type) = recoredDecorder($0)
      if type == "IN" {
        remain.insert(carNumber)
      } else {
        remain.remove(carNumber)
      }
      if let car = currentCarList[carNumber] {
        car.setTime(time, type: type == "IN" ? .in : .out)
      } else {
        let parkingTime = ParkingTime()
        parkingTime.setTime(time, type: type == "IN" ? .in : .out)
        currentCarList[carNumber] = parkingTime
      }
    }

    remain.forEach { carNumber in
      guard let car = currentCarList[carNumber] else { return }
      car.setTime("23:59", type: .out)
    }
  }

  func setFees(_ fees: [Int]) {
    baseTime = fees[0]
    baseFee = fees[1]
    unitTime = fees[2]
    unitFee = fees[3]
  }

  private func recoredDecorder(_ record: String) -> (String, String, String) {
    let line = record.components(separatedBy: " ")
    return (line[0], line[1], line[2])
  }
}

func solution(_ fees:[Int], _ records:[String]) -> [Int] {

  let parking = Parking()
  parking.setFees(fees)
  parking.setRecored(records)

  return parking.feeList
}

Run Loop vs DispatchQueue

Hey_Hen — Sun, 13 Mar 2022 18:25:37 +0900

Combine을 사용할 때, debounce와 같은 오퍼레이터를 사용하면 scheduler를 지정해 주어야 한다. (그 외에도 scheduler를 지정해주는 상황)

이때 지정해 줄 수 있는 것은 RunLoop.main 과 DispatchQueue.main 인데 이 둘은 무슨 차이일까?

query.debounce(for: .milliseconds(800), scheduler: RunLoop.main)

query.debounce(for: .milliseconds(800), scheduler: DispatchQueue.main)

직접 실행해 보면 얼핏 차이가 없는 것처럼 보이지만 실제로는 중요한 차이가 있다.

RunLoop.main 를 스케줄러로 사용하면 사용자의 터치 반응 등의 이벤트가 전달되지 않는다.

따라서 스크롤 중에는 debounce가 제대로 되지 않는 다는 뜻

반면 DispatchQueue.main 터치 반응 등의 이벤트가 동작 하는 도중에도 이벤트가 전달이 된다.

RunLoop.main은 RunLoop.main.perform 을 호출하고 DispatchQueue.main은

DispatchQueue.main.async를 호출하기 때문!

출처: https://stackoverflow.com/questions/56724566/runloop-vs-dispatchqueue-as-scheduler/58849015#58849015

2019 KAKAO BLIND RECRUITMENT - 오픈 채팅방, Swift

Hey_Hen — Sun, 13 Mar 2022 00:21:53 +0900

https://programmers.co.kr/learn/courses/30/lessons/42888

코딩테스트 연습 - 오픈채팅방

오픈채팅방 카카오톡 오픈채팅방에서는 친구가 아닌 사람들과 대화를 할 수 있는데, 본래 닉네임이 아닌 가상의 닉네임을 사용하여 채팅방에 들어갈 수 있다. 신입사원인 김크루는 카카오톡 오

programmers.co.kr

1. 핵심은 출입로그 메시지에서 이름이 변경된 유저의 로그 내용을 변경해야 한다는 뜻이다. 일일이 서치해서 지우기에는 입력 받는데 O(N), 출력문으로 컨버팅 하는데 O(N) 으로 O(N^2)이므로 여유가 없다. 따라서 User를 클래스로 정의하고, 참조를 통해 해결해 볼 수 있다.

2. User는 id로 구분 가능한 Hashable 객체이다.

3. Chat 클래스는 Log 형태로 User를 소유하고 있고, Enter, Leave, Change 명령어를 수행할 때 이름을 참조해서 바꾸기 때문에, 별도의 시간 소모 없이 수행이 가능하다.

import Foundation

final class User: Equatable, Hashable {
  let id: String
  var name: String

  init(id: String, name: String) {
    self.id = id
    self.name = name
  }

  static func == (lhs: User, rhs: User) -> Bool {
    lhs === rhs
  }

  func hash(into hasher: inout Hasher) {
    hasher.combine(id)
  }
}

final class Chat {

  enum Log: CustomStringConvertible {
    case enter(User)
    case leave(User)

    private func messageFormatter(log: Log) -> String {
      switch log {
        case .enter(let user):
          return "\(user.name)님이 들어왔습니다."
        case .leave(let user):
          return "\(user.name)님이 나갔습니다."
      }
    }

    var description: String {
      messageFormatter(log: self)
    }
  }

  private var log: [Log] = []

  private var userList: [String: User] = [:]

  var message: [String] {
    log.map{$0.description}
  }

  func enter(user: User) {
    if let alreadyUser = userList[user.id] {
      log.append(.enter(alreadyUser))
      alreadyUser.name = user.name
    } else {
      log.append(.enter(user))
      userList.updateValue(user, forKey: user.id)
    }
  }

  func leave(userId: String) {
    guard let user = userList[userId] else { return}
    log.append(.leave(user))
  }

  func change(userId: String, changeName: String) {
    guard let target = userList[userId] else { return }
    target.name = changeName
  }
}

func solution(_ record:[String]) -> [String] {

  let chat = Chat()

  record.forEach { packet in
    let command = packet.components(separatedBy: " ")
    switch command[0] {
      case "Enter":
        let user = User(id: command[1], name: command[2])
        chat.enter(user: user)
      case "Leave":
        chat.leave(userId: command[1])
      case "Change":
        chat.change(userId: command[1], changeName: command[2])
      default:
        return
    }
  }
  return chat.message
}

2020 KAKAO BLIND RECRUITMET - 문자열 압축, Swift

Hey_Hen — Sat, 12 Mar 2022 01:34:32 +0900

https://programmers.co.kr/learn/courses/30/lessons/60057

코딩테스트 연습 - 문자열 압축

데이터 처리 전문가가 되고 싶은 "어피치"는 문자열을 압축하는 방법에 대해 공부를 하고 있습니다. 최근에 대량의 데이터 처리를 위한 간단한 비손실 압축 방법에 대해 공부를 하고 있는데, 문

programmers.co.kr

1. 기본적인 알고리즘은, 1칸씩 잘라보고, 그 다음 2칸씩 잘라보는 행위를 계속 반복하는 것이다.

이때 문자열이 1,000 자 라면 500자 까지만 잘라보면 되는데, 왜냐하면 501자를 자르게 되면 남은 길이가 499자 이므로 앞서 자른 문자와 무조건 일치하지 않는다. 따라서 전체길이 S 일 때 S/2 까지만 자르는 동작을 반복하면 된다.

2. 문자열의 길이가 1일때 예외처리

3. 문자열을 자를 때 자른 문자열이 이전 문자열과 일치 할 때, 나온 회수를 +1 해준다., 아니라면 배열에 추가한다.

4. 압축한 문자열 길이를 계산한다.

5. 자르는 범위 오른쪽 경계가 nil이거나 초과하면 반복문을 빠져나오고 다음 자르는 단위로 이동한다.

6. 반복된 회수가 1일때는 별도로 표시하지 않으므로 예외처리

연산 횟수는 최악의 경우 500 * 500 * 500 으로 125,000,000

import Foundation

final class CompressedString: CustomStringConvertible {
  let word: String
  var count: Int = 1

  init(word: String) {
    self.word = word
  }
  var countAnnotation: String {
    count > 1 ? String(count) : ""
  }

  var description: String {
    "\(countAnnotation)\(word)"
  }
}

func solution(_ s: String) -> Int {
  let wholeLenth = s as NSString
  let bound = wholeLenth.length / 2
  var shortestStringLenth = 1001
  if wholeLenth.length == 1 { return 1 }
  for unit in 0..<bound {

    var compressedStrings: [CompressedString] = []
    var lbound = s.startIndex
    var rbound = s.index(lbound, offsetBy: unit, limitedBy: s.index(before: s.endIndex))
    var previousString = CompressedString(word: "")
    while true {
      if rbound == nil || rbound! >= s.endIndex {
        let substring = CompressedString(word: String(s[lbound..<s.endIndex]))
        if !substring.word.isEmpty {
          compressedStrings.append(substring)
        }
        break
      }
      let substring = CompressedString(word: String(s[lbound...rbound!]))

      if substring.word == previousString.word {
        previousString.count += 1
      } else {
        compressedStrings.append(substring)
        previousString = substring
      }

      lbound = s.index(after: rbound!)
      rbound = s.index(lbound, offsetBy: unit, limitedBy: s.endIndex)
    }

    var legnth = 0
    compressedStrings.forEach {
      legnth += ($0.description as NSString).length
    }
    shortestStringLenth = min(shortestStringLenth, legnth)

  }
  return shortestStringLenth
}

DiffableDataSource와 Realm

Hey_Hen — Thu, 3 Mar 2022 11:42:39 +0900

Issue

DiffableDataSource와 Realm을 함께 썼을 때 발생했던 문제와 해결법
DiffableDataSource는 Diff을 위해서 일종의 뷰의 상태를 가지고 있는데, 데이터가 변하면, 이전에 가지고 있던 상태와 비교해서 뷰를 갱신합니다.

Storage에서 Object3이 삭제가 되고, snapshot을 재 구성해서 dataSource에 apply를 실행하게 되면, 이전 DataSource Snapshot과 비교해서, 화면을 갱신하는 상황입니다.
그런데 해당 과정에서 Realm 예외처리 오류가 발생합니다.

   RealmManager.shared.deleteTodo(todo: todo)
    print(dataSource.snapshot().itemIdentifiers(inSection: .Task).map{($0 as! ToDo).task})

Realm에서 해당 데이터를 지운 후 dataSource에서는 아직 갱신이 되지 않았기 때문에, 해당 객체를 참조해볼 수 있는데, 프린트만 해도 에러가 납니다.

Terminating app due to uncaught exception 'RLMException', reason: 'Object has been deleted or invalidated.'
terminating with uncaught exception of type NSException

Realm Object로 생성한 객체는 Realm DB에서 삭제한 후에는 참조할 수 없도록, 예외처리가 들어가 있는 것 같습니다.
DiffableDataSource에서는 Diff을 위해, 삭제된 객체를 들고있어야 하는데, Realm에서 못들고 있게 하니까 snapshot을 apply 할 수 없게 되는 현상이 발생합니다.

Solution

1.

일반적인 DiffableDataSource 순서는
1. 스토리지에서 삭제
2. Snapshot 갱신
으로 볼 수 있는데, 이를 반대로 해볼 수 있습니다.
1. Snapshot 갱신
2. 스토리지에서 삭제

guard !todolist.isEmpty else { fatalError() }
    var snapshot = self.dataSource.snapshot()

    for todo in todolist {
      guard let _ = dataSource.indexPath(for: todo) else {
        print("delete error")
        return
      }
    }

 snapshot.deleteItems(todolist)
 dataSource.apply(snapshot, animatingDifferences: true)

 RealmManager.shared.deleteTodo(todo: todo)

근데 이러면 DiffableDataSource를 쓰는 의미가 없죠, DiffableDataSource의 장점은, 언제든 ConfigureSnapshot만 호출하면 되는 부분이 중요한데 말이죠!
그래서 다른 방법!

2.

1.의 솔루션을 조금 다르게 생각해서
DiffableDataSource에서 Diff 연산을 하고 난 뒤에 스토리지에서 삭제하는 컨셉은 똑같이 생각합니다.

기존에는 Realm DB에서 삭제를 이렇게 해버렸다면

바로 삭제하지 않고, 삭제한 데이터를 관리하는 섹션으로 따로 관리하는 거죠
Realm 내부에서 삭제된 데이터를 관리하는 별도의 모델을 만들거나

원래 모델에 isDelete: Bool 를 추가해서 필터링 해서 가져오는 방법도 있죠

애초에 사용자 경험 관점에서, 삭제를 바로 해버리는 것 보다는 안전장치를 두는게 더 좋은 선택일 수도 있다고 생각이 드네요

Realm Delete를 설명하는 문서

문서를 읽읍시다. ^^

CAF파일 이란? (번역)

Hey_Hen — Wed, 2 Mar 2022 02:43:33 +0900

CAF란?

Core Audio Format(이하 CAF)는 애플에서 개발한, 오디오 포맷으로 기존의 AIFF, WAV등의 한계점을 개선하기 위한 포맷이다.

Advantages

무제한 파일 사이즈
- AIFF, AIFF-C, WAVE는 기존 오디오 포맷은 4기가바이트의 용량 제한이 있었고, 대략 15분 정도의 길이의 오디오만 담을 수 있었지만, CAF는 용량에 제한이 없기 때문에, 이론적으로 수백년 길이의 오디오도 저장 할 수 있다.
안전하고 효율적인 녹음
- AIFF와 WAV는 녹음이 끝난 뒤 파일의 사이즈를 나타내는 헤더를 업데이트 해야하는데, 헤더 저장이 정상적으로 완료되지 않으면 파일을 못쓰게 되는 경우가 있다. CAF는 헤더없이 파일의 사이즈를 결정할 수 있다.
호환성
- CAF는 다양한 오디오 포맷의 래퍼 역할로, 메타데이터, 멀티채널에 대한 호환이 가능하다.
다양한 보조 데이터의 취급
- 오디오 편집에 필요한 추가 데이터나 채널 레이아웃, 텍스트 어노테이션 등도 함께 저장할 수 있다.
데이터 의존성 지원
- CAF의 특정 메타데이터는 편집 카운트 값으로 오디오 데이터에 연결되어있어, 이를 이용해 오디오 데이터가 변경된 경우를 확인할 수 있다.

CAF File Structure

CAF는 버전을 표기하는 헤더를 포함하고, 그 뒤로는 일련의 청크가 위치한다.

청크는 또 그 안에서, 청크의 유형을 정의하고, 데이터 섹션의 크기를 나타내는 청크 헤더와 청크 데이터로 구성된다.

CAF파일에 필요한 청크 유형은 오디오 데이터 청크와 오디오 데이터 형식을 지정하는 오디오 Description 청크를 필요로 한다.

Chunk Structure

청크의 타입을 나타내는 4자리 코드
청크 크기를 바이트 단위로 나타내는 숫자

Packet, Frame, Sample

Sample: 디지털화한 오디오 데이터의 한 채널에 대한 하나의 숫자 (44100샘플이라고 하면 1 샘플이 44100개)
Frame: 각 채널에 대해 하나의 샘플을 타나내는 샘플 세트, 프레임의 샘플은 동시에 재생되도록 되어있다. *비디오에서 설명하는 프레임과는 다른 개념! 착각하지 말자
Packet: 가장 최소 단위의 데이터 블록으로 Linear PCM 데이터의 경우 각 패킷에 정확히 하나의 프레임이 위치한다. 압축된 오디오 데이터 형식의 경우는 패킷의 프레임 수는 인코딩에 따라 다르다. 예를 들어 AAC 패킷은 1024프레임의 PCM을 나타낸다.
SmapleRate: 압축/압축해제 된 데이터의 전체 프레임 수 대 초당 샘플

출처 : https://developer.apple.com/library/archive/documentation/MusicAudio/Reference/CAFSpec/CAF_intro/CAF_intro.html#//apple_ref/doc/uid/TP40001862-CH203-TPXREF101

Swift- CoreBluetooth 찍먹

Hey_Hen — Tue, 1 Mar 2022 21:40:38 +0900

Bluetooth

iOS에서는 BLE(Bluetooth Low Energy) 무선 기술을 CoreBluetooth 프레임워크를 통해 연결 가능하다.

Central: Bluetooth 장치에서 데이터를 수신하는 개체

Peripheral: 다른 장치에서 사용할 데이터를 게시할 Bluetooth 장치

Advertising Packets: 블루투스는 Advertising Packets 형태로 가지고 있는 데이터 중 일부를 브로드캐스트 한다.

패킷에는 주변 장치의 이름, 기능 등과 같은 정보가 포함될 수 있다.

Central의 역할은 이러한 AdvertisingPackets 을 스캔하고 관련이 있는 주변 장치를 식별하고 개별 장치에 연결하고 추가 정보를 확인한다.

Service

주변 장치의 특정 기능 또는 특징을 설명하는 데이터 및 관련 동작의 모음, 예를들어 심박 센서에는 심박수 서비스가 있다.

Characteristics

자세한 정보를 제공한다. 예를 들어, 심박수 서비스에는 분방 비트 수 데이터가 포함된 심박수 측정 특성이 있다. 심박수 서비스가 가질 수 있는 또 다른 특징은 바디 센서 로케이션으로, 의도된 신체 위치를 설명하는 문자열이 포함된다.

각 서비스 및 특성은, 16bit or 128bit이 될 수 있는 UUID로 표시된다.

CBCentralManager

CBCentralManager는 코어 블루투스를 관리하는 모델로, 델리게이트를 통해서 이용할 수 있다.

뷰 컨트롤러 등에서 다음과 같이 프로퍼티와, 초기화를 실시한다.

var centralManager: CBCentralManager!

centralManager = CBCentralManager(delegate: self, queue: nil)

extension ViewController: CBCentralManagerDelegate {
  func centralManagerDidUpdateState(_ central: CBCentralManager) {
    switch central.state {

      case .unknown:
        print("central.state is .unknown")
      case .resetting:
        print("central.state is .resetting")
      case .unsupported:
        print("central.state is .unsupprted")
      case .unauthorized:
        print("central.state is .unauthorized")
      case .poweredOff:
        print("central.state is .poweredOff")
      case .poweredOn:
        print("central.state is .poerwedOn")
      @unknown default:
        print("central.state is .unknown default")
    }
  }
}

CBCentralManagerDelegate를 채용하게 되면, centralManagerDidUpdateState(_:) 를 필수적으로 구현하게 되는데, 말그대로 central의 상태로, 이상태에서 빌드를 하게 되면, 디바이스의 블루투스가 켜져있다면 poweredOn상태 블록을 실행하게 된다.

블루투스를 이용하기 위해서, 다음과 같은 동의를 얻어야 함 Privacy - Bluetooth Always Usage Description

Scanning for Peripherals

그 다음은 주변 기기를 검색할 차례다

주변 기기 검색은 CBCentralManager의 **scanForPeripherals(withServices:options:) 메소드를 통해 가능하다.

withServices 인수는 CBUUID를 통해, 앱에서 관심있는 블루투스 기기의 advertise만 확인하는데, 추천하는 값은 기본적으로 nil이다. 예를들면, 싸이클 관련 어플리케이션인 Strava를 보면, 싸이클 컴퓨터를 블루투스로 연결하는데, 관련기기가 아니면 서치 자체가 되지 안흔다. 아마 이러한 부분을 이용한 것으로 생각된다

options인수는 말그대로 검색을 커스터마이징 하는 방법으로, 이건 우선은 패스

그러면 해당 메서드를 호출해보자.

case .poweredOn:
  print("central.state is .poerwedOn")
  centralManager.scanForPeripherals(withServices: nil)

어떻게 보면 당연한 이야기 인데, 해당 메서드는 poweredOn상태에서만 호출할 수 있다. 그 외에 호출하게 되면 API MISUSE 메시지가 날아온다.

scanForperipherals는 검색을 시작하라는 명령어인데 그럼 검색된, 블루투스 기기는 어떻게 확인 할 수 있을까

CBCentralManagerDelegate 에서 didDiscover로 제공되는 메서드가 있다.

print(peripheral)

우선 프린트

빌드해보면 맥북 블루투스도 잡히고, 에어팟도 잡히고, 우리집에는 없는 기기도 잡힌다.

캡처 화면에는 일부만 보이지만, 실제로 해보면 꽤 많은 검색 결과가 나오기 때문에, 여기서 필요한 서비스만 걸러 내보고자 한다. 앞서 얘기했던 CBUUID를 이용해 볼 것이다. 에어팟과 같이 오디오 재생 장치만 걸러볼려고 한다!

블루투스 시방 확인 https://www.bluetooth.com/specifications/assigned-numbers/

시방서에 들어가면 16-bit UUID pdf를 받을 수 있는데, 여기서 AllocationType을 찾아보면 GATT Service가 있다.

잘 찾아보니 이거는 자전거에 들어가는 스피드, 케이던스 센서

인데, 내가 찾고싶은언 에어팟과 같이 오디오 관련도니 서비스 인데, 못찼겠다. 다음에 찾아보겠ㅇㅁ

서비스를 필터링 하는건 못했으니, 그냥 이름으로 기기를 잡아 보려고 한다.

var airpods: CBPeripheral!
func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) {
    if peripheral.name ?? "" == "둥둥팟" {
      print(peripheral)
      airpods = peripheral
      centralManager.stopScan()
    }
  }

에어팟의 이름이 “둥둥팟"이기 때문에, peripheral.name이 “둥둥팟”과 같을때 CBPeripheral 인스턴스로 전달해준뒤 centramManager를 stopScan하면 더이상 스캔을 계속하지 않는다.

Connecting to a Peripheral

방금 찾아서 인스턴스로 만들었기 때문에 이를 연결하는 방법은 centralManager에 **connect(_:options:) 메서드를 호출하고, 첫번째 인자에 Perpiheral 인스턴스를 전달하면 된다.

이를 스캔을 정지하기 전에 호출해주자!

블루투스 기기가 연결 되었다는 것을 어디서 알 수 있냐하면

같은 델리게이트 메서드에서 확인 가능하다., 만약 성공적으로 연결 되었다면, 이 부분이 호출 된다.

주변 기기를 연결 한 다음에는, 주변기기가 제공하는 서비스를 다시 검색해야 한다.

해당 내용은 연결된 기기의 Delegate에서 확인 가능하다. 따라서 우선 기기를 연결해준 다음

airpods.delegate = self

델리게이트 self

확인된 서비스 목록을 보아야 하는데, 이는 CBPeripheral 메서드로 호출 가능하다.

func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) {
    airpods.discoverServices(nil)
    print("Connect to: \\(peripheral)")
  }

해당 코드를 didConnect에서 호출 하면

extension ViewController: CBPeripheralDelegate {
  func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {
    guard let services = peripheral.services else {
      print("didDiscoverServices Error \\(error?.localizedDescription)")
      return
    }

    for service in services {
      print(service)
    }
  }
}

peripheral에서 service를 배열 형태로 받으 ㄹ수 있다.

그렇게 해서 받은 서비스는 위 사진처럼 나타내는데, 아직은 이게 뭘 의미하는지 모르겠다. 콩나물이 2개라 2개가 출력되나?

아니면 오디오 입/출력 2개로 나뉘어서 2개 서비스인지 모르겠다

예제를 보면, UUID 부분이 정의가 되어있으면 우리가 아는 영단어로 떨어지는데, 에어팟이라 그런가..저게 128Bit UUID인가 싶다.

예를들어, 아까 GAPP Service에서 확인한 것 처럼, 심박이면 “UUID = Heart Rate”, “UUID = Cycle Cencer” 이런식으로 나온다는 것

Discovering a Service’s Characteristics

맨 처음 설명했든 주변기기에는, Characteristics가 있는데, 주변기기가 가지는 특성을 전달한다. 케이던스 센서면, 분당 회전수를 특성으로 전달해줄 것이다. 에어팟은, 사운드 기기니까, 오디오 정보, 볼륨이나, 주파수를 전달하지 않을까?

for service in services {
      print(service)
      print("Characteristic: \\(service.characteristics)")
}

<CBService: 0x283400a00, isPrimary = YES, UUID = 9BD708D7-64C7-4E9F-9DED-F6B6C4551967>
Characteristic: nil
<CBService: 0x283400cc0, isPrimary = YES, UUID = 7798082B-B7B7-45A6-9933-563492EFE04E>
Characteristic: nil

놀랍게도 아무것도 엄슴.이 아니라 방법이 잘못 되었는데, Characteristic을 찾는 방법은

didDiscoverCharacteristicsFor 를 통해서 찾아야 한다.

service에서는

print(peripheral.discoverCharacteristics(nil, for: service))

위 코드를 호출 해 주고

func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) {
    guard let characteristics = service.characteristics else {
      print("didfail didscover characteristics with error: \\(error)")
      return
    }

    for characteristic in characteristics {
      print(characteristic)
    }
  }

델리게이트 메서드를 호출해서, 특성을 확인한다

<CBCharacteristic: 0x2826204e0, UUID = F195B8FB-A9E2-4401-858B-2F87A06928A8, properties = 0x2, value = {length = 8, bytes = 0x0101000407020101}, notifying = NO>
<CBCharacteristic: 0x282620540, UUID = E1F9B835-7E47-413D-AF94-C68E574B8F7E, properties = 0x4, value = (null), notifying = NO>
<CBCharacteristic: 0x282620480, UUID = A08CE5EF-698A-42A2-B980-7F3AC00B3845, properties = 0x14, value = (null), notifying = NO>
<CBCharacteristic: 0x2826203c0, UUID = 6288EA2D-7B89-47AD-890B-9FA6BF3CFC58, properties = 0x14, value = (null), notifying = NO>
<CBCharacteristic: 0x282620420, UUID = 3F1C161D-6473-4746-91F5-6D27610780C6, properties = 0x10, value = {length = 91, bytes = 0x01003856 0001d041 0151b83d fabea0b8 ... 962aac7f 17a0757f }, notifying = NO>
<CBCharacteristic: 0x2826205a0, UUID = C7C6947D-3165-4BCB-8EAF-B328896CB531, properties = 0x14, value = {length = 4, bytes = 0x01000300}, notifying = NO>
<CBCharacteristic: 0x282620720, UUID = 82F6BC0A-1BCA-4873-AFC9-EC5890E3469A, properties = 0x2, value = (null), notifying = NO>
<CBCharacteristic: 0x2826206c0, UUID = D5F96AFA-2F2C-41BB-A7E6-F54ABE6235B4, properties = 0x2, value = (null), notifying = NO>
<CBCharacteristic: 0x282620660, UUID = D5621CC1-F7AB-45DB-9403-9EAF744D5390, properties = 0x6, value = (null), notifying = NO>

그래서 뭔가 잔뜩 나왔는데, 뭐가 뭔지는 모르겠고, 어떤 거는 value를 가지고 있는 것도 있다.

UUID에 따라서 어떤 내용인지 파악하면 되는데, 에어팟을 내가 생각한게 아니고, 블루투스 스펙에도 나와있지 않다. 애플이 임의로 정의 해 둔 것이라는 것

만약 실제로 개발하는 입장이라면 아마

“D5621CC1-F7AB-45DB-9403-9EAF744D5390” 이 ID는 현재 배터리 상태를 보내는 거고

“D5F96AFA-2F2C-41BB-A7E6-F54ABE6235B4”는 현재 착용중인지 나타내는 값이고

이런식으로 아마 차트를 정리 해 두었을 것이다.

그래서 각 특성에 따라서 Properties를 가지는데, 가상으로 생각해보면, 현재 배터리 상태를 나타내는 것은 에어팟에서 값을 가져올 것이기 때문에 read를 가지고 있을 것이다.

https://developer.apple.com/documentation/corebluetooth/cbcharacteristicproperties

여기부터는 가상의 코딩.ㅎ

peripheral.readValue(for: characteristic)

특성을 readValue하게 되면 이 결과가

요 델리게이트 메서드로 넘어가게 된다.

그러면 아래 처럼 상태 처리를 해서

func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) {
    if characteristic.uuid == CBUUID(string: "배터리상태") {
      print(batteryState(from: characteristic))
    }
  }

battryState를 계산해주는 메서드를 호출하면 되고

private func batteryState(from characteristic: CBCharacteristic) -> Int {
    //byte 처리
    return -1
}

batteryState 메서드에서는 characteristic으로 전달된 value값(Data)를 처리해야 한다.

이 부분도 실제로 해보고 싶은데, 에어팟 블루투스 시방서가 없어서.. 가상으로 해보자면

[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 56, 224, 1, 0, 0, 0, 0, 0, 91, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 52, 50, 46, 49, 49, 56, 55, 48, 54, 48, 48, 48, 52, 48, 48, 48, 48, 48, 48, 46, 57, 124, 99, 115, 118, 49, 58, 50, 46, 48, 46, 53, 124, 99, 115, 118, 50, 58, 49, 46, 57, 46, 52, 124, 100, 97, 116, 101, 58, 50, 48, 50, 49, 32, 49, 49, 32, 49, 49, 124, 117, 112, 100, 118, 58, 49, 54, 53]

이런식으로 바이트 쪼가리가 데이터로 들어오는데, 이를 시방서를 보고

예를들어 뭐 12번째 자리가, uint8 형식으로, 배터리를 0~100까지 나타낸다고 그러면, 알아서 잘 변환해서 처리하면 된다.

집에 범용적인 블루투스 기계가 없어서 실제로 해보지 못하는게 너무 아쉽다.

전체코드보기

https://github.com/urijan44/CoreBluetoothPractice/blob/main/CoreBlueToothPractice/ViewController.swift

NMapsMap M1 Build Error

Hey_Hen — Sat, 26 Feb 2022 17:40:12 +0900

하드웨어 환경

해결방법

Xcode 로제타로 실행하세요

소개

NMapsMap을 사용해야 하는데, 해당 프레임워크는 cocoapods 설치밖에 지원하지 않습니다. 거기다 잘~ 설치하고나서 보니, SPM으로 설치된 것들이 빌드 오류가 발생습니다.

대빡치는 상황

Git 잘못 올라간 파일 및 기록 삭제

Hey_Hen — Mon, 21 Feb 2022 15:06:51 +0900

Intro

출시한 프로젝트에 GoogleCrashlytics랑 Analytics 달아놓고, 평생 비공개 할꺼라, 신경을 못썼는데, 프로젝트를 공개로 돌리려고 봤더니, GoogleService-Info.plist 가 노출이 되는걸, 뒤늦게 눈치챘다.
Gitignore에 넣는것도 깜빡했고, Commit 로그에도 남아있는 관계로... 깃에서 파일을 삭제하고 커밋 히스토리에서 해당 파일을 삭제하고자 했다.

파일 삭제

우선 git에 잘못 등록된 파일은 아래 명령어를 사용하자

git rm --cached -r <DIRECTROY>
git rm --cached <FILE_NAME>

cached 옵션은, remote에서 이를 삭제한다는 뜻으로 해당 옵션이 없으면 local에서도 삭제해버리니, 주의하자

삭제한 후, gitignore에 추가하고, commit, push하자

커밋 히스토리 삭제

지금 당장 올라간 파일은 삭제했지만, 깃은, 해당 커밋에 파일내용이 그대로 들어간다. 따라서, 히스토리에서도 해당 파일에 대한 내용을 삭제할 필요가 있다.

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch <PATH_FILE_NAME>' --prune-empty -- --all

입력한 파일 이름을 가지고 필터링 해서, 해당 커밋에서 내용을 삭제해준다.

좀 기다리면 커밋 아이디가 줄줄이 뜨면서 rewirte되었다고 뭐가 많이 나온다.
만약 Rewirte 내용이 안나온다면, 파일 이름을 맞게 입력했는지 패스는 맞는지 확인하자!

마치며.

애시당초 민감한 파일은, 비공개로 하더라고 애초에 리모트에 올리지 말자!

명품 C++ Programming - 1장 연습문제(이론) 짝수 정답

Hey_Hen — Sat, 19 Feb 2022 02:47:39 +0900

(네이버 블로그에서 이전 작성한 글입니다)

2. ④

- 기계어로 프로그램을 작성하는 것은, 그만큼 사이드이펙트를 줄일 수 있지만, 생산성 측면에서 완전히 낭비입니다. 좋은 개발자가 되는 지름길로는 보기 힘듭니다.

4. ②

- C언어는 절차 지향 프로그래밍 언어입니다.

6. ②

객체 지향의 특성은 다음과 같습니다.

- Encapsulation

- Inheritance

- Polymorphism

- Abstraction

https://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#OOP

Introduction to Object Oriented Programming Concepts (OOP) and More

This article helps to understand OOP concepts, focusing on .NET/ C#. This is written in the form of asking questions and writing answers to them, making it easy to understand.

www.codeproject.com

8. ④

C++는 클래스 외부에서 변수를 선언할 수 있기 때문에 캡슐화 원칙이 무너져 순수 객체지향 언어로 보기 어렵다.

현대 C++언어와 모던한 언어들 모두 멀티패러다임이기 때문에 크게 문제되는 부분은 아니다.

10. ②

C++ 컴파일러가 하나가 아닌데, 표준 C++ 로 작성하게 되면, 컴파일러가 달라도 문제없이 동일하게 동작한다.

12.

캡슐화: TV를 예로 들자면, TV에는 다양한 객체의 집합인데, 전원 버튼, 외부 연결 컴포넌트, 디스플레이, 스피커 등으로 구성되어있다. 각 컴포넌트 들은 각자의 역할만 수행할 뿐, 다른 컴포넌트들이 무슨 일을 하는지는 알 수도 없고, 관심도 없습니다. 디스플레이가 안나와도 스피커는 나오거든요. 스피커 컴포넌트에 내부에는 다른 컴포넌트로 부터 받은 오디오 신호를 내부적으로 코딩하고 아마 play()등의 메서드로 출력할겁니다. 내부적으로 코딩하는 부분을 processing() 메서드라고 한다면 해당 processing 메서드는 스피커 안에서만 동작하지, 전원 컴포넌트가 speaker.processing() 같은 형식으로 호출을 할 수는 없습니다.
다형성: 오퍼레이터를 예를 들어 설명하라고 되어있는데, 수라는 모델이 있다고 가정했을 때 수는 기본적으로 사칙연산이 가능할 겁니다. 마찬가지로 대소관계 비교도 가능 할 것이구요, 이 수라는 모델을 서브클래싱 하면, 실수, 정수 등이 될 수 있습니다. 실수와 정수는 '수' 개념을 서브클래싱 한 것으로, '수'에서 가능했던 사칙연산과 대소비교가 가능하게 되는 것입니다. 실제로 구하는 방법은 무슨 수인가에 따라서 조금씩 달라집니다. 프로그래밍에서는 상속에 의해서 나타나고, 메서드 오버라이딩, 오퍼레이터 오버라이딩 으로 활용됩니다.
상속성: 좀더 쉬운 예시를 들면, 사람이라는 부모 클래스가 있고, 사람을 상속한 학생 클래스가 있다고 가정하면, 사람은 통상적으로 이름이 있고, 나이, 생일 등이 있습니다. 이를 상속한 학생 클래스는, 이름, 나이 생일을 포함한 학교, 학년, 시험 성적등이 있겠죠

14. ④

Type Conversion은 C도 된다.

16. ①

C++ 소스파일은 텍스트 파일이다. 따라서 메모장으로도 편집이 가능하다.

18.

그림은 링킹을 설명하는 그림으로, 링킹이란 여러 실행 코드들을 컴파일 하여 나온 objㅇ파일과 라이브러리 등을 결합하는 과정으로, 이를 한데 묶어 실행파일을 만들기 위해 필요한 작업이다. 만약 링킹 하는 과정에서 참조하는 코드를 찾을 수 없다면, 링크 오류가 발생한다.

링킹 과정에서 실행파일로 같이 묶지 않고, 실행파일 시점에 라이브러리를 참조하도록 하는 것이 바로 Dynamic Linking Library이다.

20.

c++ 20 기준으로도 netowrk library를 포함하고 있지 않습니다. c++ 23에 network를 의제가 포함되어 있긴 하지만, 확정된 사항이 아닌 것으로 알고있습니다. c++ 20 때도 포함된다는 얘기도 있었으니까요

처음 c++를 공부할 때, 이부분이 상상히 궁금했는데, 참고할만한 블로그 글이 있습니다.

https://quuxplusone.github.io/blog/2019/10/09/why-no-networking/

Why doesn’t C++ have networking support?

Recently, in a discussion of the Networking TS on one of WG21’s internal “reflector” mailing lists, Bjarne Stroustrup wrote:

quuxplusone.github.io

22.

IDE라고 줄여말하는 이것은, 프로그램을 개발하는데 필요한 기능을 모아놓은 프로그램입니다. 코드를 작성하는데에는 메모장만 있으면 되지만, 생산성을 높이기 위해, 자동완성, 편리한 빌드세팅, 컴파일러 등 다양한 기능을 모아놓은것이 IDE이죠. IDE마다 목적이 다르기 때문에 개발하고자 하는 목적에 따라 IDE선택을 하시면 되겠습니다.

Windows플랫폼에서는 Visual Studio가 강력할 것이고, 윈도우 GUI를 작성하는데에는, qt도 존재합니다.

Apple 플롯폼은 Xcode가 독보적이고, 안드로이드 앱 개발에는 안드로이드 스튜디오, Java진영은 이클립스와 InteliJ가 있습니다.

Diffable Data Source

Hey_Hen — Fri, 18 Feb 2022 23:30:51 +0900

(safari에서는 gif를 이미지를 불러올 수 없습니다. 곰탱이로 보여집니다. chrome로 봐요)

Intro

DiffableDataSource는 wwdc2019에서 Advances in UI Data Sources라는 이름으로 발표된 API입니다.
DiffableDataSource는 기존 DataSource를 구성하는 새로운 방법으로, 복잡한 코드를 간편하고 빠르게 작성할 수 있게 해줍니다.
CollectionView와 TableView에서 애니메이션 효과는 꼭 필요한 유저 경험을 제공합니다.

출현배경

CollectionView, TableView 모두 동시에 적용 되므로, CollectionView로 앞으로는 통일하겠습니다.
간단한 CollectionView 써보셨다면, 사실 크게 복잡하지 않은 앱에서는 딱히 문제가 없으셨을 것입니다.
셀을 삭제하고, 추가할 때

collectionView.deleteItems 또는 insertItems을 통하면 애니메이션 효과를 얻을 수 있습니다.

HIG에 따르면 애니메이션은 사용자에게 조작감을 향상 시키고, 앱을 컨트롤하고 있다는 느낌을 들게해주는 중요한 요소입니다.
앱이 조금 복잡해져
Item을 삭제, 추가, 이동 한다고 했을 때는 batch block을 열어, 안에서 IndexPath를 계산해주어
앞서 애니메이션을 주는 메서드들을 작성할 수 있습니다.
그런데 앱은 이것보다 더 복잡해질 수 있습니다.

이처럼 대량의 데이터가 오갈 수 있는 외부 서비스나, DB , 혹은 아까 말했던 것처럼 좀더 복잡하게 동작하는 DataSource의 경우 한번에 데이터가 여러개 추가, 삭제, 편집 등 다양하게 동작할 수 있습니다.
유저가 인터페이스를 통해서 조작하는거 까지는 처리가 쉬운데, 외부에서 들어오는 경우, batch 업데이트를 어떻게 해야 할까요?
방법이 없는 것은 아니지만, 꽤 코드가 복잡하고 길어질 것은 확실합니다.
여기서 한번쯤은 다들 경험 해보셨을

batch update 크래시 에러를 볼 수도 있습니다.

앱이 크레시가 발생하기 때문에 여간 위험한게 아니기 때문에 애니메이션 없이 reloadData()나 reloadSection()을 한다고 가정해봅시다.

임의의 앱을 만들어 보았는데요
개발자가 이력서 보이기를 설정하면, 화면에 표시되는 구조입니다.(가상으로)
애니메이션 없이 처리되니까 뭐가 어떻게 변하고 있는지, 알 수가 없고 꽤 정신 없습니다.
이렇게 경우에 따라 애니메이션이 없는 앱은 나쁜 유저 경험을 발생시킵니다.
이를 해결하는 것이 바로 Diffable Data Source 인것입니다.

Diffable Data Source

Diffable Data Source가 위에서 말한 어떠한 문제점들을 해결할까요?
1. No more batch update
2. No more IndexPath
3. Easy Animation
Diffable Data Source는 diff 연산과, View 업데이트의 두 가지고 생각할 수 있습니다.

DiffableDataSource는 현재 뷰의 상태를 Current Snapshot이라는 형태로 관리를 하게 됩니다.

그리고 아까처럼 데이터의 변동 사항이 생기면 이를 New Snapshot으로 봅니다.

New Snapshot을 생성하고 이를 Current Snapshot으로 적용하기 위해 apply() 메서드를 호출하게 되는게 이게 DiffableDataSource에서 가장 매력적인 부분입니다.

apply()메서드는 원래 Data Source에서 우리가 일일이 배치 블럭 열고, 인덱스 패스 계산하고, deleteRows등을 호출 하는 과정을 한번에 해결해줍니다.

DiffableDataSource를 사용한 상태입니다. 이 모든게 DiffableDataSource를 적용하고, apply() 메서드만 호출한 결과물인거죠.
그러면 DiffableDataSource 는 어떻게 사용할 수 있나요?
아래 3가지를 구현하면 됩니다.
1. Hashable
2. configureDataSource()
3. configureSnapshot()
하나씩 천천히 봅시다.

Hashable

DiffableDataSource에 들어가는 인스턴스는 Hashable을 채용한 모델이여야 합니다. Diff 연산을 하기위해, 고유한 ID를 가질 필요가 있는 것이죠

final class Developer: Hashable {
  static func == (lhs: Developer, rhs: Developer) -> Bool {
    lhs.id == rhs.id
  }

  func hash(into hasher: inout Hasher) {
    hasher.combine(id)
  }

  var id = UUID().uuidString
  var name: String
  var major: Major
  var language: [Language]
  var carrer: String
  var searcable: Bool = true

    ...
}

Configure Data Source

ConfigureDataSource는 특별한게 아니고, 기존 DataSource에서 하던 cellForRowAt 같은 것이라고 생각하시면 됩니다.
RxDataSource를 사용해셨던 분들은 구조가 한번에 이해가 되실 겁니다.
우선 클래스의 Property에 DataSource 선언이 필요합니다.

var dataSource: UICollectionViewDiffableDataSource<Section, Developer>!

UICollectionViewDiffableDataSource(TableView도 UITableViewDiffableDataSource로 똑같습니다.)

이는 제네릭 타입 클래스로 Section Hashable Type과 Item Hashable Type을 받습니다. Item Hashable Type은 앞서 Hashable을 적용한 모델이 들어가면 되는것이고, Section에는 임의로 만드시면 됩니다.
예를들어 보여주고자 하는 CollectionView에 Main섹션, Body섹션 이 있다면

enum Section {
  case main
  case body
}

이런식으로 만든 후 Section Type에 전달해 주면 됩니다. 어렵지 않죠?

이제 configureDataSource()를 만들어서 호출해보겠습니다.

private func configureDataSource() {
    dataSource = UICollectionViewDiffableDataSource<Section, Developer>(collectionView: collectionView) { collectionView, indexPath, developer in
      let cell = collectionView.dequeueReusableCell(withReuseIdentifier: ProfileCardCell.identifier, for: indexPath) as! ProfileCardCell
      cell.configure(developer)
      return cell
    }
  }

메서드는 viewDidLoad() 등에서 호출해주시면 됩니다.

UICollectionViewDiffableDataSource는 초기화로 collectionView와 cellProvider 클로져를 받습니다.

cellProvider를 보면 collectionView, indexPath, itemIdentifier 가 전달되는데

itemIdentifier는 제네릭으로 전달한 Hashable 모델입니다. 그러니 지금은 developer를 그대로 전달받는 것이죠

그래서 원래 데이터 리스트에서 indexPath로 찾을 필요 없이 바로 cell에 전달하시면 되는겁니다.
그런데 내용을 기존 data Source의 cellForRowAt 와 똑같죠? 심지어 numberOfRowInSection, NumberOfSection 는 호출하지 않아도 됩니다.

Configure Snapshot

이제 dataSource와 cell구성은 되었으니 snapshot구성을 해봅시다. snapshot도 마찬가지로, viewDidLoad()등에서 호출하는데, configureDataSource()다음으로 호출해주시면 됩니다.

func configureSnapshot(animatingDifferences: Bool = true) {
    var snapshot = NSDiffableDataSourceSnapshot<Section, Developer>()
    snapshot.appendSections([.main])
    snapshot.appendItems(storage.filteredDevelopers, toSection: .main)
    dataSource.apply(snapshot, animatingDifferences: animatingDifferences)
  }

snapshot 구성은 NSDIffableDataSourceSnapshot 클래스를 이용합니다.

인스턴스를 생성하고, append Section과 append Item을 전달해 준뒤

dataSource.apply() 해주시면 끝입니다.

body 섹션까지 전달하고 싶다면 appendSections에 [.main, .body] 와 같은 형태로 작성하면 되겠죠?

이게 끝입니다. 앞으로 데이터가 변경되면 configureSnapshot()만 호출해주시면, 알아서 CollectionView가 애니메이션 과 함께 동작할 것입니다.

아까의 화면이 지금까지 한 것의 결과물인거죠. 데이터 변경 시점만 Notification이나 Rx등을 통해 옵저버를 통해 구독하고 있다가 configureSnapshot() 코드만 호출하면 끝인겁니다.

Performance

이렇게 쉬운 DiffableDataSource 성능은 어떨까요?
diff 연산은 결국 데이터를 하나씩 비교하는 작업이기 때문에 O(N)의 시간 복잡도를 가집니다. 그러면 데이터가 커지면, 일일이 백그라운드 큐에서 apply()를 해야하나요?
아니요!
DiffableDataSource는 diff연산은 알아서 백그라운드 큐에서, UI update는 알아서 메인 큐에서 실행해줍니다. 맞습니다. 스레드 관리가 필요가 없습니다!

또 기존 indexPath로 Item을 얻고, 원래 데이터에서 해당 아이템을 찾고 하는 과정을 dataSource.itemIdentifier(for:)메서드를 통해 O(1) 시간으로 얻어올 수 있습니다. 모델이 Hashable이기 때문입니다. 멋지죠?

Trade-off

이렇게 좋은 DiffableDataSource 문제는 없을까요?
아쉽게도 있습니다.

1. iOS 13.0이 최소버전
WWDC2019 (iOS 13.0)으로 발표되었기 때문에 미만의 OS에서는 사용할 수가 없습니다.
출시한 앱에 적용해보았는데, OS가 13.0, 14.0, 15.0에서 똑같은 코드로 각기다른 에러가 발생하더라구요, 제가 잘 사용하지 못한 것도 있지만, 바르게 사용하기 위해서는 숙달하는 시간도 필요할 것 같습니다.

2. RxDataSource
프로젝트에서 RxSwift를 사용한다면 RxDataSource라는 대체제도 있습니다. RxDataSource도 한계점이 있지만, 굳이 RxDataSource부분을 DiffableDataSource로 바꿀래? 라고 그러면 거기까지는 아니라는 거죠

3. Bug
DiffableDataSource를 쓰면 원래 dataSource = self가 완전히 무력화 되는데,
제가 겪었던 버그는 tableView에 Drop, Drag Delegate를 사용해야 하는데 전혀 호출되지 않았던 적이 있습니다.

https://gookbobhenry.notion.site/DiffableDataSource-DropDelegate-ISSUE-52d6e52640bb41cf8172c58d490fe37b

DiffableDataSource DropDelegate ISSUE

TableView에서 Drag, Drop Delegate를 이용해서 드래그하여 셀 재정렬이 가능한데, DiffableDataSource에서 Drop Delegate 메서드들이 호출이 안 되던 문제.

gookbobhenry.notion.site

delegate = self 순서 변경으로 해결된 문제였지만, 얼마나 삽질했는지 생각하면 지금도 화가납니다.

그럼에도, 기존 DataSource에 비해 애니메이션 까지 구현하기가 굉장히 쉽고, 편리합니다. 그래서 저는 간단한 앱에도 DiffableDataSource를 씁니다. 이쪽이 작성이 더 빠르거든요.

DiffableDataSource는 iOS 14.0에서 한단계 더 진화하는데 이부분은 아직 저도 공부중으로, 관심있으시면 WWDC2020에 Advances in diffable data sources 영상을 보시는 걸 추천드립니다.
Section Snapshot과 Reordering Support 가 새로 생기거든요

References / Resources

WWDC 2019 Advances in UI Data Sources
Reference Project

Sample Project

Design Pattern - Coordinator Part1

Hey_Hen — Wed, 9 Feb 2022 18:00:06 +0900

Coordinator Pattern

Coordinator Pattern은 Structure Design Pattern으로 View Controller간의 로직 흐름을 조직하기 위한 디자인 패턴이다.

간단하게 얘기하자면, 뷰간 화면 전환 Coordinator로 한번에 관리하겠다는 뜻이다.

5개의 컴포넌트로 이루어져 있다.

코디네이터 프로토콜: View Present, Dismiss 메소드를 정의
코디네이터 인스턴스: 코디네이터 프로로콜을 채용한 인스턴스, 뷰 컨트롤러를 어떻게 만들 것인지 알고있다.
라우터 프로토콜: View Present, Dismiss 메소드를 정의
라우터 인스턴스: 라우터 프로토콜을 채용한 인스턴스, 코디네이터와 다른 점이라면, 어디서 무엇을 보여줄 것인지가 아니라, 어떻게 보여줄 것인지를 정의한다.
뷰 컨트롤러 인스턴스 들: 뷰 컨트롤러는 서로, 어디서 어떻게 표시될지는 모른다.

코디네이터 패턴 클래스 다이어그램 srouce: raywenderlich

사용목적은 다음과 같다.

뷰 컨트롤러간의 종속성을 때어내고 싶을 때
뷰 컨트롤러의 재사용성을 높이고 싶을 때
런타임에 뷰 컨트롤러 시퀀스가 결정될 때

Router

Router는 Coordinator Pattern에서 어떻게 뷰의 Present, Dismiss의 방법을 정의한다.

import UIKit

public protocol Router: AnyObject {
  func present(_ viewController: UIViewController, animated: Bool)
  func present(_ viewController: UIViewController, animated: Bool, onDismissed: (() -> Void)?)
  func dismiss(animated: Bool)
}

extension Router {
  public func present(_ viewController: UIViewController, animated: Bool) {
    present(viewController, animated: animated, onDismissed: nil)
  }
}

프로토콜 에서는 present와 dismiss 메소드를 정의한다.

NavigationRouter

UINavigationController를 사용할 때 Router가 어떻게 동작하는지 만든다

import UIKit

public class NavigationRouter: NSObject {
  private let navigationController: UINavigationController
  private let routerRootController: UIViewController?
  private var onDismissForViewController: [UIViewController: (()->Void)] = [:]

  public init(navigationController: UINavigationController) {
    self.navigationController = navigationController
    self.routerRootController = navigationController.viewControllers.first
    super.init()
    self.navigationController.delegate = self
  }
}

NavigationRouter는 UINavigationController와 RootViewController, 그리고 View가 Dismiss됐을 때 동작을 저장하는 Dictionary로 [UIViewController: (() -> Void)?)]
정의한다.

이제 NavigationRouter는 Router 프로토콜을 채용한다.

extension NavigationRouter: Router {
  public func present(_ viewController: UIViewController, animated: Bool, onDismissed: (() -> Void)?) {
    onDismissForViewController[viewController] = onDismissed
    navigationController.pushViewController(viewController, animated: animated)
  }

  public func dismiss(animated: Bool) {
    guard let routerRootController = routerRootController else {
      navigationController.popToRootViewController(animated: animated)
      return
    }
    performOnDismissed(for: routerRootController)
    navigationController.popToViewController(routerRootController, animated: animated)
  }

  private func performOnDismissed(for viewController: UIViewController) {
    guard let onDismiss = onDismissForViewController[viewController] else {
      return
    }
    onDismiss()
    onDismissForViewController[viewController] = nil
  }
}

present시에는 present할 viewController를 파라메터로 가진다. 전달받은 viewController는 navigationController에 push되는데, 이때 onDismissForViewController에 onDismissed 클로져와 함께 등록된다.

dismiss(animated:)메소드는 뷰가 dismiss될 때를 정의하는 것으로,
routerRootViewController가 없으면 가장 아래 뷰 컨트롤러까지 pop한다.

있을 경우는 평범하게 해당 뷰 컨트롤러까지 pop하는데 이 전에 performOnDismissed를 호출한다. 해당 메서드는 뷰를 present할때 정의해 두었던 dismiss 클로져를 실행하고, 딕셔너리에서 정리하기 위함

Coordinator

코디네이터 프로토콜은 각 뷰 컨트롤러간의 계층 구조를 나타내기 위함이다.
코디네이터 프로토콜은 아래와 같다

public protocol Coordinator: AnyObject {
  var children: [Coordinator] { get set }
  var router: Router { get }

  func present(animated: Bool, onDismissed: (()->Void)?)
  func dismiss(animated: Bool)

  func presentChild(_ child: Coordinator, animated: Bool)
  func presentChild(_ child: Coordinator, animated: Bool, onDismissed: (()->Void)?)
}

Coordinator 프로토콜을 준수하는 객체를 children으로 가지고
router를 가진다.

extension Coordinator {
  public func dismiss(animated: Bool) {
    router.dismiss(animated: animated)
  }

  public func presentChild(_ child: Coordinator, animated: Bool) {
    presentChild(child, animated: animated, onDismissed: nil)
  }

  public func presentChild(_ child: Coordinator, animated: Bool, onDismissed: (()->Void)?) {
    children.append(child)
    child.present(animated: animated, onDismissed: {[weak self, weak child] in
      guard let self = self, let child = child else { return }
      self.removeChild(child)
      onDismissed?()
    })
  }

  public func removeChild(_ child: Coordinator) {
    guard let index = children.firstIndex(where: { $0 === child }) else { return }
    children.remove(at: index)
  }
}

child를 present 할 때는 children에 해당 child View Controller를 등록한다. onDismissed 클로져에는 실행 시에 스스로를 제거하는 클로져이다.

Simple Example

간단한 실제 예제로 Coordinator 패턴을 좀더 들여다보자.

간단하게 각기다른 3개의 뷰 컨트롤러가 있다고 가정하자.
Coordinator 패턴이 아닌 일반적인 방법으로 계층을 보면

ViewController1에서 ViewController2를 인스턴스화 하고 push한다(네비게이션 기준, present일 수도 있다.)
ViewController2에서 ViewController3를 인스턴스화 하고 push한다.

이고 각 뷰컨트롤러 내용에는 화면 전환에 대한 코드가 존재할 것이다.

//View Controller1
func buttonAction() {
    navigationController?.pushViewController(ViewController2, animated: true)
    //or
    present(ViewController2, animated: true)

}

//View Controller2
func buttonAction() {
    navigationController?.pushViewController(ViewController3,     animated: true)
    //or
    present(ViewController3, animated: true)
}


//View Controller3
func buttonAction() {
    navigationController?.popViewController(animated: true)
    //or
    dismiss(animated: true))
}

Coordinator 패턴에서는 이 부분이 뷰 컨트롤러에서 빠지고, 두 컴포넌트, Coordinator와 Router로 분리되어 작성된다.

그러면 뷰컨트롤러에서는 Coordinator에게 나 버튼 눌렸으니 화면 이동해줘! 라고 핸들러나 델리게이트로 알려주기만 하면 된다. 어떻게 전환할지(push, present)는 Router에서,
어디로 이동할지(ViewController1 -> ViewController2)는 Coordinator에서 관리하게 된다.

Concrete Coordinator에서는 ViewController의 계층을 알고있고, View Controller에서 델리게이트 또는 핸들러 등으로 화면 전환이 필요하다고 요청하면, Router를 통해 어떻게 전환할 것인지 결정한다.

장점

Coordinator Pattern의 장점은 위 처럼 하여, 여기저기 흩어져 있는 뷰 계층을 Coordinator에서 한눈에 파악이 가능하고, 뷰 전환에 관련된 코드가 뷰 컨트롤러에서 빠지므로, 뷰가 좀더 정말 보여주는 거에만 집중할 수 있다.
다만 너무 작은 시스템에서는 오히려, 오버킬이 될 수 있다.

Access Control

Hey_Hen — Wed, 9 Feb 2022 17:59:53 +0900

Access Controler(접근제어)

Reference by Swift Apprentice

프로그래밍시 프로퍼티나 메소드, 이니셜라이저 기타 유형 등을 이용해서 Swift 타입을 선언하고 이러한 요소들을 합쳐 API 인터페이스를 구성한다. 코드가 복잡해지고 인터페이스를 제어하는 과정에서 일명 도우미 메소드를 인터페이스 내부에서 사용하는 경우가 있다.

외부에서 이 인터페이스를 사용할 때는 이러한 도우미 메소드는 숨기는 것이 구현의 복잡성을 숨길 수 있다.

또 이 숨겨진 내부 상태는 공개 인터페이스가 항상 유지해야 하는 불변성을 유지하게 하는 일명 캡슐화로 알려진 기본적인 소프트웨어 설계 개념이다.

접근 제어가 없다면?

은행 라이브러리를 작성하고 있다고 가정하자, 해당 라이브러리는 다른 은행이 뱅킹 소프트웨어를 작성할 수 있는 기반을 하는데 도움이 되는 라이브 러리이다.

protocol Account {
  associatedtype Currency

  var balance: Currency { get }
  func deposit(amount: Currency)
  func withdraw(amount: Currency)
}

이 코드는 Account로 정의 된 것은 잔액을 확인하는 프로퍼티와, 입출금을 하는 메소드가 정의 되어 있다.

typealias Wons = Int

class BasicAccount: Account {

  var balance: Wons = 0

  func deposit(amount: Wons) {
    balance += amount
  }

  func withdraw(amount: Wons) {
    if amount <= balance {
      balance -= amount
    } else {
      balance = 0
    }
  }
}

한국은행에서 이 프로토콜을 가져와 위와 같이 프로토콜을 준수해서 클래스를 만들었다고 친다.

Account 프로토콜에서 잔고는 읽기를 요구사항으로 정의 했지 쓰기 기능에 대해서 제한은 걸어두지 않았다.

//계좌를 개설한다.
let account = BasicAccount()

//계좌에 입 출금한다.
account.deposit(amount: 10_000)
account.withdraw(amount: 5_000)

//돈을 1백만원으로 변경한다?
account.balance = 1_000_000

계좌의 잔고 변동은 입출금 메소드를 통해서만 변경이 가능해야 하는데 이 경우 아무런 제약사항이 없기 때문에 외부에서 내부 상태를 직접적으로 변경할 수 있다.

이러한 예시로 접근 제어가 보안 기능과 연관이 있다고 착각할 수 있다. 접근 제어의 목적은 보안이 아니라 객체의 불변성과 정확성을 유지하는 것에 있다는 것을 명심하자.

접근 제어 종류

접근 제어는 속성이나 메소드 앞에 형식 선언 앞에 modifier 키워드를 추가로 선언한다.

예를들어 위와 같은 BasicAccount에 접근제어를 설정하자면

typealias Wons = Int

class BasicAccount: Account {

  private(set) var balance: Wons = 0

  func deposit(amount: Wons) {
    balance += amount
  }

  func withdraw(amount: Wons) {
    if amount <= balance {
      balance -= amount
    } else {
      balance = 0
    }
  }
}

balance를 설정하는 set은 private로 외부에서 이를 접근하는 것을 제한한다. 아까와 같은 실행 코드를 작성하게 되면 balance 메소드는 접근이 불가하다며 컴파일 에러를 발생시킨다.

private : 동일한 소스 파일 내에서 타입 정의, 모든 내부 타입, 해당 타입의 확장자에만 액세스 할 수 있다.
fileprivate : 정의된 소스 파일 내 어디에서나 액세스 할 수 있다.
internal : 정의된 모듈 내 어디에서나 액세스 할 수 있다. 이 수준은 Swift에서 기본으로 설정되어 있다.
public : 모듈을 가져오는 모든 곳에서 액세스 할 수 있다.
open : public과 동일하며 모듈의 코드를 재정의 할 수 있는 추가 기능이 부여가 된다.

Private

Private 접근 제어는 정의된 엔티티와 그 안에 있는 모든 Nested type에 대한 접근을 제한한다(이를 Lexical scope라고도 함). 동일한 소스 파일 내의 extension에 대한 엔티티에는 액세스 할 수 있다.

class CheckingAccount: BasicAccount {
  private let accountNumber = UUID().uuidString

  class Check {
    let account: String
    var amount: Wons
    private(set) var cashed = false

    func cash() {
      cashed = true
    }

    init(amount: Wons, from account: CheckingAccount) {
      self.amount = amount
      self.account = account.accountNumber
    }
  }
}

accountNumber의 경우 고유한 id이므로 상수이면서 외부에서 접근을 제한하며 Check Nested 타입의 경우 여기까지 접근을 할 수 있다.

해당 예금 계좌는 수표를 쓸 수도 있고 이를 현금화 할수도 있어야 하기 때문에 아래 메소드를 추가한다.

func writeCheck(amount: Wons) -> Check? {
  //출금을 하는데 출금 금액보다 잔고수가 많아야 한다.
  guard balance > amount else {
    return nil
  }

  //출금 목표 금액 만큼의 수표를 작성한다.
  let check = Check(amount: amount, from: self)
  //출금
  withdraw(amount: check.amount)
  return check
}

func deposit(_ check: Check) {
  //수표가 아직 현금화 되지 않았을 때만 진해앟ㄴ다.
  guard !check.cashed else {
    return
  }

  //계좌에 입금한다.
  deposit(amount: check.amount)
  //수표를 현금화 했다고 알린다.
  check.cash()
}

철수가 영희에게 수표를 쓴다고 가정하자

//철수의 계좌를 만들고 3백만원을 입금한다.
let 철수Checking = CheckingAccount()
철수Checking.deposit(amount: 3_000_000)

//철수 계좌로부터 2백만원의 수표를 작성한다.
let check = 철수Checking.writeCheck(amount: 2_000_000)!

//영희의 계좌를 만들고 수표를 철수가 쓴 수표를 입금한다.
let 영희Checking = CheckingAccount()
영희Checking.deposit(check)
영희Checking.balance // 2_000_000

//이미 사용한 수표를 한번 더 사용하지만
//계좌는 변도잉 없다.
영희Checking.deposit(check)
영희Checking.balance // 2_000_000

코드 작성을 해보면 알겠지만 영희Checking.까지 입력했을 때 자동 완성이 표시하는 인터페이스를 제공한다.

또 철수가 작성한 수표의 경우 한번 사용하고 현금화가 되었는데 우리는 이를 private(set)으로 작성하였기 때문에 외부에서 직접적으로 현금화된 상태를 변경할 수 없다.

또 check의 경우 Basic Account의 Nested 유형인데 private로 선언된 accountNumber직접적으로 접근할 수 없지만 우리는 초기화때 이를 account로 넘겨 받았기 때문에 이를 통해 접근할 수 있다.

여기까지 작성된 코드 중 Account protocol과 Wons typealies BasicAccount를 플레이그라운드에서 Sources 폴더로 Account.swift 라는 파일을 만들고 옮겨보자

그리고 CheckingAccount 클래스도 Sources 폴더에 CheckingAccount.swift 파일을 만들고 옮기자

이렇게 되면 남은 철수가 영희에게 수표를 작성하고 옮기는 코드가 CheckingAccount를 찾지 못해 컴파일 에러가 발생한다. 이는 나중에 해결할 것이다.

Fileprivate

fileprivate는 private가 제공하는 동일한 파일 내에서 동일한 lexical scope와 확장자 대신 엔티티와 동일한 파일에 작성된 모든 코드에 대한 접근을 허용한다.

지금 당장은 아까 작성한 Check에 대해 코더가 접근하고 수정하는 것을 막을 방법이 없다.

우리는 코드의 안전성을 위해서 CheckingAccount에서만 Check가 작성되기를 원한다.

Check의 생성자를 private로 선언해버리면 어떻게 될까?

private init(amount: Wons, from account: CheckingAccount) { //...

외부에서 Check를 선언하는 것을 막을 수 있지만 CheckingAccount에서 접근하는 것도 막아버리니 원하는 것은 아니다.

이런 상황에 사용할 수 있는 것이 바로 fileprivate이다. Check의 생성자를 fileprivate로 바꾸어 보자.

이렇게 되면 오로지 CheckingAccount에서만 Check를 작성할 수 있다.

Internal, Public, Open

private와 fileprivate는 다른 타입의 파일에 접근하는 코드를 보호할 수 있다. 이러한 Access Modifier는 Internal 디폴트 액세스 레벨에서 엑세스룰 수정했다.

Internal 엑세스 레벨은 엔터티가 정의된 소프트웨어 모듈 내의 모든 위치에서 엔터티에 액세스 할 수 있음을 의미한다. 지금까지 모든 코드를 하나의 플레이그라운드 파일을 작성했는데 이는 모두 동일한 모듈에 있음을 의미한다

내부 액세스 수준은 엔터티가 정의된 소프트웨어 모듈 내의 모든 위치에서 엔터티에 액세스할 수 있음을 의미합니다. 지금까지 모든 코드를 하나의 플레이그라운드 파일에 작성했습니다. 이는 모두 동일한 모듈에 있음을 의미합니다.

플레이그라운드의 Sources 디렉토리에 코드를 추가하면 플레이그라운드에서 사용하는 모듈을 효과적으로 생성한 것이다. Xcode에서 플레이그라운드가 작동하는 방식으로 Sources 디렉토리의 모든 파일은 한 모듈의 일부이며 플레이그라운듸 모든 것은 Sources 폴더의 모듈을 사용하는 또 다른 모듈이다.

Internal

플레이그라운드로 돌아가서 아까, private가 끝나고 Sources폴더로 파일을 나눈 뒤 코드가 작동하지 않는 것을 알고 있다.

CheckingAccount를 찾을 수 없다는 이유로 컴파일 에러가 발생하고 있다.

이에대해서 더 잘 설명하려면 Public과 Open에 대해서도 알아야 한다.

Internal은 별도로 사용하지 않았지만 이는 Swift에서 기본 액세스 수준이므로 명시적으로 선언할 필요가 없다.

Public

CheckingAccount를 플레이그라운드에 정상적으로 표시되게 하려면 액세스 수준을 Internal에서 Public으로 변경해야 한다. Public은 정의된 모듈 외부의 코드에서 보고 접근할 수 있는 엔터티이다.

CheckingAccount 클래스에 Public modifier를 추가하자 또한 CheckingAccountrk Account 모듈에서 BasicAccount를 불러올 수 있도록 BasicAccount에도 public을 추가하자

이번엔 CheckingAccount에 대한 접근은 가능하지만 여전히 다음과 같은 에러가 발생한다.

CheckingAccount' initializer is inaccessible due to 'internal' protection level

CheckingAccount의 생성자가 internal 보호 수준으로 접근할수가 없다고 한다.

타입 자체는 Public으로 공개되었지만 해당 멤버는 여전히 Internal이므로 모듈 외부에서 사용할 수가 없다. 이제 덕지 덕지 public을 붙일 차례이다.

BasicAccount와 CheckingAccount에 기본 생성자를 public으로 해서 새로 만들어 주고

BasicAccount의 경우 balance, deposit, siwthdraw 그리고 typealias를 모두 public으로 선언한다.

CheckingAccount에서는 writeCheck(amount:), deposit(_:) Check을 모두 public으로 선언한다.

BasicAccount에서 balance는 private(set)으로 선언 되어 있는데 이경우는

public private(set) var balance: Wons = 0

위와 같이 작성해 주면 된다.

Open

이제 CheckingAccount 및 해당 멤버들이 공개되어 뱅킹 인터페이스를 설계된 대로 사용할 수 있다. 하지만 한가지 기존 계좌 형태가 아니라 다른 특별한 형태, 예를들어 이자가 붙는 계좌를 만든다고 했을 때를 보자

class SavingsAccount: BasicAccount {
  var interestRate: Double

  init(interestRate: Double) {
    self.interestRate = interestRate
  }

  func processInterest() {
    let interest = Double(balance) * interestRate
    deposit(amount: Int(interest))
  }
}

그러나 BasicAccount가 Open이 아니라서 재정의 할 수가 없다는 에러가 발생한다. 이제 BasicAccount를 Public에서 Open으로 수정해서 해결 할 수 있다.

BasicAccount 가 open으로 공개되었다고 해서 그 안에 정의된 출금, 입금 메소드를 재정의 할 수는 없다.

override func deposit(amount: Wons) {

    super.deposit(amount: 1_000_000)
}

다행히도 이런 코드는 동작하지 않는다.

Extension 코드 조직화

접근 제어의 주제는 코드가 느슨하게 결합되고 응집력이 높아야 한다는 내용이다. 느슨하게 결합된 코드는 한 엔터티가 다른 엔터티에 대해 아는 정도를 제한하므로 코드의 다른 부분이 또 다른 부분에 덜 의존하게 된다. 앞에서 나온 내용처럼 응집력이 높은 코드는 밀접하게 관련된 코드가 함게 작업하여 작업을 수행하는데 도움이 된다.

행동(Behavior)에 의한 Extension

Swift의 효과적인 전략은 코드를 행동에 따라 extension을 구성하는 것이다. extension 자체에도 접근 제어를 적용할 수 있다. 그러면 전체적인 코드 섹션을 public, internal, private로 분류하는데 도움이 된다.

예를들어 CheckingAccount에서 사기 방지 기능을 추가하려고 한다.

CheckingAccount에 다음과 같은 속성을 추가한다.

private var issuedChecks: [Int] = []
private var currentCheck = 1

그리고 private extension을 추가한다.

private extension CheckingAccount {
  func inspectForFraud(with checkNumber: Int) -> Bool {
    issuedChecks.contains(checkNumber)
  }

  func nextNumber() -> Int {
    let next = currentCheck
    currentCheck += 1
    return next
  }
}

위 메소드와 프로퍼티로 수표 발행의 사기 행각을 추적을 계획이다. 이 확장자는 private로 선언했는데 암시적으로 해당 멤버 전부를 private로 보게 된다. 이렇게 하면 해당 기능은 오로지 CheckingAccount에서만 컨트롤 할 수 있다.

프로토콜에 따른 Extension

또 다른 분류법은 프로토콜 준수를 기반으로 확장하는 것이다.

extension CheckingAccount: CustomStringConvertible {
  public var description: String {
    "Checking Balance: $\\\\(balance)"
  }
}

위 확장은 CustomStringConvertible을 구현하는데 더 중요한 것은 다음과 같다.

description이 CustomStringConvertible의 일부분임을 분명히 한다.
다른 프로토콜을 준수하는데 영향을 주지 않는다.
CheckingAccount의 나머지 에 대해 영향을 끼치지 않고 손쉽게 제거하고 추가할 수 있다. 이해하기도 쉽다

available()

SavingsAccount를 보면 이자를 증가시키는 메소드를 여러번 호출해서 반복적으로 동작해서 이자 추가를 남용할 수도 있다. 이 기능을 좀더 안전하게 만들기 위해 계정에 PIN을 추가할 수 있다.

class SavingsAccount: BasicAccount {
  var interestRate: Double
  private let pin: Int

  init(interestRate: Double, pin: Int) {
    self.interestRate = interestRate
    self.pin = pin
  }

  func processInterest(pin: Int) {
    if pin == self.pin {
      let interest = balance * interestRate
      deposit(amount: interest)
    }
  }
}

SavingsAccount에 pin을 추가하고 이자 증가 메소드가 이 PIN을 매개변수로 사용하는지 확인한다.

이제 이자 증가 메소드를 함부로 사용할 수 없도록 했지만 기존에 이 SavingAccount클래스를 사용하던 은행 클라이언트는 업데이트된 코드로 인해서 기존에 쓰던 코드가 컴파일이 되지 않는다.

이전 구현을 사용하는 코드가 깨지는 것을 방지하려면 코드를 교체하는 대신 더 이상 사용하지 않아야 한다.

class SavingsAccount: BasicAccount {
  var interestRate: Double
  private let pin: Int

  @available(*, deprecated, message: "Use init(interestRate:pin:) instead")
  init(interestRate: Double) {
    self.interestRate = interestRate
    pin = 0;
  }

  init(interestRate: Double, pin: Int) {
    self.interestRate = interestRate
    self.pin = pin
  }

  @available(*, deprecated, message: "Use processInterest(pin:) instead")
  func processInterest() {
    let interest = balance * interestRate
    deposit(amount: interest)
  }

  func processInterest(pin: Int) {
    if pin == self.pin {
      let interest = balance * interestRate
      deposit(amount: interest)
    }
  }
}

이렇게 하면 이전버전을 사용하려고 하는 유저에게 경고 메시지를 남겨줄 수 있다.

별표 매개변수는 영향을 받는 플랫폼을 나타내고, 두번째 매개변수는 deprecated, renamed, unavailable을 나타낸다.

Opaque return types

은행 라이브러리 사용자를 위한 공개 API를 만들어야 된다고 하자 createAccount라는 새 계정을 만드는 함수를 만들어야 한다. 이 API의 요구 사항 중 하나는 구현 세부 정보를 숨겨 클라이언트가 일반 코드를 작성하도록 권장하는 것이다. 이는 생성 중인 계정 유형(BasicAccount, CheckingAccoung 또는 SavingsAccount)를 노출해서는 안된다는 의미이다. 대신 프로토콜 Account를 준수하는 일부 인스턴스만 반환한다.

이를 활성화하려면 우선 Accouns 프로토콜을 public으로 두어야 한다.

func createAccount() -> Account {
  CheckingAccount()
}

위와 같이 이제 코드를 작성하면 에러가 발생하는데 프로토콜 Account는 Self 또는 연관 타입 요구사항이 있기 때문에 일반 제약 조건으로만 사용할 수 있다고 한다.

이 문제를 해결하기 위해서는 아래 처럼 쓰면 된다.

func createAccount() -> some Account {
  CheckingAccount()
}

some 키워드를 붙였다. 이게 불투명한 반환 타입이며 Account 클래스 타입을 노출하지 않고 함수가 반환하려는 타입을 결정할 수 있도록 한다.

Swift 최적화

Swift에서 접근 제어자의 역할은 기본적으로 접근 범위를 제한함으로써, 객체지향의 원칙을 지키는데 있으나, 동시에 컴파일러에서 빌드 속도를 최적화 하는데 이용될 수 있다.

컴파일러가 .swift 파일을 빌드할 때, 각 객체(클래스나 구조체)관의 의존성(누가 누구를 호출하는지)을 확인하는데 이때 접근제어자로 이를 명시적으로 지정하게 되면 컴파일러는, 해당 클래스의 재정의 여부나 의존 여부를 쉽게 판단하게 된다.

private class E {
  func doSomething() { ... }
}

class F {
  fileprivate var myPrivateVar: Int
}

func usingE(_ e: E) {
  e.doSomething() // There is no sub class in the file that declares this class.
                  // The compiler can remove virtual calls to doSomething()
                  // and directly call E's doSomething method.
}

func usingF(_ f: F) -> Int {
  return f.myPrivateVar
}

출처

swift/OptimizationTips.rst at main · apple/swift

프로젝트에 여러 모듈이 있는 경우, 다른 모듈에서 참조할 필요가 없는 경우는 기본인 internal로 선언되는 것도 중요하다! 모든것을 다 public 선언 해버리면 컴파일러가 전부 관계 조사를 해야할 것이다.

SwiftGen 사용기 (Homebrew)

Hey_Hen — Wed, 9 Feb 2022 16:47:47 +0900

소개

SwiftGen을 간단하게 소개하자면

이해하기 쉽게 시나리오로 설명을 해보려고 한다.

Assets 카탈로그에 Icons, Image, Color등을 정의하고 이를 프로젝트에서 사용하기 위해서는 각각의 생성자 (Color로 예를들자면 UIColor(named:) 를 통해 Asset에 지정한 문자열 상수를 넣어 불러와야 한다.
```
let customColor = UIColor(named: "customRed")!
```
해당 방법은 문자열을 하드코딩 한다는 점에서, 실수가 발생할 여지가 있고, 또 런타임에 에러가 결정되기 때문에 컴파일 타임에 해당 실수를 잡아내기 어렵다.

그래서 보완책으로 아래 처럼 사용해볼 수 있었다.

enum Constans: String {
  let customRed = "customRed"
}

extension UIColor {
  static var customRed: UIColor {
    UIColor(named: Constans.customRed.rawValue) ?? UIColor()
  }
}

let customRed: UIColor = .customRed

추가한 에셋이 많을 경우는 매크로 코드를 짜서 일괄로 생성하는 방법도 썼었다.

이 부분을 간편하게 해주도록 나온 것이 바로 SwiftGen이다.
SwiftGen은 위 과정을 템플릿을 통해 일괄적으로 작업할 수 있게 해주고,
하드코딩에 의한 실수, 또 컴파일 타임에 에러를 잡을 수 있도록 도와준다.
어떻게 사용하는지 알아보자.

설치

설치 전에 나의 작업 환경은 다음과 같다.

m1 macbook pro 16g
Xcode 13.2
Monterey 12.1

설치 방법
github에 잘 소개 되어있기도 한데 여러 방법마다 장단이 있는 것 같다.

Download the ZIP
CocoaPods
Homebrew
Mint
Zip과 CocoaPods는 프로젝트 별로 따로 적용하는데 이용하기 편하고
Homebrew와 Mint는 시스템 전체적으로 사용할 수 있기 때문에,프로젝트 마다 일일이 설정하기 싫은 경우 선택할 수 있다.

나는 Homebrew를 선택했고, Homebrew로 설치했지만, 프로젝트마다 다르게 swiftgen.yml을 다르게 적용해보려고 한다.

Homebrew 설치

terminal에서 brew로 swiftgen을 설치한다.

brew update
brew install swiftgen

이 경우 hoem directory에 기본적으로 swiftgen.yml이 위치하게 된다.

swiftgen 기본 사용법

swiftgen의 기본 사용 방법은 swiftgen.yml을 통해 템플릿을 작성하고
swiftgen으로 템플릿을 파싱하는 식이다.

swiftgen.yml에서는 번들의 Assets.xcassets를 파싱해서
Asset+Generated.swift(예시 이름)를 생성한다.

Asset+Generated.swift에는 열거형으로 Asset에 정의한 것들을 접근할 수 있게 한다.
예를들어

let customRed: UIColor = Asset.Color.customRed.color

위와같이 쓸 수 있다. 타입 어노테이션은 참고하라고 써둔 것이고 필수가 아니다.

일단은 저게 어떻게 돌아가는지 간단하게 테스트 해보자.

터미널에서 다음과 같이 입력한다.

cd ~/Desktop
swiftgen config init

만약 여기서 에러 났으면 brew로 swiftgen이 설치가 안된거다.

우선 사용하기 편하게 데스크톱 디렉토리로 이동 한 뒤 작업한다.
위 명령어는 swiftgen.yml을 생성하는 명령어이다.
Dekstop 디렉토리로 가면 swiftgen.yml이 생성되어 있을 것이다.
아마 swiftgen config init 명령어를 입력하면 swiftgen.yml 파일이 자동으로 편집기로 열릴 것이다.

swiftgen.yml내용을 보면 주석으로 사용법이 자세하게 적혀있는게 나중에 디테일 하게 사용하고 싶다면 꼭 읽어보자

우리는 우선 asset에만 집중해보자.

프로젝트에서 방금 만든 swiftgen.yml을 가져오자.

릴리즈 하고 나면 swiftgen이 실행 될 일이 없기 때문에, 따로 가져올 필요가 없지만, 설명에 편의를 위해 가져왔다. 프로젝트에 따로 추가하지 않아도 되고 필요한 디렉토리 위치시켜 두고 위치만 지정하면 된다.

yml내용을 보면

# xcassets:
#   inputs:
#     - Main.xcassets
#     - ProFeatures.xcassets
#   outputs:
#     - templateName: swift5
#       params:
#         forceProvidesNamespaces: true
#       output: XCAssets+Generated.swift

이 부분이 Asset을 파싱 후 컨버팅 해주는 부분으로, 조리해서 사용하면 된다.

사용해보려고 하는 부분은 Color Asset을 별도로 만들어 볼려고 한다.

Asset Catalog를 하나 새로 만든다.

이름은 Color 로

Color Asset안에 커스텀 컬러 몇개 저장 후

swiftgen.yml에 다음과 같이 내용을 추가한다.

xcassets:
  inputs:
    - Color.xcassets
  outputs:
    - templateName: swift5
      params:
        enumName: Colors
      output: Color+Generated.swift

내용을 찬찬히 뜯어보면

xcassets: xcassets 형태를 파싱하기 위한 명령어로 문서보면 xcassets말고도 string, ib 등등이 있다.
inputs: 입력할 파일로 우리가 생성한 Asset Catalog를 전달
outputs: 출력할 영역
- templateName: swift5를 쓰자, 특별히 swift4를 쓸일이 있으면 해당 내용을 전달하면 된다. 자세한 내용은 문서
- params: 파일을 출력할 때 몇가지 옵션을 줄 수 있다.
- enumName: 따로 설정하지 않으면 기본 열거형의 이름이 Asset로 정해진다.
- output: 출력할 파일 이름

작성이 끝났으면 terminal로 해당 yml이 있는 디렉토리로 찾아간다.
그리고 아래 명령어를 입력
swiftgen config run
성공적으로 명령어가 동작했다면
File written: Color+Generated.swift
이라고 표시된다.
지금은 아무것도 보이지 않을텐데 해당 디렉토리로 가 보면
Color+Generated.swift파일이 생성 되어 있을 것이다.
이를 프로젝트에 추가한다.

struct ContentView: View {
  var body: some View {
    Text("Hello, world!")
      .padding()
      .foregroundColor(Colors.customRed.color)
  }
}
extension View {
  func foregroundColor(_ uicolor: UIColor) -> some View {
    self.foregroundColor(Color(uicolor))
  }
}

extension은 foregroundColor에서 UIColor로 바로 생성할 수 있도록 작성 된것

실제로 컬러는
Color.customRed.color로 접근할 수 있다. 형태는 Color는 yml에서 작성한 enumName이다.

여기까지가 기본적인 작업 플로우로, 정리해보면

swiftgen.yml 을 생성
swiftgen.yml 템플릿 내용을 작성
terminal에서 swiftgen config run
생성된 swift파일 프로젝트에 추가
이다.

여기서 좀더 생각해보면, Asset Catalog에 새 Asset이 추가될 때 마다 terminal 키고 swiftgen config run 하면 너무 귀찮은데? 라는 생각이 들 수 있다. 이부분을 자동화 시켜줄 수 있는것이 바로 Run Script이다.

RunScript

프로젝트 -> 타겟 -> 빌드 페이즈(Build Phases)로 이동한 뒤
Run Script를 하나 추가하자.

run script는 빌드 할 때 자동으로 터미널 켜서 스크립트 안에 적힌 내용을 실행시켜 주는 기능이라고 생각하면 된다.

요 Shell 안에 내용을 작성할 것인데

여기서 앞서 우리가 터미널에서 했던
swiftgen config run 을 작성해주면
빌드 될 때 마다 파싱해서 Generated.swift를 생성해 줄 것이다.

위 내용을 넣고 빌드해보면~

에러가 난다.
별 내용은 아니고 terminal에서 swiftgen 실행시키려고 하는데 없어서 그러는 거다.
brew에 설치된 swiftgen을 실행시켜야 해서 패스를 지정해 준다.

PATH=/opt/homebrew/bin:$PATH
swiftgen config run

여기서 실행 시켜보면 또 에러가 난다.

이번에는 swiftgen.yml을 찾을 수가 없다고 나온다. 엥?
그래서 해당 명령어를 실행하기 전에 위치한 디렉터리가 어딘지 보자

PATH=/opt/homebrew/bin:$PATH
pwd
ls
swiftgen config run

스크립트에 위 내용으로 변경후 발생하는 에러를 보면

프로젝트 폴더에는 가있는데 타겟 폴더에 안들어가 있다.

타겟 폴더 안으로 들어가면 되겠다.

PATH=/opt/homebrew/bin:$PATH
cd SwiftGenPractice
swiftgen config run

이제 빌드해보면 에러가 발생하지 않고 정상 빌드 될 것이다!

인라인?

이 경우는 swfitgen.yml을 찾고 내용대로 파싱해서 파일을 생성하는 방식인데 사실 예제처럼 파싱할 내용이 많지 않으면 yml없이 인라인으로 작성할 수도 있다.

swiftgen xcassets Resources/Images.xcassets --templateName swift5 --output "Constants/Assets+Generated.swift"

정리

swiftgen은 자동화 도구로 사용만 잘하면 굉장히 유용하다.
굳이굳이 homebrew로 설치하고, 프로젝트 마다 다르게 사용하려면 위 처럼 고생한다. 잘 동작은 하는데 이게 맞는 방법인지는 모르겠다.
템플릿을 커스텀하거나, 파싱하는데 더 다양한 옵션을 제공하므로 문서를 꼭 확인하자.
전체코드

Firebase Auth 전화번호 회원가입

Hey_Hen — Wed, 9 Feb 2022 16:46:45 +0900

Firebase Auth에서 제공하는 전화번호 인증해보기

1. 사전작업

우선 Firebase Auth 전화번호 인증은, Slient Push Notification을 이용해 토큰을 보내기 때문에 Push Notification을 사용하는 것과 동일하다.

따라서 아래의 준비가 필요하다.

유료 애플 개발자 계정
Xcode Project Setup
Apple Developer Member Center Identifier

유료 애플 개발자 계정

앞서 말했지만, 유료 애플 개발자 계정을 필요로 한다.

Xcode Project Setup

Push Notification을 받는 것이기 때문에 Xcode 설정이 필요하다.
Project - Target - Signing & Capabilites - Push Notifications

Apple Developer Member Center Identifier

인증토큰은 Firebase project에 등록해야할 토큰으로 아래 과정을 통해서 만들 수 있다.

Developer Apple의 Member Center로 이동 후, Keys탭으로 간다.

적당히 알아볼 만한 이름을 작성하고, APNs를 체크 한 후 Continue - Register

그다음 Download가 나오는데

경고문을 찬찬히 읽어보면, 보안을 위해 다운로드 후에는 서버에서 해당 키를 삭제한다고 한다. 그러니까 다운받은 그것이 유일본이기 때문에 잃어버리지 않도록 안전한 곳에 보관해야 한다.

키를 다운받아 보면 AuthKey_ABCDEFGH~ 이런식으로 되어있는데 언더바 뒤의 알파벳,숫자 조합이 바로 키 아이디가 된다.

이제 디바이스 토큰, 인증 토큰(키), 그리고 하나 더 필요한 것은 TeamID인데 이것은 화면 우측 상단 계정에 이름 아래에 있다.

위 토큰을 이제 Firebase에 넣어주면 된다.

해당 내용은 파이어베이스 전화번호 인증 문서 참고

Firebase 인증 문서

2. 프로젝트

파이어베이스에 프로젝트에 앱을 등록했으면, 이제 프로젝트에 작성할 일만 남았다.

우선 본인은 SwiftUI로 했는데 SwiftUI 처음 진입하면 AppDelegate가 없다.

다음과 같이 작성해준다. (프로젝트명App.swift)

import SwiftUI
import Firebase

class AppDelegate: NSObject, UIApplicationDelegate {

  func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {

    FirebaseApp.configure()
    return true
  }

  func application(_ application: UIApplication,
                   didReceiveRemoteNotification notification: [AnyHashable : Any],
                   fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {

  }
}

@main
struct FirebasePhoneAuthPracticeApp: App {
  @UIApplicationDelegateAdaptor(AppDelegate.self) var delegate

  var body: some Scene {
    WindowGroup {
      ContentView()
    }
  }

노티피케이션의 기본적인 플로우는 아래와 같다.

application(_:didFinishLaunchingWithOptions:) 에서 registerForRemoteNotifications를 통해 APN으로 디바이스 토큰을 전송한다
APN은 앱에 디바이스 토큰을 반환하고 이때 application(_:didRegisterForRemoteNotificationsWithDeviceToken:) 호출하거나 토큰 등록에 실패했을 시 application(_:didFailToRegisterForRemoteNotificationsWithError:) 를 호출하여 알린다.
디바이스는 토큰을 binary 또는 hexadecimal 포맷으로 provider(서버)로 토큰을 보낸다. provider가 이제 토큰을 추적하기 시작한다.
provider가 notification 요청을 다수의 토큰과 함께 APNs로 보낸다.
마지막으로 APNs가 notification을 유효한 토큰이 제공된 각 디바이스에 알림을 보낸다.

그런데 Firebase 전화번호 Auth는 Slient Push Notification이기 때문에 application(_:didFinishLaunchingWithOptions:) 는 FirebaseApp초기화 때문에 필요하고 나머지는 필요하지 않다.

따라서 Slient Push를 이용하기 위한 사전 작업이 따로 필요하다.

Background Modes

Slient Push Notification은 사용자에게 보이지 않는 기능이고 백그라운드에서 동작한다. 따라서 Sining & Capabilites에 Background Modes를 추가하고 거기서 Remote Notifications을 체크 한다.

App Delegate

func application(
  _ application: UIApplication,
  didReceiveRemoteNotification userInfo: [AnyHashable: Any],
  fetchCompletionHandler completionHandler:
  @escaping (UIBackgroundFetchResult) -> Void
) {
  ...
}

application(_:didReceiveRemoteNotification:fetchCompletionHandler) 델리게이트 메서드가 있어야 한다. 해당 코드는 이미 작성했으므로 Slient Push Notification을 사용할 준비가 되었다.

또 Slient Push Notification은 유저에게 알람이 발생하지 않으므로 알람에 대한 동의를 받을 필요가 없다.

인증하기

인증하는 작업 플로우는 다음과 같다.

전화번호를 검증하고 요청한다.
1번 과정이 성공적으로 진행되면 해당 번호로 인증번호가 온다.
유저가 작성한 인증번호가, 실제로 서버에서 보낸 인증번호가 일치하는 작업을 한다.
3번이 성공적일 경우 로그인 루틴을 실행한다.

1. 전화번호 검증

func requestVerifyCode() {
    buttonDisabled = true
    let validPhoneNumber = "+82\(phoneNumber)"
    PhoneAuthProvider.provider().verifyPhoneNumber(validPhoneNumber, uiDelegate: nil) { verification, error in
      if let error = error {
        print("error: \(error)")
        buttonDisabled = false
      } else {
        self.verificationId = verification
        withAnimation {
          watingVeryfiId = true
        }
      }
    }
  }

텍스트필드에 입력된 전화번호를 검증하고 Firebase서버에 요청하는 코드로

verifyPhoneNumber(_:uiDelegate:completion:) 메서드를 통해 요청한다.

첫번째 인자에 유저가 입력한 전화번호가 들어가면 된다. 입력은 통상적으로 입력하는 010~ 패턴이면 되는데 앞에 국가코드를 포함해야 한다.

전화번호 검증이 성공했을 때 인증코드가 전화번호로 날아오게 된다.

2. 인증번호 검증

func verifyLogin() {
    isVerifying = true
    let credential = PhoneAuthProvider.provider().credential(withVerificationID: verificationId ?? "", verificationCode: userVerify)
    Auth.auth().signIn(with: credential) { (success, error) in
      if let error = error {
        print("error: \(error.localizedDescription)")

      } else {
        print("success")
        showMainView = true
      }
      isVerifying = false
    }
  }

이제 유저가 받은 인증코드를 다른 텍스트필드에 입력하고, 1에서 받은 인증코드와 비교하는 메서드를 작성한다.

credential(withVerificationID:verificationCode) 메소드에 첫번째 인자는 verifyPhoneNumber메서드로 받은 인증코드, 그리고 두번째 인자에는 유저가 입력한 인증코드가 된다. 두 개가 일치하게 되면 인증이 성공하는 것이다.

기본 코드만 작성 한 것으로 토큰 관리나, 로그인 상태 관리 등은 꼭 별도로 해야한다!

전체 코드 보기

iOS 15.0 UIButton

Hey_Hen — Wed, 9 Feb 2022 16:45:20 +0900

WWDC2021가 발표한지는 한참 지났지만, 정리해보는 UIButton,
iOS15.0의 버튼이 특별히 달라지는 것은 아니지만, 기존에 서브클래싱 등으로 해결해야 했던것을 Configuration을 통해 제공해주는 것이 핵심이다.

Basic Style

iOS15.0 UIButton은 기본 4가지 스타일을 제공한다.

Plain
Gray
Tinted
Filed

전통적인 UIButton은 다음과 같을 것이다.

let button = UIButton(type: .system)
button.setTitle("Sign In", for: [])

여기에 Basic Style을 적용하는 방법은 아래와 같다.

let button = UIButton(type: .system)
button.setTitle("Sign In", for: [])
button.configuration = .filled()

Basic Style을 적용해서 BackgroundColor Tint와CornerRadius가 있는 버튼을 빠르게 얻을 수 있다.
바닐라 스타일을 사용하는 사람들에게는 편리한 기능으로 보인다.

UIButton.Configuration

UIButton 인스턴스를 생성 한 후에, 프로퍼티들을 바꾸는 것이 아니라, UIButton.Configuration을 미리 만들고, UIButton 인스턴스를 만들 때 configuration을 생성자에 전달할 수 있다.
이 방법은 굳이 UIButton을 서브클래싱 하는 것보다 더 나은 재사용성을 누릴 수 있다.

위 예제에서는 button을 생성 한 뒤에, 타이틀을 입력했지만 configuration을 사용하면 아래와 같이 할 수 있다.

var config = UIButton.Configuration.tinted()
config.title = "Hello, Swift!"
config.image = UIImage(systemName: "swift")

let button = UIButton(
  configuration: config,
  primaryAction: UIAction(handler: { _ in
    print("Hello, Swift!")
  }))

configuration에는 다양한 옵션이 있기 때문에 입맛대로 사용하기도 편하다.
예를들어서 이미지 위치가 왼쪽이 아니라 오른쪽에 위치했으면 좋겠다고 한다면

config.imagePlacement = .trailing

이 한출 추가하는 것으로 이미지는 오른쪽으로 이동한다.

이 외에도 타이틀과 이미지의 패딩, 타이틀의 정렬 기준 등등 다양하기 때문에 문서를 보고 사용해 보길 권장

ConfigurationUpdateHandler

Button을 사용하다보면, 항상 똑같은 모습을 보여주는 정적인 버튼 말고도, 상태에 따라 변하는 동적인 버튼을 많이 사용한다.
기존에는 버튼 상태를 나타내는 모델에서 모델이 변경되면 버튼을 업데이트 하도록 구성할 수 있었다.

   button.configurationUpdateHandler =  { [unowned self] button in
      var config = button.configuration
      config?.title = "오늘의 할일"
      config?.image = self.done
      ? UIImage(systemName: "checkmark.square.fill")
      : UIImage(systemName: "square")
      config?.subtitle = self.done
      ? "01/16 Done!"
      : "01/16"
      button.configuration = config
    }

button.setNeedsUpdateConfiguration()

setNeedsUpdateConfiguration()을 호출해서, 버튼 UI의 갱신상태를 변경 요청할 수 있다.

Other Features

Button.Configuration은 이외에도 다양하고 유용한 기능을 제공한다.

Activity Indicator: UIButton에 별도로 서브클래싱 없이 Activity Indicator를 넣을 수 있다.
Metrics adjustments: 타이틀, 이미지, 서브 타이틀간의 위치를 설정할 수 있다.
Semantic styling: 버튼을 만들기가 더 쉬워졌다.
Customization: Color, TextAttribute 등 커스텀에 필요한 기능을 Configuration을 통해 제공한다.

기존에 UIButton에 Activity Indicator를 이용하려면 서브클래싱을 통해서 해야했는데 Button.Configuration에 이 기능이 들어갔다.


var loggin: Bool = false {
    didSet {
      button.setNeedsUpdateConfiguration()
      button.isEnabled = !loggin
    }
  }

button.configurationUpdateHandler =  { [unowned self] button in
      var config = button.configuration
      config?.title = "Sign In"
      config?.showsActivityIndicator = loggin
      config?.image = UIImage(systemName: "externaldrive.connected.to.line.below")
      button.configuration = config
    }

func requestLoggin() {
  loggin = true
  //Network Request Code
  DispatchQueue.main.asyncAfter(deadline: .now() + 2.5) {
     self.loggin = false
  }
}

configurationUpdateHandler()에 showActivityIndicator만 설정해 주면 된다.
예를들어서 로그인을 요청하면 서버에서 응답이 올때까지 버튼에 인디케이터가 표시 되어야 하는 경우, 다음 과 같이 코드를 작성할 수 있다.

Toggle Button

버튼의 On/Off 상태를 좀더 편리하게 사용해주는 새 기능으로 해당 프로퍼티를 true로 설정하게 되면 버튼 선택에 따른 상태를 얻을 수 있다.

button.changesSelectionAsPrimaryAction = true

changeSelectionAsPrimaryAction을 true로 하면 버튼 토글 상태가 button.isSelected로 전달된다.
맨 위에서 했던 예제로 다시 돌아가자면

button.changesSelectionAsPrimaryAction = true

button.configurationUpdateHandler =  { button in
  var config = button.configuration
  config?.title = "오늘의 할일"
  config?.image = button.isSelected
  ? UIImage(systemName: "checkmark.square.fill")
  : UIImage(systemName: "square")
  config?.subtitle = button.isSelected
  ? "01/16 Done!"
  : "01/16"
  button.configuration = config
}

버튼의 상태를 isSelected로 선택해볼 수 있다.

Pop-up button

버튼을 구성할 때 팝업 버튼 형식으로 쓰고 싶을 때는 showMenuAsPrimaryAction 을 true로 두기만 하면 된다.

button.showsMenuAsPrimaryAction = true
button.menu = UIMenu(children: [
  UIAction(title: "삭제하기", attributes: .destructive, handler: deleteComment),
  UIAction(title: "수정하기", handler: editComment)
])

만약 팝업 버튼 안에서 토글 방식이 필요하다면 changeSelectionAsPrimaryAction을 true로 두면 팝업 안에서 토글 형식으로 쓸 수 있다

button.showsMenuAsPrimaryAction = true
button.menu = UIMenu(children: [
  UIAction(title: "매일반복", handler: repeatEveryday),
  UIAction(title: "요일반복", handler: repeatDay)
])
button.changesSelectionAsPrimaryAction = true

각 예제 프로젝트는 TIL에서 보실 수 있습니다.
https://github.com/urijan44/TIL-Store/tree/master/iOS_Swift/UIKit/UIButtonConfiguration.playground

Swift, Concurrency

Hey_Hen — Wed, 9 Feb 2022 16:41:46 +0900

Concurrency(동시성)

동시성 프로그래밍이라고도 한다. Concurrency는 여러 작업을 나누어서 처리하는 것으로, 우리가 사용하는 아이폰이 노래도 재생하면서, 유저의 입력에 따라 이메일도 작성할 수 있고, 중간에 전화도 받을 수 있는 것이 이 동시성이다.
만약 노래를 재생하는 동안은 화면을 터치할 수 없고, 인터넷 검색도 불가능하다면, 굉장히 불편할 것이다.

코드로 실제로 어떻게 되는지 보자

//1
func calculatePrimes() {
    for number in 0...1_000_000 {
      let isPrimeNumber = isPrime(number: number)
      print("\(number) is prime: \(isPrimeNumber)")
    }
  }

//2
func isPrime(number: Int) -> Bool {
    if number <= 1 {
      return false
    }
    if number <= 3 {
      return true
    }

    var i = 2
    while i * i <= number {
      if number % i == 0 {
        return false
      }
      i = i + 2
    }
    return true
 }

calculatePrimes()는 1에서 1백만 까지의 자연수 중에 소수 를 구하는 메서드로, 해본 사람은 알겠지만 꽤 오랜 시간이 걸리는 작업이다.

var body: some View {
    VStack {
      Spacer()
      DatePicker(selection: .constant(Date())) {
        Text("Date")
      }
      .datePickerStyle(.wheel)
      .labelsHidden()
      Button {
        calculatePrimes()
      } label: {
        Text("Calculate Primes")
      }
      Spacer()
 }

화면에는 DatePicker UI가 있고, 버튼을 누르면 소수를 구하기 시작한다.

소수 구하기 버튼을 누르면 해당 계산을 하느라 DatePicker의 UI가 동작하지 않는다.
그 이유는 DatePicker의 UserInteraction과 calculatePrimes()를 둘다 메인 쓰레드에서 수행하고 있기 때문이다. calculatePrimes()가 쓰레드를 점유하고 있어서 다른 메인 쓰레드에서 작업해야 하는 User Interaction이 동작하지 않는 것이다.

Thread/Multithread

멀티쓰레드 라는 얘기 많이 들어보았는데, 그럼 쓰레드는 뭘까,

컴퓨팅에서 쓰레드는 OS 스케줄러에 의해 독립적으로 관리될 수 있는 프로그래밍된 명령의 가장 작은 시퀀스다.

요즘은 CPU는 다수의 코어와 그 이상의 쓰레드를 가지고 있어, 물리적으로 작업을 동시에 처리할 수 있다. 이게 멀티 쓰레딩이다.
이 부분이 Parallelism과 차이점이다. 병렬프로그래밍이라고 하는 Parallelism는 작업의 단위가 스레드가 아니라, CPU가 된다. 앞서 caculatePrimes()메서드를 하나의 스레드에서 점유해서 계산하지 않고, 분할해서 계산해서 작업의 속도를 높이는 것이 Parallelism이고
Concurrency의 핵심은 스레드이다.

Context Swiching

Concurrency의 또 하나의 핵심은 Context Switching으로, 하나의 코어는 Time Slicing이라는 방법을 통해 Concurrency하게 움직인다. 쉽게 이해해보면, 내가(아이폰) 커피를 만드는데 이 커피를 만드는 동작안에는 원두를 분쇄하고, 물을 끓이고, 컵을 준비하는 일련의 동작이고, 이를 아주 빠르게 한다, 다른 사람(사용자) 입장에서 보면 거의 동시에 일어나는 것 처럼 보인다.

Use Concurrency

그래서 다시 맨 처음 어플리케이션으로 돌아와서, iOS는 기본적으로 멀티쓰레드이다. 소수를 구하는 것과 동시에 UI작업을 처리할 수 있는 것이 당연한 것이다. 그런데 실제로는 계산을 하느라 UI작업을 하지 못했다. 우리는 소수를 구하는 작업을 다른 쓰레드에서 하도록 명시할 필요가 있다.

애플은 고맙게도? 쓰레드를 편리하게 사용할 수 있는 프레임워크를 제공한다. 굉장히 Low하게 보면 NSThread와 더 내려가서 Unix POSIX 쓰레드를 통해서 이 쓰레드를 사용할 수 있지만 우리에게는 Grand Central Dispatch(GCD) 가 있다. GCD 또한 Concurrency 작업을 위한 프레임워크로 꽤 LowLevel 측면으로 디자인 되어있다.

또다른 옵션은 Operation Queue로 GCD위에 만들어져 있고, 더 쉽고 간결한 코드를 제공한다.

그 다음은 2019년에 나온 Combine으로 이는 백그라운드에서 작업을 선언형으로 관리한다. 오퍼레이터를 통해 스레드 간의 쉬운 전환이 가능하다.

또! 그다음은 Swift Concurrency가 있다.

GCD

GCD는 스레드 위에 구축되며, 공유 스레드 풀을 관리한다. 이를 사용해서 DispatchQueue 에 코드 블록을 처리하고 GCD는 이를 실행할 쓰레드를 결정하게 된다.

Queue

Queue는 FIFO구조로 먼저 들어온 작업을 먼저 내보낸다는 특징이 있다. GCD는 같은 방식으로 작업 순서를 보장한다. 이때 Queue는 Seiral이거나 Concurrent일 수 있다.

이처럼 Serial은 선형 시간동안 하나의 작업만 실행된다. Task1이 끝나면 Task2가 실행되는 식이다. 쓰레드를 사용해서 이를 Concurrent하게 할 수 있다.

Concurrent는 Task순서대로 일단 작업을 할당하긴 했지만 Serial과는 다르게 Task2보다 Task3과 Task4가 훨씬 더 빨리 끝나서 작업물을 반환한다. 그래서 작업 순서를 보장할 수 없다.
커피를 다 볶은 다음에 컵에 넣고 물을 부어야 하는데, 물이 먼저 끓었다고 물부터 냅다 부어버린 것

Operation Queue

GCD를 사용하기 위해서는 Operation을 상속해서 만들 수 있다.

class CaculatePrimeOperation: Operation {


  override func main() {

    for number in 0...1_000_000 {
      let isPrimeNumber = isPrime(number: number)
      print("\(number) is prime: \(isPrimeNumber)")
    }
  }

  func isPrime(number: Int) -> Bool {
    if number <= 1 {
      return false
    }
    if number <= 3 {
      return true
    }

    var i = 2
    while i * i <= number {
      if number % i == 0 {
        return false
      }
      i = i + 2
    }
    return true
  }

}

main()에서 앞에서 작성한 소수 구하기 메서드를 이식한다.

let operation = CaculatePrimeOperation()
func calculatePrimes() {

  let queue = OperationQueue()
  queue.addOperation(operation)

}

그런 다음 해당 클래스의 인스턴스를 만든 뒤, OperationQueue의 인스턴스에addOperation으로 넘겨준다.

  func calculatePrimes() {
    let operation = CalculatePrimeOperation()
    let queue = OperationQueue()
    queue.addOperation(operation)
  }

사실 꼭 Operation을 상속하는 클래스를 만들 필요는 없고 addOperation이 클로져를 제공하기 때문에 메서드를 해당 클로져 안에 작성해주면 된다.

OperationQueue는 인스턴스를 만들 때 자동으로 남는 쓰레드를 할당해 준다. 만약 메인 쓰레드를 사용하라고 명시적으로 알리고 싶다면

let mainQueue = OpearationQueue.main

으로 쓸 수 있다.

OperationQueue말고도 더 쉽고 간편한 방법은 DispatchQueue가 있다

DispatchQueue

DispatchQueue.global(qos: .userInitiated).async {
  for number in 0...1_000_000 {
    let isPrimeNumber = number.isPrime
    print("\(number) is prime: \(isPrimeNumber)")
  }
}

쓰레드를 global로 보낼 수 있다. qos설정은 애플 문서에서 자세히 확인할 수 있다.
https://developer.apple.com/documentation/dispatch/dispatchqos/qosclass

그래서 이제 앞에서 소수를 구하느라 반응하지 않던 UI를 구조할 수 있게 되었다.

Swift Concurrency

이 작업을 Swift Concurrency를 이용하면 코드 한줄? 추가하는 것으로 가능하다.

  func calculatePrimes() {
    doneLabel = "Calculating!"
    Task {
      for number in 0...1_000_000 {
        let isPrimeNumber = number.isPrime
        print("\(number) is prime: \(isPrimeNumber)")
      }
    }
    doneLabel = "Done!"
  }

Refereces

Swift - Function Notation

Hey_Hen — Wed, 9 Feb 2022 16:39:37 +0900

Function Notation은 함수를 표시하는 법을 뜻한다.

func viewDidLoad()

뷰 컨트롤러에 viewdidLoad라는 메서드가 있다는 것은 다들 알 것이다.

이를 표기할때는 `viewDidLoad()` 로 표시하면 된다. 인자가 있는 함수의 경우는 어떨까?

다음은 SceneDelegate에 있는 메서드 중 하나이다.

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions)

이런 경우는 어떻게 써야할까? 복사 붙여넣기 해서 길에 늘여써야 할까?

아니다

swift 에서는 이를

scene(_:willConnectTo:options:)

로 표시한다. 표시할 때는 외부에 보여지는 레이블 이름을 붙이며, 없는 경우는 언더바로 처리한다.

그리고 뒤에 타입을 명시하지 않고 콜론으로 구분한다.

Swift - Any vs AnyObject

Hey_Hen — Wed, 9 Feb 2022 16:38:55 +0900

Swift쓰다보면 Any와 AnyObject 둘 다 쓰이는 걸 볼 수 있는데,

Any는 함수 타입을 포함해서 모든 타입의 인스턴스를 나타낼 수 있다.

반면 AnyObject는 모든 클래스 타입의 인스턴스를 나타낼 수 있다.

{
  "name": "henry",
  "age": 27
}

위와 같은 json 형태로 데이터가 들어올 때, Decode용 모델을 만들어서 Decodable을 해도 되지만

JSONSerialization을 이용해서 간편하게 쓸 수도 있다.

let fetchedData = try! JSONSerialization.jsonObject(with: json)

jsonObject(with:) Any를 리턴한다.

예를 어떻게 접근할 수 있을까?

let fetchedData = try! JSONSerialization.jsonObject(with: json) as! [String: Any]

[String: Any]로 타입캐스팅이 가능하고, json으로 들어오는 키 값이 name하고age 인걸 알고 있기 떄문에

fetchedData["name"] as! String // henry
fetchedData["age"] as! Int // 27

로 사용할 수 있다.

AnyClass는 모든 클래스가 암시적으로 채용하는 최상위 프로토콜로, 클래스에만 사용할 수 있다.

Any, AnyClass는 런타임에 타입이 결정된다.

전체코드