[iOS] required init?(coder: NSCoder)의 정체를 찾아서

NSCoder

UIView를 상속해 커스텀하게 뷰를 구성하게 되면 두 종류의 생성자를 확인할 수 있습니다. 우리가 일반적으로 코드에서 사용하는 생성자는 frame을 파라미터로 받는 생성자였죠. 그럼 NSCoder를 사용하는 생성자는 언제 쓰일까요?

 

이 물음에 답을 하기 위해서는 NSCoder가 무엇인지부터 알아야겠죠? NSCoder의 공식 문서를 찾아가봅시다.

일단 공식문서에서는 NSCoder를 추상클래스라고 소개하고 있어요. 어떤 객체가 다른 객체를 아카이빙(archiving. 압축이라고 볼 수 있겠죠?) 하거나 분배(distribution)할 수 있도록 합니다. 아직 잘 모르겠어서 오버뷰에서 더 자세한 내용을 읽어볼게요.

 

 NSCoder declares the interface used by concrete subclasses to transfer objects and other values between memory and some other format. This capability provides the basis for archiving (storing objects and data on disk) and distribution (copying objects and data items between different processes or threads).

 

여기서 설명이 명확해지네요. NSCoder는 인터페이스이고 이를 구현하는 서브클래스는 어떤 객체를 메모리와 다른 데이터 포맷 사이에서 전환을 가능하게 해준다고 합니다. 그리고 이건 아카이빙과 디스트리뷰션을 통해 가능하죠.

 

Archiving은 객체와 데이터를 디스크에 저장하는 것을 의미하고 Distribution은 객체와 데이터를 서로 다른 프로세스나 스레드사이에서 복사하는 것을 의미한다고 하네요.

 

The concrete subclasses provided by Foundation for these purposes are NSArchiver, NSUnarchiver, NSKeyedArchiver, NSKeyedUnarchiver, and NSPortCoder. Concrete subclasses of NSCoder are “coder classes”, and instances of these classes are “coder objects” (or simply “coders”). A coder that can only encode values is an “encoder”, and one that can only decode values is a “decoder”.

 

NSCoder를 구현하는 클래스들은 Foundation 프레임워크에도 포함되어 있는데요, NSArchiver, NSUnarchiver, NSKeyedArchiver, NSKeyedUnarchiver, NSPortCoder가 있습니다. 이런 클래스들을 "Coder Classes"라고 하고, 이 클래스들의 인스턴스를 "Codier Objects(혹은 Coders)"라고 해요.

 

그리고 인코딩을 지원하는 Coder를 Encoder, 디코딩을 지원하는 Coder를 Decoder라고 하죠. 이건 다 아는 이야기죠?

 A coder stores object type information along with the data, so an object decoded from a stream of bytes is normally of the same class as the object that was originally encoded into the stream. An object can change its class when encoded, however; this is described in Archives and Serializations Programming Guide.

Coder는 객체의 타입을 데이터와 함께 저장해두었다가 디코딩이될 때 이 타입을 그대로 사용합니다. 그래서 일반적으로는 인코딩했던 타입이 디코딩 시에 그대로 적용되죠.

 

이렇게 불친절하게 문서를 적어두고 가장 밑에서 두 개의 문서를 읽어보라고 하고 있네요.. NSCoder의 서브클래싱에 대한 내용과 Archiving과 Serialization에 대한 가이드가 있습니다.

 

저희가 직접 NSCoder의 서브클래스는 구현할 일이 많이 없을 것 같아서 아카이빙과 직렬화에 대한 문서를 읽어볼게요!

 

Archives and Serializations Programming Guide

Introduction

Intro

아카이빙과 직렬화는 계층을 이루고 있는 데이터를 바이트 스트림으로 만들 수 있는 방법입니다. 바이트 스트림이 되면 파일에 쓰여질 수도 있고, 네트워크를 통해 전송이 될 수도 있죠. 바이트 스트림이 디코딩되면 기존 계층이 그대로 재생성됩니다. 이를 위해서 아카이빙은 객체들이 서로 가지고 있는 관계들과 값을 기록해주게 됩니다. 그리고 직렬화는 계층간의 프로퍼티의 값들이 가지는 값들을 리스트업 해두는 것 뿐이죠.

 

