모바일 웹을 개발하다 보면 각 디바이스 별로 기능을 다르게 주는 경우가 있습니다.

아이폰 인경우는 어떤 기능을 실행하고 또 안드로이드인 경우는 다른 기능을 실행하고 등등이요.

그런데 전화기를 다 가지고 있지 못하면 이 기능을 제대로 테스트하지 못하기도 합니다.

이럴 경우 user agent 를 바꿔서 데스크탑이나 랩탑에서도 모바일 디바이스에서 해야만 하는 테스트를 할 수가 있습니다.

각 브라우저에 맞는 User Agent Switcher 플러그인을 설치하시면 되는데요.

우선 크롬부터 알아 보겠습니다.

1. 크롬 user agent switer

https://chrome.google.com/webstore/detail/djflhoibgkdhkhhcedjiklpkjnoahfmg

 우선 크롬 브라우저를 실행시킨 후에 위 링크로 접속을 합니다.

다음에 오른쪽 위에 있는 Added to chrome 버튼을 클릭하시면 됩니다.

간단하죠?

그러면 오른쪽 위에 저런 아이콘이 생기는데요. 이 아이콘을 누르고 원하는 디바이스를 선택하시면 됩니다.

그럼 위와 같이 제 랩탑에 있는 크롬 브라우저인데 Platform 이 iphone으로 잡히고 User Agent에도 iPhone으로 잡힙니다.

2. 파이어폭스 user agent switer

http://chrispederick.com/work/user-agent-switcher/

파이어폭스에서도 마찬가지로 이 링크로 가셔서 설치하시면 됩니다.

그리고 메뉴에서 tools - Default User Agent를 선택하셔서 사용하세요.

그러면 아까와 마찬가지로 랩탑에 있는 파이어폭스 브라우저인데도 아이폰으로 인식합니다.

그리고 또 다른 파이어폭스용 User Agent Switcher 인것 같은데요.

https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher/

여기로 가셔서 받으셔도 됩니다.
저는 저 위에걸로 깔아서 쓰고 있습니다.

모바일 웹 개발하시는데 도움이 되시길 바랍니다.

ERD Tools - Avolution, dbForge Studio (MySQL), ER/Studio, ERwin, Oracle Designer, PowerDesigner, Rational Rose, Toad Data Modeler, Microsoft Visio, Visual Paradigm, RISE Editor

A Complete Guide to Filing Bugs with Apple

Report your Apple Bugs and Features

앱 스토어에 iOS 앱을 올리시나요? 애플에 1년에 99불을 지불하시나요? 개발하실 때 Xcode를 사용하시나요? 어떤것에든 yes를 대답하셨다면 여러분은 Apple Developer 입니다.

모든 소프트웨어는 버그들을 가지고 있습니다. 코로나도 예외는 아니죠. 우리는 지원하는 다양한 플랫폼에서 발생하는 버그로부터 여러분을 보호해 드리려고 열심히 일하고 있습니다. 하지만 완벽하지는 못하죠. vendor 가 그 문제를 고쳐야 될 때도 있습니다.

애플 디벨로퍼로서 사람들은 가끔 이 버그때문에 절망하기도 하죠. 하지만 사실 애플은 bug report를 꾸준히 받고 있고 또 꾸준히 고치고 있습니다. 다른 큰 회사들이랑 다르죠. 큰 회사에 bug를 report 해 보세요. 그 방법을 찾는게 쉽지는 않을 겁니다. 하나 예를 들자면 저는 몇년전에 Southwest 항공에 버그를 report 하려고 시도했었습니다. Southwest는 의도적으로 온라인을 통해서 그들을 접촉하는 통로를 만들어 두지않았습니다. 그래서 저는 직접 편지를 썼습니다. 그들이 메일을 받았다는 연락은 받았지만 지금까지 그 bug는 고쳐지지 않았습니다.

애플은 unique 합니다. 그들은 외부 개발자들이 그들의 내부 bug/feature tracking system에 bug를 report 할 수 있도록 오픈했습니다. 그들은 이것을 Apple Radar라고 부르고 애플의 직원들이 정기적으로 그 report들을 관리합니다. 만약 task 가 Radar 에 있지 않으면 애플의 기술자들은 그 문제에 대해 일을 하지 않을 것이고 bug가 고쳐지지도 않을 겁니다.

*YOU* Must File Bugs to Get a Fix! (Not somebody else)

개발자들로부터 이런 얘기들을 많이 듣습니다. "누군가가 bug를 신고 할거야" 혹은 "애플이 이미 이 bug를 알고 있을거야". 이말은 잘못된 겁니다. 아무도 bug를 신고하지 않으면 Apple은 이것에 대해 알 수가 없습니다.

그리고 그 말이 사실이라고 해도 문제가 안 됩니다. Radar는 voting/priority 시스템이기 때문입니다. Radar는 report가 얼마나 많은 사람들에 의해 중복해서 보고 됐는지를 조사합니다. 더 많은 사람들이 올린 이슈에 대해 애플은 우선순위를 두어서 bug를 fix 할 겁니다. 그렇기 때문에 애플이 이미 알고 있더라도 누구나 bug를 report 해야하는 겁니다.

