JoonSwift

[Core Data] Delete Rule을 이해하고 적절하게 사용해보자!

JoonSwift — Thu, 26 Jan 2023 02:10:13 +0900

이번 포스팅에서는 제가 Core Data를 사용하여 Relationship을 만들 때, 항상 그냥 지나쳤던 Delete Rule에 대해서 이해하고, 이를 적절히 사용하는 방법에 대해 정리하려고 합니다.

NSDeleteRule

우선 Delete Rule! 애플 공식 문서를 먼저 확인해보면 NSDeleteRule이라는 Enumeration으로 정의되어 있는 것을 확인할 수 있습니다.

enum NSDeleteRule : UInt, @unchecked Sendable

정의되어 있는 case들을 살펴보면

noActionDeleteRule
nullifyDeleteRule
cascadeDeleteRule
denyDeleteRule

모두 Core Data의 model editor에서 Relationship을 생성하고, 오른쪽의 Inspector에 Delete Rule을 눌러보면 확인할 수 있는 케이스들입니다.

하나하나 살펴보겠습니다.

Delete Rules

No Action

첫번째로 No Action 입니다. 이름처럼 아무 행동도 하지 않는 옵션입니다. 예를들어, A라는 객체와 B라는 객체 사이에 Relationship을 생성했다고 생각해보겠습니다.

No Action으로 설정한 상태에서 여기서 A 라는 객체가 삭제된다면

이런식으로 B는 존재하지 않는 A 객체를 가리키고 있을 것입니다. 그래서 애플 공식 문서에도, 만약 No Action인 Relationship에서 객체를 삭제한다면, 이를 참조하는 객체들을 꼭 삭제 해주거나, 반대 Relationship 객체들을 모두 Nullify로 설정하라고 적혀있습니다!

Nullify

다음은 Nullify 입니다. Nullify가 default 이고, 제가 Delete rule을 모를 때 기본으로 놓고 사용했었던 옵션입니다.

아까의 이 Relationship에서 A라는 객체가 삭제되면, A라는 객체를 참조하고 있던 객체들은 이제 모두 참조하고 있던 A가 사라지게 되는것입니다.

그림으로 나타낸다면.. A는 사라지고 B만 덩그러니 남은 그림이 될 수 있을 것 같습니다.

Cascade

다음은 Cascade입니다. 이 옵션은 Relationship의 타겟이 To One 일 때 정말 유용하게 사용될 수 있습니다. 예를들어, one-to-many Relationship이 있다고 가정해보겠습니다.

원래 one-to-many의 그림은 위와 같지 않겠지만, 이해하기 쉽게 이렇게 그려보았습니다. 만약 여기서 one에 해당하는 A객체를 삭제하면, Delete rule이 Cascade일 때,

이렇게 A 객체를 참조하고 있던 B 객체들을 모두 제거할 수 있습니다. 만약 Nullify 옵션을 사용했다면, A가 제거되었을 때, 제거 된 A를 가리키고 있는 B가 남아있게 됩니다. 그러므로 이렇게 one-to-many와 같은 Relationship에서 유용하게 사용할 수 있는 옵션입니다!

Deny

마지막으로 Deny 입니다. Deny는 실수를 방지하기 위한 Rule입니다. 만약에 지우려고 하는 Relationship의 객체를 다른 객체가 Relationship으로 참조하고 있다면, 이를 지울 수 없게 하는 Rule입니다.

만약 A와 B라는 객체의 Relationship, B와 C의 Relationship이 있다면, A와 B에서 B를 삭제하려고 하면, B와 C사이의 Relationship에서 C라는 객체가 아직 B를 참조하고 있기 때문에, 지우는것이 불가능해져, 실수로 삭제하는 것을 방지해줍니다.

정리

이번 포스팅을 통해서 Delete rule 4가지에 대해서 살펴보았습니다. 디폴트인 Nullify가 어떤 의미인지도 살펴보았고, Cascade와 같이 유용한 Delete rule에 대해서도 이해하고, 다음부터 사용하면서, Core Data 숙련도를 조금 높이는 계기가 되는 포스팅이었습니다. ㅎㅎ

[AutoLayout] LayoutGuide 활용하기

JoonSwift — Thu, 29 Dec 2022 14:58:47 +0900

@MainActor class UILayoutGuide : NSObject

공식문서에 따르면 LayoutGuide는 AutoLayout과 상호 작용할 수 있는 직사각형 영역입니다. 이전에 'dummy view', 'placeholder view'와 같이 원하는 Layout을 위해 만들었던 View들 대신, 더 안전하고, 효율적인 직사각형 영역을 만들어주는 방식입니다.

주로 사용해본 UIKit의 Layout Guide 들은 간단하게 살펴보고, 직접 UILayoutGuide를 만드는 것을 중점적으로 글을 작성하겠습니다.

제공해주는 Layout Guides

Safe Area layout guide

첫 번째로 가장 많이 사용하고 있는 Safe Area layout guide입니다. navigation bar, tab bar, tool bar를 덮지 않는 영역이고, notch 또한 덮지 않는 영역을 제공해 주며, 아주 유용하게 사용되고 있습니다.

Layout Margin guide

이름에서 알 수 있듯 약간의 margin이 들어간 View를 배치할 수 있게 도와주는 Layout Guide입니다.

Readable Content guide

이 Layout Guide는 글이 많은 앱에서 아주 유용하게 사용됩니다. 사람이 머리를 돌리지 않고 읽을 수 있는 글의 길이 까지만 보여줄 수 있게 View를 배치할 수 있게 도와주는 Layout Guide입니다.

직접 Layout Guide를 만들어보자

두 View 사이에 공간을 주는 Layout Guide를 직접 만들어 보겠습니다.

우선 UILayoutGuide를 선언하고, 해당 Layout Guide에 가운데 공간을 줄 수 있게 constraint를 만들어줍니다.

let space = UILayoutGuide()
view.addLayoutGuide(space)

space.widthAnchor.constraint(equalToConstant: 16).isActive = true
space.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = true

그리고 좌, 우에 있을 View를 만들어 constraint를 만들어 줍니다.

leftView.translatesAutoresizingMaskIntoConstraints = false
leftView.backgroundColor = .systemRed

rightView.translatesAutoresizingMaskIntoConstraints = false
rightView.backgroundColor = .systemBlue

view.addSubview(leftView)
view.addSubview(rightView)

NSLayoutConstraint.activate([
  leftView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
  leftView.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor),
  leftView.trailingAnchor.constraint(equalTo: space.leadingAnchor),
  leftView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor),
  
  rightView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
  rightView.leadingAnchor.constraint(equalTo: space.trailingAnchor),
  rightView.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor),
  rightView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor),
])

여기서 중요한 부분은

`leftView.trailingAnchor.constraint(equalTo: space.leadingAnchor)`

`rightView.leadingAnchor.constraint(equalTo: space.trailingAnchor)`

이 두 부분입니다. leftView의 trailing은 space의 leading, rightView의 leading은 space의 trailing에 걸어준 것을 확인할 수 있습니다. 실행하면

