샌디에고로 이사왔습니다.

반년짜리 프로젝트인데... 이곳에서 열심히해서 인정받고 다름 프로젝트에도 채택되고 해서 좀 오래 있었으면 좋겠네요.

그렇지 않으면 반년 후에 어떻게 될지 모르는게 취업비자로 이곳 미국에서 일해 먹고 사는 처지네요..

지난번 로드 아일랜드 쪽 프로젝트도 끝나고 다음 프로젝트 찾으면서 비자 transfer도 생각하고 하느라고 여간 스트레스가 아니더라구요.

이번에는 은행 Bill Payment 프로젝트인데 TDD 를 사용하는 프로젝트 입니다.

저는 테스팅 팀에 소속돼 있는데 팀원들이 다 개발자 출신이고 테스팅 업무 경험이 없어서 배우면서 해야 되네요.

당분간은 다른 공부 할 시간이 없을 것 같습니다.

가끔 TDD 쪽 공부하다가 여유 되면 여기 블로그에 올릴 생각입니다.

LA 밑에 있는 San Diego 로 이사왔는데 완전 외국 분위기 나고 정말 좋네요.

미국 동부랑은 완전 세상이 다릅니다.

이곳에서는 인터넷을 달지 않을 생각입니다.

아파트 관리사무실 건물에 WiFi 사용할 수 있는 곳이 있거든요. 쓸 일 있으면 관리사무실 건물로 가서 사용하려구요.

집에서 인터넷 하면서 헛시간 소비하는 일이 줄어들겠네요.

그동안 한국 소식을 접하지 못했는데..

박근혜는 아직도 사람들을 다 인선을 못했네요. 인사 능력이 영 엉망인것 같고... 약속을 지킨다는 이미지를 그렇게 심어주고 강조했는데... 공약들도 다 어긴다고 하고...

그냥 MB 한테도 그랬듯이 5년동안 별일 안하고 조용히 있다가 떠나주기를 바랍니다.

MB는 그동안 쌓아왔던 민주적인 틀을 무참히 짓밟고 나갔죠.
거기에는 그런 권력에 빌붙어서 놀아났던 놈들이 있었기 때문에 가능했던 겁니다.

MB도 깜방에 보내야겠지만 김재철 같은놈 그리고 국정원 불법선거, 정치검찰의 한심한 작태들을 상기하면 MB에 부역했던 놈들도 다 처벌해야 된다고 생각합니다. 반드시......

참여연대에서 MB 정부의 정치검사 46명의 명단을 공개했네요.

http://www.gobalnews.com/news/articleView.html?idxno=379 로 가시면 관련 기사를 보실 수 있습니다.

이 정치 검사놈들 꼭 기억하고 진실을 밝혀내고 반드시 처벌해야 합니다.

San Diego 에서 진행되는 새로운 프로젝트에 참여하게 됐습니다.

지난번 진행하던 New England 프로젝트는 중국 팀이 생기면서 그쪽 팀으로 업무가 모두 이관 되면서 제 역할은 끝났구요.

인도에 이어 이제 중국이 IT 쪽도 잠식해 들어가기 시작하는 건가?

몇달간 Knowledge Transfer 를 진행하고 일도 같이 진행하고 했는데... Dalian에 있는 중국애들이랑 같이요...

적극적이고 feedback 빠르고 확실하고 실력도 좋고 괜찮더라구요.

무엇보다도 영어가 그렇게 유창하지 않은데 부끄러워하거나 주저하지 않고 적극적으로 자신의 의견을 내고 항상 회의에 적극적으로 참여하는 게 인상 깊었습니다.

몇달간 중국팀으로부터 저도 많은 것을 배웠어요.

인도애들이 긴장해야 되겠던데요... 중국애들이 치고 들어오면 미국내 IT 를 잠식하고 있는 인도의 위상이 약간 변화가 오지 않을까.....

제가 이렇게 남 걱정 하고 있을 때가 아니죠.

언제든지 선택받지 못하면 한국으로 돌아가야만 되는 미국에서의 외국인 노동자로서 New England 쪽 프로젝트 끝나가면서 접했던 그 한 없는 불안감과 막막함 그리고 초라함이 다시는 반복되지 않도록 좀 안정 됐으면 좋겠네요.

