Tizen <push> 원격에서의 App Launch & 메시지 전달 - 2. 설계하기

시작하기 전에...
Tizen 공부를 시작하며 에도 썼듯이 혼자 공부하며 서술합니다.
실제 사실과 다를 수도 있고, 보이는 대로 사견을 서술할 예정입니다.
잘못되었다 싶은 부분은 댓글이나, 메일로 알려주세요.
Tizen 2.4 Native 기준으로 포스팅 합니다.

Tizen Push에 대해 포스팅 해보겠습니다.

Push는 단순 API 사용으로만 보면 매우 간단하면서도,
심도있게 Service를 설계하다 보면 굉장히 까다롭고 고려 사항이 많아지는 어려운 기능입니다.

따라서 포스팅을 나누어서 해보겠습니다.

1. 시작하기 (UI App에서 단순 Push 수신)
2. 설계하기 (서버 Flow & App Flow)
3. 구현하기 (제대로 설계 되었지만 그래도 내용은 간단한 Sample)

본 Post는 2. 설계하기 (서버 Flow & App Flow) 입니다.

Push를 사용하는 Service라면 Backend와의 긴밀한 연계를 필요로하는 Service일 가능성이 높습니다.
또한 서비스를 위한 별도 서버를 두고 있는 게 일반적입니다.
(이는, 여러가지 이유를 들 수가 있는데 여기에 설명하기에는 너무 장황하므로,
간단하게 관리 효율과 Push 서버 Quota 절약 정도를 이유로 들겠습니다.)

결국, [단말 <-> Push 서버 <-> 개별 서버] 사이에서 Push를 어떻게 효율적으로 이용할 지에 대한 Design이 필요합니다.

(제가 생각하는) Design 시 Push Service에 대해 고려해야 할 요소는 다음과 같습니다.

1. Push Message는 유실될 수도 있다.
  -> 대부분의 Push Service Provider들은 "유실 방지에 최선을 다하지만 유실될 수 있다" 고 명시하고 있습니다.

2. Data 길이가 제한적이다.
  -> Tizen Push는 Message가 2kb (Android GCM은 4kb)로 제한되어 있습니다.

3. 즉시 도달하지 않을 수 있다.
  -> 단말의 Data Network 상황이 좋지 못하면 Push 메시지 수신도 지연될 수 있습니다.
  -> 그렇지만 그나마 Push가 최선일 확률도 높습니다.

4. 남의 서버임을 명심하자.
  -> 본인의 Service에서 생성한 Data나 사용자 정보가 다른 회사의 Server에 보관되고 발신됩니다.
  -> 사용자의 민감정보, 유출되지 말아야 할 정보는 Push Payload에 대해 재고해볼 필요가 있습니다.

Push Server를 사용해 Data를 전달하는 방범론에 대해 3가지 모델을 제시해 보겠습니다.

기준은 Push Server에 얼마나 의존적이냐 입니다.

1. Push based service : Full dependent model

Push를 사용하는 가장 원시적(?) 인 방법입니다.
메시지 전달 수단을 Push에 의존해 Data 전제를 전달하고 있습니다.
위에 제시한 고려사항 4가지 전체에 대해 부정적인 Model이지만,
Data의 중요도가 그리 높지 않고 단순한 서비스라면 고려해볼만 합니다.
Design이 간편하고 App / Server에서 고려사항이 적기 때문에 Side Effect이 비교적 적을 것입니다.

Message를 보호하고 싶다면 암호화해서 Push로 전달하고 단말에서 복호화해서 풀 수도 있습니다.

2. Push based service : Minimum dependent model

Push는 Notify 용도로만 사용하는 방법입니다.
위의 고려사항 4에 대해 특히 중요한 모델 Design이며, 나머지 3개도 어느정도 Cover되는 부분입니다.

Push에 중요 Data를 실어 전달할 경우,
첫째, 남의 회사 Server (=Push Server)에 본인의 Data가 저장되고
둘째, 다른 App에게 부정한 방법에 의해 Hooking될 위험성도 내재합니다. (가능성은 적지만...)
Public Cloud가 가지게되는 고질적인 고민 입니다.

