Seorenn SIGSEGV

이번 글은 굉장히 유명한 수학 함수 3가지를 적어보는 글입니다. 그리고 오랜만에 구어체가 아닌 존대말(?)로 쓰는 글이기도 하겠네요. 이번에 언급하는 함수 세 가지, 즉 ceil(), floor(), round() 함수는 C 언어 시절부터 쓰이던 수학 함수 중 일부입니다. 이 함수 들은 현대의 거의 대부분의 언어에서도 대부분 동일한 이름으로 제공될 정도로 필수 함수이지요. 이 함수들의 용도 및 활용법을 Swift 기준으로 정리해 보겠습니다. 물론 다른 언어에서도 거의 동일하니 언어가 의미가 있는지는 잘 모르겠지만요.

아직 세상은 넓고도 험하다. 코딩을 하던 도중 아래 오류의 문제가 제법 골머리를 썩였다. Could not cast value of type ‘_SwiftValue’ to ‘SomeProtocolName’ 이 글은 위의 오류와 관련된(?) 문제를 해결하던 과정에서 나온 오랜만의 삽질을 정리한 내용이다.

Xcode 9 이전에 개발했던 프로젝트를 Xcode 9 에서 Swift 4 기반으로 변경한 적이 있다. 이 과정에서 단 한줄의 코드 변경도 없었고, 당연하게도 해당 프로젝트는 별 문제는 없이 잘 동작하였다. 다만 약간 찝찝하게도 빌드 도중 아래와 같은 색다른(?) 경고를 보게 되었다. The use of Swift 3 @objc inference in Swift 4 mode is deprecated. Please address deprecated @objc inference warnings, test your code with “Use of deprecated Swift 3 @objc inference” logging enabled, and then disable inference by changing the "Swift 3 @objc Inference" build setting to "Default" for the "TARGET NAME" target. 해석하자면 뭐라고 할까... 그냥 구버전 방식의 @objc 를 사용하는 것이 Swift 4 에선 호환이 안되니 무슨무슨 설정을 바꿔라 이런 의미로 해석된다. 하여간, 이 글은 이 경고를 해결하는 방법을 설명한다.

Xcode 9 을 제대로 찝적거릴(?) 기회가 생겨서 신기능을 조금씩 느껴보고 있다. 이왕 이렇게 된거 이런 기능들을 영상으로 한번 찍어보자 해서 녹화해서 편집해 봤다.

Swift 4 부터는 KVO (Key-Value Observing) 를 쓰기가 이전보다 약간 더 편해질 예정이다.

KVO 는 Key-Value Observing 의 약자, 즉 특정 키의 값의 변화를 감지하기 위한 기능이다. Objective-C 를 위해 만들어진 기능이라 등장한지는 제법 되었지만, 현재의 앱 개발 패러다임에 있어서 - 모델(Model)의 변화를 뷰(View)에 반영하기 위함 등 - 값 변화를 인식하는 것은 굉장히 중요하기 때문에 무시할 수는 없는 기능인 것 같다.

최근에는 좀 게으르게(?) 지내고 있다가 WWDC가 온줄도 모르고 Xcode 9 의 베타가 나오는 줄도 모르고 허송세월 보내고 있었다. 잠깐 정신을 차리고 Swift 4 에 관련된 내용을 간단히 정리해 볼까 한다.

개인적으로 꼽는 Swift 4의 가장 유용한 업데이트 중 하나로 Codable 프로토콜 및 JSONDecoder / JSONEncoder 를 꼽고 싶다. JSON 이라는 이름이 가지는 의미야 유명하니 무슨 말인지는 다들 알 것인데, Codable 이라는 프로토콜은 타입과 JSON을 언어 차원에서 묶어주는 방법을 제공해 준다는 점에서 파격적(?)이다. 이 글은 이 새로운 기능에 대해 겉(?)만 핥으려는 내용이다.

오랫만에 옛날에 만들어 둔 iOS용 앱 프로젝트를 수정할 일이 생겼다. 그런데 문제를 수정하고 디버그 모드로 디바이스에 넣어서 실행시켜보니 괴상한 오류메시지가 로그 창에 찍히기 시작했다.

Implicit Animation 이전에 CALayer 애니메이션 에서 언급한 방법들은 Explicit Animation 즉 명시적인 애니메이션이라고 불린다. 이와 반대 개념으로 암시적인(Implicit) 애니메이션도 있을 터인데 이 암시적 애니메이션은 레이어의 동작(Behavior)에 의해 발동되는 애니메이션이다. 쉽게 말해서 프로퍼티 등에 값을 넣으면 애니메이션이 발동하면서 변화되는 모습을 보여준다. 프로그래머가 직접 애니메이션을 명령하지 않았지만 자동으로 애니메이션이 동작하였기에 암시적이라고 부르는 것이다. view.layer.contents = UIImage(named: "flower").cgImage 위 코드는 뷰 레이어에 이미지를 표시하는 기초적인 코드이다. 그런데 이 코드 이전에 이미 contents 에 이미지가 올라가 있는 상태라면 다른 이미지로 바로 바뀌지 않고 페이드 애니메이션, 즉 이미지가 서서히 나타나는 듯한 효과로 변경(transition)된다. 물로 OS나 기타 조건에 의해 바뀔 수는 있으니 절대적인 것은 아니다. 중요한 점은 그저 레이어의 프로퍼티를 바꿨는데 애니메이션이 발동된다 는 것이다. 이게 바로 암시적 애니메이션이다.