Test Betas and File Early

애플은 beta(seeds)를 release 합니다. 그들은 뭔가가 제대로 작동하지 않는지에 대해 알고 싶어 합니다. 이 때 제대로 잡아야 재앙을 막을 수 있습니다.

여러분들 중 iOS 5.0 에서 OpenAL 관련해 진짜 악성 bug가 있었다는 것을 기억하시는 분이 계실겁니다. 정말 재앙이었습니다. 왜냐하면 충분히 막을 수 있었거든요. 그런데 아무도 거기에 대해서 참여하지 않았습니다. iOS 5.0 beta 4에서 OpenAL API 에서 제대로 작동을 멈추게 하는 부분 관련한 audio code에서 무언가 문제점이 있었습니다. 그래서 audio 가 완전히 망가졌었죠. 몇몇 개발자들은 사실 beta 4에서 이 사실을 발견 했습니다. 그런데 애플이 알 거라고 집작했거나 아니면 누군가가 report 했을 거라고 생각해서 아무도 report를 하지 않았죠. 결국 beta 7 에서 그 문제점에 대해 제대로 인식하기 시작했고 제가 그 버그를 report 했습니다. 그런데 이미 때는 늦었습니다. 애플은 이미 코드 단에서 bug fix에 대해  lock down 해 버렸습니다. 그래서 애플은 이후에 보안 이슈같은 아주 critical 이슈들만 fix 했죠. 그래서 그 문제는 5.1 버전까지 fix 되지 않은 채로 있었습니다.

그러는 동안 우리는 Corona에서 이 문제와 관련되서 문제점을 극복하려고 몇주간의 시간을 투자했습니다. 우리가 그 solution을 찾았을 때까지 이 문제로 인해 bad performance 를 감수해야 됐습니다. 우리는 그 문제를 해결할 수 있었던 것을 행운이라고 생각합니다. 그것 이외에도 아직 fix되지 않은 iOS에 이미 있었던 버그들이 우리들의 일에 지장을 주었습니다.  그래서 그런 버그들이 또 다른 버그들을 야기하기도 했죠.

애플은 이것을 iOS 5.1에서 fix 했습니다. 문제는 계속 iOS 5.0 을 쓰고 있는 사람들에게는 그 bug가 계속 나타날 거라는 거죠. 그러니까 iOS 5.0 이 완전히 사라질 때까지 우리는 그 bug의 피해를 계속 받을 수밖에 없는 겁니다. (다행히 대부분의 유저들이 2주만에 over-the-air update를 통해서 5.1로 업그레이드 했습니다. 5.0과 관련된 문제가 훨씬 일찍 해결 될 거 같긴 합니다. )

여기서 배운 점은 누군가 beta 4에서 bug를 발견해서 report 하기만 했다면 이 문제는 5.0 이전에 해결 됐을 거라는 겁니다.

Write Good Bug Reports

애플이 제공하는 좋은 bug report 쓰기를 보시려면 여기로 가세요.

아래 몇가지 참조할 만한 사항을 추가합니다.

- 가급적 자세한 정보를 보내세요. 누군가가 그 버그에 대해 report 했을 수 있습니다. 하지만 여러분이 표현한 다른 현상이 버그를 고치는데 더 도움을 줄 수 있습니다.

- 현상을 간단하게 재현해 볼 수 있는 test case 를 제공해 주세요.

- 애플팀에게 어떤 버전에서 그 문제가 일어났고 어떤 OS와 device에서 테스트를 해 봤다는 것을 알려주세요.

- 관련된 다른 버그를 아시면 bug report 에 그 bug number를 포함해 주세요.

- Corona를 사용하고 있다는 것에 대해 그리고 모든 detail하게 알지 못하는 것에 대해 말하는데 부담 갖지 마세요. 애플은 여러분의 binary 파일로도 테스트를 할겁니다. 그러니까 bug report 에 여러분이 built 한 바이너리 파일도 넣어 주세요. 그리고 애플과의 discussion에 우리(Corona) 도 넣어 주세요. 애플에 버그를 submit 할 때 Corona에도 같이 submit 해 주세요. 그리고 애플의 bug report 를 copy 해주시면 감사하겠습니다. (bug number랑요)

- 애플은 좀 더 많은 정보가 필요하면 여러분을 contact 할 겁니다. 거기에 follow up 해 주세요. 애플이 여러분에게 contact 했는데 어떻게 제공할지를 모르면 저희에게 알려 주세요. 저희들이 애플이 필요로하는 정보를 얻는데 도움을 드리겠습니다.

Be Polite

제 경험상으로 애플 기술자들은 그들의 일에 자부심을 가지고 있고 그들의 제품을 사용하는 유저들을 사랑하고 있습니다. 그들은 좋은 bug report를 받는 것을 좋아합니다. 자신들의 상품을 좀 더 좋게 변화시키는 일을 할 수 있으니까요. 여러분도 정중하게 너무 꾸짖는 톤으로 들리지 않도록 신경 써 주세요.

