Seorenn SIGSEGV

세마포어도 병렬 프로그래밍 동기화를 위한 전통적인 기능 중 하나이다. GCD(Grand Central Dispatch) Dispatch 에서도 세마포어가 제공되기에 이를 간단히 살펴보고자 한다.

제목이 좀 뜬구름 잡기인 듯 한데 좀 더 쉽게 풀자면 이렇다: 프로젝트에 스토리보드가 두 개다. 이 중 하나는 튜토리얼용으로 앱 시작 시 한번만 보여줄 것이다. 이걸 스토리보드 하나로 만드면 너무 복잡해서 나눈 것이다. 앱 시작 시 특정 조건의 경우에는 튜토리얼용 스토리보드의 UI로 시작해야 한다. 그런데 어떻게 해야하지? 그냥 딱딱하게 설명할까 했지만 이번엔 좀 수고를 들여서 메모를 만들어 본다 -_-;

간밤에 애플이 Swift가 오픈소스화 되었다고 공식 발표하였다. 공식사이트는 이제 아래 사이트이다.

Sequence Type의 대표적인 예는 배열(Array)이 있겠다. 하지만 정확히 말하자면 배열 처럼 고정인덱스를 가진 타입이 아니라 그냥 순차적인 리스트 정도가 딱 어울리는 표현이다. 다르게 표현하자면 이터레이션(Iteration), 즉 나열 가능한 타입이다. 어쨌든 이런 타입을 만드는데 필요한 SequenceType 프로토콜에 대해 알아보자.

오랫만에 남기는 초간단 메모글은 'iTunes에서 파일 공유 기능을 활성화 하는 방법' 에 대한 것이다.

언제 어떻게 왜 추가되었는지 몰랐던(?) Objective-C 제너릭을 간단히 정리해 보는 글이다.

iOS 9과 OS X 10.11 에 앱 네트워크 보안(App Transport Security) 이라는 정책이 새롭게 추가되었다. 이로 인해서 구글에서도 애드센스 관련해서 뭔가 말이 많았던것 같은데, 나도 개발 도중에 문제를 겪었기에 메모하는 겸 블로그로 정리해 본다. 아 참고로 이 내용은 애플에서도 개발중인 내용이라 추후에 변경될 가능성 이 있다고 한다.

이 글은 앱의 설정창을 코드로 띄우는 방법에 대한 메모이다. 참고로, 설정(Preferences)를 띄우신 띄우지만 앱 개별 설정으로 바로 들어가게 되는 방법임을 유의하자. 그리고 이 방법은 iOS 8 버전부터 사용이 가능하다.

사실 얼마 전까지만 해도 debugPrint 라는 함수가 있는지 조차 몰랐었다. 뭐 이제서라도 알게 되었으니 메모도 할겸 print 와 debugPrint 에 대한 글을 써 본다.

Swift 2 에서 map 과 비슷한 flatMap 이라는 녀석을 사용 할 수 있다. 애초에 map 의 용도는 ' 배열의 각 아이템을 가공해서 다른 배열을 만드는 것 '이다. 그렇다면 평평하다는 이름을 가진 flatMap 은 어떤 용도일까? 이 글에는 flatMap 이 무엇인지에 대한 명확한 해답이 없다. 그냥 특징만 나열해 놓고 '뭐에 쓰는 것임' 이라고 징징거리는 글이다. -_-;;

연산하는데 시간이 오래 걸리는 경우를 가정해보자. 당연히 기다리는데 지루할 것이다. 그런데 이 연산 작업을 쪼게어서 병렬로 처리하는게 가능하다면 당연히 (남는 CPU 코어를 이용해) 병렬처리 하는 것이 더 빠른 결과를 얻기 위한 방법이다. 다만, 병렬로 계산하기 때문에 모든 병렬 연산 작업이 끝나야 최종 결과물 산출이 가능해진다. 이 모든 병렬 연산이 끝나는 시점을 어떻게 파악할 것인가?

디스패치 큐(Dispatch Queue)라는건 일종의 스레드 개념과 비슷하다. 클로져로 구성된 태스크(Task)를 이 큐(Queue)에다 등록하면 별도의 스레드에서 이 큐의 내용물을 뽑아서 해당 스레드에서 태스크를 구동시키게 해 주는 문 역활을 한다. 물론 큐가 1:1로 스레드와 연결되는 건 아니다. 큐에는 직렬큐(Serial Queue)와 병렬큐(Concurrent Queue)가 있다. 큐의 태스크는 단일 스레드에서 직렬로 돌아갈 수도 있고 병렬로 태스크 갯수 만큼의 스레드에서 모두 병렬로 돌아갈 수도 있다. 이미 GCD 기초글에서 메인큐(Main Queue)와 글로벌 큐(Global Queue)를 사용하는 방법에 대해서 다루었었는데, 이번에는 커스텀 큐를 만들어서 병렬 프로그래밍을 하는 방법 중 기초적인 것들을 알아보자. 다만 큐 생성 부분을 제외하면 기본적으로 동일하다보니 별로 볼 내용은 없을지도 모른다. -_-; Update: Swift 3 기반의 문법으로 업데이트 하였다.

