한글이 포함된 경우 NSURL 객체 생성이 되지 않는 문제에 대한 해결책

지난 주말 그동안 잘 사용하고 있던 XML Parser의 Document가 생성되지 않아 이번주에는 그 부분부터 보고 있다. Debugging을 해보니 XML Document 객체를 만들기 이전에 NSURL 객체 생성을 하게 작성해 두었는데, NSURL 객체 자체가 제대로 생성되지 않고 있었다. (아래의 코드)

더 따져보니 위의 코드에서 urlString 자체는 문제없이 만들어지는데, urlString으로 만들려고 하는 NSURL 객체만 문제가 있었다. NSURL 문서를 살펴보니 RFC 2396을 꼭 지켜야 한다는 문구를 볼 수 있었는데 RFC 2396은 대체 뭔가? RFC는 IETF (Internet Enginerring Task Force)에서 작성한 인터넷 기술에서 지켜야 하는 규칙 등을 작성해 놓은 문서이다. 2396은 그 문서 일부의 일련번호. 찾아보니 URI에 대한 규칙 등을 다루고 있다는 걸 알 수 있었다. 참조한 내용으로 미루어 짐작해보니 한글이 문제가 되는건 아닌가 싶었다. 그래서 임시로 “삼성역” 대신 “abc”를 넣어 돌려보니 정상.


문제는 간단해졌다. 어떻게하면 한글이 포함된 문자열로 NSURL 객체를 만들어낼 것인가만 고민하면 끝. 여기저기 문서들을 뒤적뒤적 거리니 역시 간단한 해결책이…문자열을 인코딩해서 사용하면 된다. (아래 코드 참조)

원래의 코드에 한 줄만 추가했다. stringByAddingPercentEscapesUsingEncoding 호출. Encoding 방법으로 NSUTF8StringEncoding을 지정해주면 끝난다. 추가한 함수는 특수 문자 같은걸 처리하기 위해 encoding을 해서 문자열을 돌려주는 함수. 사용한 encoding은 UTF-8.


빌드하고 다시 디버깅해서 찍어보니 모든게 정상.

디버깅을 생활화하고, 표준 문서 잘 살펴보고 따져봅시다!!




이해를 돕기 위한 Objective-C 문법 (Ch.9)

Chapter 9가 마지막입니다. 몇 주 전부터 느끼던 건데, 제가 보고 있었던 Head First iPhone Development 라는 책이 초심자들이 무작정 따라하면서 흥미를 느끼기에는 괜찮긴 한데 Head First 시리즈가 가지고 있는 특성 (여기저기 낙서하듯이 흐트러져 있는) 때문에 종종 복잡하고 혼란스럽게 느껴질 때가 있었습니다. 또 진도가 나갈수록 새로운 control의 사용법들이 등장했는데, 이런 내용은 어차피 나중에도 참조해야 하는 거라서 chapter 7 쯤 되니까 직접 부딪히면서 배우는게 낫겠다는 생각이 들더군요. 어쨌든 마지막 chapter에서는 고급과정인 카메라와 맵킷을 사용하는 방법이 등장합니다. 시뮬레이터 기반으로 구현했기 때문에 실제로 카메라를 직접 동작시킬 수는 없었지만 Map Kit과 Core Location의 활용은 꽤 흥미로웠습니다.


Flipping

여러 application을 사용해보다 보면 화면전환시의 animation 중에 화면이 뒤집히면서 변경될 때가 있습니다. 이게 flipping 입니다. 이것을 구현하는 방법은 매우 간단합니다. 전환하는 스타일을 flip 하겠다는걸 의미하는 UIModalTransitionStyleFlipHorizontal 상수만 사용하면 되더군요. 물론 몇가지 작업도 해야하지만 보통의 view를 사용할 때와 같습니다.

위의 사용예문을 보면, 우선 CapturedPhotoViewController.xib 파일로 CapturedPhotoViewController의 객체를 생성했습니다. 그리고 생성한 controller의 modalTransitionStyle을 UIModalTransitionStyleFlipHorizontal로 지정해주고 controller를 modal view로 설정해주는 걸로 끝이네요. 간단합니다. 정말. 참 showInfoButtonPressed 는 화면 전환을 명령할 수 있는 button 등을 미리 만들어두고 IBOutlet으로 만들어서 연결되어 있어야 호출이 가능하겠죠.