Types of Bugs – Apple or Corona?

어떤게 애플 버그인지 어떤게 코로나 버그인지 어떻게 구분하죠? 가끔 이를 구분하기 어려울 때가 있습니다. 아래 몇가지 hint를 드리겠습니다.

Regression: 같은 device이고 수정하지 않은 같은 프로그램인데 이전 iOS 버전에서 잘 돌아가는데 새로운 iOS 버전에서 에러가 발생한다면 이것을 regression bug라고 합니다. 이것은 대부분 Apple bug 이고 bug report 를 해야할 사안입니다. 빨리 report 해 주세요.

Device specific:  iPad 1과 iPad 2 에서 뭔가 다른 이상한 점들이 있다면 이것은 Apple bug일 가능성이 큽니다. 이럴 경우 어느쪽 버그인지 확실하지 않으면 Apple 과 Corona에 같이 bug report 해 주실것을 부탁드립니다.

Similar problems with apps *not* made with Corona: 코로나를 사용하지 않은 다른 앱에서도 같은 버그가 발생하면 Apple bug일 가능성이 큽니다.

We tell you it’s an Apple bug:  우리가 이미 알고 있는 Apple bug들도 있습니다. 우리가 그것은 Apple bug라고 하면 그것을 애플에 report 해 주세요. (priority를 높이기 위해서요)

Feature requests: Radar 는 feature request도 할 수 있습니다. Siri API access 같은 것을 원하면 애플에게 그것을 오픈해 달라고 요청하실 수도 있습니다. 이런 것들도 bug report 해도 됩니다.

My Personal Results

저는 여러분에게 거짓말하고 싶지 않아요. 많은 버그들이 fix 되지 않을 겁니다. 그리고 애플 엔지니어들로부터 여러분이 report 한 버그에 대한 추가 정보를 요청 받는 경우도 아주 드물겁니다. 그런데 말씀 드릴 수 있는 것은 적지 않은 버그들이 response 받고 fix 된다는 점입니다. 저는 애플에 500여개의 버그를 report 했습니다. 그 중에 25% 가량이 fix되거나 해결 된 것 같습니다. 25%면 꽤 괜찮은 비율이라고 생각합니다. 구글이나 마이크로소프트에 report 한 버그는 0% 거든요. 제 bug report 를 그들이 읽었는지 어떤지에 대해서도 저는 전혀 모릅니다.

Bugs Every Corona User Should File

아래 몇개의 버그들을 소개해 드리겠습니다.

Lua support for Xcode:

Xcode 4에는 Lua 에 대해 syntax highlighting 을 제공하지 않습니다. 모든 Corona 유저들이 이 bug를 report 했다면 (feature request) 이 기능은 제공 됐을 겁니다. 왜냐하면 여러분은 이 report를 최고 우선 순위로 올려 놓을 만큼 충분한 머릿수가 되거든요. 이렇게 되도록 만듭니다. 오늘 bug report 를 해 주세요. 애플이 그 버그 레포트가 duplicate 인것을 알아 차리도록 bug report  rdar://9321859 부분을 알려 주세요.

Layer-backed WebView sometimes crashes on Mac:

맥에서 코로나의 Native object들은 애플의 layer-backed views라고 불리는 Core Animation technoloty와 아주 세련되게 잘 어울리도록 돼 있습니다. 하지만 WebView는 이 기술과 2007년 선보인 이래로 OpenGL과 작동하는데 심각한 문제가 있습니다. (제 original bug 가 그 때부터 보고 됐었거든요.) 많은 개선이 있었지만 아직까지 Corona Simulator와 crash 하는 문제점은 있습니다.  만약에 이 webview가 Corona Simulator에서도 잘 작동이 된다면 개발자들에게 아주 편리한 기능이 될 겁니다. 이 bug를 지금 fix 합시다. 여러분의 bug report 에 rdar://1326401 도 추가해 주세요.

Switching between recording and playback causes a momentary freeze:

불행히도 iOS5에는 1개 이상의 심각한 audio bug가 있었습니다. 다른 버그는 recording mode와 playback mode가 서로 교차할 때 일 순간 어플리케이션이 freeze 되는 현상을 유발합니다. Corona에서 제공하는 샘플 앱을 보면 iOS5에 대해 Lua 에서 이 부분을 피해가는 제 2의 방법을 사용하고 있는 것을 볼 수 있을 겁니다 . 그 제 2의 방법을 보면 recording과 playback 모드가 서로 switch 하는 것을 피하기 위해 동시에 playback 과 record 모드를 작동시키고 있습니다. 이런 방법으로 해결은 하고 있지만 이 방법은 비용이 많이 드는 방법입니다. 그래서 performance에도 악영향을 주고요. 아이폰은 큰 이어폰대신 작은 이어폰을 사용하기 위해 playback speaker를 switch 합니다. 아마도 feedback noise를 피하기 위해서 일 겁니다. 여러분들 중에 playback과 recording을 동시에 작동시키기를 원하지 않는 분들은 저희들에게 컴플레인을 하실겁니다. 하지만 small ear speaker를 사용하는 것은 애플의 디자인입니다. 동시에 작동하도록 만드는 것은 저희들이 어쩔 수 없이 선택한 겁니다. 애플만이 이 문제를 fix할 수 있습니다. 그러니까 bug report를 해 주세요.  rdar://145440 도 bug report에서 언급해 주시구요.

