이럴 경우 android.app.Service를 상속하여 서비스를 만들고 이를 manifest 파일에 추가하고 적절한 시점에 Activity.startService를 불러 서비스를 띄우면 된다.

순진한 접근으로 이를 해결하려하면 Service.onStart 메서드에서 Thread를 하나 만들고 해당 Thread 속에서 주기적으로 서버자원을 체크하다 변동이 있을 경우 notification을 주고, onDestroy에서 스레드를 종료시키면 끝이다.

그러나

폰별로 시간 차이가 있을 수 있겠으나, 내 Motorola Droid에서는 스크린이 꺼지고 폰이 IDLE 상태가 된지 15분이 지나면 배터리 절약을 위해 Wi-Fi를 비활성화 한다. 효율적인 방법이라고 생각한다. 하지만 개발자가 원하는 것은 아니다.  15분동안 주고 받은 패킷이 전혀 없어야 꺼지는 게 아니라 패킷을 계속 주고 받든 말든 어찌됐든 15분 후면 Wi-Fi가 비활성화되고 2G 혹은 3G로 절체되기 때문이다.

만약 당신이 원하는 것이 매 1분마다 HTTP 연결을 만들어 자원을 확인하고 연결을 종료하는 것이라면 크게 문제가 안될지도 모른다. 그저 2G/3G 망으로 바뀌어 재요청을 날리는 것이므로, 네트워크 절체도중 요청을 날리지만 않으면 아무런 문제없이 계속 요청을 보내고 응답을 받을 수 있기 때문이다.

그런데 2G/3G를 사용하면 배터리를 적게 소모하는 대신 ‘돈’을 쓰게 된다. 사용자는 이것을 원하지 않을 수도 있다. 이런 경우 android.net.wifi.WifiManager.WifiLock를 사용하여 서비스가 활성화중일 때 WifiLock을 잡아 Wi-Fi를 끊기지 않게 할 수 있다. 물론 더 많은 배터리를 소모하기 때문에 사용자에게 알려줘야할 필요가 있을 것이다. (Setting 등으로)

문서에도 나와있지만, 여러분이 만든 앱이 락을 잡지 않더라도 다른 앱이 락을 잡고 있으면 Wi-Fi는 끊기지 않는다. reference count라고 보는 편이 좋겠다. OS가 WifiLock reference acount를 주시하고 있다가 0보다 크면 끄지 않고 0이 되면 끄고.

여기까지하면 다 된 기분이 들지도 모른다. 아니다. 30분~1시간동안 사용자의 활동이 없으면 배터리 절약을 위해 CPU도 동작하지 않게 된다. 이럴땐 android.os.PowerManager.WakeLock이 필요하다. 백그라운드 서비스의 경우 스레드가 계속 돌기만 하면 되므로 스크린이 꺼지지 않도록 SCREEN_BRIGHT_WAKE_LOCK, SCREEN_DIM_WAKE_LOCK 같은 것을 잡을 필요는 없고, 그저 PARTIAL_WAKE_LOCK 을 잡아 CPU 동작이 멈추는 것만 방지하면 된다.

그런데 이것들이 왜 ‘주의사항‘ 인걸까?

안드로이드 폰에 기본탑재된 Google Talk이나 각종 background sync들을 비활성화하지 않았다면 당신이 CPU WakeLock을 잡지않아도 Google Talk이나 다른 녀석들이 잡아주기 때문에, 테스트 할 때 이런 사항들을 알아내기 어렵기 때문이다.

이런 것들을 다 적용하더라도 여전히 주의할 점이 있다. 당신이 만든 앱만 깔면 배터리가 미친듯이 빨리 소모된다고 고객이 화를 낼지도 모르니 Setting에서 이러한 사항들을 고객이 조정가능하게 해줘야 함을.

물론 android.permission.WAKE_LOCK이 필요함을 잊지 마시고.

Force Close!

J2ME/SE 에서는 UI Thread (Event Dispatch Thread)가 작업을 처리하다 예외를 만나도 결코 어플리케이션이 죽지 않는다. 데스크탑의 경우 콘솔에 stack trace가 출력되고 해당 이벤트 처리만 안될 뿐이다. 예를 들어 버튼을 눌렀을 때 ActionListener.actionPerformed 에서 divided by zero를 만나면 콘솔에 예외가 출력될 뿐이지 앱이 죽는 경우는 발생하지 않는다.