OptionSetType은 기존의 비트 단위 옵션셋을 대체하기 위해 등장한 프로토콜이다. enum이나 #define을 쓰던 때와는 다르게 struct 기반의 옵션셋 구현을 가능하게 해 준다.

사람에 따라 사소하지 않은 변화일 수도 있지만, Swift 가 버전 1.2에서 2.0 으로 올라가는 사이에 바뀐 것들 일부를 정리해 본다. (개인적으로 큰 변화라고 느끼는 부분은 별도의 글로 정리하였으니 글 목록을 찾아보자. -_-;)

Swift 2.0 에서 개선된 사항 중 CFunctionPointer를 클로져로 대체 할 수 있다는 것이 있다. 이건 정말 큰 개선 사항이다. 왜냐하면 난 아직도 이 CFunctionPointer 타입을 다룰 줄 모르기 때문이다. -_-;;

Swift 는 문법으로도 다양한 기능을 제공하는 고급 언어이다. 하지만 고급 언어이기 때문(?)에 최적화된 C 라이브러리를 종종 사용해야 할지도 모르고 그럴 때는 C의 포인터를 함께 사용해야 할 가능성도 있다. 그래서 Swift의 포인터 처리에 대해 간단히 정리하려 한다. 참고로 이 글은 Swift 3 가 등장하기 이전에 쓰여졌다. Swift 3 에서의 포인터는 [ Swift 속의 C Pointer 이야기 - 시작 ] 글을 참고하자.

아마도 Swift 2.0 들어서 문법적으로 가장 강력한 기능이 아닐까 생각하는 것이 바로 이 defer 문이다. 아 물론 개인적인 생각일 뿐이다... '-';;

Swift 2.0 에서 컨트롤 제어(Control Flow) 쪽으로 추가된 구문 중 guard 라는게 있다. if 문 같은 것과 비교하면 특별할 건 없지만 코드 읽기 차원에서 유용한 경우를 제공하기 때문에 소개해본다.

Xcode 6 하에서 Swift 코드로 만들어진 프로젝트의 유닛테스트를 하려면 해당 모듈을 public으로 선언해야만 가능했다. (관련글: Swift 프로젝트의 유닛테스트(Unit Test) ) 이는 Swift의 엑세스 컨트롤의 구현 의도와 Xcode에서 테스트 코드가 구성되는 방식의 의도가 다르다는 차이 때문에 발생하는 문제였다.

Swift 2.0 에서 드디어 예외처리 - 공식 블로그에는 Error Handling Model 이라고 표현하고 있다 - 이라는 OOP 언어라면 누구나(?) 다들 가지고 있는 기능(?)이 추가되었다. 그런데 기존 다른 언어들과는 조금 다른 모습이긴 하다

플랫폼(Platform), 즉 현재 프로젝트의 타겟 OS가 OSX 이냐 아니면 iOS냐를 구분하는 전처리기를 정리한다. 기존의 Swift 글에서도 정리했던 적이 있지만 Objective-C 코드에서도 종종 사용되기에 별도로 정리한다.

얼핏 생각해서는 UIView 서브클래싱 하는 것과 비슷하리라 생각했는데 API의 사용법이나 결과가 조금씩 달랐다. 그래서 XIB를 이용해 인터페이스 디자인을 할 수 있는 NSView 서브클래싱을 정리해 본다.

UIView 기반의 클래스를 만들 때 XIB를 이용해 뷰 디자인을 하는 방법에 대해 정리한다. 기초적인 내용이긴 하지만 그래서 워낙 자주 까먹는 내용이다. -_-;

Swift 1.2 에서 'Set' 이라는 새로 추가된 컬렉션 타입이 있다. Set 타입은 중복되지 않는 값들을 보관하기 위한 순서가 없는 배열과 비슷하다. 혹은 수학에서 흔히 말하는 '집합'과도 비슷하다.이 Set 타입에 관해서 간단히 정리해 보려고 한다.

Swift 1.2 업데이트 내역 에 관한 글을 쓰면서 as! 오퍼레이터에 대해 좀 오해한 것 같다. 그래서 이 오퍼레이터의 기능에 대해 간단히 살펴보고자 한다.

이미 Swift의 프로퍼티(Properties)에 관한 내용 중 '나중에 생성되는 프로퍼티(Lazy Stoed Properties)' 항목에서 간략하게 설명했었지만, 조금은 더 실생활(?)에 도움이 되는 예제가 필요하다는 생각이 들었다. 그래서 이 lazy 프로퍼티를 약간 더 자세히(?) 정리해 본다.

아직 Xcode 6.2가 정식으로 릴리즈 되지도 않았는데 벌써 Xcode 6.3 베타가 나오는 어이없는(?) 상황이 이어지고 있다. Xcode 6.3에서는 드디어 Swift가 업그레이드 되어서 1.2가 들어가게 되는데 이와 관련된 변화점을 살펴보고자 한다. 가급적이면 모든 내용을 다루고 싶지만 이해가 안되는 것도 많고 별로 몰라도 되는 것도 있어서 중요하다 싶은 내용만 다룬다. 이번 업데이트는 크게 Swift, Xcode 그리고 Objective-C 세 가지 파트로 나뉘어진다.