I have publicly mirrored these bugs at Open Radar:

저는 Open Radar에 이 버그들을 공개적으로 미러링하고 있습니다.

http://openradar.appspot.com/9321859

http://openradar.appspot.com/radar?id=1326401

http://openradar.appspot.com/radar?id=1454403

Open Radar

이것은 옵션사항입니다. 애플 개발자들은 이미 발견된 버그에 대해 같이 고민해보고자 그 버그를 share 하는 커뮤니티를 시작했습니다. 이 Open Radar에 여러분의 bug report를 공유해 보세요.

What are you waiting for?

여러분은 애플에 개발자 certificate를 위해 99불을 지불 하셨습니다.  여러분은 Mac을 구입하셨습니다. iOS device를 구입하셨습니다. Bug들은 개발시 여러분의 시간과 비용을 증가시킵니다. 그러한 것들은 여러분의 고객을 놓치게 합니다. 그대로 두면 나중에 다시 여러분의 일에 문제를 불러 일으킬 겁니다. 여러분의 투자금을 보호하세요. 그리고 미래의 골치 아픈 문제를 방지하세요. 그 버그들을 오늘 report 하세요.

Apple Radar

Apple Radar에 file report 를 시작하세요.

Local Notifications Guide (iOS)

이번주 화요일의 튜토리얼은 코로나의 Local Notification 기능에 대해 다루겠습니다. 현재 iOS 플랫폼에서만 가능합니다.

여러분 앱의 사용자가 local notification을 받으면 alert 하게 될 거고 소리가 날 거고 메세지가 뜰 겁니다. 그리고 그 notification과 관련된 어떤 행동을 할 수 있는 옵션들이 제공 될 겁니다.

notification을 받을 때 여러분의 앱이 foreground에 있지 않으면 (예를 들어 유저가 인터넷 서핑을 한다 던지, 페이스북을 한다 던지 등등) 유저에게 메세지를 보여줄 수 있습니다. 그리고 여러분의 앱으로 돌아갈 수 있도록 하는 옵션을 줄 수 있습니다. 그러면 여러분 앱을 좀 더 많이 사용할 수 있도록 하겠죠.

Notification은 아주 customizable 합니다. 소리를 내게 할 수도 있고 메세지를 보일수도 있고 앱 아이콘에 badge count를 넣을 수도 있습니다. 또한 user가 특정 notification에 답했을 때 정확히 여러부닝 필요로하는 것을 수행하기 위해서 custom data를 여러분 앱에 pass 할 수도 있습니다.

오늘 다룰 튜토리얼에서는 코로나의 이 local notification 에 대해 알아야 할 모든것에 대해 다루겠습니다.

Local vs. Push Notifications

Local Notification하고 Push Notifications 하고 헛갈리지 마세요. 유저 입장에서 보면 alert이나 message, sound, badge icon 등등 모두 똑 같겠지만 개발자 입장에서는 분명히 다르니까요.

Push와 Local Notification의 다른점은 Push notification은 원격 서버에서 와서 유저에게 push 되는 겁니다.(내부적으로-locally- 따로 정해진 스케줄에 따라 일어나는 것이 아닙니다) 이건 셋업하는데 조금 더 복잡합니다 (보안 문제 같은것들을 생각해야 하거든요.) 그리고 서버를 셋업해야 되기 때문에 비용도 높은 편입니다. (유저가 많을 경우에는 더 그렇겠죠.)

Local notification을 보면 모든것이 유저의 device에서 locally 처리 됩니다. 그리고 미리 지정된 시간이나 간격 등이 세팅돼 있습니다. (scheduled) 그러니까 원격 서버가 필요 없는거죠. (추가적인 비용 발생이 없다는 겁니다.) 또 다른 잇점은 코로나에서 이 Locall Notification을 셋업 하는 것은 아주 쉽다는 겁니다.

사실 여러분들이 Push notification으로 하고자 하는 많은 것들을 local notification으로 할수 있는경우가 많습니다. 또 Local 로만 할 수 있는 것들도 있구요. 예를 들어 여러분들의 앱에서 원격에서 데이터를 가져올 필요가 없다면 Push 보다는 Local을 사용하는 것이 훨씬 더 나을 겁니다.

Scheduling Notifications

Notification에 대한 일정을 잡기 위해 (schedule) system.scheduleNotification() 함수를 사용해야 합니다.

신택스는 아래와 같습니다. 두 방법 모두 유효합니다.

이 함수는 나중에 notification을 cancle 하는 데 사용할 수 있는 reference ID를 return 합니다. 나중에 이 cancel 부분을 구현하려면 system.cancelNotification() 함수를 사용하시면 됩니다.

이 notification을 일정 시간 후로 일정을 잡으려면 secondsFromNow를 사용하거나 universal time을 사용해서 특정 date/time을 지정해 주시면 됩니다.