UIImagePickerController

카메라를 사용하기 위해서는 UIImagePickerController를 이용하면 된다고 합니다. UIImagePickerController를 사용하게 되면 일반 사용자들은 카메라로 사진을 찍거나 라이브러리에서 사진을 선택해서 가져올 수 있게 됩니다. Controller를 생성한 후에 sourceType이라는 속성에 어떤 값을 지정하는냐에 따라 기능을 선택할 수 있는데, 속성값으로는 UIImagePickerControllerSourceTypePhotoLibrary, UIImagePickerControllerSourceTypeCamera, UIImagePickerControllerSourceTypeSavedPhotosAlbum 세가지가 있습니다. 각각은 photo library, camera, photo album에서 이미지를 가져오겠다는 것을 의미하며 복수 선택도 가능합니다. 일반적인 경우처럼 “|(OR)” 를 쓰면 되겠죠. 또 현재 application이 동작중인 device에서 어떤 것을 지원하고 있는지 알고 싶다면, isSourceTypeAvailable 이라는 method를 써서 분기하면 되겠습니다.


AR (Augmented Reality)

최근 유행하고 있는 증강현실을 구현해보고 싶다면 어떻게 해야 하는지 궁금했습니다. 뭔가 복잡할 것 같기도 했고, 구석구석 따져보면 간단할 것 같기도 했는데 카메라로 비치는 실사 자체가 호기심을 자극하기 때문에 그런 혼란을 갖게 되는지도 모르겠습니다. 책에서는 아주 짧게 언급되어 있는데 UIImagePickerController 위에 overlay view를 올리면 된다고 하네요. 이 부분은 관심이 많기 때문에 나중에 자세히 확인해보고 정리할 생각입니다.


이해를 돕기 위한 Objective-C 문법 (Ch.8)

Chapter 8에서도 계속 같은 내용의 application을 개선하고 업데이트 하는 내용입니다. 주로 다루고 있는 내용은 data model에 변경사항이 생겼을 때 Core Data를 이용해서 쉽고 빠르게 처리할 수 있는 방법이구요. 수배자 명단에서 수배자를 검거했다고 선택하게 되면 검거자 리스트에도 해당 data가 표시되는 것까지 처리하고 있네요. 이번 chapter까지 끝내면 심심하지만 원래 의도했던 기본 기능은 갖출 수 있습니다.


Data Model의 변경

기존의 data model을 사용하다가 속성을 추가, 삭제, 변경하고 싶은 경우가 분명히 발생할 것 같습니다. 보통의 경우라면 DB 자체를 다루게 될테니 DB 스키마가 변경됨을 의미하고, 귀찮고 복잡한 작업을 하나하나 해줘야 합니다. 하지만 Data Core를 이용하면 작업이 훨씬 줄어들 수 있습니다. 잘 생각해보면 처음에 Data Core를 사용하기 시작할 때 부터 DB와 관련된 복잡한 작업은 하지 않았었는데, 확실히 이 부분은 편리하다는 생각이 드네요. 아무튼 Data Model을 변경할 일이 생기면 아래의 작업들을 순서대로 해주면 됩니다.

1. 변경할 기존의 data model 선택

2. Design > Data Model > Add Model Version 메뉴 선택

3. 2.과정을 거쳐서 생성된 새로운 버전의 data model 선택

4. Design > Data Model > Set Current Version 메뉴 선택

5. Data Model 변경


Managed Object Context에 data 저장 그리고 취소

data를 저장하기 위해서는 save (commit 한다는 것을 의미), 되돌리고 싶다면 rollback message를 보내라고 되어있습니다. 참 직관적이라는 생각이 드네요. save, rollback, …:)


viewWillAppear / viewDidLoad