무슨 소린지 잘 모르겠죠? 일단 여기서 하고자 하는건 어떤 데이터를 바이트 스트림으로 바꾸고자하는 것이고, 이때 데이터들이 가지고 있는 계층관계도 포함하고 싶은거예요. 바이트 스트림으로 바꾸려는 이유는 파일에 작성하거나, 네트워크로 전송하기 위해서이구요. 여기서 말하는 바이트 스트림으로 바꾸려는 "데이터"가 무엇인지 조금 추상적인 것 같은데 바로 다음 섹션을 통해서 힌트를 얻어보자구요!

 

Object Graphs

객체 중심으로 구성되어 있는 애플리케이션(우리가 만드는 모든 앱이 다 그렇겠죠..!)은 객체들이 굉장히 복잡하게 얽혀있습니다. 서로 연결되어 있기도 하고, 어떤 객체가 다른 객체를 소유하기도 하죠. 이렇게 객체들이 얽히고 얽혀있는 구조(Web이라고 표현하네요)를 객체 그래프(Object Graph)라고 합니다.

복잡쓰..

만약에 이런 애플리케이션을 혹은 애플리케이션의 일부를 파일로 저장하고 싶다면 어떻게 해야할까요? 아니면 다른 프로세스에게 전달해서 사용해야 할때는요?

 

우리가 잘 알고 있는 Nib이나 plist 파일이 객체 그래프가 파일로 저장된 좋은 예시인데요, Nib은 사용자 인터페이스에 대한 복잡한 객체들의 관계를 파일로 표현하고 있고, plist 파일도 어떤 객체에 대한 값의 목록들을 파일로 저장하고 있습니다.

 

이런 것들이 가능한 이유가 Archive와 Serialization이 있기 때문이죠.

 

오 Nib에 대한 이야기가 나왔습니다..! 커스텀 뷰의 생성자에 NSCoder가 나온것과 뭔가 연관이 있을 것 같네요..! 계속 읽어보겠습니다!

 

Archives

아카이브를 사용하면 복잡한 객체 그래프를 저장할 수 있게 해줍니다. 아카이브는 객체 그래프 안에 있는 모든 객체들의 식별자를 보존하고 그래프 내의 다른 객체들과의 관계도 보존합니다. 아카이빙 된 데이터를 언아카이빙하면 몇가지 예외상황을 제외하고는 아카이빙하기 전 객체 그래프를 정확하게 복원(rebuilt)합니다.

 

아카이브를 데이터 모델의 저장수단으로 사용하면 따로 저장을 위한 포맷팅을 해주지 않아도 돼서 이점이 있죠. 언아카이빙을 하면 그대로 사용할 수도 있구요.

 

아카이빙이 지원되려면 객체가 반드시 NSCoding 프로토콜을 채택하고 있어야 합니다.

NSCoding 문서를 열어보니 이렇게 두 개의 메서드가 Required로 안내되어 있는데요, 하나는 객체의 변수들을 아카이빙하는 메서드이고, 다른 하나는 아카이빙된 데이터에서 변수와 데이터들을 복원하는 메서드입니다.

 

Foundation에 포함된 모든 값 타입 객체들은 NSCoding을 채택하고 있습니다. NSString, NSArray 같은 친구들이요. 이런 타입들은 따로 코드를 작성해주지 않아도 아카이빙할 수 있습니다.

 

Serializations

