날아라x2 종이비행기

양질의 국산 App이 나오기를 바라는 개발자중의 한 사람으로 iPhone 개발자가 많아졌으면 하는 바램에 글을 쓰게 되었습니다. 경험이 철철 녹아든 글은 아니지만 나름 심혈을 기울여서 연재를 해보려고 합니다. 아무쪼록 제 노력이 헛되지 않았으면 좋겠습니다.

첫번째 연재로 개발환경을 구축하고 Hello World 프로젝트 만드는 것으로 시작하겠습니다.

우선, iPhone Dev Center에서 iPhone SDK를 다운로드 받습니다.
http://developer.apple.com/iphone/

노파심에 말씀드리지만, Mac 장비가 필요하고 Mac OS 10.5.5에서 정상 동작한다고 합니다. PC에서는 정상적인 방법으로는 개발하실 수 없습니다. 맥북이나 맥미니라도 한 대 장만하셔야 개발하실 수 있음을 명심하시길 바랍니다.

SDK를 다운로드 받기 위해서는 회원가입이 필요합니다. 회원가입시 입력하는 개인정보는 차후 iPhone Developer Program 가입시 오류가 생기지 않도록 정확하게 입력하는 것이 좋습니다. 회원 가입후 로그인하면 비로소 SDK를 다운로드 할 수 있게 됩니다.



글을 쓰고 있는 현재 iPhone OS 2.2까지 출시되어서 2.2 버전을 설치하고 있습니다. 기존에 설치된 상태에서 업그레이드를 해야할 경우에도 설치만 하면 기존 버전을 제거하고 재설치하니 그냥 설치하시면 됩니다.



연이어 약관이 출력되는데 계속 진행하시면 됩니다. 시간이 좀 되시면 읽어보시는 것도...


기본 설정대로 설치하면 되겠습니다. 설치가 완료되면 /Developer/Applications에 Xcode와 그 형제(Dashcode)를 찾으실 수 있으니 이 아이콘을 대시보드에 등록해두고 쓰시면 편리하겠지요?

iPhone 개발을 한다면 항상 보게될 Xcode 입니다. 세련된 아이콘 만큼이나 개발 환경도 비교적 편리합니다. 다만, 탭 기능만 있었다면 더할 나위 없었을 텐데 하는 아쉬움이 있기는 합니다. 언젠가 생기겠죠?

이제 실행해보겠습니다. Xcode 아이콘을 선택해서 실행하시면 다음과 같은 Welcome 화면(Xcode News)를 보실 수 있는데, 귀찮으시면 저처럼 Show at Launch에 체크를 해제해두시고 소식이 궁금하실 경우에만 Help - Xcode News를 이용해서 보시길 바랍니다.


설치는 모두 끝났습니다. 이제는 개발자라면 누구나 다 아는 Hello World 프로젝트를 하나 만들어 볼까요? 시시해 보이긴 해도 보통 이 프로젝트 하나가 그 개발 환경에 대한 이해력을 높히는데 큰 도움이 된다고 생각합니다. 그래서 저 또한 Hello World로 시작하겠습니다.

Xcode News를 닫고 File - New Project..를 선택하여 새 프로젝트 창을 열어보겠습니다.


그림처럼 View-Based Application을 선택하고 Coose... 버튼을 클릭합니다.


프로젝트명은 HelloWorld로 입력하고 Save를 합니다. 그러면, View-Based Application인 HelloWorld 프로젝트가 생성됩니다. 아마 아래 그림과 비슷한 모양으로 생성이 될 것입니다.


왼쪽 상단에 Device - 2.2라고 그림에는 나와 있는데 지금은 시뮬레이터로 테스트할 예정이므로 Simulator로 시작하는 것 중 적당한 버전으로 선택하시면 됩니다. 그리고 나서 일단 Build and Go를 해보겠습니다. Build and Go 버튼을 클릭하시거나 CMD + ENTER로 실행이 가능합니다.


