최근 아이폰 어플을 공부하고 개발하고 배포까지 하면서 개발시 꼭 체크하거나 염두해야할 일을 생각나는데로 정리해 보았다. 

 

1. 메모리는 항상 관리한다.

Instruments를 이용해 Memory leaks를 반드시 한다. 특히 View Controller가 전환시, 또는 데이터 통신후에 체크하도록 하는 것이 중요하다. Instruments를 이용하면 완벽하지 않지만 문제를 해결할 수 있는 발판을 마련해준다.

 

또한 Build만 해보지 말고 Build and Analyze를 통해 잠재적으로 메모리 leaks가 생길 부분을 찾도록 한다. 완벽하지 않지만 retain후 release를 안한 부분도 은근히 잘 찾아주므로 꼭 활용하길 바란다.

 

2. 디바이스 테스트는 필수

아이폰 시뮬레이터에서 동작을 잘하던 것이 디바이스에서 테스트 하면 중간에 멈추던가 이상한 동작할 하는 경우가 발생한다. 거의 대부분 이것은 메모리 문제이다. 디바이스는 제한된 메모리이기 때문에 메모리 경고가 자주 일어난다. 또한 이러한 메모리 문제는 View Controller에서 viewDidLoad 메소드를 다시 호출시켜 그에 따른 대책을 마련하지 않으면 어플이 죽거나 이상한 동작을 하게 된다.

 

디바이스에서 테스트는 개발 중간중간 자주 해야한다. 그렇지 않고 시뮬레이터에서만 개발하다가 디바이스에 올린뒤 발생하는 문제를 해결하려면 노력이 배 이상이 들 수 있다.

 

 

3. Memory Warning을 지나치지 말아라.

일단 아이폰 시뮬레이터의 메뉴를 보면 강제적으로 메모리 경고를 줄 수 있다. 그렇게 되면 AppDelegate와 View Controller에서 메모리 경고를 감지할 수 있게 된다. 경고가 발생하면 필요없는 자원을 해제 시키길 바란다. 또한 View Controller에서는 viewDidUnload 메소드가 호출될 수 있다. 이때 self.myView = nil 처리가 되어 있으면 이 객체는 메모리 반환이 되고 나중에 viewDidLoad와 viewWillAppear 호출된다. 이 때 중복된 메소드 호출이나 잘못된 메모리 반환으로 어플이 중간에 중지되거나 이상한 데이터를 View상에 보여주게 된다. 이런 처리도 말끔하게 해주어야 된다. 결국 View Controller의 라이프 사이클을 잘 이해하는 것이 중요하고 그에 따라 대처해야한다.

 

 

4. 인터페이스 빌더를 잘 활용하자.

개발자이기 때문에 인터페이스 빌더를 사용안하고 오로지 코딩으로 뷰배치를 하시는 분들이 있다. 초반에 아이폰 개발때는 이 방법이 좋을 수 있다. 무언가 코드안에서 다 해결할 수 있기 때문이겠다. 하지만 아이폰과 같은 작은 기기의 어플들은 긴 기간의 개발을 요구될 수 없다. 짧은 기간안에 빠른 승부를 내야하는게 바로 아이폰 어플이라고 본다. 뭔가 View 구성을 코드로만 하다 보면 개발자는 나중에 지쳐버린다. 한 페이지 View를 만드는데 만해도 엄청난 노력이 들어가야 한다.

 

인터페이스 빌더를 이용해 ViewController 단위로 만들고 TableView에 보일 Cell들도 만들면 여러분은 어느정도 View 구성하는 스트레스에서부터 해방될 수 있다. 완벽하지 않지만 복잡한 배치를 위해 골머리 쌓는 일에서는 거의 70~80% 해방된다. 게다가 ViewController의 코드도 많이 짧아진다. 왜냐하면 View를 구성하기 위한 코드가 많이 줄기 때문이다.

 

또한 인터페이스 빌더를 이용하면 Command+R 만으로 시뮬레이터에서 View를 미리 볼 수 있다. 이런 것들을 활용하면 개발에 많이 도움된다.

 

 

5. SVN을 이용한 소스 관리를 꼭 하자.

개발하면서 소스관리 툴하나 쓰지 않는다는 것은 사실 말이 안된다. Eclipse와 같은 툴을 다뤄봤던 사람이라면 소스관리를 위해 SVN을 많이 사용했을 것이다. 협업을 위한 것도 있지만 개인적으로 쓰더라도 소스 관리는 반드시 필요하다. Xcode는 기본적으로 SCM 기능이 있어 이것으로 소스관리가 가능하다. Eclipse에 비해서 많이 불편한 편이지만 익숙하면 쓸만하다.

 