San Diego 로 오면서 봤던 저 삭막한 사막처럼 외국인 노동자로 산다는 건 정말 건조한거 같아요.

오늘부터 새로 시작하는 San Diego 프로젝트.....

열심히 해서 더 인정받고 더 안정된 미국에서의 외국인 개발자가 되고 싶어요.... ;;

수요일 입니다. 다시 FAQ 시간이 돌아왔습니다. 오늘의 주제는 런타임 에러 처리와 안드로이드 퍼미션에 관한 내용들을 다루겠습니다.

1. What about the Runtime Error Message Popup on current Daily Builds?

안드로이드용은 Build 1030부터 그리고 다른 플랫폼들은 Build 1047 부터 적용됐는데요. 런타임 에러가 나면 팝업 메세지 박스가 뜨고 파일과 line number 와 함께 해당 에러를 보여 줍니다. (debug build 로 세팅 됐을 경우에요).  그리고 물론 콘솔에도 에러 정보가 뜨구요. 그러니까 이제는 콘솔 없이도 런타임 에러를 볼 수 있는 기능이 추가 된거죠. Build 1047 부터 여러분 코드에 런타임 리스너를 include 하실 수 있습니다. 이 리스너는 에러를 trap 하고 런타임 팝업 메세지 박스를 뜨지 않도록 할 수 있습니다. 이 때 다른 동작을 행하도록 분기해 버리면 런타임 에러가 발생해도 앱이 멈추지않고 계속 작동하게 할 수 있습니다.

모든 플랫폼과 맥/윈도우 시뮬레이터에서 런타임 메세지 박스는 디폴트로 보이도록 설정돼 있습니다.

2. How do I implement a Lua Runtime Error Listener?

아래 예제를 보시면 런타임 리스너를 어떻게 implement 하는지 보실 수 있습니다. ("unhandledError") 코로나 시뮬레이터나 디바이스에서 이 코드를 실행하면 print statement 의 string 과 함께 concatenating a nil value 에 의해 발생한 에러를 보실 수 있을 겁니다.

local releaseBuild = true   -- Set to true to suppress popup message

-- Error handler
local function myUnhandledErrorListener( event )

    if releaseBuild then
        print( "Handling the unhandled error >>>\n", event.errorMessage )
        display.newText( ">>> ERROR OCCURRED <<<", 30, 1, native.systemFont, 18 )
    else
        print( "Not handling the unhandled error >>>\n", event.errorMessage )
    end
    
    return releaseBuild
end

Runtime:addEventListener("unhandledError", myUnhandledErrorListener)

-- Displays text message in center of screen
txtMsg1 = display.newText( "Runtime Error Test Code", 55, 200, "Verdana-Bold", 14 )

print( "ABC" .. nil )  -- <<<< Lua error here

이 리스너에서 false (default value)가 return 되면 이 리스너 함수를 나갈 때 팝업 메세지 박스가 뜹니다. true 가 return 되면 리스너 함수가 런타임 에러를 처리한다는 의미 입니다. 그래서 팝업 메세지가 뜨지 않습니다. 위 코드에서 releaseBuild 변수는 팝업 메세지가 표시 될지 안될지를 결정하는 변수 입니다.

3. What is the best practices for the Runtime Error Listener?

런타임 팝업 메세지 와 런타임 에러 리스너 기능을 추가한 이유는 진행되는 코드의 상황과 에러를 보여줄 수 있는 툴을 개발자들에게 제공하기 위해서 입니다. 만약에 디버그를 위해서 빌드를 한다면 (iOS에서는 developer mode가 되겠고 안드로이드에서는 debug key 를 사용한 빌드가 되겠죠.) 에러가 발생한 파일과 그 line number 가 포함된 런터임 에러 정보를 보실 수 있을 겁니다. 이 정보들은 팝업 메세지 박스를 통해서 보게 되죠. 만약에 런타임 리스너를 추가하고 이 팝업 박스를 띄우지 않는다고 하더라도 그 에러 정보들을 얻을 수 있습니다. (리스너에 전달된 event table 이나 콘솔창등에서요.)