iPhone Simulator 테두리가 잘렸군요. 저와 같은 결과물을 얻으실 수 있으실 겁니다(테두리가 잘린 것은 제외하고...). 실행이 안되신다면 처음부터 다시 시도해 보세요(그렇다고 SDK까지 새로 설치하실 필요는 없으실 겁니다).

실행되는 것을 확인했으니 종료 버튼을 클릭해서 프로젝트 실행을 중지하고 화면을 좀 수정해보겠습니다. 종료 버튼은 이렇게 생겼습니다.


Xcode 좌측 Overview 영역의 Resources를 보시면 HelloWorldViewController.xib가 있습니다. 확장자 xib는 Interface Builder(이후 IB로 줄이겠습니다)로 생성되는 파일입니다. HelloWorldViewController.xib를 더블클릭 하시면 IB가 실행됩니다.




View를 더블클릭하시면 다음과 같은 황량하고 암울한 화면을 보시게 됩니다. 이제부터 할일이 좀 있습니다. 이 화면을 적절히 채워넣는 임무가 생겼습니다. 여백이란 가끔 공포를 느끼게 합니다. 어떻게 채워줄지 고민하게 만들죠. 이번에는 별 생각 없이 Hello World 이 두 단어만 넣겠습니다.


IB가 실행될 때 몇가지 창이 더 뜨게 되는데 그중 하나가 Library창 입니다. 이 창은 View를 만들기 위해 사용되는 기본적인 컴포넌트를 사용하기 위한 공간 입니다. Hello World 글자는 Label을 이용할 예정이므로 Label을 선택한 후 황량한 View에다가 Drag-and-Drop시킵니다. Drag-and-Drop 용어를 모르신다면 지식X에다가...




그런데 아무리 해도 중앙 정렬이 안되시죠? Label의 크기는 마우스로 조정 가능하지만 정렬은 Label 속성창에서 제어할 수 있습니다. IB가 뜰 때 함께 뜬 브라더스 중 하나가 그 역할을 합니다. 없다면 Tools - Inspector를 이용해서 보실 수 있습니다. 탭이 여러개 있는데 첫번재 탭이 Attributes Inspector 입니다.


속성창에서 Layout으로 된 부분을 보면 많이 보셔서 아실 겁니다. 정렬 아이콘. 그에 맞게 화면이 변하니 맘대로 변경해 보시길 바랍니다. 이제 변경이 끝났습니다. 좀 실망스럽죠? 그래도 처음부터 복잡하면 너무 어려우니 이정도로 마무리하는 게 좋을 듯 합니다. 문구는 Hello World라고 하셔도 좋고 맘에 드는 문구로 바꾸셔도 저는 할말이 없습니다.

이제 실행해봐야겠지요? IB에서 CMD+S로 저장하시고 Xcode에서 Build and Go를 합니다.


썰렁하지만 그래도 좀 나아 보입니다. 아니라구요? 그렇다면 좀 전에 Library 창에 있던 다른 컴포넌트를 맘대로 넣어보세요. 마구 넣는다고 맥이 insanelymac이 되지는 않습니다. 아, 영어 좀 한다고 하시면 insanelymac.com에도 유용한 정보들이 꽤 많습니다. 참고하세요.

자, 이제 끝났습니다.
아니, 이제부터가 시작입니다.
천천히 조금씩 시작해보세요. 아직 Objective-C에 대해 들어본 적도 없다면 먼저 Objective-C의 기본 개념부터 찾아서 공부해두시기 바랍니다. 구글링 해보시면 한국어로 된 멋진 PDF 문서도 검색하실 수 있으실 것입니다.

농한기라 고요한 겨울 시골에서 갑갑한 마음을 잠시라도 잊어버릴 수 있었습니다.

예정대로 iPhone, iPod Touch OS 2.2가 나왔습니다. 몇가지 성능 향상과 추가된 기능이 있으나 그동안 비 영어권 사용자에게 불편했었던 자동고침에 대한 설정 옵션이 추가된 것이 가장 반가운 소식입니다.
아직 업데이트 안하셨다면 어서 업데이트를...^^