그러나 Android 플랫폼에서는 UI Thread가 이벤트 핸들러를 실행하다 예외를 만나면 어플리케이션 전체가 주저앉는다. 어찌보면 앱 전체가 죽는 것이 옳다. 예외는 적절히 처리되어야만 하는 녀석이 맞기 때문이다. 하지만 기존 자바 UI 개발자들은 이러한 상황에 익숙치 않다.

안드로이드 기기에는 이러한 예외들을 볼 수 있는 기본 콘솔이 없다. USB Debugging을 켜고 logcat을 띄우면 force close를 일으킨 예외를 볼 수 있지만, 간헐적으로 발생하는 예외인 경우 개발자조차도 항상 USB Debugging을 켜두고 있지 않기 때문에 stack trace를 볼 수 있는 방법이 없다.

java.lang.Thread 에 좋은 메서드가 있다. setDefaultUncaughtExceptionHandler가 바로 그것이다.

코드를 블로그에 붙여넣는 것을 싫어하므로, stackoverflow의 How do I obtain crash-data from my Android application? 글만 링크하겠다.

주의할 점은 Thread의 기본 UncaughtException 핸들러를 제거하지 않는 것이다. 앱이 죽는 게 싫다고 새 핸들러에서 예외를 무시해버리면 다음줄에서 예외가 발생하게 되니 점점 더 원인을 찾기 힘들어지기 때문이다. 예외를 만나면 Throwable.getStackTrace()로 StackTraceElement[]를 뽑아 적절히 가공하여 SD Card에 저장하거나 개발자의 서버로 전송한 뒤 기존 UncaughtException 핸들러를 불러 꼭 앱을 ‘죽여’주자.

그런데 한가지 주의 사항이 있다. 예외가 간헐적으로 발생하고, 개발자가 앱을 빈번히 업데이트하는 경우 stacktrace의 결과가 current codebase와 틀려지는 문제가 생겨서 오류가 발생한 정확한 위치를 파악하기 힘들어지는 문제가 생긴다.

내 경우 마켓에 릴리즈 할 때마다 git 커밋로그에 릴리즈 버젼넘버를 포함시키고, force close 로깅할 때 앱의 버전 번호를 함께 넘긴다. 그러면 예전 버전의 앱에서 오류가 보고됐을때도 혼란에 빠지지 않을 수 있다.

stack trace를 네트워크로 전송하고자 한다면 android.permission.INTERNET이 필요함을 잊지 마시고.

지난달 중순에 UK £1.0 유료앱으로 올렸었고, 하루에 3~6개씩 3주에 걸쳐 총 100카피가 팔렸다. feature도 거의 없고 버그도 많았던 유료앱이 100개나 팔렸다는게 신기할 따름이다.

그렇지만 3주에 100카피는 너무 적다고 생각한다. 비록 유료앱 런칭했던 시점에는 블로그 운영도 안했고 (지금은 앱전용 영문 블로그를 운영하고 있음) 어떠한 형태의 홍보도 하지 않았지만 말이다.

그러던 일주일 전, 무료로 바꿔보면 어떤 일이 일어날지 궁금해졌다. 그래서 잠깐 무료로 바꿔봤다. 그리고나서 엄청난 사실을 깨달았다. 유료앱의 가격을 바꾸거나 유료앱을 무료앱으로 바꾸는건 승인없이 개발자 맘대로 할 수 있지만, 한번 무료앱으로 바뀐 앱은 유료앱으로 영영 바꿀 수 없다는 사실. 어찌보면 당연한 것인데, 그래도 Google android market 정도면.. javascript confirm 창으로 알림 정도는 줄 수 있는 거 아니였을까?

그래서 pro 버전을 만들어야겠다는 생각이 뒤따랐다. Free 버전에는 광고를 넣어야되나.. 이런저런 생각이 나를 괴롭힌다.

하지만 일단 제품이 좋아야하지 않겠나. 그래서 품질을 올리기 위해 지난 일주일동안 업데이트를 15번쯤 했다. 덕분에 안정성도 유료앱시절보다 훨씬 좋아졌고 영어, 프랑스어 등으로 날라온 고객의견메일들도 일일히 제품에 반영하여 회신하고.. (Google Translate 덕에 프랑스어로 온 메일도 프랑스어로 회신할 수 있게 됐다 ㅋ)