다룰 것들이 많이 있지만 오늘은 secondsFromNow를 사용해 보겠습니다. 만약 여러분이 coordinated universal time option을 사용하고 싶으시면 coordinatedUniversalTime argument에 대해 좀 더 자세한 설명이 있는  system.scheduleNotification() API 문서를 보세요.

두번째 argument는 secondsFromNow 를 선택했느냐 coordinatedUniversalTime를 선택했느냐와 관계 없이 사용하는 겁니다. 이것은 여러분의 notification에 대해 특정 정보를 보관하고 있는 options 테이블 입니다.

• alert – 유저에게 보여지는 메세지 
• badge – 앱 아이콘에 보여지는 badge number
• sound – notificatin을 받으면 play 될 sound file
• custom – Custom data/params to be used by your app, relevant to the notification (can be a variable, table, JSON string, etc).

개와 관련된 앱을 만든다고 가정하고 들어주세요. 여러분 앱은 10분(600초) 후에 강아지에게 먹이를 주어야 하는걸 알려주기 위해 notification 일정을 잡을겁니다. 그 예제는 아래와 같습니다.

맨 처음에 native.getProperty( “applicationIconBadgeNumber” )를 사용해서 현재 application badge number를 받았습니다. 그리고 options table에서 그 숫자를 1 증가시켜서 세팅했습니다.

나머지는 그냥 보시면 아실겁니다. notification을 600초(10분)로 일정을 잡았고 두번째 인자로 notifyOptions table 을 전달했습니다.

notifyOptions table 안에 custom data로 launch_scene key 를 pass 했습니다. 이것은 이 notification을 받을 때 pet_shop으로 가도록 하기 위해 notification listener안에 있는 이 데이터를 보관하게 하는 겁니다. 나중에 이 데이터를 사용해서 pet_shop scene 으로 가겠죠. 이 custom 옵션에 무엇을 넣느냐는 전적으로 여러분 마음입니다.

Notification Listener

이 notification을 scheduling 하는 것은 단지 첫번째 step일 뿐입니다. 이제 이 notification을 받으면 어떤 것을 하도록 만들어야 합니다. 이 작업은 notification event listener 를 사용해서 작업합니다.

예제를 보여드리기 전에 여러분의 notification event listener function에 pass 될 event data를 알려드리겠습니다.

• event.name – evnet.name은 항상 "notification” 입니다.
  
• event.custom – 여러분이 custom option 을 통해서 pass 한 custom data 입니다.
  
• event.type – 이 값은 항상 “local”이 될 겁니다.
  

아래 notification listener 와 관련된 예제가 있습니다.

이 전에 notificatin schedule을 잡을 때 custom data로 scene key를 설정했죠? 위에서 보듯이 이 값은 event.custom에다 해당 key 값을 넣어서 그 value를 받아오도록 돼 있습니다. 프로그래밍을 하면서 다양하게 사용될 수 있겠네요.

NOTE: 위에서 보듯이 global Runtime object를 사용해서 notification event를 add 하실 수 있습니다. 

Canceling Notifications

system.cancelNotification() function를 사용하면 notification을 cancel 하실 수 있습니다. 이 함수를 call 할 때 두가지 옵션이 있습니다. system.scheduleNotification()에서 return 된 reference ID를 첫번째 argument에 넣어서 특정 notification을 cancel 할 수 있구요,  아니면 아무것도 안 넣고 현재 있는 모든 notification들을 cancel 할 수도 있습니다.

위에 예제로 만든 notification을 cancel 하려면 아래와 같이 하시면 됩니다.

아래와 같이 하면 현재 schedule 된 모든 notification 이 cancel 됩니다.

launchArgs (Important)

유저가 여러분의 앱을 사용하고 있지 않을 때 local notification 이 왔다면 그 notification의 성격에 따라서 유저에게 알리거나 특정 scene으로 안내하고 싶으실 겁니다. 위에서 보았듯이 이런 작업은 notification event listener를 통해서 handle 해야 합니다.

문제는 여러분의 앱이 suspend 되거나 close 됐을 때 그 notification listener는 active 상태가 아니라는 겁니다.

경우에 따라 위의 예제의 경우 앱을 실행 할 때 main scene 이 아니라 pet_store로 가도록 해야 할 수도 있습니다. 이럴 때 launchArgs를 사용합니다. 

main.lua

위에서 보듯이 notification listener는 이전 예제에서 보여 드렸던 그 리스너랑 똑 같습니다. 다른 점은 main.lua 의 첫번째 라인에서 launchArgs  변수를 선언해서 실행 될 부분을 assign 한다는 겁니다.(the “…” is literal; not placeholder text).

notificationListener() function 내 어딘가에 launchArgs 에 attached 된 notification table 과 함께 앱이 시작됐는지 체크해야 합니다.

그러면서 이 listener function을 manually invoke 하게 됩니다. 이 listener 함수는 첫번째 argument로 launchArgs.notification 를 전달 했다는 것을 기억해 두세요.