production release 라면 error type 만 가능합니다. 런타임 리스너를 implement 하시고 에러 팝업을 띄우지 않도록 세팅한 다음 내부적으로 그 에러를 log 하게 되죠. 이 에러 로그로 무엇을 할 지는 여러분이 하기 나름입니다. 그냥 무시할 수도 있고 문제점들을 track 하기 위해 서버로 보낼 로그 파일을 만들수도 있구요. 팝업 에러가 뜨도록 하는 것의 장점은 이 에러 정보가 Google Play 에 전달 될거라는 겁니다. 개발자들은 그 에러 정보를 Google Play 에서 보실 수 있게 되는 거죠. 만약 팝업 창을 띄우지 않게 되면 여러분이 에러 정보를 log 해서 여러분의 서버에 전달하지 않는한 그 에러 정보는 lost 되게 되죠.

디버그 할 때는 대부분 런타임 팝업이 뜨도록 하는 경우가 많을 겁니다. 그리고 앱 스토어에 올릴 때는 그 팝업을 띄우지 않도록 바꾸는 경우가 많을 거구요.


이전 FAQ 에서 언급한 건데요. 에러를 그냥 무시해 버리는 것은 그다지 좋은 방법은 아닙니다. 런타임 에러가 발생하면 앱이 안정적이지 않게 될 수 있습니다. 가능하면 많은 디바이스에서 앱을 테스트 해 보고 에러가 발생하면 이 에러를 없애거나 pcall 을 이용해서 trap 하셔야 합니다.

4. I'm using the Runtime Listener but I'm still getting the Runtime Error popup.

여러분 코드에서 런타임 에러 리스너를 implement 해서 에러 팝업창을 띄우지 않도록 했는데도 계속 팝업이 뜬다면 런타임 리스너가 시작하기 전에 런타임 에러가 일어났을 가능성이 큽니다. 위 예제에서 보여드렸듯이 런타임 리스너 함수는 코드 내에서 정의를 하셔야 합니다. 그리고 그 함수를 가능하면 빨리 enabling 하셔야 합니다. 그래야 에러를 trap 하실 수 있습니다. 런타임 에러 리스너가 enable 되기 전에 일어난 에러들은 당연히 팝업 메세지를 발생시킬겁니다. 일반적으로 startup 시 발생하는 에러는 fix 하기가 쉽습니다. 그리고 trap 작업도 필요 없구요. 터치 이벤트, 충돌 등이 일어날 때 발생하는 런타임 에러들이 trap 해야할 그런 에러들 입니다.

5. What about Android Permissions and runtime errors?

Build 1030에서 안드로이드 Manifest 에서 디폴트 퍼미션을 없앴습니다. 여러분이 필요한 퍼미션들을 추가해야 된다는 얘기죠. Daily Build 샘플 코드 프로젝트와 API 페이지들을 보시면 build.settings 파일 안에 필요한 퍼미션들이 있읍니다.

대개 퍼미션을 빠뜨리면 런타임 팝업과 함께 런타임 에러가 발생합니다. (혹은 unHandledError 리스너가 call 되기도 하죠.) 퍼미션을 빠뜨리는 것은 앱을 릴리즈 하기 전에 뭔가가 테스트 되고 또 fix 되어야 한다는 얘기 입니다. (6번 질문을 보세요.)

6. Which Android Permissions won't generate a runtime error?

어떤 API call 들은 build.settings 파일에 특정 퍼미션이 세팅되어 있지 않으면 조용히 fail 해 버립니다.
아래와 같은 것들인데요.

• display.capture
• display.captureBoard
• display.captureScreen
• media.newRecording
• media.newVideo
• media.save
• media.show
• native.webView
• native.newWebPopup
• heading( Compass) event
• location (GPS) event

위의 API들을 사용할 때는 그 코드가 원하는대로 제대로 작동하는지 꼭 확인하셔야 됩니다. build.settings 파일에 이런 퍼미션들이 세팅되어 있는지도 한번 더 확인하는 습관도 좋은 거 같습니다.


각 API 별로 필요한 안드로이드 퍼미션이 무엇인지 보시려면 Daily Build Documents 를 확인해 보세요.

That's it for today's answers. I hope you enjoyed them and even learned a few things!