본 모델의 경우, Push를 Notify 용도로만 사용하므로 Push 관련 App & Server Design도 비교적 단순하면서
Data는 자신만의 Secure한 전송 로직을 자유롭게 쓸 수 있다는 장점이 있습니다.
Data 길이도 문제되지 않으며, 메시지 유실도 본인 서버만 잘하면 문제 없습니다.

단점은, Push의 실시간성을 반감시킬 수 있습니다.
Push는 Platform Level에서 빠르고 높은 우선순위로 Data를 가져와서 App에게 전달하므로 가장 빠른 반면,
그를 전달받은 후 App은 다시 ④와 같이 별도 자신의 서버와 연결하고 Data를 받아오는 시간을 필요로 합니다.
Device의 Network 상태가 어중간하게 나쁜 상황에서는 Push는 간신히 받았지만
App의 Connection 시도는 실패할 수도 있습니다.
(더욱이 App이 서버와 별도의 Secured Connection을 설계하였다면 초기화가 더 오래 걸리겠지요)

3. Push based service : Hybrid model

2의 모델에서 Push의 실시간성만 어느 정도 보완한 모델이 되겠습니다.
Push로는 사용자에게 즉시 보여 줄 간단한 요약 데이터만 전달 후,
전체 Data는 별도 Connection으로 가져오는 방법 입니다.

단점은 구현 복잡도가 높습니다.
Summary로 가져온 Push Data와 별도 Connection으로 가져 온 Data와 중복되는 Case에 대하여 처리 로직을 고안해야 하며,
단말 밑 서버에서는 중복 Message에 대한 Timing Issue에 대한 고려가 필요합니다.

또한, 이런 경우라도 Message 보호를 위해 Push Message는 암/복호화를 할 수 있습니다.

서버에서 Push 발신시 추가적인 Option에 대해 알아보겠습니다.

Tizen Push Server API tutorial의 Message field key-value pairs를 참조하면,

Action에 ALERT, SILENT, DISCARD, LAUNCH 네가지 옵션이 제공됩니다.

이 Action Field에 대해서는 유의해야할 점이 존재합니다.

1. Additional한 부분이므로, Alert, Launch 등으로 메시지를 전달 받았어도
동일 Message가 Push Connect 시 Notify Callback으로 전달 됩니다.

2. App이 Push Disconnect 상태일 때만 Option들이 유효하게 적용됩니다.
 -> 예를 들어, App이 push_service_connect()를 호출해 연결을 유지하고 있을 때,
     사용자가 Home키를 누른 경우 App은 안보이지만 push_service_disconnect()가 호출되지 않았다면 여전히 연결 상태이므로
     아무리 ALERT로 메시지를 보내도 효과가 나타나지 않습니다.

	Message Field 사용예	설명
ALERT	"action=ALERT&alertMessage=Alert Test"	상단 Noti Bar에 표시됩니다. (사용자가 Noti 클릭 시 App Launch)
SILENT (default)	""	아무것도 안합니다.
DISCARD	"action=DISCARD"	Guide가 부실해서 뭐에 쓰는지 모르겠습니다
LAUNCH	"action=LAUNCH"	App Control이 날아갑니다. (App Launch)

ALERT 옵션 사용 결과 입니다.

추가로 뒤에 &로 엮어서 Badge 옵션도 줄 수 있습니다.

Badge는 INCREASE로 원하는 숫자만큼 증가시키거나
직접 Set 할 수 있습니다.

   

Message Field는 이와 같이 지원하는 Option이 다양하지만,
Push disconnect 상태에서만 동작한다는 점 때문에 관리하기가 까다롭습니다.
App이 Background에 있지만 Push Connect인 상태일 때, Notify Callback으로 여러 Option들이 전달된다면
필요에 따라서는 App이 직접 Notification이나 Badge를 생성해줘야 할 수도 있습니다.
따라서 되도록이면 섞어쓰지 말고 한가지 옵션만 통일해서 사용하기를 권장드립니다.