올해 초 얼음이 꽁꽁 얼어 있을 때 나홀로 출사를 다녀왔었는데, 무지 추웠던 기억밖에는 없습니다.
시간이 되면 겨울 출사를 다시 한 번 가보고 싶군요.

겨울 문턱의 갈

아시다시피 SQLite는 오픈소스며 무료로 제공되는 로컬 DB 중 하나입니다. 빠르고 단순하면서도 SQL을 이용할 수 있어서 개발자들이 좋아할만한 로컬 DB라 하겠습니다. 최근 많이 사용하고 있는 Firefox의 데이터저장소(쿠키, 폼정보 등등)로도 사용되고 있더군요.

상용 DBMS의 경우에는 DB 관리툴이 있어서 편리하게 스키마를 생성하고 데이터를 입출력하면서 개발을 할 수 있었는데, SQLite는 기본적으로 지원되는 툴이 없어서 셸에서 직접 SQL을 입력해가면서 개발하는 불편함이 있었습니다. 그러나, 구하면 얻는다고, Firefox 브라우저의 플러그인으로 SQLite Manager라는 것이 있었습니다.

바로 설치해서 실행해보니 그동안 불편했던 점을 대부분 해소할 수 있었습니다. 설치하는 방법을 간략하게 소개하고 과정을 스크린 샷으로 대체할까 합니다. iPhone 개발에 많은 도움이 되기를 바라면서...
















그림만 보셔도 무엇을 할 수 있는 툴인지 아실 것입니다.
이것만으로도 개발 생산성이 10%는 향상되지 않을까 싶습니다.

너무나 추웠던 날, 정타임과 함께 정신없이 사진만 찍어대다 부들부들 떨면서 떡볶이를 먹던 기억만 납니다.
주머니에 있던 초코바는 꽁꽁 얼어서 먹을 수도 없는... 그런 말도 안되는 상황이었으니...

제목은 거창하게 시작하긴 했지만 내용은 모두들 알고 계시는 것일 수 있습니다. 저의 개인적인 개발 경험(뭐, 길지는 않습니다^^)을 통해 얻게된 지식을 정리하는 정도로 많이 부족할 수 있으니 눈을 버리고 시간을 버리기 전에 미리 양해를 구햡니다.

iPhone은 Mac OSX용 애플리케이션을 개발용 XCode에 iPhone SDK를 이용하는 방식으로 개발을 하게 되어있습니다. 결국, Objective-C 언어를 바탕으로 Cocoa라는 UI 관련 프레임워크를 iPhone에 맞게 변형시킨 Cocoa Touch라는 프레임워크를 제공하게 됩니다. 이는 기존의 Cocoa를 대부분 계승한다는 의미로 개발 패턴도 기존과 동일하다는 점을 보여준다 하겠습니다.

최근 수년간 웹개발에서 논의되어 왔고 이제는 어느정도 정착단계에 들어간 MVC 패턴은 Mac 및 윈도우즈 애플리케이션에서는 이미 많이 사용되어 왔었습니다. 별로 새로울 것도 없는 개발 패턴이기는 하지만 여전히 이를 잘 지키기는 쉽지가 않습니다.

iPhone 개발을 시작한지는 얼마되지 않았지만 개발하면서 나름대로 iPhone에 맞게 개발 패턴을 만들어두고 그에 맞춰서 개발하는 것이 생산성 향상에 도움이 될 듯 하여 글로서 정리해보려 합니다. 아직 경험 부족으로 부족한 부분이 있겠지만 개인적인 용도로 사용하고자 정리하는 것이라 또 한 번 양해를 우선 구합니다.

MVC?
약자를 풀어보면 Model - View - Controller가 되겠습니다. 귀에 딱지가 앉을 정도로 많이 들으셨을 것입니다. iPhone 개발을 하면서 느끼는 것이지만 Model은 어느정도 명확하게 구분해서 개발을 하게 됩니다. 그러나, View와 Controller는 경계가 다소 모호하더군요. 여기서 말하는 뷰는 xib 또는 nib 확장자를 가진 IB(Interface Builder) 파일이 아닙니다. 그걸 지원하기 위한 또는 UI를 그리기 위한 .m 확장자를 가진 소스를 이야기하는 것입니다.