여기까지 입니다. 코로나에서 local notifications 의 일정을 잡고 어떤 동작을 하도록 하는 것에 대해 모두 배우셨습니다. 이것을 활용하셔서 다양한 효과를 내실 수 있을 겁니다.

뉴저지를 떠나면서 인터넷하고 페이스북으로만 접하는데...

앞으로 큰 행사 두개를 준비하고들 계시네요...

뭐 도와드릴 수 있는 방법은 없고

다른분들에게 이런 행사가 진행되고 있다는 소식이나 알리고 싶습니다.

사람의 인연이라는게 알 수가 없어서

이런 좋은 기가 통하는 소식은 여러분들에게도 좋은 기가 전달되지 않을까...

그러면 여러분들에게도 좋은 일들이 생기지 않을까 기대하면서......

제20회 밀알 사랑의 캠프

1. 일시: 7월26(목) - 28일(토)
2. 장소: Double Tree Hotel (200 Atrium dr. Somerset, NJ 08873)
3. 주최: 밀알선교단 예상 인원 : 600 명
강사: 이재서 박사 (시각장애인,밀알설립자, 세계밀알총재), 이근민 목사 (세계밀알 이사장 )
4. 문의: 뉴저지밀알선교단 (201-530-0355, www.mijumilal.org )

21세기 사마리아인 이야기

한 장애인이 길 가에 쓰러져 도움을 요청하고 있었다.
한 성도가 보았으나 아들 학원 시간 때문에 피하여 지나가고
한 집사가 보았으나 성가대 일 때문에 피하여 지나가고
한 장로가 보았으나 나라가 해야 할 일이라고 피하여 지나가고
한 목사가 보았으나 영혼 구원하는 일이 아니기 때문이라고 피하여 지나갔다.
그 때 사람들로부터 놀림을 당하는 한 정신지체 장애인이 그를 보고 불쌍히 여겨
다가가서 몸을 일으켜 세우고 집에 가서 눕히고 엄마에게 말하여 돌보게 하였다.
누가 쓰러진 장애인의 이웃이 되겠는가?

20년 전 누가 쓰러진 장애인의 이웃이 되겠는가? 질문에 구체적으로 응답하고자
밀알 사랑의 캠프를 시작했습니다. 50 여명으로 시작한 밀알 캠프가 지금은 동부,서부 1000 여명의 장애인과 봉사자가 참여하는 캠프가 되었습니다.
여행 한 번 하기 힘든 장애인들에게 밀알 캠프는 일년내내 기다리는 잔치입니다.
함께 함으로 진정한 사랑을 보고 배울 수 있는 소중한 시간입니다.

시간을 내어 봉사하는 봉사자가 필요합니다 (300 명)
가고 싶어도 회비 때문에 부담이 되는 사람들에게는 후원자가 필요합니다.

www.mijumilal.org

Love without Limits with Nick Vujicic
(닉 부이치치초청 집회)
+ Sunday, August 5, 2012 at 5 p.m.
+ Felician College (Lodi Campus)
262 South Main St. Lodi, NJ 07644
+ Tickets:
$50 VIP (200 seats)
$20 General Admission (1,300 seats)
+ Tickets are only available in advance at America Wheat Mission in NJ (뉴저지밀알선교단 201-530-0355, miju92@yahoo.co.kr, www.mijumilal.org)
+ Doors open at 4 p.m.
+ About Nick Vujicic at http://www.lifewithoutlimbs.org/about-nick/
+ Translator : Pastor Brian Lee ( New England Grace PCA)

아무런 이유 없이 외로움이 느껴질 때가 있어.

잘 생각해 보니 아무런 이유가 없는건 아닌것 같군.

'건축학개론'을 보다 우연히 눈 돌린 비오는 창밖이 어쩌면 그렇게 외로워 보이던지...

인도에 있을 때 새벽에 자전거타고 산책나간 광야에서

어둑히 멀리 있는 양치기 노인을 봤어..

참 낭만적이고 목가적이고 한가한 여유를 느끼고 있었는데..

그 양치기 노인이 나한테 다가오더니

어제 점심부터 굶었는데 100원만 달라는 거야...

그에겐 고달픈 노동이었을 뿐이야.

나한테 한가한 여유를 느끼게 해 주었던 그 행위가....

비오는 창밖의 가로등 불빛이 외롭다.

외로움이 하나 떠나간다.

창밖은 여전히 외롭다.

하나님이 태초에 빛이 있으라 말씀하셨다지?

거짓말이야.

하나님은 태초에 외로움이 있으라 말씀하셨어.

가로등 불빛이 꺼져 버리니

외로움도 사라진다.

이사오고 나서 적응하느라고 바빴는데 메일함에 소포가 왔다가 갔다는 쪽지가 있었어요.

사람이 없어서 쪽지만 놓고 간 것 같은데.

찾아왔더니 코로나에서 보낸 소포더라구요.

저 멀리 캘리포니아에서 왔어요.

보낸 주소 보이시죠?

거기가 코로나 회사 주소인데요.

한가지 바뀐게 있습니다.