해서 3주동안 100개 팔렸던 앱을 무료로 바꾸고나서 1주일만에 5,000개가 나갔다. Google android market은 유료앱 구매후 24시간내 묻지마 환불정책이 있어서, 사람들이 일단 다운로드하고 맘에 안들면 바로 환불하겠지 생각했었는데.. 잘못된 생각이였다. 하루에 5개 다운로드되던 앱이 어찌 하루에 600개가…

기본 기능들에 대한 지원과 메신저 앱의 생명인 안정성 확보가 끝나고나니, i love this app! 하며 날 기쁘게 만들어주는 고객들이 생기기도 하지만, 화상채팅 지원해달라, 파일전송은 왜 안되냐, Nudge(창 흔들기)는 왜 안되냐, 자기 girl friend가 dark theme을 안좋아하는데 테마 지원 기능은 언제 들어가냐..  등 요구사항들도 계속 들어오고 있다. 괴테의 말대로, 서두르지 말고 그러나 쉬지 말고 전략만이 유일한 방법이다.

경쟁앱도 무시할 수 없다. 나같은 무료 MSN 앱이 이미 4개가 있고, 모두 다 나보다 시장에 먼저 들어간 앱들이라 다운로드수도 어마어마하다. 게다가 통합메신저로 유명한 Meebo와 eBuddy, IM+도 마켓을 지키고 있다. 하드코어 게임하는 기분으로 하나씩 하나씩 다 밟는 수 밖에 없다. 성공하려면.

획기적인 아이디어를 기반으로 새로운 마켓을 형성하는 것은 나같은 일개 개발자가 할 수 있는 일이 아니다.  이미 잘 형성된 마켓에 들어가 피터지게 싸워서 1등이 되는 수밖에 없다.  그러다 지치면 재미난 아이디어로 조그마한 앱 만들며 기분전환하고.. 하는게 개발자의 삶이 아닐까.

제품이 아직 맘에 안들어서 블로그에 홍보는 못하겠다.

갑자기 이런 류의 책으로 관심이 되돌아간 이유는, 최근 무리한 일정을 소화하기 위해 나름 내 의지로 할 수 있는 최선을 다 했음에도 불구하고 내 예상과 내 결과물이 판이하게 달랐기 때문이다. 그동안은 게을러서 계속 스스로의 태도를 탓하며 (열받거나 짜증나서 스스로를 케어할 수 없게되면 남탓하기도 하지만 ㅋ)  어떻게 더 좋은 태도와 개념을 탑재해야될지 고민했었는데, 나름 한다고 했는데도 자꾸 오류가 보이니 더이상 태도만 탓할 수 없겠다는 생각에서이다. 이제 마스터 요다와 괴테와 니체의 가르침을 잠시 뒤로하고 과학서로 피신한다.

최근 내가 맞이한 어려움은 다음과 같다. 해야할 일의 개수가 많다. 그런데 각 할 일들의 난이도는 높지 않다. 물론 여태까지 써보지 않은 플랫폼도 있었지만, 개념이 같고 API 사용법만 다른 경우라면 잘 설명된 문서를 통해 어렵지 않게 해당 지식을 획득할 수 있으므로 큰 문제가 되지 않는다. 자아(ego)가 등장해서 친숙하지 않은 환경이니 어려울꺼야~ 속도를 줄여~ 하고 속삭이지 않는 바에야 이런 부분에서 시간을 축내는 일은 발생하지 않는다.

새로운 일은 쉽던 어렵던 설계작업이 동반되어야 하고, 그에 따라 새로운 문맥을 탑재해야 한다. 나는 동시에 한가지 일밖에 못해서 문맥변환을 처리하려면 다음과 같은 과정을 거쳐야 한다.

1. 기존 작업물에서 생긴 버그와 해결하지 못한 문제들에 대한 책임감 unload
2. 기존 작업물에서 해야할 일들에 대한 기대와 희망 unload
3. 새 작업물의 업무 범위 정의
4. 새 작업물의 핵심 문맥 암기
5. 새 작업물 처리과정 시작