오늘 Xcode 8.3 이 정식으로 릴리즈 되면서 Swift 3.1 도 함께 정식 릴리즈 되었다. 그래서 변화점을 간략히 정리해 보려고 한다. 주관적(?)으로 정리할 것이기 때문에 정확한 내용은 영어 울렁증(?)이 없다면 공식 사이트의 릴리즈 노트 를 보는 것이 좋을지도 모른다.

복잡한 뷰 컨트롤러들을 다루면서 여기 저기 소속된 데이터를 다루려고 할 때 소유권 때문에 곤란함을 느낄 때가 많았다. 이럴 때 NotificationCenter 를 이용해 알림(Notification)을 던지는 방식으로 컨트롤러 객체들끼리 통신을 하기도 하는데, 뭐 하여간 이런 저런 여러 사유로 노티피케이션(Notification 혹은 NSNotification)을 사용할 일이 종종 있다. 하지만 항상 쓸 때 마다 느끼는데, 이 알림(Notification)의 이름(Name)을 찾는데 곤혹을 느끼곤 한다. 왜나하면 한군데에 정리된 것이 아닌 전역 상수 형태로 선언된 것이 대부분이기 때문이다. 물론 개인이 구현하는 프로젝트에서 쓸 Notification 은 굳이 이런 전통을 따를 필요는 없다. 누구나 한번 쯤은 해 볼 만한 Notification Snippets 를 한번 만들어 보자.

레이어 이야기를 쓰다가 계속 삼천포로 살짝 빠지는 느낌이 들지만, 이번 글은 레이어 트랜지션(Transition), 즉 장면전환 애니메이션에 관한 글이다.

CALayer 에 관한 글을 적으면서 애니메이션에 대해 언급할 필요가 생겼는데 간략히 하기에는 양이 너무 많은 것 같다. 그래서 이번엔 CALayer 애니메이션에 관한 것을 별도로 정리하려고 한다. CALayer 의 이름에서 볼 수 있는 머릿글자 CA 는 Core Animation 의 약자이다. Quartzcore 라는 거대한 시스템의 일부이기도 한 이 Core Animation 은 레이어 애니메이션을 위한 기능들로 구성되어 있다. 전체를 설명하기에는 양의 방대함도 그렇고 개인적인 지식도 문제가 되기 때문에 애니메이션과 관련된 Quartzcore 의 몇 클래스만을 정리해 본다.

CAGradientLayer 는 CALayer 기반 클래스로 그라디언트를 그리는 기능을 제공하는 특수 레이어다.

CATextLayer 는 그 이름처럼 화면에 글자를 그리기 위한 용도의 CALayer 기반 레이어 클래스이다. UILabel 이나 NSTextField 등에 비해 기능적인 면에서 부실하기는 하지만 아무래도 퍼포먼스 면에서는 우위일 것이다.

지금까지 iOS 및 macOS 용 앱을 여럿 만들어 왔지만 레이어에 대해서는 자세히 공부해 본 적이 없었다. 블로그에 글 쓸 주제도 적어지고 마침 필요도 하기에 레이어에 대해 공부해 보면서 알게 된 것들을 정리해 보려고 한다.

이 글은 포인터에 관련이 있거나 간접적인 접근 방법에 대한 글이다.

버퍼(Buffer)라는 용어는 대체로 연속적인 메모리 공간을 의미한다. 메모리를 할당해서 구한 포인터는 이 버퍼의 시작 주소를 담고 있다고 볼 수 있다. 버퍼는 메모리 덩어리 그 자체다. 하지만 스위프트(Swift)는 포인터를 쓸 수 있는 언어가 아니기 때문에 연속적인 메모리를 액세스 하는 것이 불가능하다. 그래서 위의 버퍼 개념이 맞지 않는다. Swift 에서는 버퍼를 대체하기 위해 배열(Array)을 대신 사용한다. 랜덤 액세스도 되고 이터레이션도 되는 그 배열 말이다. UnsafeBufferPointer 와 UnsafeMutableBufferPointer 는 이런 Swift 버퍼와 C 버퍼 사이의 상호호환을 위해 제공되는 특수한 컨테이너다.

Swift 에서 C 포인터(Pointer)는 왜 쓰는가. 모호할 때도 있고 쓰기도 귀찮고 문제도 자주 일으키는 그 개념을 말이다. 그런데 답은 C 포인터 라는 이름에서 이미 나와있다. 당연히 C로 구현된 함수가 포인터를 사용하게 되니 이 함수를 쓰려면 포인터를 다뤄야 한다는 것이다. C 가 점점 대중(?)들에게 잊혀져 가는 현재로썬 포인터는 거의 쓸 일이 없어졌다고 볼 수도 있다. 하지만 동일개념을 사용하는 C++도 아직 현역이고 암호화 등 바이너리 연산 계통에선 여전히 C가 현역이다. 거기에 포인터도 거의 따라나니다 보니 아직은 땔 수 없는 애증(?)의 관계인 것 같다. 이번 글은 예전에 썼던 포인터 글이 오래된 것 같아 새롭게 Swift 3 기준으로 C 포인터에 대해서 작성해 본다.