UITableView를 예로 들겠습니다. View 소스들은 보통 UIViewController를 상속해서 사용하게 됩니다. 여기에 UITableView를 얹었다(IB를 사용하든 직접 코딩을 하든)고 하겠습니다. 그러면, UITableViewDelegate, UITableViewDatasource 프로토콜을 구현하게 됩니다. 그러면, 테이블을 출력하기 위해 데이터를 어디에서 가져오게 될까요? Controller에서 데이터를 만들어서 Model 객체(들)을 테이블(View)로 전달해야하겠죠?
그런데, 여기서 문제가 생깁니다. 보통, UIViewController를 구현한 클래스(명칭이 애매해서 그냥 [View소스]라고 하겠습니다)에서 그 작업을 해버립니다. 왜냐하면, 현재 [View소스]에서 바로 접근할 수 있는 IBOutlet 변수들이 존재하고 IBAction으로 호출된 위치가 바로 [View소스]이기 때문입니다. 귀차니즘 또는 처음에는 별 기능없이 액션을 처리한다고 생각하게 되지만 개발이 진행되면서 그 코드량이 점점 많아지게 됩니다. 결국, [View소스]에 방대한(?) 비즈니스 로직이 생겨버리게 됩니다. 단적인 예이기는 하지만, 저의 경우는 이런 문제가 가끔 생기는 것을 보게 됩니다.

그래서 위와 같은 그림을 그리게 되었습니다. 그림을 설명하자면...

xib와 관련된 View 클래스가 하나씩 존재합니다.
하나의 MainWindow.xib는 하나의 MainViewCtrl을 갖게 됩니다. 물론, XCode에서 Window Based project로 생성하면 모든 delegate는 {PRJ NAME}AppDelegate에서 처리하게 됩니다. 그러나, 여기서부터 문제가 시작이 됩니다. 아, 우선 기본적으로 생성되는 소스를 보면 설명한 것처럼  AppDelegate 앞에 프로젝트명이 붙습니다. 이거 별로 보기가 좋지 않아서 리네이밍을 한후 IB에서 MainWindow.xib를 열어서 App Delegate 클래스명도 바꿔줍니다. 그러면 별 문제없이 단순한 AppDelegate 클래스명을 이용할 수 있습니다. AppDelegate *app = [[UIApplication sharedApplication] delegate];처럼 클래스명을 단순하게 하면 언제 어디서든 깔끔한 코딩으로 메소드를 호출할 수 있으니까요.
AppDelegate에서 문제가 생기는 이유는 여기에 비즈니스로직, UI 처리 액션, UI 관련 IBOutlet 변수 등등... 코딩의 대부분을 여기서 하는 불행한 사태가 발생할수도 있습니다. 그래서, 저는 AppDelegate에는 비즈니스로직만 담으려 노력하고 나머지는 MainViewCtrl이라는 클래스를 하나 더 만들었습니다. 여기에서 실행하면서 처음으로 접하게 되는 화면인 Root View(or Main View) UI를 처리하는 액션이나 IBOutlet 변수를 정의 및 실행하도록 하고 있습니다. 물론, 새로 만든 MainViewCtrl을 정상적으로 동작시키기 위해서는 UIApplication과 관련된 delegate 이외에는 모두 MainViewCtrl로 향하도록 선연결 작업을 해줘야 합니다(물론, IB에서). 또한, 대부분 Window 앞에 UIViewController를 하나 얹게 되는데 여기 클래스명을 MainViewCtrl로 바꾸는 것도 잊으시면 안되고, AppDelegate에서도 MainViewCtrl IBOutlet 변수를 하나 만드셔서 IB에서 MainViewCtrl과 연결을 해둬야 그 변수를 정상적으로 이용 가능하게 됩니다. (예를 들어가면서 설명하면 더 이해가 편하시겠지만 지금은 나름 정리하는 중이라 시간이 나질 않아서 죄송합니다.)