기존에 다른 일로 쉽사리 이동하지 못했던 이유들은 1, 2번 문제였다. 이를 발견하는데 꽤 오랜 시간이 걸리긴 했지만 자아를 버림으로써 이를 해결했다. 3번의 존재는 그리 어렵지 않게 찾을 수 있었다. 하지만 3번에서 정의한 새로운 문맥을 탑재(load)하는데는 시간이 필요하다. 왜냐하면 무의식으로 접근해서 쓸 수 있을만큼 외워야하기 때문이다.  이 암기작업은 비용이 적지 않게 든다. 그런데 나는 4번 작업을 무시하고 바로 5번으로 건너뛰어 들어갔다. 아직 문맥탑재가 끝나지 않았는데, 요것 요것을 하면 된다고 정의했다고 해서 해당 문맥의 아이템들이 머리속에서 유기적으로 엮여 마구마구 작업이 되면 얼마나 좋겠냐만은, 당연히 현실은 그렇지 못했다. 거북이 같은 속도로 움직이게 된다.

그 결과, 조금 우습지만, 새 작업물에 대한 문맥을 뽑아서 따로 외우는 시간을 도입하기로 했다. 종이에 쓰고 하늘보고 중얼중얼.. -_- 하다가 아니 이게 웬 19세기 학습방법인가.. 하는 마음에 암기에 관한 책들을 다시 들춰보고 있다.

챕터 5의 단기기억 부분이 필요하다. 업무 정의는 이미 끝난 상태라 무엇이 필요한지는 알고 있다. 그러나 필요한 것을 load 하는데 비용이 들어 (탐색기를 뒤지거나 cd; ls 콤보를 날린다거나 소스코드를 뒤적인다거나 오피스 문서를 뒤적인다거나) 이미 로드된 것들조차 잃어버리는 것이 문제이기 때문이다. 목표는 정보 인출속도를 최대로 올려서 이미 load된 다른 문맥들이 단기기억소에서 밀려나가지 않도록 보호하는 것이다.

브레인 룰스와 공부의 비결에서 얻은 결론은, 일정 시간간격을 두고 반복 노출하는 것이 기억에 도움이 된다는 것이였다. 다행히 이렇게 외운 것들도 다시 건드려주지 않는 이상 30일이내에 20%미만만 남기고 기억에서 사라진다고 에빙하우스가 밝혀줬으니 머리가 터져 미치는 일은 없을 듯 하다. 넉넉한 시간이 주어졌다면 자연스럽게 외울 수 있겠지만, 내게 그런 운은 없으니…

고등학생이 된 기분으로 외우자 외워.

p.s. 물론 아침에 일어나서 수분공급도 잊지말고 해줘야하고, 종합비타민도 먹어야되고, 주기적으로 근육운동도 해줘야하고, 무리한 알콜 섭취도 삼가야하고.. (중얼중얼 담배 끊는다는 얘기는 죽어도 안함)

• Do, or Do not. There’s is no try.

괴테의

• 서두르지 말고 그러나 쉬지 말고
• 무지개도 15분 이상 떠 있으면 사람들은 눈길을 돌린다
• 목표에 가까워질수록 어려움은 커진다
• 생각없이 일을 하면 늘 도망갈 길만 찾아다니게 된다.
• 자유도 생활도 그것을 매일매일 싸워 얻는 자만이 누릴 자격이 있다는 것

.

경험이 늘어갈수록 하나의 사건에서 파생될 수 있는 오만가지 케이스를 자각할 수 있게 된다.  그리고 그 케이스들은 보통 안좋은 경험을 통해 배우게 된다. 머리를 잔뜩 써서 배울 수도 있지만, 시간이 많이 든다는 이유로 관리자들이 선호하지 않는다. 부딪혀서 배우면 바로바로 문제점을 찾아 땜빵할 수 있기 때문이다. 이 방법이 가진 문제 중 치명적인 한가지는, 부딪힐 때 느껴지는 부정적인 감정이 함께 학습된다는 것이다. 그렇다고 시간을 들여 공부하는 방법을 택하게 되면, 대부분의 사람들이 공부하기 싫어서 미루고 미루다 결국 최선을 다했다고 자기 합리화하거나 지금은 공부할 기분이 아니라는 핑계로 딴짓을 하며 시간을 죽인다. 그래서 결국 관리자들은 그냥 밀어붙인다. 옳고 그름을 떠나 프로젝트를 제 시간에 맞추기 위한 전략으로 아주 매력적으로 보이기 때문이다.