원래 코로나 SDK 의 회사 이름은 Ansca 였었는데 바뀌었습니다.

Corona Labs 나 Corona Labs Inc. 로 바뀌었습니다.

저도 이틀전에 공지가 와서 알게 됐어요.

회사 홈페이지와 트위터 그리고 페이스북 주소도 바뀔거랍니다.

아직 준비중이라서 공개하지 말아달라고 하던데요.

공식적으로 발표 되면 글 올릴께요.

명예대사들에게 티셔츠를 보낸다고 해서 그것만 기대했는데.. 센스있네요.

머그잔하고 가볍고 잘 튀는 고무공 그리고 공책, 펜, 스티커 이렇게 보내 줬네요.

공 하나만 더 보내주면 저글링을 할텐데... ^^

아주 열정적으로 회사를 운영하는 것도 Corona SDK 를 좋아하는 이유 중 하나입니다.

물론 SDK 자체도 아주 훌륭하고요. 계속 발전해 가고 있구요.

Corona Labs Inc. 화이팅입니다.

How to Use Bitmap Masks

Posted by Jonathan Beebe

이번주 튜도리얼은 많은 프로젝트에서 꾸준히 애용되고 있는 기능이지만 한편으로는 특별한 use-case로 인해 여러분이 잘 모를 수 도 있는 기능을 다뤄볼까 합니다. 이 기능은 bitmap masking 인데요, graphics.newMask() 함수를 사용해서 구현합니다.

아마 bitmap masking이 무엇인지 잘 모를수도 있습니다. 또 어떻게 유용하게 사용될지에 대해서 알지 못할수도 있구요. 그러신 분들은 이번 강좌를 잘 보세요. 분명히 아주 유용한 툴일테니까요. Bitmap mask는 약간 tricky 한 방법으로 문제를 해결하는데 사용될 수 있습니다.

    - 이미지의 투명한 부분에는 touch 이벤트가 안 먹게 하기 (아주 많이 쓰이는 케이스 입니다)
    - 특정한 모양으로 이미지를 Clip 하기 (예를들어 스크롤 뷰 위젯에서 전체 스크린 내의 일부 sub-section 부분을 clip 하기 위해 bitmap mask 를 이용할 수 있습니다.)
    - solid background가 있는 이미지에 transparency 주기

위에 보시듯이 masking의 주요 목적은 이미지의 일 부분을 숨기는 겁니다. (혹은 전체 display 그룹의 일 부분을 숨길수도 있구요.) 즉 이미지를 masking 하는 겁니다. 그러려면 masking 할 이미지도 있어야 합니다. mask라는 단어를 사용하는 이유가 그냥 이미지나 그룹에 덮어씌우는 기능을 하기 때문입니다.

What a mask looks like

아래에 과일 이미지가 있습니다. (fruit.png) 그리고 bitmap mask image 가 있습니다. (fruit-mask.png) 이 두개의 이미지를 사용할 겁니다. 회색으로 서양의 체스판 모양으로 돼 있는 부분은 이미지의 투명한 부분입니다.

오른쪽의 bitmap mask의 검은 부분이 투명한 부분이 될 겁니다. 그리고 흰 부분은 이 mask가 정확하게 apply 됐을 때 보여지게 될 원래 source 이미지가 들어갈 부분입니다. 이 mask로 사용될 이미지에는 어떤 특별한 제약이 있는것이 아닙니다. 아무 이미지나 사용하실 수 있습니다.

What’s the point?

위 두개의 이미지를 사용할 건데 뭘 하려는 것일까요? mask 이미지에 있는 검은 색은 이미 source image에서 투명하게 돼 있는 부분인데요. 이 튜토리얼에서 다룰 것은 bitmap masking을 사용해서 특정 부분을 투명하게 만드는것 말고 투명한 부분에서는 touch 이벤트가 안 먹도록 만드는 방법을 알려 드릴 겁니다.

투명한 부분이 있는 이미지라도 touch listener를 달면 전체 이미지에서 이 touch 이벤트가 먹힐겁니다. 오직 저 사과만 터치했을 때 어떤 이벤트가 발생하도록 하려면 어떻게 해야 할까요? 그렇게 하려면 이 bitmap mask를 사용해야 합니다. 또 예를 들어 어떤 이미지가 있는데 그 이미지의 일 부분에만 터치가 먹히게 하고 싶을 때도 이 방법을 사용할 수 있습니다. 이미지내에 투명한 부분이 없을때도 말이죠.

Bitmap mask requirements

mask로 사용할 이미지를 만들때는 아래와 같아야 합니다.

   1. width와 height가 4의 배수여야 합니다.
   2. 적어도 3px의 검은테두리가 있어야 합니다.

위의 가이드라인을 따르지 않는다면 예상한 대로 masking이 일어나지 않을 것이고 이것을 debug 하는 것도 힘들겁니다. 추가적으로 고려해야 할 사항들을 아시려면 Bitmap Mask documentation 을 읽어 보세요.

Applying the mask

mask를 적용하려면 graphics.newMask()를 사용해서 새로운 mask를 만들어야 합니다. 그리고 object:setMask() 메소드를 사용해서 객체나 그룹에 apply 합니다.

