코로나에서의 안드로이드 notification 에 대해 새로운 소식을 전해 드리기로 했죠. 그리고 안드로이드와 iOS 의 notification 은 완전히 다른 거라서 cross-platform development가 얼마나 어려운 건지를 이 기능이 잘 보여준다고 말씀 드렸구요.
만약 우리가 iOS 플랫폼을 위해서만 개발을 했다면 이런 기능들을 아주 빨리 추가하고 다른 일들도 빨리빨리 진행 해 나갔을 겁니다. 하지만 우리는 Android 도 지원을 하고 있습니다. 그 외에도 desktop app 이나 Corona Simulator 에서 동작할 수 있도록하는 작업도 해야 되구요. 그리고 사실 Mac 과 윈도우에서도 동작하도록 하는 작업도 하고 있습니다.
The ‘I’ in API
이 4개의 OS들 중 안드로이드 부분이 일 진행이 가장 더딥니다. 내부적으로 우리끼리 통하는 룰이 있습니다. 안드로이드 관련 작업은 최소한 5~10배는 더 다른것들보다 소요 된다구요. 거기에는 두가지 원인이 있습니다.
첫번째로 안드로이드에는 mulriple (forked) flavor들이 있습니다. 게다가 standard Android (Google Play) 이외에도 Kindle 과 NOOK 이 있구요 여기에도 각각 자신들의 앱 스토어가 있습니다. 이런 이유 때문에 같은 버전이라도 모든 안드로이드 디바이스들에 맞게 다르게 작업을 해야 하는 부분들이 있습니다. 일례로 OpenGL device driver 가 각 디바이스별로 다른 performance 를 보여주기 때문에 별도로 작업을 해야 했습니다. 여기에 여러 다른 서비스들이 있죠. 예를 들어 maps, in-app purchase, notification 등등이요. 이런 서비스들도 서로 완전히 다릅니다. 이런 서비스들에 어떤 변화가 오면 서로 다른 OS들은 물론 같은 OS라도 서로 다른 device 별로 개발과 테스트를 따로 해야 됩니다.
두번째로는 Android API는 그렇게 충실하지 못합니다. 어떤 경우에는 API 자체에 잘못된 부분도 있지요. 하지만 그것보다도 저는 API design 자체가 충실하지 못합니다. 제 생각에 API 의 I 는 interface 대신 interaction 으로 해야 더 맞다고 생각합니다. 그 이유는 개발자가 이 것들과 interact 해야만 하니까요. iOS API 는 NextStep에서 온 오리지널 MacOS API 가 개선된 걸 겁니다. 그러니까 이 API는 10 수년간 다듬어 진 것이지요. 그리고 오랜 기간동안 다듬어진 것처럼 보이기도 합니다. naming 과 API 의 semantic이 일관성있게 만들어 져 있습니다.
반면에 안드로이드는 새로 만든 API 입니다. 그리고 아주 좋은 API라고 할 수는 없습니다. 우리는 안드로이드 API 중에 awkward한 API를 아주 많이 봤습니다. 그리고 85% 정도만 설명이 돼 있고 15% 부족한 부분도 많이 봤습니다.
예를 들어서 안드로이드에서 multitouch 를 implement 할 때 많은 장애물들을 뛰어 넘고 나서야 각각의 touch들을 identify 할 수 있었습니다. 화면에 손가락이 touch 됐을 때 그 터치 이벤트가 터치되고 move 되고 화면에서 떼어질 때까지 같은 id를 갖고 있어야 합니다. multitouch 에서는 이 부분이 아주 중요하죠. 여러 터치 이벤트 들을 서로 구분해야 하니까요. 하지만 안드로이드의 MotionEvent 에서 이 id 들은 unique 하지가 않습니다. 그래서 저희들은 저희들의 방법을 따로 만들어야 했습니다.
Android notification infrastructure (or lack thereof)
안드로이드를 상대로 일을 할 때 우리만의 방법을 만들어 내야만 하는 경우는 이제 저희들에게는 일반적인 것으로 받아들여 집니다. 그리고 안드로이드의 notification을 만들 때도 마찬가지로 저희 팀은 저희들만의 방법을 만들어서 부족한 부분을 메꾸어 넣어야 했습니다. 우리가 iOS 에서 한 것과 비슷하게 안드로이드에서도 기능하도록 하기 위해서 저희들은 여러 scaffolding 을 만들어야 했습니다.
예를 들어 Corona API 에서는 notification을 schedule 하는 기능이 있습니다. iOS notion 에서는 단 한줄로 이 기능을 사용할 수 있었습니다. 그런데 안드로이드에서는요... 그렇게 쉽지는 않았습니다. 거기에는 schedule notification 기능이 없었습니다. 그래서 저희들이 그 기능을 만들어 넣어야 했지요.
이 부분은 그렇게 큰 문제는 아니었습니다. 정말로 큰 문제는 안드로이드가 자신의 notification을 관리하기 위해 app에 요구하는 것들이었습니다. 즉 앱은 notification work을 만들기 위해 여러 가지로 관리되어야만 합니다. 특히 앱이 background로 돌아갈 때나 강제로 앱이 exit 됐을 때 혹은 phone 이 reboot 될 때 등입니다. None of these come out of the box.
여러분의 앱이 background로 돌아갈 때 (예를 들어 back button을 눌렀을 떄) scheduled notification은 시간이 되면 나타나야 합니다. 여러분이 앱을 강제로 종료했을 때 schedule 된 notification은 나타나지 않을 겁니다. 이게 안드로이드의 limitation 입니다. OS 가 제공해야 되는 기능인데 제공하지 못하고 있는 거죠.
다른 경우는, 여러분이 앱을 강제로 종료했거나 phone을 reboot 했다면 notification은 status bar 가 사라지면서 그 자리에 나타날 겁니다. 왜냐하면 notification은 앱과 연결돼 있고 OS 에서 globally reside 되지 않기 때문이죠. 그래서 우리가 무엇을 했는가 하면 이 notification을 persist 하도록 한 겁니다. 그래서 앱을 relaunch 하면 이 notification들은 status bar 안에 다시 나타나게 됩니다. 메일 앱에서의 기능이랑 비슷한 거죠.
무슨 의미냐 하면 notification이 scheduled 되면 이 notification들은 오직 앱이 foreground 이거나 background 일 경우에만 나타납니다. 그리고 만약 그 앱이 강제 종료 됐거나 phone 이 reboot 됐다면 그 notification은 나타나지 않는 겁니다.
status bar 에 나타나는 notification이 흥미로운 부분입니다. 왜냐하면 애플리케이션은 status bar에 나타나는 자신의 notification을 manage 해야하거든요. 왜냐하면 메일 앱이 하는 것처럼 우리가 그 notification을 persist 했으니까요. 유저가 tap 하게 되면 status bar에 있는 notification을 clear 혹은 remove 시켜야 합니다. 그래야지 persistence data가 제대로 sync'd 되니까요.
그 위에 저희들은 안드로이드에 unique 한 것들을 몇개 추가했습니다. 코로나의 디폴트 notification icon 대신에 여러분의 custom icon을 넣을 수 있도록요. 그리고 iOS notification에 익숙한 분들을 위한 몇가지 기능들도요. 그리고 custom notification sound 같은 것들도...
이런 것들은 모두 나름대로의 trick 을 사용한 겁니다. 하지만 제대로 동작을 하죠. 저희들은 standard Android, Kindle, NOOK 에서 돌아가는 notification system 을 만든 겁니다.
이런 작업들이 안드로이드에 remote push notification 기능을 코로나에서 지원하도록 하기 위해 한 작업들 입니다. Google Play's service (Google Cloud Messaging)들은 standard Android device에서만 제공된다는 것을 유의하세요.
==== 원문은 저 위의 제목에 달린 링크를 따라 가시면 나옵니다. 이해가 안되게 번역이 됐거나 잘 못 번역이 된 것은 다 제 실력이 모자라기 때문입니다. 필요하시면 저 링크를 클릭해서 원문을 참조하세요. ===