결국 간단한 기능 하나를 만들면서 오만가지 케이스가 머리속에 떠오르고, 그와 함께 부정적인 감정들이 함께 휘말려든다. 그러면 기본기능 구현 비용, 부정적인 감정들을 견디거나 제거하는 비용, 오만가지 케이스를 처리하는 비용, 이렇게 3배(혹은 그 이상)의 리소스가 필요하다.

그래서 나와 당신은, 예전보다 코딩이 느려진 것이다.

너무 자학하지 말자는 차원에서

p.s. 오만가지라고 해봐야 한번에 많아야 2-3가지 정도일 뿐.

우리가 생각해낸 아이디어들의 대부분은 실현되지 않는다. 왜냐하면 그 아이디어를 실현하기 위해 우리가 고군분투하지 않기 때문이다. 고군분투하지 않는 나나 당신의 게으름을 탓할 생각은 없다. 그 아이디어는 그저 그정도였던 것 뿐이다. 게으름과 꾸물거림을 이겨내고 행동으로 옮길만큼의 가치가 없다고 판단한 것 뿐이다. 혹은 트라우마의 간섭을 받아 스스로 채운 족쇄를 아직 벗지 못했거나.

완벽주의는 분명히 좋지 않다. 왜냐하면 눈만 높고 실력은 형편없는 사람이 자기 허영심이나 채우겠다고 아둥바둥 대며 현실을 외면하고 가야할 길을 걷지 않는 것이기 때문이다.

가능한한 심플하게 만드는 걸 누가 하기 싫어서 안하나 어려워서 안하지. 심플한 기능과 사용성을 얻어내는 과정이 복잡도를 이겨내는 과정보다 훨씬 더 어려운 거 아닌가.

최종 결과물을 보며 ‘오, 심플하고 쓰기 쉽고 필요한 건 다 되네!’ 라고 느끼게 해주려면 우수한 기획자가 필요하기도 하지만 개발자도 적지 않은 고생을 해야한다. 그런데 일단 완료부터하고 나중에 업그레이드 하겠다는 생각으로 어려운 부분들을 계속 뒤로 미뤄둔다면, 거대한 쓰레기 매립장에 쓰레기 하나 추가하는 거랑 다를 바가 없다. 지금 내게 어려운 일은 시간이 지나도 똑같이 어렵다. 그림자가 길어져 더 어려워보이면 보였지 더 쉬운 일로 변하지 않는다. 곰팡이가 생기고 썩어서 아예 범주에서 없어질 수 있을 뿐이다.

중요한 것은 대상이 아무리 어렵고 모호해도 회피하지 않고 한걸음씩 앞으로 걸어나가려는 의지와 용기다. 4 Simple Principles of Getting to Completion의 마지막 원칙인 make it public, quick은 홀로 서서 걸어갈 수 없는 사람이 대중들에게 ‘나 좀 떠 밀어주실래요’ 부탁하는 거 아닐까. 그래봐야 약간의 긴장감 상승을 얻을 수 있을 뿐, 대부분 그저 엎어지고 만다.

성장하는 과정에서 발생하는 쓰레기는 피할 수 없겠지만, 쓰레기를 많이 만들었다고 성장하는 것은 절대로 아니다.

생각보다 어렵지 않다. 메모리 관리 직접해야한다고 하지만, C에서 메모리 관리하던 생각하면 이건 귀찮은 것도 아니다. 발로 짠 다음 Run with Performance Tool -> Object Allocations으로 지켜보면 대부분 잡힌다.

iPad이 출시되면 화면 크기를 고려한 동적 레이아웃 코드들이 들어가겠지만, 320×480 고정크기 개발은 개발자에게 큰 매력이다. 게다가 동시에 하나의 앱밖에 실행할 수 없다는 것 (멀티태스킹이 안된다는 것) 또한 개발자를 신경쇠약으로부터 구해주는 요소이다. 지난주에 안드로이드 유료앱을 만들어 Android Market에 올렸었는데, 개발기간의 많은 시간을 Activity 관리와 화면크기를 신경쓰느라 소비한 내 입장에서는 iPhone 개발은 쉽게만 느껴진다.