Model 인스턴스 초기화는 AppDelegate를 이용합니다.
iPhone에는 SQLite라는 걸출한 데이터베이스를 내장하고 있습니다(구글 안드로이드로 그렇다죠? 빠르고 간편하고 오픈소스라 그런가 봅니다. 써본 결과로 sqlite 기본 라이브러리로 개발하기엔 불편한 점이 많고 FMDatabase라는 래퍼 라이브러리를 이용하면 JDBC와 유사한 방법으로 사용할 수도 있습니다. 일부 오버헤드는 있겠지만.).
저같이 Productivity나 Entertainment 관련 개발을 좋아하시는 분(게임을 제외한 대부분의 분야가 해당될 수도 있겠죠.)은 벌써 SQLite를 이용해서 개발해 보셨을 것입니다.
일반적으로 데이터베이스를 사용하기 위해서는 접속(Connection)이라는 과정을 거치게 됩니다. SQLite는 로컬 파일을 기반으로 입출력하기 때문에 네트워크 접속과 같은 문제로 접속 부하가 생기지는 않습니다만, 접속을 시도할 때마다 DB 파일을 열어서 스키마와 통계정보를 갖고 있는 딕셔너리를 메모리에 올리는 과정이 발생할 것입니다. 이과정에서 오버헤드가 분명 생기리라 봅니다. 그래서, Apple에서 제공하는 샘플(SQLiteBook)을 보시면 아시겠지만 DB 접속은 AppDelegate에서 1회만 발생합니다.
App이 초기화되는 AppDelegate의 init 메소드에서 접속을 맺고 dealloc에서 접속을 종료하는 형태로 App이 동작하는 동안에는 1회만 접속을 맺도록 하는 것이 좋겠습니다. 그러나, DB 동시 처리를 해야할 경우에는 고려를 해야합니다. iPhone은 동시에 1개의 App만 동작되도록 설계가 되어 있어서 지금 동작하는 App 내에서만 동시 처리가 없다면 문제가 없긴 합니다. 이렇게 1회 접속한 포인터(pointer)는 AppDelegate의 변수에 두고 이를 공유하는 형태로 사용하면 됩니다.
App을 개발할 때 모델 클래스에는 CRUD를 모두 처리할 수 있도록 구현하게 됩니다. CRUD를 처리하기 위해서는 DB 접속 포인터가 필요할 것이고 이걸 AppDelegate에서 지원하는 형태로 하면 편리하게 사용할 수 있습니다.
Factory Pattern처럼 newEmployee와 같은 메소드를 호출하면 DB접속 포인터가 주입된 새로운 모델 인스턴스가 반환되게 되면 DB 접속 포인터를 어떻게 주입해야 하는 가에 대한 고민은 모두 사라지게 될 것입니다. 물론, 데이터의 목록(모델 객체의 목록)을 요청할 경우에도 마찬가지로 AppDelegate를 활용해서 DB 포인터를 가진 상태로 반환하면 됩니다(물론, 반환은 NSArray, NSMutableArray에 담긴 모델 객체 정도겠지요.).

AppDelegate 1개만 사용하는가?
그건 아닙니다. 비즈니스 영역별로 분리해서 클래스를 만들고 이를 미리 초기화 하던지 필요할 때 초기화해서 쓰던지 간에 AppDelegate를 경유하도록하면 됩니다. 어떤 UIViewController 클래스든 AppDelegate *app = [[UIApplication sharedApplication] delegate]; 코드를 이용하여 AppDelegate를 접근할 수 있기 때문에 비즈니스 객체의 메소드 호출 관문으로 활용하면 될 듯 합니다.

참고로, 그림에는 없지만 Icons라는 group은 Resources의 서브 그룹으로 들어가 있어서 각종 Icons을 담아두는 용도로 사용이 됩니다.

현재 개발하고 있는 App은 이 패턴을 따라 개발하고 있습니다. 지속적인 수정 보완이 필요하기에 이 문서도 지속적으로 업데이트할 예정입니다. 부족한 글 끝까지 읽어주셔서 고맙습니다.