아이폰 앱 개발기

아직 얼마되지 않아 모르는게 더 많지만,
짧은 시간이나마 아이폰 앱을 개발하면서 느낀 점들을 적어 본다. 
일종의 개발 방법론이랄까...ㅋ

1. 하나의 앱에 UIViewController 와 XIB 는 하나만...
아이폰 앱 개발에서 UIViewController 는 가급적 하나로 제한 하는 것이 좋다는 생각이다.
(특별히 예외적인 경우는 어쩔 수 없지만...)
하나의 UIViewController 에 다수의 UIView를 생성하고 이를  addSubview  하는 것이 맞다는 생각이다.
(이런 개념이 없이 뷰하나마다  Controller  와 XIB  를 생성했더니 나중엔 어디서 뭘 해야 하는지 정신이 없더라는...)

2. 사용자 이벤트(터치) 핸들러는 UIViewController  에 구현
아무 개념이 없을 때, 참 고민스러웠던 것 중 하나가
각 UIView에서 발생하는 터치와 같은 사용자 이벤트에 대한 핸들러를 어디에 만들 것인가 였다.
추상화라는 개념에서 보자면 각 뷰에서 모든 것을 처리하는 것이 맞겠다 싶지만,
실제 이렇게 적용해 보니 여간 불편한 게 아니다.
각 UIView에서 발생한 사건에 대해서 UIViewController 에 어떤 변화를 주어야 할 경우,
각 UIView의 핸들러에서는 자신을  addSubview  한 UIViewController 를 참조할 수 있는 방법이 마땅치 않다.
(방법이 없는건 아니지만 왠지 짝퉁 코드 같은 느낌이다.) 
그렇다고 모든 뷰에  UIViewController  를 선언하고, 해당  UIView를 만들때 마다 이를 설정하는 것도 그닥 내키는 방법은 아니다.

이럴 바에는 차라리  UIView  내에서 발생하는 모든 이벤트를
그  UIView를 addSubview한 UIViewController 로 연결하는 것이 맞다는 생각이 든다.
 
 즉,  
단순 display 는 UIView 에서
이벤트에 대한 처리는 UIViewController  에서....

3. 인터페이스 빌더의 최대 활용.
동적으로 화면 구성이 바뀌는 경우가 아니라면,
아니 그렇다 하더라도 변화의 경우의 수가 그리 많지 않다면, 
각각을 하나의  UIView 로 하고 그 내용(버튼의 배치, 이미지 위치 등등)을 
IB (인터페이스 빌더) 를 이용하여 설계하는 것이 좋다.
물론 코드로 모든것을 다 생성할 수도 있지만, 코드량이 장난이 아니다.
나이 먹으니 타이핑이 그리 귀찮을 수 없다.

4. @property 활용
처음에 저것이 뭐에 쓰는건지 참 난감했다. 
Object-C  가 처음이니 당연하다.
그런데 이놈 참 똑똑한 놈 같다. 
접근자를 자동으로 만들어주니 말이다.
처음엔 괜히 코딩량만 늘어난다 싶어 생략한 경우가 많았는데,
몇줄 생략한 댓가로 수십줄의 코드량이 늘어난다.


 모 건설사 아파트의 홈네트워킹 서버와 클라이언트 앱을 개발하고 있다.
서버는 많이 해오던 일이라 크게 어려움 없이 진행됐다.
그런데 클라이언트인 아이폰 앱 개발은 실질적으로 처음일 뿐더러,
아이폰을 사용해 본적도 없는지라...ㅋㅋㅋ

처음 사용해보는 Mac,
손에 익지 않은 키보드와 패드,
Object-C 의 낮선 생김새, 
ㅋㅋㅋ

항상 그렇듯, 개발은 빡빡한 일정속에 진행되고,
아무튼 어찌어찌해서 마무리 단계에 와 있다.