내가 UI 개발을 코드로 하는 것을 좋아하는 이유는 다중 해상도를 지원하는데서 오는 신경쇠약을 피하기 위함이다. 국내 J2ME 게임 개발업체들은 화면 크기별로 코드를 따로 짠다. (2003~4년 시절 얘기다 지금은 어떨지 모르겠다) 120×146, 176×220, 240×320 … 난 이러한 짓거리를 조금도 이해할 수 없다. 초반에 살짝 머리가 아프긴 하지만, 비율을 계산하여 늘려주면 된다. 게임같은 경우 이미지 리소스들만 화면 크기별로 로드하도록 추상화시키면 된다.

결국 iPhone 개발할 때에는 Interface Builder를 사용했다. 습관이 습관인지라 동적으로 생성하는 코드도 다량 들어가긴 했지만, IB로 할 수 있는건 다 IB로 만들었다.

nil 객체에 메시지를 보낼 수 있다는 점이 매력적이다. 디버그가 어려워질 수 있는 문제가 있지만, 귀찮은 null check 코드를 쓰지 않아도 되서 좋다.

Android 개발

나는 자바 개발을 오랫동안 해왔다. 하지만 android.* 패키지들은 새로 공부해야하는 것이다. 내가 머리가 나빠서일수도 있지만, android 패키지 공부하는 게 Apple의 Foundation, UIKit 공부하는 것보다 어려웠다. 그래픽스 부분에서는 CoreGraphics가 Android의 drawing 보다 어려웠다. 이렇게 생각한 이유는 CoreGraphics가 drawRoundRect (라인8에 버그있음) 함수를 기본제공하지 않아서? 일지도 모른다. 어떤 대상에 대한 호불호는 사소한 것에서 결정되기 마련.

java.lang, java.io, java.net, java.util, java.util.concurrent 를 그대로 쓸 수 있다는 것이 가장 큰 매력이다. 그렇기 때문에 UI 코드가 없는 J2SE용 라이브러리를 안드로이드로 포팅하는 것은 일도 아니다.

안드로이드 플랫폼의 가장 큰 에러는 ‘에뮬레이터’다. 정말 말도 안되는 성능이다. 내  Motorola Droid 보다 느리다. file i/o의 경우 실폰이 에뮬레이터보다 8배가 빨랐다. UI 처리속도도 실폰이 현저하게 빠르다. 덕분에 개발을 실폰에서 하고, 테스트를 에뮬레이터에서 하는 (화면 크기별) 말도 안되는 일이 생긴다. 특히 정규식처리가 엄청나게 느리다. 프로파일러를 붙여 돌렸을 때 가장 많이 CPU를 소모한 녀석이 icu 라이브러리였다. 때문에 아주 복잡한 문자열처리를 빼고는 모두 String.substring, String.indexOf로 로직을 새로 짰다. java.util.regex.Pattern과 Matcher만 안썼다고 해결되는 것이 아니다. String.split 이나 replaceAll은 내부에서 regex.Pattern/Matcher를 쓴다. 조심하라.

플랫폼 설계사와 제조사가 갈려있다보니, 모델별 버전별로 버그가 퍼져있는 문제가 있다. 그래서 Android Market에 가보면 “Droid에서 테스트 했음. 넥서스 원 지원함” 이런 문구들을 포함한 앱들을 많이 볼 수 있다. 안좋은 징조다. write once, test everywhere가 되버렸다.

Activity 관리가 쉽지 않다. Activity Lifecycle만 보면 ‘응 그래, 직관적이고 좋네’ 라고 생각할지도 모르겠다. 해보면 안다. 하나의 앱에 Activity 가 하나라면 모를까. 그렇지 않으면 Intent에 플래그를 적절히 줘야 원하는대로 동작하는데, 공부 제대로 안하고 덤볐다간, 의도치 않게 Activity instance가 여러개 뜨는 지옥을 맞이하게 될 것이다.

유닛체계의 기본값이 pixel이 아니다. 덕분에 다중 해상도 지원 앱을 만들기 쉽지만, 이것은 어디까지나 안드로이드가 제시하는 유닛체계를 잘 공부했다는 전제 하에서나 만족한다. 분명히 아이폰에 비해 장벽이 되는 부분이다.

