예제는 다음의 구글 코드 사이트에서 관리되고 있습니다. 수정되는 사항은 항상 이곳에 반영되니, 그때 그때 업데이트 하시면 되겠습니다.
http://code.google.com/p/touching-iphone/
우선 본인의 맥에서 소스를 다운받기 위해서는 다음 그림과 같이 Terminal을 실행시킨 후 다음 명령을 입력하면 됩니다.
> mkdir example <-- 저장하고자 하는 디렉터리를 하나 생성함
> cd example <-- 해당 디렉터리로 이동
> svn checkout http://touching-iphone.googlecode.com/svn/trunk/ touching-iphone-read-only
안녕하세요. 많은 독자분들이 책에 대해서 궁금한 점이 있을것이라고 생각됩니다.
책이 나오고 거의 바로 새롭게 아이폰 SDK가 버젼없이 되면서 상당한 혼란이 있었습니다.
기본적으로 책이 쓰여지는 시점에 사용했던 SDK와 iOS를 기준으로 책이 쓰여져 있기 때문에,
현재 사용하시는 iOS와 SDK와 다른 부분이 있을 수 있습니다. 책을 쓰는 시점에서 모든 예제를
직접 만들어서 정상적으로 돌아가는지 전부 두번씩 확인을 하였습니다.
혹시 예제가 동작되지 않거나, 기타 책과 관련된 문의사항이 있으시면 저에게 메일을 보내주시기 바랍니다. fromdj2k@gmail.com 입니다. 감사합니다.
CLang 정적 분석기는 Objective-C와 C언어로 작성된 코드를 분석해서 오류를 발견해 주는 툴이다. 디버깅이나 인스투루먼츠는 실행중인 프로그램을 분석하는 동적인 작업인 반면, CLang은 정적으로 소스 코드 자체를 분석해서 오류를 검사한다. 검사할 수 있는 오류는 메모리의 누수, dealloc누락, 널(Null)값 참조 등이 있다. 직접 사용해 보자.(CLang은 또다른 프로젝트 LLVM 컴파일러를 위한 프론트엔트 프로젝트이다. LLVM은 GCC를 기반으로 컴파일 성능을 최적화하는 기술을 적용한 프로젝트이다. CLang 프로젝트의 일부로 CLang 정적 분석기 프로젝트가 포함된다. )
*프로젝트 설정하기
CLang분석기를 이용하기 위해서 Xcode상에서 설정할 사항이 하나 있다.
Base SDK 설정
위 그림과 같이 프로젝트 속성에서 Base SDK를 iPhone Simulator로 설정해야 한다. iPhone Device의 경우는 코드 서명 문제로 오류가 발생하기 때문이다. 우리는 정적으로 코드만 분석하면 되기 때문에 시뮬레이터를 선택해 주자.
* 설치하기
CLang 정적 분석기는 다음 사이트에서 무료로 다운로드 받을 수 있다. 오픈소스 프로젝트 이기 때문에 소스코드도 받을 수 있다. 아래 링크에서는 친절하게 맥OS를 위해서 바이너리 형태로 파일을 제공해 주기 때문에, 바로 쓸 수 있다.
첫 번째 명령은 프로젝트의 빌드파일을 모두 정리하는 명령이다. 두번째가 실제로 CLang분석기를 실행시키는 명령이다. 명령을 내리면 CLang분석기는 디버그 타깃을 시뮬레이터SDK로 빌드하고, 그 결과를 보여줄 것이다. 문제가 발견되면 그림30과 같이 웹페이지를 실행시켜 준다. (만약 프로젝트의 빌드가 실패하면 분석결과 오류를 발견했더라도 실행이 멈추게 되어있다. 성공적으로 빌드되었는지 확인하기 바란다.) 만약 성공적으로 빌드하고 오류가 전혀 발견되지 않았다면 웹페이지는 따로 보여주지 않는다.
CLang 분석기로 애플리케이션을 하나 분석해 보자. 아래 그림이 그 결과다.
<그림> 발견한 오류를 웹 페이지로 보여준다.
다행이 오류가 하나 만 발견되었다. Leak of returne object 오류인데, 객체를 해제하지 않았다는 오류이다. 한 가지 주의할 점은 CLang 분석기가 오류로 판단했다고 해서 반드시 오류는 아니라는 것이다. 어디까지나 그 것이 오류인지를 판단하는 것은 개발자의 몫이다. 진짜 오류인지 한번 들어가 보자. 왼쪽 화면의 View Report 를 클릭하자. 그러면 문제가 되는 소스코드를 보여주고, 친절하게 설명까지 보여준다.
31행에서 NSURL 객체를 생성하고 34행에서 잘 사용했다. 그런데 해제하지 않았다. 실수다. 고치도록 하자.
많은 개발자들이 Objective-C 의 메모리 관리를 어렵게 느낀다. Objective-C 에서 객체는 참조 카운터를 이용해서 관리되기 때문에, 참조 카운터를 증가 시키고 감소하는 작업이 프로그래머의 몫이 된다. 여기서 혼돈이 오는 것이다. 참조 카운터를 증가시키는 함수는 retain 이다. 반대로 참조 카운터를 감소시키는 함수는 release와 autorelease 이다. 하지만 문제는 이미 만들어진 객체의 메서드가 내부에서 retain 을 몇번 부르는지를 별도로 알아낼 방법이 없다는 것이다. 다음을 보자.
이 코드에서 UIImageView 는 retain 내부에서 한번 호출해서 객체를 반환해 준다. 그렇기 때문에 우리는 더이상 필요하지 않을때,
[imgView release];
를 호출해야 한다. 하지만 다음을 보자.
NSString* output = [NSString stringWithFormat:@”My name : %@”, name];
이 코드는 NSString의 stringWithFormat 클래스 메서드를 이용해서 객체를 생성하는 코드이다. 이 녀석은 retain 이 아닌 autorelease 를 호출해서 객체를 반환한다. 이렇게 어떤 메서드는 객체를 retain 해서 반환하고, 또 어떤 객체는 autorelease 로 반환하기 때문에 혼돈이 온다.
참조 카운트를 관리하는 함수는 다음과 같다.
• retain
- 참조 카운트를 1 증가 시킨다.
• release
- 참조 카운트를 1 감소시킨다. 참조 카운트가 0이 되면 메모리가 해제된다.
• autorelease
- 객체를 오토릴리즈 풀에 등록한다. 나중에 오토릴리즈 풀이 제거될때 release 를 호출해 준다.
객체의 참조를 관리하는 것은 위 3개의 메서드가 전부이지만, 문제는 클래스 내부 구현에서 위 함수들을 호출하는 지를 모른다는 점이다. 하지만 법칙이 있다. 애플이 작성한 모든 클래스는 정해진 규칙을 철저하게 따르기 때문에 이 법칙들만 알아두면 더 이상 햇갈릴 일이 없다.
* 규칙1 : alloc, copy, new를 이름에 포함하는 메서드는 retain 된 객체를 반환한다.
alloc, copy, new 가 메서드 이름에 포함되어 있다면, 그 때 반환되는 객체는 retain 되어 있다. 그래서 반드시 release 를 직접 호출해야 한다.
코드 1행의 imageNamed 메서드 처럼 클래스 메서드를 이용해서 객체를 생성하는 경우 그 객체는 autorelease 가 호출된 객체이다. 그렇기 때문에 별도로 release 를 호출하지 않아도 오토릴리즈 풀이 자동으로 release 를 호출해 준다. 하지만 이 객체에 retain 을 호출 했다면 호출한 만큼의 release 를 호출 해야한다.
* 규칙4: 포함 객체는 추가된 객체를 retain 하고, 항목을 제거할 때 release 한다.
NSArray,NSDictionay 등의 포함 객체는 항목으로 추가되는 객체에 대해서 retain 을 한번 호출한다. 그리고 객체가 포함객체에서 제거될때 release 를 호출해 준다.
13.9.5 규칙5: retain 속성을 갖는 접근자
프로퍼티를 구성할때 @property (retain) ... 과 같이 retain 속성을 지정하면 이 프로퍼티에 객체를 설정하면 retain 메서드를 호출한다.
01: myImage = [[UIImage alloc] init]; // myImage 에 retain –> 1
02: self.userImage = myImage; // myImage 에 retain –> 2
03: [myImage release]; // myImage 에 release –> 1
04: // ...
05: self.userImage = myImage2; // 예전 myImage 에 release -> 0 해제
이와 같이 객체를 설정하는 접근자는 일반적으로 그 객체에 대해서 retain 을 호출한다. 그리고 만약 다른 객체를 재설정하면, 예전 객체에 release 를 호출한다. 위 예제의 3행에서 release 를 호출한 이유를 이해할 것이다.
아아폰에서 모든 어플리케이션은 기본적으로 하나의 쓰레드를 가지고 있다. 이 쓰레드는 UIApplication 클래스에서 자동으로 생성하며 프로그램의 메인 룹이 이곳에서 실행된다. 하지만 어떤 작업이 그 작업을 마치는데 너무 오랜 시간이 걸린다면 그 작업을 새로은 쓰레드로 만들어서 실행하는 것이 좋다. 메인 쓰레드는 기본적으로 사용자와 상호 작용을 해야하는데, 어떤 작업이 시간을 너무 소모하면 사용자가 프로그램이 멈춘 것으로 오해 할 수 있다.
아이폰 OS 에서 쓰레드는 리눅스와 유닉스에서 지원하는 POSIX 쓰레드를 그대로 이용할 수 있다. 또한 코코아 터치 프레임워크 자체에서도 NSThread 라는 클래스를 이용해서 쓰레드를 좀 더 편리하게 생성할 수 있게 해 준다. 만약 이미 POSIX 로 작성된 코드를 가지고 있는 경우라면 새롭게 NSThread로 포팅하지 않고 바로 사용하는 것이 좋을 것이다.
이제 부터 코코아 터치가 제공하는 쓰레드 기능을 하나씩 구현해 보도록하자. POSIX 쓰레드는 이책에서는 따로 설명하지 않겠다.
* 쓰레드 생성하기
먼저 NSThread 객체를 이용해서 쓰레드를 생성해 보자. 다음은 NSThread 의 클래스 메서드를 이용하는 방법이다.
오토릴리즈(autoreleae) 풀은 객체 중에서 autorelease 메서드를 호출해서 생성된 객체들을 관리한다. 오토릴리즈 풀을 생성하면 그 이후로 생성되는 모든 autorelease 객체를 마지막에 생성된 오토릴리즈 풀 객체가 관리한다. 그리고 오토릴리즈 풀을 해제(release) 하면 이때 모든 오토릴리즈 객체도 같이 해제된다.
모든 쓰레드는 자신만의 오토릴리즈 스택을 관리하기 때문에, 쓰레드를 생성한 후 반드시 오토릴리즈 풀을 생성해야 한다.
* 런 루프
런 루프는 쓰레드가 외부와 통신하기 위해서 존재한다. 런 루프는 자신(쓰레드)에게 전달된 이벤트가 있는지를 검사하고, 만약 존재하는 경우 알맞은 메서드를 호출해 준다. 런 루프가 처리하는 이벤트는 크게 두가지가 있다.
• 입력 소스
• performSelector:: 계열의 메서드를 호출해서 지정한 셀렉터를 실행시켜달라는 외부의 요청.
• 타이머
• 타이머를 생성하면 그 타이머는 코드가 실행된 쓰레드의 런 루프에 소속된다. 런 루프는 타이머중에서 지정한 시간이 경과한 것들을 검사해서 메서드를 호출해 준다.
다음 코드를 보자.
01: if ( tapCount == 2) {
02: // 5개 모두 보여주자. 03: [self performSelector:@selector(showAllCircles) withObject:nil afterDelay:0.3]; 04: NSLog(@"Scheduled");
05: }
06: ... 생략 ...
07: if (tapCount > 2) { 08: [UIView cancelPreviousPerformRequestsWithTarget:self]; 09: NSLog(@"Cancelled");
10: }
이때 이미 쓰레드에 입력 소스를 추가하는 작업을 구현한 것이다. performSelector:withObject:afterDelay 메서드를 호출하면 현재 쓰레드의 런 루프에 입력 소스로써 등록이 된다. 그리고 런 루프가 실행될 때 자신에게 등록된 모든 입력 소스를 검사해서 조건이 만족되는 (여기서는 0.3초 경과) 경우 해당 메서드를 호출(예제에서는 showAllCircles)해 주는 것이다.
만약 스스로 쓰레드를 생성했다면 런 루프가 자동으로 실행되지는 않는다. 그래서 자신의 쓰레드 함수에서 직접 런 루프를 실행시켜서 주기적으로 외부의 이벤트에 대응할 수 있도록 만들어야 한다. 하지만 쓰레드가 하나의 작업만 수행하고 종료되는 경우라면 반드시 필요하지는 않다. 하지만 무한 루프를 돌면서 지속적으로 상호작용이 필요한 쓰레드라면 반드시 런 루프를 실행해 주도록 하자.
키 값 코딩은 NSObject 를 상속받는 모든 객체가 지원한다. 이는 NSKeyValueCoding 라는 프로토콜을 NSObject 가 따르고 있기 때문이다. 키 값 코딩은 무엇일까 ?
키 값 코딩 기술은 객체의 속성을 문자열을 통해서 간접적으로 접근하기 위한 것이다. 즉 객체의 속성에 접근하기 위해서 직접 객체의 접근자를 호출할 것이 아니라 속성의 이름을 인자로 전달해서 그 값에 접근하는 것이다. 객체에 접근할 때 내부적으로 접근자를 이용하게 된다. 만약 접근자가 존재하지 않으면 직접 멤버 변수에 접근한다. 다음 예제 코드를 보자.
먼저 7,8 행을 보자. imgView 는 이미지 뷰의 객체이다. 뷰의 frame 속성을 변경하는 기존 방법은 7행과 같이 점 표현법으로 접근하거나, [imgView setFrame:] 과 같이 접근자를 호출하는 것이었다. 하지만 예제는 setValue:forKey 메서드를 이용해서 문자열로 속성값에 접근한다. 이러한 접근법을 키-값 코딩이라고 한다.
13,14행은 키-값에 대해서 경로를 사용한 것이다. 키-값 경로는 접근하려는 속성에 대해서 점 표현법 문자열을 쓰게 되면, 그 문자열을 분석해서 재귀적으로 키-값 코딩을 적용하는 것이다.
14행을 보면 imgView 의 superview 속성에 키-값 코딩으로 접근하고, 그 superview 객체에서 다시 키-값 코딩으로 backgroundColor 속성에 접근한다. 이와 같이 키-값 코딩과 키-값 경로를 이용한 방법은 점 표현법, 접근자와 밀접한 관계를 갖는다.
코드의 17,18행에서 보는 것과 같이 valueForKey, valueForKeyPath 메서드를 이용해서 접근한다. 점 표현법을 사용하는 문자열로 값에 접근할 때는 반드시 valueForKeyPath 를 이용하는 것에 주의하자.
그렇다면 NSObject 가 키-값을 검색하는 방식은 어떻게 될까 ? NSObject 는 키-값 코딩으로 접근하는 메서드가 호출되면 그 키와 일치하는 이름의 접근자를 검색한다. 만약 접근자가 존재하지 않으면 직접 객체에서 일치하는 멤버 변수를 검색한다.
* 예외 상황
키-값 코딩으로 값을 읽으려고 할 때 키 값이 존재하지 않는 경우가 있다. 이럴때는 객체의 valueForUnderfinedKey 메서드가 호출된다. 이 메서드는 기본적으로 NSUndefinedKeyException 예외를 발생시킨다. 만약 존재하지 않는 키를 접근하려고 할 때 자신만의 동작을 정의하고 싶다면 valueForUndefinedKey 메서드를 재정의 하면 된다.
마찬가지로 값을 쓰는 경우도 해당 키가 존재하지 않는다면 setValue:forUndefinedKey: 메서드가 호출된다. 이 메서드도 기본 구현은 NSUndefinedKeyException 예외를 발생시킨다. 예외 대신에 별도의 작업을 진행하려면 setValue:forUndefinedKey 를 재정의 하자.
* 키-값 감시 (Key-Value Observing)
키-값 감시 기능은 객체의 프로퍼티가 변경되는 상황을 감시할 수 있다. 통보와 비슷하게 자신이 감시하고 싶은 키 경로를 지정해서 옵져버로 등록해 두면, 해당 키 경로의 값이 수정되었을 때 메서드를 호출해 준다. 키 경로를 감시하는 코드는 다음과 같다.
위 코드는 objectA 의 enable 이라는 프로퍼티 (키 경로)가 변경될 때를 감시하기 위한 것이다. 감시하는 객체는 self 이다. 그리고 3행에서는 옵션을 지정하게 되는데, 값이 변경되었다는 메서드가 호출될 때 딕셔너리로 전달될 정보를 결정한다. 마지막 4행의 context 는 값이 변경되었다는 메서드를 호출할때 같이 전달된다. 추가 정보를 인자로 전달할 때 사용한다.
이렇게 키-값 코딩 이나 점 표현법을 이용해서 객체의 속성값을 변경하면 그 속성을 감시하고 있는 객체들의 다음 메서드를 호출해 준다.
01: - (void)observeValueForKeyPath:(NSString *)keyPath
02: ofObject:(id)object
03: change:(NSDictionary *)change
04: context:(void *)context
05: {
06: if ([keyPath isEqual:@"enable"]) {
07: for (NSString* val in [change allKeys]) {
08: NSLog(@"%@ : %@",val,[change objectForKey:val]);
09: }
10: }
11: }
전달되는 인자를 보자. 1행은 키 경로가 전달된다. 예제의 경우 “enable” 이 된다. 2행은 값이 변경된 객체가 전달된다. 그리고 4행은 감시자를 등록할 때 지정했던 context 값이 그대로 넘어온다. 이제 3행을 보자. 3행은 변경된 값에 대한 정보를 딕셔너리 형태로 담고 있다. 이 딕셔너리에 포함되는 정보는 다음과 같다.
• NSKeyValueChangeKindKey
• 값이 변경된 형태를 알려준다.
• NSKeyValueChangeNewKey
• 새로운 값
• NSKeyValueChangeOldKey
• 변경되기 전의 값
마지막으로 키-값 감시를 더이상 하지 않을 때는 제거해야 한다. 다음과 같이 간단하게 제거할 수 있다.
접근자는 클래스의 멤버 변수에 접근하기 위한 함수들을 말한다. 클래스를 구현하다 보면 멤버 변수의 값을 읽고, 설정하는 작업이 매우 빈번하다. 객체지향 프로그래밍에서는 데이터 캡슐화(Encapsulation)를 위해서 클래스의 내부 변수를 직접 접근하는 대신 접근자를 이용하도록 하고 있다. 다음을 보자.
enable 이라는 멤버 변수를 접근하기 위한 접근자를 선언했다. 이와 같이 값을 읽기 위한 접근자는 그 변수 이름을 그대로 이용한다. 반대로 값을 설정하기 위한 접근자는 변수 이름의 첫글자를 대분자로 바꾸고 그 앞에 set 을 더한 이름을 사용한다. 이렇게 접근자를 선언하고 구현하면 오브젝트 C의 다른 혜택들을 자동으로 누릴 수 있다. 바로 점 표현법과 키-값 코딩이다. 다음 구문을 보자.
01: theObject.enable = YES;
위 표현이 점 표현법이다. 그런데 이 코드는 사실 다음과 같이 변환되어 처리된다.
01: [theObject setEnable:YES];
그렇다 enable 이라는 이름으로 점 표현을 사용하면 setEnable 라는 이름의 접근자를 호출하도록 미리 약속되어 있는 것이다. 이 내용은 13.3절에서 배울 키,값 코딩에도 똑같이 적용된다.
단순하게 값을 설정하고, 현재 값을 반환하는 일이 전부다. 이처럼 접근자는 아주 편리하지만, 실상 접근자를 구현하는 작업은 거의 비슷한 코드를 반복적으로 작성하는 일이 대부분이다. 그래서 고안된 것이 프로퍼티이다. 프로퍼티는 접근자를 자동으로 생성해 준다. 프로퍼티를 정의할 때 접근자에 대한 속성을 설정해서 접근자가 구현되는 방식을 결정할 수 있다. 위 코드는 다음과 같이 대체가 가능하다.
즉 실제 내부 변수를 언더바(_) 문자로 시작하게 선언한다. 그리고 외부에서 접근할 때는 언더바를 제거한 문자로 접근하도록 하는 것이다. 이렇게 해서 내부에서 접근할 때와 외부에서 접근할 때의 차이를 쉽게 구분하도록 한다.
self.enable = YES; // 접근자를 통한 설정
_enable = YES; // 객체 내부에서 접근
위 코드와 같이 접근자로 접근하는 것과 내부에서 접근하는 경우를 확연히 구분할 수 있다. 이 때 synthesize 에 = 가 사용된 것은 enable 이라는 프로퍼티가 _enable 이라는 멤버 변수를 사용한다는 것을 알리기 위한것이다.
* 프로퍼티 선언
다음으로 @property 에 속성을 설정하는 방법을 알아보자. 코드의 5행을 보면 @property 구문에 readwrite, assign 이라는 속성을 별도로 적용한 것을 볼 수 있다. 이러한 속성을 기술하는 이유는 컴파일러가 접근자를 자동으로 생성할 때 세부 동작 방식을 결정하기 위해서 이다. 예를 들어가며 하나씩 알아보자.
이 코드는 접근자의 메서드 명을 직접 설정할 때 사용한다. 컴파일러는 @synthesize 로 선언한 프로퍼티의 접근자들(getter/setter) 중에서 직접 구현되지 않은 것들을 직접 생성하는데, 이 때 getter 와 setter 이름을 위와 같이 지정해 놓으면 해당 이름을 갖는 접근자를 생성한다. 하지만 특별한 경우를 제외하고는 바꾸지 않도록 하자. 대부분의 경우 접근하려는 변수가 BOOL 형식일때 isProperty 라는 이름으로 getter 를 변경할때 만 사용된다.
01: @property (readonly, assign) BOOL enable;
이 코드는 enable 프로퍼티를 오직 읽기만 가능하도록 설정한다. 즉 setter 메서드를 생성하지 않는다. 그래서 만약 self.enable = YES; 와 같이 설정하려고 하면 컴파일 에러를 발생시킨다. readonly 를 따로 설정하지 않으면 readwrite 를 설정한 것과 같다. readwrite 속성은 따로 기술하지 않아도 기본값으로 적용이 된다.
위 3가지 사용법을 보자. 먼저 nonatomic은 다중 쓰레드에 대해서 고려할지를 선택하기 위한 것이다. 만약 다중 쓰레드 환경에서 여러 쓰레드가 경쟁적으로 접근하는 프로퍼티가 있다면 atomic 으로 설정해야 한다. 하지만 그외의 대부분의 경우 nonatomic 을 사용한다.
다음으로 가장 중요하고 또 가장 햇갈리기도 한 retain, assign, copy 를 보자. 이 3가지 속성은 각각 설정자(setter) 의 동작을 결정한다. 각각을 정리해 보자.
* retain
01: @property (nonatomic, retain) UIImage* img;
위 코드는 retain으로 설정되어 있다. 그래서 컴파일러는 다음과 같은 코드를 만들어 낸다.
4행이 핵심이다. 즉 img 에 새로운 객체를 설정하면, 그 새로운 객체에 retain 을 한번 호출해 준다. 이는 외부에서 그 객체를 release 하더라도 객체가 메모리 해제되지 않도록 유지하기 위한 것이다. 당연히 retain 속성은 Objective-C 객체만을 대상으로 해야한다.
copy 의 경우는 4행에서 처럼 설정하려는 객체의 값을 복사해서 자신이 가지고 있도록 한다. copy 메서드는 기본적으로 retain 을 한번 호출하기 때문에 따로 retain 을 추가로 호출하지는 않는다. copy 는 값을 복사해서 새로운 객체를 만들기 때문에 인자로 전달되는 객체가 자주 변경될 소지가 있는 경우에 적합하다.
copy 의 경우는 Objective-C 객체 중에서도 NSCopying 프로토콜을 따르는 것들만 적용이 가능하다는 점을 주의하자.
* assign
@property (nonatomic, assign) BOOL enable;
assign 은 가장 단순한 방법으로 그냥 값을 대입시킨다.
-(void) setEnable:(BOOL) en {
enable = en;
}
Objective-C 객체를 assign 으로 설정하는 경우는 외부에서 참조 카운트를 감소시켜 객체가 해제될 위험이 있기 때문에 주의해서 사용해야 한다. 그렇기 때문에 assign은 객체가 아닌 BOOL, int 등의 일반 값에 대해서 적합하다.
* 메모리 해제
앞에서 설명한 copy, retain 으로 지정한 프로퍼티들은 그 객체가 해제될때 같이 해제하는 작업이 필요하다. 당연히 copy 와 retain 은 객체에 대해서 retain 을 호출해서 참조 카운트를 증가시키기 때문에, 객체가 해제될 때 같이 release 메서드로 해제해야 한다.
위 코드는 임의의 객체가 UIApplicationDidFinishLaunchingNotification 라는 통보를 발생시키면 self 객체의 launchFinished 를 호출하도록 한다. 코드의 2행과 3행의 인자는 통보가 발생했을 때 호출할 메서드를 지정한다. 여기서 이벤트는 문자열로 구분된다. 그래서 UIApplicationDidFinishLaunchingNotification 도 문자열로 정의되어 있다.
5행의 object 인자는 감시할 개체를 지정하기 위한 것이다. 만약 nil 을 지정하면 모든 객체를 대상으로 이벤트를 감시하게 된다. 만약 5행의 object 를 nil 로 설정하지 않고 특정 객체를 지정해 주면, 그 객체가 일치하는 문자열의 통보를 발생시킬 때만 통보를 받을 수 있다.
removeObserver 메서드로 자신(self)이 더이상 통보를 받지 않겠다고 설정한다.
<그림1> 도움말 문서의 통보 항목
클래스의 도움말 문서를 보면 그 클래스가 발생시키는 통보를 확인 할 수 있다. 예를들어 그림1과 같이 UIWindow 클래스의 도움말을 보자. Notifications 라는 항목으로 자신이 발생시키는 통보에 대해서 설명하고 있다. UIWindowDidBecomeVisibleNotification 와 같은 통보 이름은 클래스의 헤더파일에 문자열로 정의되어 있다.
위 코드가 실행되면 통보 센터는 ObjectX 에서 myEventOccured 통보가 발생했기 때문에, 이 통보를 감시하는 모든 객체의 메서드를 호출해 준다. 이때 감시 객체들은 ObjectX가 전달한 userInfo 딕셔너리 객체도 사용할 수 있다. 이벤트를 통보받는 메시지를 구현해 보자.
어플리케이션이 처음 실행되고 부터 종료될 때 까지의 흐름을 살펴보도록 하겠다. 맥이나 윈도우 모두 그래픽 기반의 운영체제이다. 그래픽 기반의 운영체제에서 어플리케이션을 구현시키는 가장 좋은 방식은 이벤트 드리븐(Event driven)이다. 이벤트는 사용자가 마우스나 키보드를 누르는 것부터 특정 시간이 지났다는 이벤트, 네트워크로 데이터를 받았다는 이벤트 등등 모든 것이 해당할 수 있다. 놀랍게도 세계에서 가장 발전한 상용 GUI OS들인 맥 OS , MS의 윈도우즈 들의 아름다운 UI 밑에는 가장 기본적인 뼈대 Main Loop이 버티고 있다. 사실 컴퓨터 소프트웨어가 하는 일은 최초의 컴퓨터가 발명된 때와 별반 다르지 않다. 그 위에 수만 겹의 추상화가 지금의 컴퓨팅 환경을 만들어 놓았지만, 그 뼈대는 변하지 않은 것이다. 컴퓨터는 여전히 0 과 1밖에 모르는 바보다. 크게 어렵지 않으니 하나하나 익혀나가면서 정복해 보자.
* 처음 시작
사용자가 스프링 보드에 있는 어플리케이션의 아이콘을 누르면 어플리케이션이 실행된다. 다음 코드를 보자.
Xcode 에서 자동으로 생성해 주는 코드이다. 기존의 C 함수와 마찬가지로 아이폰OS 에서 실행되는 프로그램들도 시작점은 메인 함수 이다. 메인 함수는 가장 먼저 자동해제 풀을 하나 할당한다. 자동해제 풀이란 메모리를 자동 릴리즈 하겠다고 설정한 객체들을 임시로 보관해 두었다가 적절한 시점에 해제시키기 위한 저장공간 정도로 이해하고 넘어가자.
다음 코드는 UIApplicationMain 함수를 실행시킨다. 이 함수는 argc, argv 이외에 두 개의 중요한 인자를 받는다. 첫번째로 UIApplication 클래스의 이름을 전달받는다. nil 을 입력하는 경우는 기본값인 UIApplication이 사용된다. 만약 UIApplication 을 상속받아서 새로운 클래스를 만들었다면 그 이름을 넣어주도록 하자. 두번째는 어플리케이션 델리게이트의 이름을 입력하며, nil 일 경우 info.plist 에 정의된 NSMainNibFile이 가리키는 nib파일에 설정되어 있는 델리게이트를 이용한다.
<그림> 어플리케이션 흐름
그림을 통해서 흐름을 이해하도록 하자. 최초 main 이 호출되고 UIApplictionMain 이라는 함수 안에서 UIApplication 클래스가 하나 만들어 진다. 이 클래스는 UIKit8 에서 미리 구현해 놓은 것으로 어플리케이션 자체를 의미하는 클래스이며 한 어플리케션에 오직 하나의 UIApplication 클래스를 가지고 있다. pInfo.list 에서 UIApplication이 사용할 메인 nib 파일을 지정했다면(NSMainNibFile) 이 nib 파일을 읽어들인다. UIKit 프레임 워크는 이 파일을 분석해서 내부에 포함되어있는 객체들을 생성하고 초기화 시킨다. 보통 UIWindow 객체와 UIView 객체 등이 생성될 것이다. 그리고 인터페이스 빌더에서 설정했던 델리게이트나 객체 간의 연결도 설정한다. 이 작업이 완료되면 연결된 델리게이트의 applicationDidFinishLaunching 이 불려진다. 만약 nib 파일이 없는 경우 즉 NSMainNibFile을 설정하지 않은 경우에는 델리게이트의 applicationDidFinishLaunching 가 호출될 때 화면에 보여줄 객체들을 수동으로 만들어 줘야 한다.
그 이후 부터 UIApplication 에서는 이벤트를 처리하기 위한 메인 루프가 실행된다. 사용자가 홈 버튼을 누르거나, 전화를 받는 등의 이벤트에 의해서 어플리케이션이 종료된다. 이 때는 applicationWillTerminate 메시지가 불려지고, 이곳에서 어플리케이션의 상태를 저장하는 등의 작업을 해야 한다.
UIApplicationDelegate 는 지금 설명한 것 외에도 중요한 이벤트가 발생한 경우 그에 맞는 처리를 할 수 있는 다음 메서드들도 있다.
applicationDidReceiveMemoryWarning 메모리 부족 경고를 받은 경우. 현재 사용중인 메모리를 최대한 해제해야 한다. applicationWillResignActive 어플리케이션이 실행중일 때 전화가 오면, 전화를 받을 것인지 무시할 지를 선택할 수 있다. 그 전에 이 메서드가 호출될 것이다. 또한 화면 잠금 버튼을 누른 경우에도 호출된다. applicationDidBecomeActive 사용자가 전화나, 문자 등을 무시하는 버튼을 선택할 경우 다시 어플리케이션이 활성화 된 것을 알 수 있다. 처음 실행될 때 applicationDidFinishLaunching 메시지가 보내진 이 후에도 호출되고, 잠금 상태에서 다시 해제된 경우도 호출된다. application:didFinishLaunchingWithOptions 아이폰 OS 3.0에 추가된 것으로 URL 이나 원격 통보(Remote notification) 에 의해서 어플리케이션이 실행된 경우를 처리할 수 있다. application:didReceiveRemoteNotification 역시 3.0에 추가된 것으로 프로그램이 실행중에 원격 통보(Remote notification)을 받은 경우 필요한 처리를 할 수있다.
02장 설치 및 개발환경 구축.zip