Serialization은 값 객체들을 더 간단하게 저장할 수 있는 방법이예요. 딕셔너리, 배열, 문자열, 바이너리 데이터들을 계층 관계로 저장할 수 있죠. 아카이브와는 다르게 직렬화는 객체가 가지고 있던 값과 계층 상의 위치만 포함하고 있어요. 그래서 만약 어떤 객체가 다른 많은 객체들에게 참조되고 있다면, 직렬화된 파일에는 각각 하나씩 1대1 매칭이 되는 관계로 표현될 수도 있습니다.

 

plist가 대표적인 예인데요,

이렇게 객체들의 복잡한 관계를 표현하지는 못하지만, 객체들간의 계층관계와 각 객체가 담고있는 값을 표현할 수 있죠.

 

빽 투 더 탑

다시 이 코드로 돌아와볼게요. required init?(coder: NSCoder)는 어떤 일을 할까요?

 

아까 아카이빙과 디스트리뷰션이 가능한 NSCoder객체의 인스턴스가 Coder였죠? 그럼 이 메서드에서는 어떤 객체를 아카이빙하거나 언아카이빙하겠네요.

 

그럼 저 메서드도 문서를 찾아봐야겠죠?

 

레전드.. 설명이 없습니다ㅋㅋㅋㅋㅋ

다행스럽게도 UIView 문서에는 적혀있네요.. 스토리보드나 nib 파일을 통해 뷰를 로드하면서 커스텀하게 초기화를 해주고 싶다면 이 메서드를 사용하라고 하네요.

 

스토리보드와 nib으로 만들어진 뷰가 어떻길래 이럴까요??

 

이번엔 여기서 nib의 문서를 열어봤습니다..

 

 

오키오키~ 실마리를 찾았네요! Nib 파일은 인터페이스 빌더 문서라고 해요. 이 문서가 수정되고 파일이 저장될 때 객체그래프가 생성되어서 저장됩니다. 그리고 그 파일을 로드하면 객체그래프가 언아카이빙 되는 것이죠.

더 읽어보니 스토리보드로 작성하는 뷰들도 모두 Nib으로 표현된다고 합니다.

 

정리하면 스토리보드나 xib는 결국 객체 그래프가 아카이빙된 파일이고, 이 파일을 로드해주어야 뷰를 보여줄 수 있는거죠. 그리고 이때 불리는 생성자가 required init?(coder: NSCoder) 이었던 것이네요..!

 

잠깐.. 그럼 awakeFromNib은 뭔데..?

갑자기 드는 의문.. 그럼 awakeFromNib은 왜 불리는걸까요??

이번에도 역시 문서가 있었네요.

 

정리해보면 NSCoding 을 채택하는 객체가 언아카이빙된 이후에 초기화 된 이후에 불리는 메서드가 awakeFromNib이라고 해요. 객체 그래프를 이루던 모든 객체가 인스턴스화 되고 초기화되면 객체가 가지고 있는 outlet이나 action이 연결됩니다. 그 이후에 불리는 메서드가 awakeFromNib입니다.

 

객체 그래프에 있던 객체들이 언아카이빙 되고 시작되는 순서가 아카이빙된 순서와 같다는 것이 보장되지 않습니다. 그래서 init 메서드에서 다른 객체에게 메시지를 보내는 행동은 절대 하면 안된다고 해요. awakeFromNib은 모든 객체가 초기화된 이후에 호출되기 때문에 안전하다고 해요.

 

마무리

이렇게 해서 NSCoder와 객체그래프에 대해 공부해보았습니다! 예전에 한 번 들었던 내용인데 다 잊고있다가 전체적으로 문서를 다시 보니 확실히 정리가 되는 것 같아요! 오늘도 읽어주셔서 감사합니다..!

 

문서에 많이 의지하다보니 잘못 해석하거나 이해한 내용이 있을 수도 있어요.. 제 글을 너무 맹신하지 말아주시고 틀린 부분이 있다면 알려주세요!

 

래퍼런스

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

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

https://developer.apple.com/documentation/uikit/uiview/

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Archiving/Archiving.html#//apple_ref/doc/uid/10000047i

https://developer.apple.com/documentation/objectivec/nsobject/1402907-awakefromnib