새롭게 공부해야할 개념들이 적지 않다. 그에 비해 아이폰은 언어만 다를뿐, 딱히 새로 공부해야할 개념은 많지 않다. 어디서 자바 좀 했다고 안드로이드 플랫폼 만만하게 봤다간 100% 낭패다. 자바를 오랫동안 해온 사람들은 OOP에 익숙해져있을텐데, 안드로이드 플랫폼이 UI 개발시 권고하는 방법론들은 대부분 C 스타일이다. 랭기지만 자바다. UI 클래스들은 AWT 보다는 SWT에 가깝다. SWT는 위젯 생성시 parent를 넣으면 알아서 추가되기라도하지, 안드로이드에서는 add는 따로 해야함에도 불구하고 SWT처럼 매번 View 생성자에 Context를 넘겨야 한다. 번거롭다.

별도 Thread에서 UI를 고치는 작업을 EDT에서 실행해야만 하는 것은 Swing, SWT 에서 충분히 경험했을 것이다. Swing에서는 SwingUtilities.invokeLater가 그것이고 SWT에서는 EventQueue.invokeLater가 그것이다. 둘 다 static helper method를 제공해주는데.. 안드로이드는 static helper method를 제공하지 않는다. Activity.runOnUiThread는 instance method다. 이 때문에 유지해야하는 Context 크기가 자꾸 커진다. 이는 안드로이드 설계자가 생각없었던 것이 아니라 개발자가 여러 Activity 인스턴스를 관리해야하기 때문에 어쩔 수 없이 생기는 문제이다. 하지만 코딩이 번거로워진다는 점은 변하지 않는다. 심히 귀찮다.

iPhone은 main entrance가 있다. UIApplicationMain이 그것이다. 그런데 안드로이드는 main이 없다. 그저 AndroidManifest 파일에 특정 Activity 클래스의 Intent 필터에 MAIN, LAUNCHER 속성을 줄 수 있을 뿐이다. 그럼 그 Activity 클래스의 onCreate가 메인이라고 생각할 수 있을텐데.. 아니다. landscape/portrait 모드가 바뀔 때마다 onCreate가 매번 다시 불린다. onCreate 메서드를 main이라고 생각했다간 큰일난다. 꼭 landscape 모드를 바꾸지 않더라도 Activity가 백그라운드에 있다가 메모리가 부족하면 언제든 죽을 수 있고 그 액티비티로 ‘돌아가면’ onCreate가 다시 불리운다. 즉 onCreate를 main으로 생각하면 안된다는 것이다. 사용자는 메모리가 부족한지 넉넉한지 신경쓰지 않는다. 사용자가 어떤 작업을 하다 잠깐 다른 Activity로 이동했다가.. 돌아왔을 때 첫 화면이 보이면 얼마나 당황스럽겠는가! 전통적인 main method 부재에 대한 부담은 개발자의 몫이다. 다행히 AndroidManifest 파일에 application 당 1개의 instance만 생성되는 클래스를 지정할 수 있다. 그렇지만 Application 클래스의 onCreate에서 Activity를 create하면 안되므로 개발자는 충분히 혼란스러워할 수 있다. 별 수 없다.  시간을 들여 익숙해져야 한다.

SQLite

아이폰과 안드로이드 모두 SQLite를 제공한다. iPhone의 sqlite3_stmt는 읽을 때(sqlite3_column_text)는 index가 0부터 시작하고, 쓸 때(sqlite3_bind_text)는 index가 1부터 시작한다. 이게 뭐야.. 나한테 왜이래.. -_-

반면 Android가 제공하는 SQLite는 쓸 때는 String[]로 넣게 되어있어(구지 따지면 0ㅋ) index를 신경쓰지 않게 해주고, Cursor로 읽을 때는 0부터 시작한다.

두 플랫폼 모두 2월에 시작했기 때문에 아직 어떠한 결론을 내리긴 어렵지만, 아이폰은 개발하기 쉽고 바로 제품을 런칭하기 적절한 플랫폼이라 느껴지고, 안드로이드는 아직 갈 길이 멀게만 느껴진다. 개발자들이 충분히 시간을 들여 공부하면 되겠지만, 언제나 그렇듯 대부분의 사람들은 공부를 좋아하지 않고, 결국 시장에는 용기있고 무식한 개발자들이 만든 쓰레기같은 제품이 넘치게 마련이다. 공부를 좋아하는 사람은 공부하느라 바빠서(?) 시장에 제품을 내놓지 않는다.

