반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 받은 트랙백

글 보관함


Posted on . Written by



수요일 입니다. 다시 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!



반응형

Comment

  1. ㅎㅎㅎ 오랜만에 오네요...^^
    여전히 저에게는 좀 어려운 개념들이네요...ㅋㅋㅋ
    이거 보고 좀 자야겠어요..^^

  2. 잘보고 갑니다.한주도 행복한 시간이 되세요.