지금까지 참 많이 보게 되었던 method 들입니다. 이외에도 몇가지가 더 있지요. View를 표시하는 method들 여러개를 한꺼번에 정리할 필요가 있어 보입니다. 일단 viewWillAppear와 viewDidLoad를 보면 method 이름이 다른 것처럼 의미와 용도에도 명확한 차이가 있습니다. viewWillAppear는 해당 view가 화면에 표시될 때 마다 매번 호출되는 method 입니다. 예를 들어 navigation control을 사용한 application에서 item 한가지를 선택해서 상세 view가 표시되는 경우 viewWillAppear가 호출되고, 원래 view로 되돌아가서 다시 상세 view가 표시되면 다시 호출이 됩니다. 그러므로 매번 호출될 필요가 있는 구문들만 viewWillAppear에 넣어주어야 할 것 같습니다. 반면에 viewDidLoad는 전체 view (xib file)가 메모리에 올라올 때 한 번만 호출되는 method 입니다. 정확히는 load된 직후에 호출되겠네요. 이름에 did가 있으니까요.


이해를 돕기 위한 Objective-C 문법 (Ch.7)

오랜만에 정리합니다. 계속 미루고 있다가 책을 마지막까지 다 보고 나서야 정리할 생각을 하게 되었습니다. 했던거 마무리는 해야 하니까요. 이번 chapter 7에서는 새로운 application을 만드는 것으로 시작을 합니다. 수배자에 대한 정보를 listing 해주는 application 인데, chapter 9 까지 이어지네요. chapter 7에서는 tab bar를 사용해서 수배자와 검거된 사람들의 list를 분리하고 그에 필요한 data 관리는 Core Data로 하는 방법을 알려주고 있습니다. Core Data는 다시 별도로 정리를 해야할 것 같습니다. 꽤 복잡해 보여서요. 물론 직접 DB 관리하면서 쿼리문을 코드에 넣는 것보다는 훨씬 낫겠지만요.


Tab bar icon 추가 혹은 변경

Tab bar에 있는 물음표를 선택하던가 직접 구성요소를 다 펼쳐서 Tab bar item을 선택합니다. 그 이후에 오른쪽의 속성 창에서 Identifier 부분을 Custom으로 변경하고 Image에 넣고자 하는 혹은 바꾸고자 하는 image 파일을 선택해주면 됩니다.

위의 그림처럼 설정하면 끝. 간단합니다. :)


Core Data에서 Entity의 attributes 옵션들

Entity를 새로 구성하려고 attribute 들을 추가하고 수정하다보면 몇 개의 옵션들이 있는 것을 볼 수 있습니다. 그 중에서 Transient는 data를 따로 저장할 필요가 없는 임시 attribute 라는 걸 알려주는 용도이며, Indexed는 Core Data가 index 값을 별도로 만들어 빠른 검색을 가능하게 만들 필요가 있을 때 사용합니다.


Core Data의 세가지 요소

Core Data는 세가지 요소로 구성된다고 책에 언급되어 있습니다. 개인적으로는 entity도 하나의 요소가 되는거 아닌가 싶은데 일단 책에서는 그렇게 말하고 있네요. 세가지는 아래와 같습니다.

Managed Object Context : Data를 관리하는 녀석. Entity로 만들어낸 data model 들도 context가 관리합니다.

Persistent Store Coordinator : 아래 store를 관리하는 역할을 수행합니다.

Persistent Object Store : 용어 그대로 store 입니다. 책의 예제에서는 sqlite 파일이 되겠습니다.


NSFetchRequest

Managed Object Context에게 찾고자 하는 객체를 알려주기 위한 용도로 NSFetchRequest 라는 클래스를 사용해야 합니다. NSFetchRequest를 사용할 때 크게 세가지를 결정해줘야 하는데, Entity Info, Predicate, Sort Descriptor 가 그 것입니다. 어떤 entity를 찾을건지 결정해주고(Entity Info), 충족해야 하는 조건 혹은 검색 조건을 만들어줘야 하구요(Predicate). 조건을 충족하는 data가 있을 경우에 정렬시켜서 뽑을 수 있습니다.(Sort Descriptor)


NSSearchPathForDirectoriesInDomains