우리는 자신의 행동에 따른 책임을 회피할 때, 그 책임을 다른 어떤 개인이나 조직 등에 떠넘긴다. 이것은 자신의 권리를 양도하는 것을 의미한다. 그래서 에리히 프롬은 나치즘과 권위주의에 대한 그의 연구에서 이를 ‘자유로부터의 도피’라고 했다. 아주 적절한 표현이다.

책임지는 괴로움을 피하기 위해서 백만, 천만의 사람들이 하루하루 자유로부터의 도피를 시도한다.

나의 친구 중 한 사람은 아주 똑똑하지만 침울한 사람이다. 내가 그대로 놔두면 거침없이 그리고 유창하게 우리 사회의 압제적인 세력들에 대해 얘기를 토해 낸다. 인종 차별, 남녀 차별, 군비 확장 그리고 지방 경찰관들이 자기 같은 사람들이 머리를 길게 기른다고 귀찮게 구는 것 등등에 대해 흥분을 하며 얘기한다. 나는 여러 차례 “너는 이미 어린아이가 아니다” 라는 것을 지적해 주었다.

우리가 부모에게 지나치게 의존하는 그만큼 부모는 우리에게 지나친 지배권을 갖게 된다. 사실 부모는 우리를 잘 기를 책임을 갖고 있다. 그 때문에 우리는 부모의 사랑과 보살핌을 받고 있다. 부모가 억압적인 태도로 아이를 가르치면, 아이들은 자발성과 선택 능력을 제대로 기르지 못하게 된다. 그러나 아이들에게는 선택의 기회가 제한적이지만 건강한 성인에게는 무한대로 주어지기 때문에 선택 능력의 미숙은 큰 문제가 된다.

때로 우리는 두 가지의 나쁜 일 가운데 덜 나쁜 것을 선택해야 할 경우가 있다. 이런 선택 역시 우리가 결정할 문제다. 물론 이 세상에 압제적인 세력이 있다는 점에서는 나도 그 친구에게 동의한다. 그렇지만 우리는 이런 세력에 대응하고, 다루는 방법들을 단계적으로 선택할 자유를 가지고 있다. 경찰이 장발을 싫어하는 지방에서 사는 것도 그의 선택이고, 긴 머리를 그대로 기르고 있는 것도 그의 선택이다. 그에게는 다른 도시로 이사할 자유도 있고, 긴 머리를 자를 자유도 있으며 또 장발족이 당하는 불이익에 항의하는 캠페인을 벌일 수 있는 자유까지도 있다.

그러나 그는 매우 영리한데도 이런 자유를 의식하지 못하고 있다. 그는 자기의 커다란 힘을 인정하지 않고, 자신이 정치적 세력을 가지지 못했다고 슬프게 여기는 쪽을 선택한 것이다. 그는 자기가 자유를 사랑한다는 것과 자유를 방해하는 압제적인 세력에 대해 이야기하고 있다. 그러나 그런 얘기를 할 때마다 실제로는 자기의 자유를 포기하여 남에게 주어 버리고 있는 것이다. 언젠가는 선택을 하는 것이 고통스럽다는 그런 단순한 이유 때문에 삶을 적대시하는 그 친구의 태도가 바뀌기를 나는 간절히 바라고 있다.

대다수의 환자에게 존재하는 ‘무기력함’은 자유에 대한 고통을 피하고 싶은 욕망에서 생겨난다. 그래서 그들은 그들의 삶이나 문제에 대해 책임질 줄을 모른다. 그들이 느끼는 무력감은 사실 자신들의 권리를 포기했기 때문이다. 그들이 치유되고 건강해지려면, 조만간 성인의 생활 전체가 개인의 선택과 결정의 연속이라는 것을 배워야만 될 것이다. 그들이 이런 것을 전적으로 수용할 수 있을 때에만, 자유로울 수 있다. 이런 것을 수용하지 못하면 그들은 영원히 자신들을 희생자라고 느끼게 될 것이다 .

얼마전에 네이버 다이어리에서 인터뷰도 한 건 해서, 공유하려고요.

많은 경우 결혼은 그저 ‘덫’에 불과한 경우가 많다고 하지만, 저희 부부는 솔로일때보다 더 만족스런 인생을 꾸려나가고 있습니다. 결혼 결심하기 1달전에만 해도 친구들 앞에서는 ‘난 평생 독신으로 살려고’ 하고 다녔었는데… -_-;

그럼.