6. 최적화에 만전을 기하자.

아이폰은 데스크탑과 다르게 제한된 메모리, 제한된 CPU 기반이다. 그러므로 이런 제한된 환경에서도 부드럽게 동작하도록 노력해야한다. 가령 이미지를 프로세싱 하더라도 cache처리를 해야할지 말아야 할지, Thread나 Operator를 이용해 데이터를 가져오거나 말아야할지 등을 잘 결정해서 개발해야한다. 까페에 문씨님이 올린 Operator 활용법을 참고하면 좋겠다.

 

7. 다양한 장치에서 구동되도록 하자.

애플 개발 정책(?)상 xcode를 배포하면서 번들로 있는 SDK는 항상 최신을 유지한다. 그래서 구버전의 아이폰이나 아이팟 터치에 동작하도록 만들 필요가 있다. iOS 4 기반으로 개발하더라도 약간의 옵션 조정으로 3.0, 3.1 에서도 동작하도록 할 수 있다. 그것은 Groups & Files에서 어플의 이름을 선택한뒤 info에서 Build 탭을 선택한다. 거기서 iOS Deployment Target을 iOS 3.1 등으로 맞추면 가능하다. 물론 SDK 상에서 상위버전시에만 구동이 되는 부분에 대해서는 따로 조치를 취해야 하며 장치 구성상 전혀 사용할 수 없는 부분은 아에 AlertView등으로 알려줘야한다. 가령 카메라의 경우 구형 아이팟터치는 동작하지 않듯이 말이다.

 

8. [myObject release]; 후에는 반드시 myObject=nil 을 하자.

@property로 지정된 속성의 경우 self.myObject = nil 하는 것만으로도 [myObject release];myObject=nil; 이 진행된다. 하지만 속성이 @property로 지정되어 있지 않은 경우에는 self.myObject로 접근할 수 없으므로 release만 할 수 있다. 하지만 [myObject relase];만 하면 문제가 발생할 수 있다. 가령, release를 한뒤 retainCount가 0가 되면 이것은 이제 좀비가 된다. 이 좀비객체에 어떠한 메시지를 보내면 무조건 어플 죽는다. 하지만 myObject=nil 처리하면 nil에 어떤 메시지를 보내도 무시해버린다. 이러한 문제는 좀처럼 눈에 보이지 않게 어플을 죽게하는 요인이 된다. 정상적인 상황에서는 이런 문제가 안생기는데, 디바이스에 물려서 돌리면 어플 죽은 범인이 여기에도 있다. 왜냐하면 디바이스는 제한된 메모리로 waning이 빈번하게 날 수 있고 그에 따라서 viewDidLoad등이 다시 호출되면서 좀비가된 myObject를 엑세스해버리는 현상이 발생할 수 있기 때문이다. release후 다시 새로운 객체로 할당해 retain 하더라도 그냥 버릇처럼 [myObject release];myObject=nil; 이런식으로 하는게 좋다.

 

 

이외에도 많겠지만 일단 생각나는데로 정리해보았다.