책에서 계속 simulator를 사용하고 있기 때문에 실제 device와 약간 차이가 나는 부분들이 있습니다. 그 중에 하나가 DB가 존재하는 위치인데, device와 달리 simulator 사용시에는 다른 디렉토리에 저장이 되기 때문에 별도의 method를 사용해서 DB file을 찾아줘야만 합니다. 그 때 사용하는 method가 NSSearchPathForDirectoriesInDomains 입니다. 이 method의 prototype을 살펴보니 지금까지 보아왔던 Objective C의 method와는 많이 다르네요. C, C++, Java 등에서 흔히 사용하는 method와 같은 모습입니다. (아래의 그림, NSSearchPathForDirectoriesInDomains prototype)

NSSearchPathForDirectoriesInDomains method의 문서를 살펴보니 특정 directory, domain을 위한 경로 문자열을 리스트로 넘겨준다고 되어있습니다. NSSearchPathDirectory와 NSSearchPathDomainMask는 각각 enum으로 여러가지 상수들을 포함하고 있습니다. Chapter 7의 예제에서는 각각 NSDocumentDirectory, NSUserDomainMask를 사용했구요.


NSManagedObject의 생성

예제에서는 NSManagedObject를 context에서 가져오는 것으로 설명되어 있습니다만, 별도로 생성하는 방법도 있다고 합니다. 일반적인 클래스 객체의 생성처럼 alloc, init만 해서 생성하는 것은 안되고 아래처럼 entity에 대한 정보도 필요하다고 되어있네요.

[NSEntityDescription insertNewObjectForEntityForName:@"Fugitive"

inManagedObjectContext:managedObjectContext];


이해를 돕기 위한 Objective-C 문법 (Ch.6)


제 생각엔 가장 길었던 chapter 였던 것 같습니다. 몸이 안좋은 것도 있었는데 토할 정도로 짜증도 좀 나고 그랬죠. 이번에도 어김없이 DrinkMixer를 예제로 사용합니다. 흐름을 보면 소프트 키보드의 등장으로 인해 짤리는 UI, 그리고 그 때문에 컨트롤이 불가능한 것들을 어떻게 처리할 것이냐가 한가지 입니다. 책에서는 예전에도 등장했던 키보드와 관련된 이벤트를 받아서 그 때 마다의 정확한 화면 사이즈(키보드가 포함되지 않은 영역)를 계산하고 새로 만들게 되는 스크롤 뷰에 값을 넘겨 화면이 스크롤 되도록 처리하고 있습니다. 어떻게 생각해보면 키보드가 나타났다 사라지는 것, 그에 따라 화면이 가려지고 스크롤이 되지 않으면 컨트롤이 되지 않는게 당연한데 이런걸 자동으로 처리할 수 있게 제공하면 어땠을까 싶습니다. 사실 당연한 것들을 처리하는 것도 우리에겐 짐이니까요. :) 또 하나 다루는 내용은 이미 만들어져 있는 테이블 뷰에 보여지는 데이터들을 편집하고 삭제하는 기능을 추가하는 방법입니다. SDK에서 제공되는걸 그대로 사용하기 때문에 이 부분은 상당히 편하게 관리할 수 있다고 생각됩니다. 아래는 메모하고 싶었던, 이번 chapter에서 새로 등장한 녀석들입니다.



NSNotificationCenter

예전에도 나왔던 내용입니다만, 이벤트 등록을 위해 사용하는 클래스입니다. 책에서는 아래처럼 사용하고 있네요.


[[NSNotificationCenter defaultCenter] addObserver : self selector : @selector(keyboardDidShow:)

name : UIKeyboardDidShowNotification object : nil];


위의 예문을 잠깐 해석해 보겠습니다. NSNotificationCenter의 defaultCenter를 사용할건데 이벤트가 발생했을 때 전달받을 객체(Observer)는 자기 자신으로 설정하고, 이벤트가 왔을 때 호출할 녀석은 keyboardDidShow라는 method 입니다. 그리고 모든 이벤트가 발생했을 때 알려주는게 아니고, UIKeyboardDidShowNotification 이라는 녀석만 관리할 겁니다. 마지막 어떤 객체가 이벤트를 발생시켰는지는 신경쓰고 싶지 않습니다. (object : nil 부분) 이벤트를 처리하는 부분에 대해서 다시 정리한 이유는 아래 selector 때문입니다. 책에서는 아래처럼 정의하고 있습니다.


- (void)keyboardDidShow : (NSNotification *)notif  {

}