이런 화면을 볼 수 있습니다!

dummy view, placeholder view 대신에 UILayoutGuide를 사용해야하는 제일 큰 이유는 UILayoutGuide를 사용하면 View를 view hierarchy에 추가하지 않고도, 그 역할을 수행할 수 있기 때문인 것 같습니다. 이로 인해 dummy view를 그리는 비용도 감소하고, 실수도 줄일 수 있을 것 같습니다.

Design Pattern, RxSwift ) RxFlow 맛보기 - 1

JoonSwift — Tue, 19 Jul 2022 15:37:13 +0900

RxFlow?

RxFlow는 Reactive Flow Coordinator pattern을 기반으로 한 iOS 앱의 navigation framework입니다.

Why use RxFlow?

Storyboard를 더 작은 단위로 잘라내어 UIViewController들의 reusability와 collaboration이 가능하도록 해줍니다.
navigation context에 따라 UIViewController가 나타나는 방식을 다양하게 가져갈 수 있습니다.
의존성 주입(Dependency Injection)을 편리하게 구현할 수 있습니다.
UIViewController에서 모든 navigation과 관련된 코드를 없앨 수 있습니다.
navigation 코드도 Reactive Programming이 가능하게 도와줍니다.
주된 navigation case들을 addressing하면서 선언형 방식으로 navigation을 표현할 수 있습니다.
앱을 논리적인 navigation 블록들로 쉽게 잘라낼 수 있습니다.

Key concept

Flow : 각 Flow는 navigation action을 정의하는 부분입니다. ex ) UIViewController를 push 하거나 present하는 코드.
Step : Step은 navigation의 상태를 정의하는 곳입니다. Flow와 Step을 조합해서 모든 navigation action을 표현할 수 있습니다.
Stepper : Flow 내에 있는 Step을 생성(emit)할 수 있는 모든것입니다. (ViewModel이나 UIViewController)
Presentable : presented될 수 있는 것을 추상화한 것입니다. (기본적으로 UIViewController와 Flow가 Presentable입니다.)
FlowContributor : FlowCoordinator에게 Flow 내의 Step을 생성(emit)할 다음것이 무엇인지 알려줍니다.
FlowCoordinator : 개발자가 Flow와 Step을 잘 조합해서 가능한 모든 navigation 경우의 수를 나타내었다면, FlowCoordinator은 이것들을 잘 종합하여 앱의 navigation을 핸들링 해줍니다.

Project

직접 만들어보면서 감을 잡아보도록 하겠습니다ㅎㅎ

이런 구조를 가진 앱을 만들어보도록 하겠습니다.

Step 구현하기

우선 현재 구현할 앱에서 가능한 navigation 상태들을 담아둘 Step을 만들어보겠습니다.

enum ExampleStep: Step {
  case launchIsRequired
  
  case mainIsRequired
  
  case homeIsRequired
  case mypageIsRequired
  
  case homeNext
  case mypageNext
}

각각의 상태를 나타내보았습니다. 위에 그림에서도 보이듯, 6개의 화면을 6개의 case들로 나타내었습니다.

Flow들 구현하기

제일 처음 앱이 실행되면, Launch Screen을 보여줄지, Main Screen을 그대로 보여줄지 결정하는 Flow를 하나 생성합니다. 이름은 AppFlow라고 하겠습니다.

final class AppFlow: Flow {
  private let window: UIWindow
  
  var root: Presentable {
    return self.window
  }
  
  init(window: UIWindow) {
    self.window = window
  }
  
  func navigate(to step: Step) -> FlowContributors {
    guard let step = step as? ExampleStep else { return .none }
    switch step {
    case .launchIsRequired:
      return navigateToLaunchScreen()
    case .mainIsRequired:
      return navigateToMainTabBar()
    default:
      return .none
    }
  }
  
  private func navigateToLaunchScreen() -> FlowContributors {
    let viewController = LaunchViewController()
    window.rootViewController = viewController
    return .one(flowContributor: .contribute(withNext: viewController))
  }
  
  private func navigateToMainTabBar() -> FlowContributors {
    // ...
  }
}

AppFlow의 root는 UIWindow입니다. 앱이 실행되고, window의 rootViewController를 바꿔주며 보여줄것이기 때문에 root를 UIWindow로 정했습니다.

또한 AppFlow에서는 2가지의 Step에 따라 화면 전환이 일어납니다. launchIsRequired, mainIsRequired.

Launch Screen은 다른 Flow가 필요없이 LaunchViewController만 보여주고 끝날것이라. navigateToLaunchScreen 메서드를 위와같이 구현합니다.

LaunchViewController

final class LaunchViewController: UIViewController, Stepper {
  var steps = PublishRelay<Step>()
  
  //viewDidLoad ... 

  override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    DispatchQueue.main.asyncAfter(deadline: .now() + 3, execute: { [unowned self] in
      self.steps.accept(ExampleStep.mainIsRequired)
    })
  }
}

LaunchViewController는 Stepper입니다. 왜냐하면 아래의 viewDidAppear 메서드에서 특정 시간이 지난 후에, mainIsRequired 라는 Step을 emit할 것이기 때문에 Stepper입니다.

저 코드가 실행되고 나면 다시 AppFlow의 navigate(to : ) 메서드에서 받아온 Step을 확인한 후 mainIsRequired라는 상태에 따라 코드를 실행하게 됩니다.

AppFlow - navigateToMainTabBar()

private func navigateToMainTabBar() -> FlowContributors {
    let flow = MainFlow()
    let stepper = MainStepper()
    
    Flows.use(flow, when: .created, block: { [unowned self] root in
      self.window.rootViewController = root
    })
    
    return .one(flowContributor: .contribute(
      withNextPresentable: flow,
      withNextStepper: stepper
    ))
  }

MainFlow의 경우에는 이후에 또 다른 Navagation 로직이 존재하기때문에 MainFlow를 구현하고, MainStepper 또한 구현해놓은 모습입니다.