글쓴이 : 지돌스타(http://blog.jidolstar.com/724)

스타플(http://starpl.com)에서 새로운 아이폰 어플, 어플지름신(http://itunes.apple.com/app/id406292683)을 내놓았습니다. 

어플지름신은 아이폰/아이팟터치용 어플의 할인/인기/신상 정보를 거의 실시간 단위로 알려줍니다.
또한 스타플과 연동되어 다양한 어플에 대해서 이야기 할 수 있습니다.

아이폰/아이팟 터치 유저라면 한번쯤 다운로드 받아서 사용해보세요. ^^

어플지름신 앱스토어 URL : http://itunes.apple.com/app/id406292683
어플지름신 이벤트 : http://starpl.com/main/event/view/66
어플지름신 앱스토어 주소 QR Code



어플지름신 스크린 샷








개발후기
이 어플은  제 2번째 작품입니다. 저는 아이폰개발만 맡았고 기획, 프로바이더 서버사이드 개발과 디자인 분야를 맡은 사람이 따로 있지요. 총 개발소요는 설계/코딩/테스트과정 모두 포함해 아주 빠듯하게 2주했고요.  앱스토어에 2주걸려 등록되었네요. 한번 중간에 리젝도 당했고요.

아이폰 어플개발에 손을 댄지 3개월정도 되어가는데 그래도 완성품을 이렇게 만들어가니 기분은 좋습니다. 이제 결과는 지속적으로 지켜봐야겠지요. 앞으로도 이런 유용한 어플을 지속적으로 만들어갈 겁니다. 그래서 오늘도 달립니다. ^^

글쓴이 : 지돌스타(http://blog.jidolstar.com/719)


애플이 아이패드를 발표하면서 Flash Player 지원을 공식적으로 거부했습니다.
그 이후로 엄청난 논란이 있는 가운데...
Adobe CTO 케빈 린치는 다음 처럼 의견을 제시했습니다.

Adobe 케빈 린치의 '컨텐츠 및 애플리케이션에 대한 오픈 액세스

아무튼 이런 상황에서 아래와 같은 기사도 올라왔네요.
한번 읽어보시고 각자의 의견을 들어보는 것도 좋을 것 같아요. ^^

---------------------------------------------------------------------

[원문]
http://online.wsj.com/article/SB20001424052748703546004575055184080144688.html


[월 스트리트 저널(Wall Street Journal)]


애플(Apple)의 마이크로소프트(Microsoft)화?


2010.02.09 / 홀먼 W. 제킨스 주니어(Holman W. Jenkins, Jr.)


애플은 증오적 라이벌 관계로 인해 제로섬 전략에 집착하는 회사로 전락할 위험에 놓여있습니다.

현재를 언급하는 것이 아니라 애플의 시가총액이 상상할 수 없는 규모에 달하여 마이크로소프트의 시가총액을 뛰어넘는 해의 이야기가 될 수 있습니다. 당연히 축하 인사가 따르겠지만 위로의 말도 함께 따를 것입니다. 제품 개발에만 전념하는 회사의 경우 전략에 집착하는 회사가 될 위험의 소지가 있기 때문입니다. 그리고 여기서 “전략”이란 증오적 라이벌 관계로 인한 제로섬 전략을 의미합니다.

안타깝게도 현재 우리는 신뢰를 찾기 힘든 타락한 세상에 살고 있습니다.

아이패드(iPad)의 예를 들어보겠습니다. 아이패드는 세상에 공개되자마자 “구세주 태블릿”이라는 별명을 얻었습니다. 아이패드는 상상하지 못할 만큼 탁월한 제품이 아닌 단지 애플이 넷북 경쟁에 뛰어들기 위해 출시한 제품으로, 아이팟 터치(iPod Touch)를 확대해 놓은 버전에 불과합니다. 아이패드는 최상의 웹 브라우징 시스템으로 부각될 수 없을 수도 있습니다. 왜냐하면 애플이 웹 상에서 비디오를 전달하는 데 75% 가량 사용되고 있는 플래시(Flash) 지원을 거부했기 때문입니다. 그러나 아이패드(iPad)(‘지불’이라는 영어 PAID의 철자 순서를 바꾸어 만든 말)는 애플의 온라인 서비스를 통해 판매되고 있는 e북, 음악 및 비디오를 사용하기에는 적합한 디바이스로 보입니다. 단도직입적으로 말하자면 아이패드는 마치 아이튠즈(iTunes) 스토어를 후원하기 위해 최적화된 디바이스로 보입니다.


그렇다면 왜 애플은 플래시를 제외시키기로 결정했는지 궁금하지 않을 수 없습니다. 애플과 애플의 후원업체들은 플래시가 짜증나는 웹 광고를 만드는데 사용되는 제품이라는 미학적이고 철학적인 이유를 내세우고 있습니다.


애플이 플래시를 거부하는 이유는 바로 여기에 있습니다. 플래시를 사용하면 아이폰(iPhone) 및 아이패드 사용자는 아이튠즈를 통하지 않고 비디오 및 기타 엔터테인먼트를 사용할 수 있을 것이고 애플 앱 스토어(Apple App Store)에서만 현재 구입할 수 있는 다양한 기능을 무료로 얻을 수 있게 됩니다.


네트 중립성 옹호자들이나 독점 금지법 집행자들이 스티브 잡스(Steve Jobs)를 연행해가는 오류를 범하지 않도록, 한 가지 덧붙이자면 애플은 플래시를 거부할 수 있는 적법한 권리를 가지고 있습니다. 그러나 한 가지 짚고 넘어가야 할 것은 애플은 엄청난 양의 웹 컨텐츠와 사용자를 분리시키려는 전략적 선택을 내세우고 있다는 점입니다. 플래시가 버그를 부른다는 주장 등에 대해 플래시 옹호자의 시점에서 잠시 벗어나 설명해 보겠습니다. 플래시는 다른 비디오 플레이어와의 시장 경쟁에서 우위를 점하고 있으며 10억 명에 달하는 PC 사용자가 정기적인 업데이트를 다운로드하고 있다는 사실은 엄청난 성공이라고 해도 과언이 아닐 것입니다. Hulu.com에서 TV 프로그램을 시청하거나 MLB.com에서 야구 경기를 보거나 Facebook을 통해 친구와 커뮤니케이션할 때에도 플래시가 필요합니다.


현재로선 플래시를 소유하고 있는 어도비는 최소한 플래시 프로그래머가 애플의 앱 스토어를 통해 자신이 개발한 컨텐츠나 애플리케이션을 제공할 수 있도록 몇 가지 툴을 출시하고 있다고 말하고 있습니다. 이것도 애플의 축복이 있어야 가능할 것입니다. 그러나 애플은 미래의 웹 표준은 독점적인 플래시를 대체하게 될 것이라고 주장하고 있습니다. 이것은 지켜봐야 할 일입니다. 플래시는 현재 전세계 95%의 PC에 설치되어 있어 하루 아침에 웹 표준이 바뀔 가능성은 극히 희박합니다. 또한 파이어폭스(Firefox) 같은 브라우저 제작업체 모두가 애플이 말한 새로운 표준과 생각을 함께 하고 있는 것도 아닙니다.


더 크게 우려되는 바는 여기에 있습니다. 애플이 이러한 무모한 목표로 인해 자사의 모바일 디바이스 사용자층을 확대하여 단지 더 많은 사용자가 아이튠즈만 이용하도록 사용자를 가두는 “네트워크 효과”의 매혹적인 유혹에 무릎을 꿇을 수 있다는 점입니다. 애플은 최근까지 제휴 관계를 유지했던 구글(Google)과 전면전에 돌입했습니다.


지난달 말  애플 직원과의 미팅에서 스티브 잡스가  “지금까지 애플은 검색 시장에서 구글과의  경쟁을 피하기 위해 노력했지만 ‘아이폰  타도’ 를 위해 자사의 모바일 디바이스르  출시했다.” 면서 “사악해지지 말자(Don't be evil) " 라는 구글의 모토를 폄하한 발언이 일파 만파 퍼졌습니다.


구글폰으로 인해 아이폰이 없어지지는 않을 것입니다. 시장은 수많은 모바일 디바이스를 수용할 수 있는 여건을 충분히 갖추고 있습니다. 그러나 실제 위협이 되는 것은 수천만 명의 소비자를 앱 스토어인 아이튠즈만 이용할 것을 주입시킬 수 있는 애플의 능력입니다. 구글이 아이패드가 공개되기 며칠 전 자사의 슬레이트 모양의 디바이스 모델을 발표한 것은 의미 있는 행보였습니다. 구글의 모바일 디바이스는 플래시를 지원하고 있습니다. 애플 사용자가 사용할 수 없는 비디오 및 기타 웹 기능을 사용자가 구매하거나 사용할 수 있도록 했습니다.


애플이 아이폰에서 구글을 대체하기 위해 마이크로소프트의 검색 엔진인 빙(Bing)과 거래를 고려하고 있다는 소문이 돌고 있습니다. 또한 애플이 광고 사업에도 뛰어들어 구글의 서비스와 경쟁하기 위해 클라우드 서비스를 확대할 것이라는 소문도 들리고 있습니다. 어디서 많이 들어본 스토리 아닌가요?


네트워크 효과는 권력과 부를 가져오는 방법이 될 수는 있지만 마이크로소프트의 사례에서 볼 수 있듯이 너무 많은 성과는 특권의 지위를 유지하기 위한 방어적이고 망상적 시도로 인해 물거품이 될 수 있습니다. 회사의 최고 심미가이자 완벽주의자가 더 이상 정상적인 의사 결정을 내리지 못하게 되면 과연 애플은 어떤 회사가 될 것인지 많은 전문가들은 의문을 가지고 바라보고 있습니다. 애플이 점점 더 많은 사용자들에게 아이튠즈 앱 스토어만 사용할 수 있는 질이 나쁜 디바이스를 출시하는 회사로 전락되지 않을까 우려되는 바입니다.
 

+ Recent posts