Selector라고 불리우는 것은 C/C++에서 콜백함수와 유사하다고 판단되는데 method 자체는 개발자가 입맛대로 만들면 되는 녀석입니다. SDK에서 제공하는게 아니라는 얘기입니다. Parameter로 NSNotification의 포인터 타입의 notif란 이름으로 받으려고 책의 저자는 생각했나봅니다. 이 parameter는 알아서 전달받게 되겠죠? NSNotification은 userInfo 라는 field를 가지고 있는데 여기에 이벤트에 대한 자세한 정보들이 담겨있어서 책에서는 이 정보들을 이용하게 됩니다.



갑자기 등장한 여러가지 구조체들

소제목처럼 정말 갑자기 여러가지 구조체들이 등장합니다. 전 뭔지도 모르겠는데 갑자기 등장하니까 짜증이 장마처럼 밀려오더군요. 그래서 짜증을 풀고자 xcode에서 document를 불러 내용을 확인해 봤더랬습니다. :)


CGSize

정의 부분을 보면 정말 간단한 구조체입니다. CGFloat type의 width, height 꼴랑 두 개만 멤버로 보유하고 있습니다. CGFloat은 안봐도 float과 관련이 있겠다는 생각이 들어서 확인해보니 역시 아래처럼 정의되어 있네요.


#if defined(__LP64__) && __LP64__
typedef double CGFloat;
#define CGFLOAT_MIN DBL_MIN
#define CGFLOAT_MAX DBL_MAX
#define CGFLOAT_IS_DOUBLE 1
#else /* !defined(__LP64__) || !__LP64__ */
typedef float CGFloat;

LP64가 뭔지는 모르겠지만 아마 CPU data 처리량에 관련된게 아닐까 싶습니다.(64bit) 경우에 따라서 CGFloat은 double형이 되거나 아니면 반쪽짜리 float이 되겠네요.


CGRectValue

이건 구조체가 아니고 method 입니다만 CGRect 구조체를 리턴해주는 녀석입니다.


CGRect

이 녀석은 rectangle의 위치와 dimension 값을 포함하는 녀석이라고 문서에 되어있는데, CGPoint type의 origin과 CGSize type의 size를 멤버로 두고 있네요. origin은 위치일테고 size는 width와 height를 가지고 있는 구조체니 dimension을 의미합니다.



NSSortDescriptor

배열에 있는 data를 정렬할 때 사용하는 클래스입니다. 이 클래스의 객체가 직접 정렬된 data를 보유하는 것은 아니고 이름처럼 정렬을 어떻게 하겠다는 설정값들만 가지고 있는 descriptor 입니다. 예제에서는 아래와 같이 사용하고 있는데요.


NSSortDescriptor *nameSorter = [[NSSortDescriptor alloc] initWithKey : NAME_KEY ascending : YES

selector : @selector(caseInsensitiveCompare:)];

[drinkArray sortUsingDescriptors : [NSArray arrayWithObject : nameSorter]];

[nameSorter release];


NSSortDescriptor 객체를 새로 할당받을 때 NAME_KEY 를 이용해 초기화 하고 올림차순으로 정렬하겠다고 작성되어 있습니다. Selector는 비교방법을 어떻게 할건지 추가 정보를 제공합니다. 예문에서는 대소문자를 구별하지 않고 비교하라고 되어있는거구요. 이렇게 만들어진 descriptor를 가지고 NSArray를 만들고 이를 이용해 실제 drinkArray의 data들을 정렬합니다. 물론 다 사용했으니 release 해줘야겠죠.



이렇게 chapter 6까지 진행하고 보니 몇가지 컨트롤을 다루는 방식에 대해서는 어느정도 이해가 됩니다. 그런데 사실 이 모든걸 다 기억하고 있기란 거의 불가능합니다. 왜냐하면 아직 iphone에 익숙하지 않은 초보거든요. 어차피 어떤 application을 작성하려고 할 때 문서들과 sample 들을 참조해 가면서 작성해야 할텐데, 이런 생각을 하다보면 슬슬 지치네요. 그래도 시작을 했으면 끝을 맺어야 새로운 의욕이 생기게 마련이니 오버스럽게라도 후딱 끝내야겠습니다.