Flows.use 메서드를 통해 넘겨준 flow(MainFlow)가 created되는 시점에 실행될 block (여기서는 window의 rootViewController를 해당 flow(MainFlow)의 root로 바꿔주는 코드를 작성해주었습니다.

마지막으로 FlowContributor를 반환해주면서, 다음에 시작될 Flow와 그와 관련된 Stepper를 넘겨주는 코드를 확인할 수 있습니다.

MainFlow

MainFlow에서는 주로 UITabBarController의 navigation 코드를 다룹니다.

final class MainFlow: Flow {
  var root: Presentable {
    return self.tabBarController
  }
  
  private let tabBarController = UITabBarController()
  
  func navigate(to step: Step) -> FlowContributors {
    guard let step = step as? ExampleStep else { return .none }
    switch step {
    case .homeIsRequired:
      return navigateToHome()
    default:
      return .none
    }
  }
  
  private func navigateToHome() -> FlowContributors {
    let homeFlow = HomeFlow()
    let mypageFlow = MyPageFlow()
    
    let homeStepper = HomeStepper()
    let mypageStepper = MyPageStepper()
    
    Flows.use(
      homeFlow, mypageFlow,
      when: .created,
      block: { [unowned self] (root1: UINavigationController, root2: UINavigationController) in

        //Setup TabBar item and title...

        self.tabBarController.setViewControllers([root1, root2], animated: false)
      })
    return .multiple(flowContributors: [
      .contribute(
        withNextPresentable: homeFlow,
        withNextStepper: homeStepper
      ),
      .contribute(
        withNextPresentable: mypageFlow,
        withNextStepper: mypageStepper
      )
    ])
  }
}

class MainStepper: Stepper {
  var steps = PublishRelay<Step>()
  
  var initialStep: Step {
    return ExampleStep.homeIsRequired
  }
}

여기서 제가 생각하는 중요한 부분은 MainStepper의 initialStep을 homeIsRequired로 준 점과, HomeFlow, HomeStepper, MyPageFlow, MyPageStepper를 생성하여 FlowContributor를 multimple로 넘겨준 부분이 중요하게 봐야 할 부분이라고 생각합니다.

HomeFlow, MyPageFlow

final class HomeFlow: Flow {
  var root: Presentable {
    return self.navigationController
  }
  
  private let navigationController = UINavigationController()
  
  func navigate(to step: Step) -> FlowContributors {
    guard let step = step as? ExampleStep else { return .none }
    
    switch step {
    case .homeIsRequired:
      return navigateToHome()
    case .homeNext:
      return navigateToNext()
    default:
      return .none
    }
  }
  
  private func navigateToHome() -> FlowContributors {
    let viewController = HomeViewController()
    viewController.title = "Home"
    navigationController.pushViewController(
      viewController, animated: false
    )
    return .one(flowContributor: .contribute(withNext: viewController))
  }
  
  private func navigateToNext() -> FlowContributors {
    // ...
  }
}

final class MyPageFlow: Flow {
  var root: Presentable {
    return self.navigationController
  }
  
  private let navigationController = UINavigationController()
  
  func navigate(to step: Step) -> FlowContributors {
    guard let step = step as? ExampleStep else { return .none }
    switch step {
    case .mypageIsRequired:
      return navigateToMyPage()
    case .mypageNext:
      return navigateToNext()
    default:
      return .none
    }
  }
  
  private func navigateToMyPage() -> FlowContributors {
    let viewController = MyPageViewController()
    viewController.title = "My Page"
    navigationController.pushViewController(
      viewController, animated: false
    )
    return .one(flowContributor: .contribute(withNext: viewController))
  }
  
  private func navigateToNext() -> FlowContributors {
    // ...
  }
}

HomeFlow, MyPageFlow 둘 다 root를 UINavigationController로 사용하고 있습니다.

또한 HomeStepper, MyPageStepper 에서

class HomeStepper: Stepper {
  var steps = PublishRelay<Step>()
  
  var initialStep: Step {
    return ExampleStep.homeIsRequired
  }
}

class MyPageStepper: Stepper {
  var steps = PublishRelay<Step>()
  
  var initialStep: Step {
    return ExampleStep.mypageIsRequired
  }
}

이렇게 initialStep을 통해 각각의 navigate(to:) 메서드에 있는 알맞는 Step에 대한 메서드를 호출하게 구현했습니다.

NextViewController

Home과 MyPage에서 버튼을 누르면 각각 HomeNextViewController, MyPageNextViewController로 이동할 수 있도록 설계했습니다.

이 과정에서 중요하게 봐야할 점은, HomeViewController, MyPageViewController에 있는 UIButton이 바로 Next로 navigate하는 Step을 제공한다는 것입니다. 즉, Step을 emit하는 HomeViewController, MyPageViewController 둘 다 Stepper가 되어야합니다.

final class HomeViewController: UIViewController, Stepper {
  var steps = PublishRelay<Step>()
	// ...
	@objc func didTappedButton() {
	  self.steps.accept(ExampleStep.homeNext)
	}
}
final class MyPageViewController: UIViewController, Stepper {
  var steps = PublishRelay<Step>()
	// ... 
	@objc func didTappedButton() {
    self.steps.accept(ExampleStep.mypageNext)
  }
}

그러면 HomeFlow와 MyPageFlow의 navigateToNext() 메서드에는 각각

private func navigateToNext() -> FlowContributors {
  let viewController = HomeNextViewController()
  viewController.title = "Home_Next"
  navigationController.pushViewController(
    viewController, animated: true
  )
  return .none
}

private func navigateToNext() -> FlowContributors {
  let viewController = MyPageNextViewController()
  navigationController.present(
    viewController, animated: true
  )
  return .none
}

ViewController를 생성하여 navigation action을 작성해주면 됩니다.

구조를 그림으로 그려보았습니다 ㅎㅎ

정리

ViewController에 어떤 navigation action이 발생할 때, 거기서 ViewController를 생성하고, 어떻게 보여줄지 결정하는 로직을 작성했었는데, RxFlow, Coordinator pattern을 사용하니 ViewController에서 그러한 로직들을 분리할 수 있어서 보기 좋았던것 같습니다. ㅎㅎ

하지만 아직 RxFlow를 사용은 해봤는데 정확하게 내부에서 어떻게 동작하는지, 그리고 RxSwift에 대한 이해가 아직 부족해서 사용법을 알아내는데 오래 걸렸었습니다.

Setup Vulkan on VSCode and macOS

JoonSwift — Mon, 27 Jun 2022 15:27:24 +0900

Vulkan을 mac에서 사용해보고 싶어서 그리고 Xcode가 아닌 VSCode에서 사용하는 법을 포스팅해보려고 합니다. Vulkan tutorial에는 Xcode밖에 안나와서... 저는 VSCode로 하고싶어서 한번 시도해봤습니다 ㅎㅎㅎ

우선 GLFW, GLM 그리고 VulkanSDK를 다운 받은 상태라고 생각하여 진행하겠습니다.

GLFW, GLM 설치법 (https://vulkan-tutorial.com/Development_environment)

VulkanSDK 설치 (https://vulkan.lunarg.com/)

Create workspace

우선 저는 VSCode에서 Vulkan_Blog라는 폴더를 생성했습니다. 그리고 main.cpp 파일도 하나 만들어주겠습니다.

Set tasks.json args

VSCode의 Terminal 메뉴에서 'Configure Default Build Task...' 를 선택해주면

이렇게 컴파일러들이 나오는데 저는 C/C++: clang++ 활성 파일 빌드를 선택해주겠습니다. 그럼 workspace 폴더의 .vscode가 생기고, tasks.json 파일이 들어있는것을 확인할 수 있습니다.

이 tasks.json 파일의 tasks 의 args에 다음을 추가해줍니다. 제일 처음은 c++17을 사용할 수 있게 설정합니다.

{
	"version": ...
    "tasks": [
    	{
        	"type": ...
            //...
            "args": [
            	// ... 
                "-std=c++17", // add!
                // ...

다음은 homebrew로 다운받았던 GLFW, GLM의 경로를 설정해줍니다. 각각 include 와 lib 폴더의 경로를 args에 추가해주겠습니다.

homebrew에서 다운받은 것들의 경로는 arm64 구조에서 받았다면 /opt/homebrew에 아니라면 /usr/local에 있습니다!

"-I/opt/homebrew/include",
"-L/opt/homebrew/lib",

여기서 다시 강조하지만 위의 경로는 GLFW, GLM을 설치한 경로를 써주어야합니다!

다음은 VulkanSDK의 경로를 설정해줍니다. VulkanSDK역시 include, lib의 경로를 args에 추가합니다.

"-I/Users/kimhojoon/VulkanSDK/1.3.216.0/macOS/include",
"-L/Users/kimhojoon/VulkanSDK/1.3.216.0/macOS/lib",

다음은 라이브러리들을 링크해주는 작업이 필요합니다.

.dylib파일을 링크해줄 것인데, 이는 위의 GLFW, GLM을 다운받는 방법을 설명하는 웹사이트에서 Xcode설정을 할 때 하는

이 부분과 유사합니다. 방법은 간단합니다. 저 libglfw.3.x.dylib 파일, libvulkan.1.dylib, libvulkan.1.x.dylib 을 가져와주면 됩니다.

역시 args에 추가해줍니다.

"/opt/homebrew/lib/libglfw.3.3.dylib",
"/Users/kimhojoon/VulkanSDK/1.3.216.0/macOS/lib/libvulkan.1.dylib",
"/Users/kimhojoon/VulkanSDK/1.3.216.0/macOS/lib/libvulkan.1.3.216.dylib",

자! 이제 main.cpp에 (https://vulkan-tutorial.com/Development_environment) 여기 사이트에 나와있는 예제 코드를 복사 붙여넣기 한다음에 build and run을 하면!

Vulkan window 라는 창이 뜨게됩니다!

tasks.json 파일

{
	"version": "2.0.0",
	"tasks": [
		{
			"type": "cppbuild",
			"label": "C/C++: clang++ 활성 파일 빌드",
			"command": "/usr/bin/clang++",
			"args": [
				"-std=c++17",
				"-fdiagnostics-color=always",
				"-g",
				"${file}",
				"-I/opt/homebrew/include",
				"-L/opt/homebrew/lib",
				"-I/Users/kimhojoon/VulkanSDK/1.3.216.0/macOS/include",
				"-L/Users/kimhojoon/VulkanSDK/1.3.216.0/macOS/lib",
				"/opt/homebrew/lib/libglfw.3.3.dylib",
				"/Users/kimhojoon/VulkanSDK/1.3.216.0/macOS/lib/libvulkan.1.dylib",
				"/Users/kimhojoon/VulkanSDK/1.3.216.0/macOS/lib/libvulkan.1.3.216.dylib",
				"-o",
				"${fileDirname}/${fileBasenameNoExtension}"
			],
			"options": {
				"cwd": "${fileDirname}"
			},
			"problemMatcher": [
				"$gcc"
			],
			"group": {
				"kind": "build",
				"isDefault": true
			},
			"detail": "컴파일러: /usr/bin/clang++"
		}
	]
}

Swift ) Two-Phase Initialization?

JoonSwift — Fri, 27 May 2022 15:05:26 +0900

이번 포스팅에서는 Swift의 Two-Phase Initialization에 대해서 알아보겠습니다.

class SomeSubClass: SomeSuperClass {
  let someProperty: String
  
  init(someProperty: String) {
    super.init()
  }
}

제가 Two-Phase Initialization을 가장 많이 접할 수 있는 코드는 바로 위와 같이 코드를 작성할 때였습니다. 위의 코드를 작성하면 바로 문구가 하나 뜨는데 Property 'self.someProperty' not initialized at super.init call 이런 문구입니다.

과연 왜 self.someProperty가 super.init 호출 시점에 초기화되어있지 않다고 코드를 빌드조차 못하게 하는것일까?! 한번 알아보겠습니다.

Two-Phase Initialization

Swift의 Class initialization에는 two-phase 과정이 있습니다.

Phase 1 : 어떤 class hierarchy의 아래에서 위까지 모든 저장 프로퍼티들을 초기화 하는 과정이 바로 Phase one입니다.
Phase 2 : 이제 각 클래스는 저장 프로퍼티들을 수정할 수 있는 상태가 되고, 메서드 호출 등 self를 통해 접근하는 프로퍼티, 메서드들을 사용할 수 있게 됩니다.

이런 Two-Phase initialization 과정은 초기화되지 않은 프로퍼티들에 대한 접근을 막고, 다른 initializer로 부터 예상치 못하게 값이 변경되는 것을 방지하는 안전장치라고 할 수 있습니다.

또한 Class hierarchy에서 각각의 클래스를 유연하게 유지하면서, initialization 과정을 안전하게 만들어주기도 합니다.

그래서 Swift 컴파일러는 Two-Phase Initialization을 위해 4개의 Safety check를 사용하고 있습니다.

Safety check 1

지정된 이니셜라이저는 해당 클래스에 존재하는 모든 프로퍼티들이 superclass의 이니셜라이저를 위임하기 전에 모두 초기화 해줘야 합니다. 이것이 바로 제일 처음에 보았던 오류입니다.

super.init을 호출하기 전에 현재 클래스에 존재하는 language, device에 대한 초기화를 먼저 진행해주어야 합니다.

init(name: String, age: Int, language: String, device: String){
  self.language = language
  self.device = device
  super.init(name: name, age: age)
}

Safety check 2

상속받은 프로퍼티에 대한 접근을 하기 이전에 superclass의 이니셜라이저를 delegate up! 해야합니다.

class Person {
  let name: String
  let age: Int
  
  init(name: String, age: Int) {
    self.name = name
    self.age = age
  }
}

class Developer: Person {
  let language: String
  let device: String
  
  init(name: String, age: Int, language: String, device: String){
    self.language = language
    self.device = device
    self.name // Error! 'self' used in property access 'name' before 'super.init' call
    super.init(name: name, age: age)
  }

위에서 self.name 즉, 상속받은 Person 클래스의 프로퍼티인 name에 superclass의 초기화 이전에 접근하게 된다면, 컴파일러가 이를 발견하고 에러를 보여주게 됩니다.

Safety check 3

Convenience initializer은 반드시 다른 이니셜라이저에게 delegate한 이후에! 프로퍼티에 접근해야 합니다. 즉,

  convenience init() {
    self.language // Error! 'self' used before 'self.init' call or assignment to 'self'
    self.init(name: "Joonswift", age: 27, language: "Swift", device: "MacBook Pro 13 M1")
  }

이렇게 self.init 즉, 다른 이니셜라이저에게 delegate 하기 전에 language 프로퍼티에 대한 접근을 시도할 시 Swift는 그럴수 없다고 말해줍니다.

Safety check 4

First phase 즉 Phase one이 끝나기 전 까지는 어떤 메서드를 호출하지도, 인스턴스 프로퍼티들에 대한 값을 읽어오지도 못합니다.

init(name: String, age: Int, language: String, device: String){
    self.language = language
    self.device = device
    someMethod() // Error! 'self' used in method call 'someMethod' before 'super.init' call
    super.init(name: name, age: age)
    //Phase one end
    
    //Phase two start
    print(self.language)
    someMethod() // No error!
  }

위에서 Phase One에 someMethod()를 호출하면 에러가 납니다. 반면에 Phase two에서 someMethod()를 호출하거나 language프로퍼티의 값에 접근하면 정상적으로 실행되는 것을 확인할 수 있습니다.

위의 4가지 Safety check을 바탕으로 한 Two-Phase Initialization의 실행 과정을 보겠습니다.

Phase 1

클래스의 designated or convenience 이니셜라이저를 호출합니다.
해당 클래스에 대한 새로운 인스턴스가 생성되면서, 메모리에 할당하는데, 이 메모리는 초기화되지 않은 상태입니다.
designated 이니셜라이저가 해당 클래스에 존재하는 모든 저장 프로퍼티가 초기화 되었고, 값이 있다는 것을 확인한 이후에 이 저장 프로퍼티들을 위한 메모리가 초기화됩니다.
이 designated 이니셜라이저는 superclass에게 똑같은 작업을 하도록 넘겨주고 superclass 역시 똑같은 과정을 통해서 저장 프로퍼티들을 초기화 하여 메모리에 초기화 시킵니다.
이것을 계속 반복해서 결국 class hierarchy의 상속 chain의 제일 최상위 class까지 도달하면 마지막 클래스가 모든 저장 프로퍼티들이 값이 있는지, 인스턴스의 메모리가 모두 초기화 되었는지를 확인하고 Phase 1을 끝냅니다.

Phase 2

이제 다시 위에서 아래로 내려가면서 각각의 designated 이니셜라이저는 인스턴스를 수정할 수 있는 옵션이 생깁니다. 이제 self에 접근하여 프로퍼티를 수정하고, 메서드를 호출하는 등의 권한을 얻게됩니다.
마지막으로 Convenience 이니셜라이저 역시 인스턴스를 수정할 수 있고, self에 대한 접근이 가능하게 됩니다.

정리

swift.org에 정말 그림이랑 잘 그려서 설명을 해 둔 부분인데, 미루고 미루다가 계속 코드를 작성하며 super.init 전에 프로퍼티들을 초기화 하지 않아 생기는 에러들을 그저 아무생각없이 초기화 시켜주고 이것이 Two-Phase initialization이라는 개념 때문에 그런지도 모르고 넘어왔었습니다.

하지만 이번 기회에 " 아 이게 Two-Phase Initialization 때문에 나오는 에러였구나~" 라는 사실을 알고 속이 뻥 뚫리는 느낌입니다.

결론 : 기초를 튼튼하게 다지자....

참고

https://docs.swift.org/swift-book/LanguageGuide/Initialization.html#:~:text=Two%2Dphase%20initialization%20prevents%20property,value%20by%20another%20initializer%20unexpectedly.&text=Swift's%20two%2Dphase%20initialization%20process,to%20initialization%20in%20Objective%2DC.

Initialization — The Swift Programming Language (Swift 5.6)

Initialization Initialization is the process of preparing an instance of a class, structure, or enumeration for use. This process involves setting an initial value for each stored property on that instance and performing any other setup or initialization t

docs.swift.org

CoreData ) Core Data stack에 대해서

JoonSwift — Fri, 6 May 2022 16:08:17 +0900

Core Data stack은 Core Data의 이점을 모두 가져가며 Core Data를 사용하기 위해 필수적으로 알아야 할 부분이라고 생각됩니다. 이번 포스팅에서는 Core Data stack을 이루고 있는 클래스들을 공식문서를 바탕으로 정리해보도록 하겠습니다!

우선 Core Data stack의 이해를 위해 정리해볼 클래스들을 나열해보자면,

NSManagedObjectModel
NSPersistentStoreCoordinator
- NSPersistentStore
NSManagedObjectContext
NSPersistentContainer

이정도가 있겠습니다. 하나하나 알아보도록 하겠습니다.

NSManagedObjectModel

NSManagedObjectModel, Core Data 앱 개발을 시작할 때, 보통 Data model 파일을 생성하면 .xcdatamodeld 파일을 생성하게 됩니다. 여기에 Entity들을 생성하고, attribute, relationship 등 여러 설정을 별도의 코드 작성 없이 할 수 있는데, 이 .xcdatamodeld 파일을 programmatic하게 표현한 것이 바로 NSManagedObjectModel 클래스 입니다.

하나 혹은 여러개의 Entity를 가질 수 있고, Entity에는 프로퍼티들이 존재합니다. 이 프로퍼티들이 attributes, relationships 등을 나타내는 클래스들을 가지고 있습니다.

NSManagedObjectModel을 데이터베이스의 Schema라고 생각하면 편합니다. 물론 Schema보다는 더 넓은 개념이라고 할 수 있습니다.

Core Data stack의 나머지 부분들은 바로 이 Model을 가지고 Object들을 생성하거나, Property를 저장하고, 데이터를 저장소에 저장하는 과정을 거칩니다.

NSPersistentCoordinator

NSPersistent Coordinator를 알아보기 이전에, NSPersistentStore 클래스를 먼저 알아보도록 하겠습니다.

NSPersistentStore

NSPersistentStore 클래스는 Core Data의 persistent store들을 모두 추상화해둔 클래스입니다. Core Data는 4개의 저장소를 제공하고 있는데, SQLite, Binary, XML(iOS에서는 사용 불가능), In-memory 이렇게 4가지를 가지고 있고, 이들은 각각 다음과 같은 상수로 제공됩니다.

NSSQLiteStoreType : non-atomic store type으로, SQLiteDB를 사용하며, Xcode Core Data 템플릿에서 default로 사용되고 있는 방식입니다.
NSXMLStoreType : atomic store type으로, XML 파일을 사용하는 타입입니다. iOS에서는 사용이 불가능하고, memory footprint가 어마어마합니다.
NSBinaryStoreType : atomic store type으로, Binary Data file을 사용합니다.
NSInMemoryStoreType : atomic store type으로, 메모리를 사용하는 타입입니다. persistent라는 이름이 잘 어울리지 않게, 앱이 종료되거나, 기기를 꺼버리면 사라지는 형태이지만, 유닛 테스트, 캐싱에 유용하게 사용될 수 있는 타입입니다.

이제 다시 NSPersistentStoreCoordinator로 돌아오겠습니다. NSPersistentCoordinator의 역할은 Managed Object Model과 Persistent Store을 연결해주는 Bridge 역할을 하는 녀석입니다. 즉, 이 둘을 이어주어 뒤에 나올 NSManagedObjectContext를 도와주는 역할을 합니다.

NSManagedObjectContext는 NSPersistentStoreCoordinator를 통해 Object graph를 persistent store에 저장할 수 있습니다. 쉽게 말해 NSPersistentStoreCoordinator는 Context와 Model, Persistent Store 사이에서 인터페이스 역할을 해주는 클래스입니다. 그렇기에 Coordinator는 Model을 이해하고, 어떻게 정보를 Persistent Store에게 보낼지, 어떤 Persistent Store에서 fetch해올지에 대해 알고있어야 합니다. 또한, 여러개의 Thread에서 Coordinator를 사용할 수는 없습니다. Coordinator는 operator들을 Serializatize하기 때문입니다.

NSManagedObjectContext

NSManagedObjectContext는 Managed object들의 변화를 추적하고, 다루기 위한 object 공간입니다. Core Data를 다룰 때, 가장 많이 사용되는 클래스이기도 합니다.

NSManagedObjectContext는 메모리에서 Object의 변화를 관찰하고, 다양한 처리를 하는 기능을 담당하고 있습니다. 그렇기 때문에 우리가 Managed object에 어떤 변화를 주어도 context를 통해 save() 메서드를 호출하지 않으면, persistent store에는 아무련 영향을 주지 않는것입니다.

또한 Context는 Object들의 Lifecycle을 관리합니다. 이 관리를 통해 Validation, inverse relationship handling과 같은 다양한 좋은 기능들을 할 수 있는 권한이 주어집니다.

그리고 Context는 Thread-safe하지 않습니다.

NSPersistentContainer

NSPersistentConatiner는 Core Data stack을 캡슐화한 Container입니다. Core Data stack의 모든 요소들의 코드를 작성하는데에 들어가는 시간을 줄여주고, NSPersistentContainer를 선언하여, persistent store들을 load 해주면 끝나는 아주 편리한 클래스 입니다.

private lazy var storeContainer: NSPersistentContainer = {
  let container = NSPersistentContainer(name: self.modelName)
  container.loadPersistentStores { _, error in
    if let error = error as NSError? {
    	//some error message!
    }
  }
  return container
}()

이런식으로 사용될 수 있습니다.

그렇게 제가 이해한바로 Core Data stack을 그림으로 나타내보면...

이런식으로 구성되어 동작하는 것으로 이해했습니다.

정리

각각의 클래스에 대한 명확한 이해나 어떤 기능이 있는지에 대해 100% 이해하지는 못했지만, Core Data stack의 구성 클래스, 그들의 대략적인 역할, 흐름 등에 대해서 알아보는 포스팅을 작성하였습니다.

직접 만들어보며 정리하는 시간을 가져야겠습니다. ㅎㅎㅎ

참고 문서

https://developer.apple.com/documentation/coredata/core_data_stack

Apple Developer Documentation

developer.apple.com

제가 잘못이해하고있는 부분이나 틀린 부분이 있다면 댓글에 남겨주시면 정말 감사하겠습니다!

CoreData ) NSSecureCoding (정말정말정말 간단하게 알아봄)

JoonSwift — Wed, 4 May 2022 14:36:51 +0900

CoreData의 Transformable 타입을 알아보다가 NSSecureCoding이라는 녀석을 만나고 한번 살펴보다가 엄청난 Objective-C 개념들을 만나고 우선은 공식문서의 내용에 대해서만 정리하도록 마음먹었습니다.

NSSecureCoding?

A protocol that enables encoding and decoding in a manner that is robust against object substitution attacks.
- Apple Developer Document -

Object Substitution 공격에 맞서기 위한 강력한 Encoding, Decoding 방식을 가능하게하는 프로토콜입니다.

음.... 직접 코드로 작성하며 이 NSSecureCoding이라는 프로토콜을 채택해보았습니다.

class MyClass: NSSecureCoding {
  static var supportsSecureCoding: Bool
  
  var someClass: SomeClass
  
  // ... 

  func encode(with coder: NSCoder) {
  	// coder.encode(someClass, forKey: "someClass")
  }

  required init?(coder: NSCoder) {
    // Decode here...
  }
}

NSSecureCoding 프로토콜을 채택하자 supportsSecureCoding, encode(with coder: ), required init?(coder: ) 이렇게 3가지를 필수적으로 구현해야하는 것들로 주어집니다. (encode(with coder: )와 required init?(coder: )는 NSCoding의 메서드입니다.)

supportsSecureCoding : 이 static 프로퍼티는 이름에서도 알 수 있듯, 이 클래스가 SecureCoding을 지원하느냐 에 대한 Boolean 값을 나타내는 프로퍼티입니다. 공식문서의 Discussion을 보면 Seucre Coding을 지원하는 Class를 작성할 때, 이 클래스 프로퍼티의 getter 반환 값이 true임을 보장해야한다고 합니다.
encode(with coder: ) : 파라미터로 받아온 coder를 활용하여 인스턴스 변수들을 Encoding 과정을 작성해야하는 메서드입니다.
required init?(coder : ) : 인코딩한 object들(enclosed objects)을 decodeObjectOfClass: forKey: 메서드를 사용하여 반드시 디코딩 해주어야 합니다.

그래서 이 NSSecureCoding을 활용하면 아래와 같이 Object를 디코드 할 수 있습니다.

class MyClass: NSObject, NSSecureCoding { 
 // ...
}

class SomeOtherClass {
  var myClass: MyClass?
  
  init(coder: NSCoder) {
    let object = coder.decodeObject(of: MyClass.self, forKey: "myClass")
  }
}

대충 이런 형태로 구현될 수 있는듯합니다.

NSSecureCoding이 아닌 NSCoding만 활용할 경우에는

if let obj = coder.decodeObject(forKey: "myClass") as? MyClass {
      
}

이런식으로 as? MyClass를 활용하여 MyClass라는 타입을 타입캐스팅을 통해 가져옵니다. 이런 디코딩의 경우, 공식문서의 설명을 빌리자면, 클래스의 타입을 확인할 때, 이미 object가 생성된 상태이며, 만약 이것이 컬렉션 클래스의 일부라면, 잠재적으로 object graph에 삽입될 수도 있기에 안전하지 않은 방법이라고 합니다.

결국 Object가 생성되기 전에 클래스의 타입을 확정짓기 못하기 때문에 안전하지 않다는 결론으로 생각됩니다.

반면에 위의 NSSecureCoding을 채택한다면, Object가 생성되기 전에, 클래스의 타입을 확정지을 수 있기 때문에 더 안전합니다.

이상으로 NSSecureCoding의 정의가 무엇인지, 왜 안전한지, 채택하면 필수적으로 구현해주어야 하는 메서드나 프로퍼티에 대해서 아~~~주 간단하게 알아보았습니다.

정리

내용이 조금 어려운것 같아 문서를 읽는 듯이 포스팅을 한것 같습니다. CoreData를 계속 공부하면서 더 알게되는 부분, Transformable 타입을 사용하면 NSSecureCoding에 대해서 새롭게 알게되는 부분이 나온다면 다시 정리하여 포스팅을 수정하는 시간을 가져야겠습니다 ㅎㅎ

참고 자료

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

Apple Developer Documentation

developer.apple.com

아래에 Conforming Types를 보면 정말 많은 타입들이 이 프로토콜을 준수하고있다는걸 확인할 수 있습니다 ㄷ ㄷ!!

Swift ) Designated Initializer, Convenience Initializer

JoonSwift — Mon, 2 May 2022 16:37:58 +0900

Designated Initializer?

designated initializer는 클래스의 기본적인 이니셜라이저입니다. 보통 클래스에서 이니셜라이저를 생성하면 작성하게 되는

init(parameters) {
  statements
}

이런 형태를 가진 이니셜라이저를 designated initializer라고 합니다. 클래스는 상속이 가능하기에, 이 designated initializer는 정말 중요한 역할을 합니다. 바로 상위 클래스(super class)의 이니셜라이저를 delegate하는 역할을 수행할 때 사용하기 때문입니다.

class User {
  let email: String
  let name: String
  let authority: String
  
  init(email: String, name: String, authority: String) {
    self.email = email
    self.name = name
    self.authority = authority
  }
}

class SpecialUser: User {
  init(greeting: String) {
    super.init(email: "special@email.com", name: "special", authority: "user")
    print(greeting + "I'm \(name)")
  }
}

let speicalUser = SpecialUser(greeting: "Hi!") // Hi!I'm special

SpecialUser 클래스는 User클래스의 subclass입니다. 그래서 이니셜라이저 코드에 super.init( ... ) 을 추가하여 해당 클래스의 superclass 즉, User 클래스의 이니셜라이저를 호출합니다.

UIKit에서 대표적으로 정말 많이 보는 viewDidLoad(animated: )가 있습니다. 항상 viewDidLoad 메서드를 override할 때, super.viewDidLoad를 호출해왔는데, 이는 UIViewController 클래스에 선언되어있는, viewDidLoad 실행문을 실행시킨다는 의미와 같습니다.

Designated Initializer의 Initializer Delegation 형태는 위의 그림과 같습니다. 이는 Swift 공식문서의 'Initializer Delegation for Class Types' 파트에서 Initializer들 간의 관계에 대한 Rule을 정리해놓은 부분이 있는데,

Rule 1
A designated initializer must call a designated initializer from its immediate superclass.

해당 Rule에 해당하는 케이스라고 볼 수 있습니다. 어떤 클래스가 super class가 있다면, 그 super class의 designated initializer를 꼭 호출해주어야 한다는 룰입니다. (super class는 본인이 super class이므로 해당 룰에 적용되지 않습니다.)

Convenience Initializer

Convenience Initializer는 supporting initializer라고도 합니다. Convenience Initializer의 주된 역할은, 같은 클래스에 있는 Designated Initializer의 파라미터에 기본값(Default Value)를 주는 역할을 하거나 그 클래스의 인스턴스를 생성하여 특별한 용도로 사용하기도 합니다.

convenience init(parameters) {
  statement
}

init 앞에 convenience 를 붙여 사용합니다.

아까 위의 예제에서 init 아래에 convenience init을 추가해보도록 하겠습니다.

// In User class

  // init 
  
  convenience init(name: String) {
    var email: String = ""
    var authority: String = ""
    
    if name == "admin" {
      email = "admin@email.com"
      authority = "Admin"
    } else {
      fatalError("관리자가 아니면 name만으로 생성할 수 없습니다.")
    }
    
    self.init(email: email, name: name, authority: authority)
  }

활용법은 다음과 같습니다. convenience initializer 내부에는 name이 admin인지 확인하여 email 과 authority에 값을 넣어 self.init을 호출해주는 코드입니다.

let user = User(email: "user@email.com", name: "user", authority: "user")
let admin = User(name: "admin")
let notAdmin = User(name: "notadmin") // Fatal Error!

여기서 admin 과 notAdmin은 convenience initializer를 통해 생성된 인스턴스입니다. notAdmin의 경우 fatalError 코드가 호출되는데 이는 convenience initializer에서 name이 "admin"이 아니라면 fatalError 코드를 실행하게 했기 때문입니다.

print(user.email) // user@email.com
print(admin.email) // admin@email.com

Convenience Initializer는 옆으로(?) 가는 형태로 볼 수 있습니다. Swift.org에 나머지 Rule 2, 3에 대한 것도 확인해보겠습니다.

Rule 2
A convenience initializer must call another initializer from the same class.
Rule 3
A convenience initializer must ultimately call a designated initializer.

Convenience initializer는 반드시 같은 클래스에 있는 다른 initializer를 호출해야 합니다. 이 다른 initializer는 Designated Initializer가 될 수도, Convenience Initializer가 될 수도 있습니다. 하지만 중요한건 Same class!

Rule 3는 Convenience initializer는 반드시 마지막에는 Designated initializer를 호출해야 합니다. 즉, 옆으로 옆으로 Convenience initializer들을 타고 가다가도 마지막 화살표는 해당 클래스의 Designated Initializer를 향해야 한다는 의미입니다.

정리

처음에 영어로 Designated Initializer라는 표현이 처음 들어보는 표현이라 어색했었습니다. 항상 그냥 이니셜라이저라고 부르던 녀석이 Designated initializer라는 이름을 가지고 있었다니..

Convenience initializer에 대해서도 알아가는 시간을 가졌습니다. 코드를 작성하면서 한번도 써보지 않아 어떤 역할을 하는 녀석인지 몰랐지만, 이번 포스팅을 통해 알게되었습니다.

또한 Initializer Delegation이라는 표현과 Rule이 있다는 사실 또한 배워가는 좋은 포스팅이 되었습니다~

참고 문서

https://docs.swift.org/swift-book/LanguageGuide/Initialization.html

Initialization — The Swift Programming Language (Swift 5.6)

docs.swift.org

CoreData ) .xcdatamodeld?

JoonSwift — Tue, 26 Apr 2022 00:33:11 +0900

.xcdatamodeld 파일

CoreData를 활용하여 Data Model을 만들면 .xcdatamodeld 확장자를 가진 파일을 쉽게 찾아볼 수 있습니다.

이번 포스팅에서는 .xcdatamodeld 파일이 어떤 역할을 하는지에 대해 정리해보려고 합니다.

d 의 의미

.xcdatamodeld 에서 .xcdatamodel 이라면, datamodel 확장자 같은데, 뒤에 d가 하나 더 붙으면서 이 의미가 궁금해지게 만들고 있습니다. .xcdatamodeld 에서 d의 의미는 document (Document Package) 라는 의미를 가지고 있습니다.

(Document Package에 대한 설명은 아래의 참고문서에 남겨놓겠습니다.)

즉, 우리는 CoreData를 사용할 때, 이 Versioning을 지원하는 Managed Object Model을 사용하는데, 이 모델들이 파일 시스템에서 .xcdatamodeld 라는 document에 의해 보여집니다.

What's in document?

.xcdatamodeld document는 모델에 대한 version들을 그룹화 해놓은 파일 패키지 입니다. 이는 각각 .xcdatamodel 확장자를 가진 파일과, 모델에 대한 version 정보를 담은 Info.plist로 나타내어 집니다.

그래서 어떤 모델을 만들어 해당 모델에 대한 다른 version을 생성하면, 이렇게 .xcdatamodel 확장자를 가진 파일 2개가 .xcdatamodeld 패키지 안에 생성되는것을 확인할 수 있습니다.

정리

문서들을 읽으며 이해한바로는 다양한 버전을 가질 수 있는 Managed Object Model의 관리가 복잡하고 여러울 수 있기 때문에, 이를 패키지화 하여 내부적으로 유연하게 관리해주는 역할을 하는 것이 .xcdatamodeld라고 이해했습니다.

.xcdatamodeld 패키지 안에는 여러 버전의 .xcdatamodel 파일들이 존재할 수 있고, 버전에 대한 정보 또한 가지고 있습니다.

참고 문서

https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/DocumentPackages/DocumentPackages.html#//apple_ref/doc/uid/10000123i-CH106

Document Packages

Document Packages If your document file formats are getting too complex to manage because of several disparate types of data, you might consider adopting a package format for your documents. Document packages give the illusion of a single document to users

developer.apple.com

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmModelFormat.html

Model File Format and Versions

Model File Format and Versions A managed object model that supports versioning is represented in the filesystem by a .xcdatamodeld document. An .xcdatamodeld document is a file package (see Document Packages) that groups versions of the model, each represe

developer.apple.com

Swift ) Difference between components and split

JoonSwift — Tue, 19 Apr 2022 15:46:14 +0900

저는 주로 백준 온라인 저지의 알고리즘 문제를 풀 때, split 메서드를 사용하여 인풋을 공백 단위로 받아오곤 했는데, components를 사용하는 방법도 있어 아래와 같이 두 가지 코드를 번갈아가며 사용했었습니다.

let input = readLine()?.split( ... )
let input = readLine()?.components( ... )

이번 포스팅을 통해 두 메서드의 차이점을 한번 알아보도록 하겠습니다.

components return [String] split return [Substring]

가장 눈에 띄게 확인할 수 있었던 차이점은 리턴타입입니다.

func components<T>(separatedBy separator: T) -> [String] where T : StringProtocol

components는 StringProtocol 의 타입인 T를 받아 [String]을 반환합니다.

func split(
	separator: Character,
	maxSplits: Int = Int.max, 
	omittingEmptySubsequences: Bool = true) -> [Substring]

반면에 split은 [Substring]을 반환해주고 있는 모습을 확인할 수 있습니다.

String and Substring

Substring을 잘 이해하면, split을 사용할 때, components를 사용할 때의 이점을 잘 살릴 수 있겠다는 생각을 가지고 Substring에 대해서 알아보겠습니다.

Substrings in Swift have most of the same methods as strings, which means you can work with substrings the same way you work with strings.

Swift.org 의 Substrings 부분을 보면 Substring에 대한 설명이 나옵니다. Swift의 Substrings은 string과 거의 동일한 메서드를 가지고 있고, 이는 string과 똑같이 활용할 수 있다는 의미라고 합니다.

String과 동일하게 활용할 수 있는 Substring! 차이점도 아래에 나와있는 것을 확인할 수 있습니다.

The difference between strings and substrings is that, as a performance optimization, a substring can reuse part of the memory that’s used to store the original string, or part of the memory that’s used to store another substring.

여기서 제가 가장 흥미로웠던 구문은 'a substring can reuse part of the memory that's used to store the original stirng' 입니다. 원래의 string이 저장된 메모리를 재사용한다!

바로 확인해보겠습니다.

let base: String = "This is base string"

let componentString = base.components(separatedBy: " ")
let splitString = base.split(separator: " ")

base라는 String을 하나는 components로, 하나는 split으로 나누었습니다.

우선 base에 대한 정볼르 눈에 담아두겠습니다.

그 다음은 componentString으로 가보겠습니다.

components 메서드로 String을 나눈 결과는 base라는 String과 아무런 관련이 없습니다. 새로운 메모리 공간에 "This", "is", "base", "string" 각각이 할당되고, 그것들의 배열을 만들어 낸 것을 확인할 수 있습니다.

하지만 splitString! 이녀석을 한번 확인해보겠습니다.

어디서 많이 본 주소값이 있습니다. 바로 저 0x8000000100003eb0 이 주소! 아까 base의 StringObject가 담긴 주소값과 동일한 것을 확인할 수 있습니다. 이를 startIndex와 endIndex를 활용하여 Slice 즉, 잘라서 표시해주는 것을 알 수 있습니다.

이 부분에서 위에서 확인했던 Original String의 메모리 공간을 재사용 한다는것을 확인할 수 있습니다.

그림으로 확인해보면 (그림을 잘 못그려서 미리 죄송합니다. ㅎㅎ)

이런 차이점이 있습니다. 위와 같은 특징 때문에 공식 문서에서 Substring은 String과 달리 해당 String을 활용하고 있을 때만 짧은 시간 그 String을 활용하여 어떤 작업을 할 때 사용할 수 있다고 합니다.

However, unlike strings, you use substrings for only a short amount of time while performing actions on a string.

그럼 이제 componentString과 splitString을 활용하여 새로운 String을 생성하면 어떤 결과가 나오는지 한번 확인해보겠습니다.

let newString = String(splitString[0])
let componentsNewString = String(componentString[0])

newString은 splitString[0] 즉, "This" 라는 String을 새로운 String으로 가지게 됩니다.

그림으로 그려보면

newString이라는 새로운 String을 만들어 "This"를 참조하게 만드는 순간 Original String에서 벗어나 새로운 공간을 참조하게됩니다.

정리

Substring은 기존의 String의 메모리 공간을 재사용 하여 문자열을 표현한다는 사실을 알게되었습니다.

하지만 실제 백준에서 사용하는 방법인 아래의 코드들

let componentInput = base.components(separatedBy: " ")
let splitInput = base.split(separator: " ").map({ String($0) })

이 둘 중 어떤 것이 더 성능에 좋은지? 에 대한 정답은 없는것 같다는 것이 저의 생각입니다. 결국 split도 Substring을 그대로 사용하지 않고 다시 map을 통해 String으로 변환하는 작업이 들어가므로 결국 똑같지 않을까? 라는 것이 저의 생각입니다. ㅎㅎㅎ

참고

https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html

Strings and Characters — The Swift Programming Language (Swift 5.6)

Strings and Characters A string is a series of characters, such as "hello, world" or "albatross". Swift strings are represented by the String type. The contents of a String can be accessed in various ways, including as a collection of Character values. Swi

docs.swift.org

(Substrings 파트)

* 혼자 공부하면서 이해한 부분이니 혹시나 틀리거나 잘못 이해하고 있는 부분이 있다면 댓글로 알려주시면 감사하겠습니다!!