예제로 보는 Swift 두 번째 포스팅. 이번에는 웹페이지에서 쓰이는 16진수 컬러코드를 UIColor로 변환하는 방법을 쓸 데 없이 길게 풀어써 본다. 참고로 이 글은 플레이그라운드(Playground)에서 작성한다는 가정 하에 쓰여진 글이다.

NSScanner는 문자열(String, NSString)에서 값을 스캔하기 위한 클래스이다. 아래 공식 레퍼런스에는 Abstract Superclass 라고 소개되어 있긴 하지만 예상외로 별도로 구현할 필요 없이 그대로 써도 된다.

스위프트(Swift)는 Objective-C의 많은 기능들을 새롭게 포장해서 제공해 주고 있는데 프로토콜도 그 중 하나이다. 이 프로토콜(Protocols)과 딜리게이션 패턴(Deleagation Pattern)에 대해 간단히 정리해 본다.

Swift가 뜨고 있는(?) 현재로썬 그다지 자주 쓸 일은 없을 것 같긴 하지만, Objective-C ARC의 Toll-Free Bridged Types에 대한 이야기를 써 본다.

이번 글은 개인적으로 빡쳐서 쓰는 한탄글이다 -_-; 종종 Swift는 아직 준비가 덜되었다고 떠벌리고 다녔는데 이번에는 정체불명의 오류로 인해 다시금 준비가 덜 되었다고 이야기를 해야 할 것 같다. 이번 글은 Swift의 Dictionary(사전형)의 아이템을 업데이트 할 때 발생하는 EXC_BAD_ACCESS에 관한 이야기이다.

과거에 쓴 dispatch_once 및 static struct 를 사용한 싱글턴 패턴 은 외워서 쓰기가 좀 귀찮다. 라인수가 조금은 기니깐. 그래서 찾아보니 의외로 단순하게 Swift의 클래스에 싱글턴 패턴을 적용 할 수 있는 방법을 찾았다.

오랫만에 Objective-C 전용 글. 구시대(?) 방식으로 performSelector를 쓰는 경우 요즘은 아래와 같은 식의 빌드 경고가 발생 할 수 있다.

클로져 이용 시에도 메모리 관리와 관련된 지식이 필요 할 때가 있다. 일반적인 변수 대입 과정에서 리테인이 발생하는 요소 외에도 클로져 내부에서 외부의 변수를 참조 할 때 발생하는 리테인을 깜빡 할 수도 있기 때문이다.

지금까지 레퍼런스 카운트와 ARC에 관해 설명해 오다가 마치 삼천포에 빠진 것 처럼 구조체와 클래스에 대한 이야기가 나오게 되었다. 그런데 이 구조체와 클래스의 차이점으로 메모리 관리 상의 차이도 존재하기 때문에 짚고 넘어가야 할 것 같다. 다만, 이 둘의 차이에 대해 이미 이해하고 있다면 무의미한 글이 될 수도 있으니 그냥 넘어가자.

앞서 Objective-C의 레퍼런스 카운트 개념 에 대한 기본적인 지식을 설명했다. 이제 Swift 영역으로 돌아와서, ARC에 대해 좀 더 깊이 들어가 보자.

소프트웨어를 만들 때 메모리 관리라는 건 언어에 따라 중요성의 차이가 다르긴 하다. 하지만 왠만해서는 신경써서 작업해야 하는 것이 메모리 관리이다. 얼마나 적거나 많은 메모리를 사용하는지, 또는 어느 시점에서 메모리가 해제되면 효율적인지 등등 신경써야 할 부분이 제법 많다. 이 글은 Swift의 메모리 관리에 대한 기본적인 지식 시리즈 첫 번째로, ARC(Automatic Reference Counting)의 전제가 되는 레퍼런스 카운트(Reference Count) 개념부터 정리한다. 직접적인 Swift 에 대한 내용이 아니기 때문에 꼭 알아야 할 필요는 없을지도 모르겠다.

이 글은 이 블로그에서 Xcode와 관련된 글의 링크를 모은 길찾기용 글이다.

글 제목이 Core Foundation 으로 한정하고 있는 것 같지만, 정작 실체는 iOS(+ Cocoa Touch) 앱 개발과 OS X(+ Cocoa) 개발에 공통적인 글 링크를 정리하고 있는 글이다. :-) 과거 글은 Objective-C 위주로 쓰여져 있는 점에 주의하자.

이 글은 본 블로그에서 macOS용 앱 개발 및 Cocoa 프레임워크 전반에 대한 글 링크를 별도로 정리한 길찾기용 글이다. 관련된 내용이 업데이트 되면 (귀찮지 않으면) 이 글에도 업데이트 할 예정이다.

이 글은 본 블로그에서 iOS 앱 개발 전반 및 Cocoa Touch 프레임워크에 대한 글의 링크를 별도로 정리한 길찾기용 글이다. 관련 글이 업데이트 될 때 마다 이 글에도 해당 항목을 추가할 예정이다.