위와 같이 Message Field는 옵션 등에서만 이용하는 것이 관리에 용이합니다.
별도로 전달해야할 Data는 appData Field를 이용하시면 되며,
type이라는 optional Field가 있는데,
개발 시 필요한 Protocol을 정의 시에 유용하게 이용하실 수 있을 듯 합니다.

timeStamp는 왠만하면 넣어서 보냅시다.
정교한 Service를 만든다면, 실제 배포 전 검증 단계에서 여러 Defect들을 확인하는 데에 도움이 됩니다.

마지막으로 Push를 어느 앱이 받게 설계할 것인가를 정해야 합니다.

UI App이 받을 수도 있고, Service App이 받을 수도 있습니다.

1. UI App이 받을 경우 (지향하지는 않습니다.)

위에 언급한 Message field에서 action이 SILENT, DISCARD 일때는 문제가 없습니다.
ALERT 일때는 약간의 고려사항이 발생합니다.

App이 resume 상태일 때, action=ALERT로 Push가 온다면
Noti를 표시해야하는가 말아야 하는가에 대한 고민이 생깁니다.

Resume 상태는 이런 상태입니다.

Home Key를 눌렀거나, Root Window에서 Back key를 눌렀는데 App을 계속 살려두었을 때입니다.

만약 이런 상태 (App이 안보이는 상태)에서는 Noti를 표시하지 않겠다고 생각하시면
app_create_cb()에서 push_service_connect()을 호출하시고,
app_terminate_cb()에서 push_service_disconnect()를 호출하시면 됩니다.

그러나, App이 안보이는 상태는 종료나 다를 바 없으므로 Noti가 나와야한다고 생각하시면
app_resume_cb()에서 push_service_connect()을 호출하시고,
app_resume_cb()에서 push_service_disconnect()를 호출하시면 됩니다.

action이 LAUNCH일 때는 항상 UI App이 뜬다는 점에 유의하시기 바랍니다.
Android GCM의 경우 Push가 Broadcast 모델에 기반하지만,
Tizen의 경우 다른 Application Modeling을 가지고 있습니다.
LAUNCH 옵션으로 Push를 받게되면 시도때도 없이 App이 Launch되어 UI를 Draw할 위험성을 갖게 됩니다.

따라서 App은 LAUNCH 로 날아올 Push에 대해 항상 잠재적 위험성을 갖게되는데,
이러한 이유 때문에 UI App이 직접 받기 보다는 Service App을 따로 두어 Push를 수신하는게 안정적입니다.

2. Service App이 Push를 받게 될 경우 (권장)

Service App은 Tizen의 Background Model입니다.
모든 Push Message가 다 사용자에게 UI를 띄워 표시할 내용이 아닐 수도 있습니다.
이럴 경우 Background에서 먼저 받아서 Data를 확인하고, 별도 판단을 거쳐 필요시에만
UI를 Draw할 수 있습니다.

이 때 유의할 점은,

1. Service App이 먼저 뜨는 상황이므로 Background Category를 Manifest에 넣어 놓는게 안정적입니다. (Tizen 2.4이상 해당)

2. Service App은 할일이 끝나면 바로바로 종료될 수 있도록 작성해야합니다.

3. 반드시 UI App과 패키징되어야 합니다. (같은 패키지여야만 상호 Launch, IPC 등이 자유롭습니다.)

패키지 구조는 다음과 같습니다.

Push로 Service를 설계할 때 고려사항을 생각나는대로 나열해 봤습니다.
더 상세한 사항들은 실제로 부딪혀 가면서 규정하고, 수정해 나가시면 될듯합니다.

다음에는 3. 구현하기 (제대로 설계 되었지만 그래도 내용은 간단한 Sample) 를 포스팅하겠습니다.

Wearable도 다르지 않다는걸 보여드리기 위해 Wearable 타깃으로 구현할까 합니다.