local mask = graphics.newMask( "fruit-mask.png" )

local fruit = display.newImage( "fruit.png" )
fruit.x, fruit.y = display.contentCenterX, display.contentCenterY

-- apply mask to object
fruit:setMask( mask )

위의 코드를 보시면 우선 mask를 생성하고 display object를 만들고 그 마스크를 display object에 apply 했습니다. 이렇게만 하면 약간의 문제가 생길겁니다. 디폴트로 객체의 적용 좌표는 0,0 이 됩니다. (좌상단이 되겠죠) 그리고 mask는 중앙을 기준으로 하는 reference point가 적용 되면 아래와 같은 모양으로 object:setMask()가 적용 될 겁니다.

mask 가 적용될 객체의 정 중앙에 제대로 덮이길 원하시면 객체의 maskX와 maskY 프로퍼티를 수정해 줘야 합니다.

fruit.maskX = fruit.contentWidth*0.5
fruit.maskY = fruit.contentHeight*0.5

마스크는 대상 객체의 0,0 지점에 위치한다는 것을 꼭 기억해 두세요. 위의 코드를 추가하고 나면 아래와 같이 될 겁니다.

결과적으로 모바일 화면에는 아래와 같이 나오게 됩니다.

자 겉으로 보기에는 그냥 display.newImage() 해서 원래 배경이 투명한 이미지를 display 한것과 다를것이 없습니다. 만약 원래 배경색이 투명하지 않았다면 겉모습이 투명하게 바뀌었을 테니까 뭔가 변화가 있다고 느껴지겠죠. 어쨌든 위에 사용한 원래 이미지 파일에는 배경이 투명하게 이미 돼 있었습니다. 그러니까 위 예제가 유용하게 사용되려면 투명한 부분을 un-touchable 하게 만들어야 쓸모가 있게 되겠죠.

다행스럽게도 이미지가 이렇게 한번 mask 되고 나면 다음 사용법은 아주 쉽습니다. 그냥 간단하게 object.isHitTestMasked 프로프티를 true로 세팅하면 투명해진 부분에 touch 이벤트가 안 먹히게 할 수 있습니다.

fruit.isHitTestMasked = true

이제 여러분이 이 fruit 객체에 touch 리스너를 달게 되면 전체 256X256 이미지가 다 touchable 되는것이 아니라 투명하지 않은 부분만 touchable 될 겁니다. 이 예제의 경우엔 아주 정확하게 과일 부분에 터치할 경우에만 touch 이벤트가 적용 되겠죠.

Dynamic Content Scaling

bitmap mask는 dinamic content scaling을 지원하지 않습니다. 그렇다고 해서 방법이 전혀 없는 것도 아닙니다. 구현하시려면 high resolution asset를 로드해서 object.maskScaleX와 object.maskScaleY 프로퍼티를 원하는 크기에 맞게 세팅해 주세면 됩니다.

예를 들어, retina display에 맞춰서 개발을 하고 있고 아주 super-sharp 하게 되도록 mask를 사용하고 싶으시면 fruit-mask.png와 fruit-mask@2x.png 두개를 준비하세요. (원본보다 두배 크기의 이미지를 준비하시면 됩니다.) 그리고 mask를 생성할 때 (graphics.newMask()) @2x asset을 사용하시면 됩니다. 그리고 나서 fruit.maskScaleX 와 fruit.maskScaleY 를 display.contentScaleX와 display.contentScaleY로 세팅하세요.

아래 예제가 있습니다.

local mask = graphics.newMask( "fruit-mask@2x.png" )

local fruit = display.newImage( "fruit.png" )
fruit.x, fruit.y = display.contentCenterX, display.contentCenterY

-- apply mask to object
fruit:setMask( mask )
fruit.maskScaleX = display.contentScaleX
fruit.maskScaleY = display.contentScaleY
fruit.maskX = fruit.contentWidth*0.5
fruit.maskY = fruit.contentHeight*0.5

이런 방식을 사용하면 좀 더 다양한 해상도에 맞도록 이미지들을 준비하면 좀 더 super-sharp 하게 이 mask를 사용할 수 있겠죠. 물론 각각 다른 high resolution 이미지를 사용해야 겠죠. 같은 방법으로 안드로이드 디바이스들도 이렇게 적용하실 수 있습니다.

그리고 mask는 전체 display group 객체에도 apply 될 수 있다는 것을 기억해 두세요.

Removing a mask

객체에서 mask를 제거하고 싶으시면 간단하게 object:setMask(nil)을 해 주시면 됩니다. 또한 변수를 nil로 선언해도 이 mask를 제거하실 수 있습니다.

fruit:setMask( nil )
mask = nil

이 bitmap mask에 대한 또 다른 예제도 보실 수 있습니다. 다운로드 받으신 Corona SDK의 Flashlight 샘플을 한번 보세요. 경로는 /SampleCode/Graphics/Flashlight 폴더 입니다. 이 bitmap mask로 어떤 다른 좋은 효과를 줄 수 있을까요?