반응형
Messaging Concepts and Options
https://developers.google.com/cloud-messaging/concept-options
Google Cloud Messaging APIs는 넓은 범위의 메시지처리 선택사항들과 능력들을 제공한다. 여러분들이 GCM APIs 로 무엇을 할 수 있을지 이해를 돕기 위해서, 이 페이지는 GCM 메시지의 기본적인 요소들을 설명하고 가장 공통적으로 사용되어지는 메시지의 선택사항들의 몇몇에 대해 목록화 했다.
Components of a message
앱 서버는 the target, the message options, the payload와 같은 기본적인 요소들로부터 하나의 다운스트림 메시지 요청을 만든다. 이런 요소들은 GCM HTTP나 XMPP connection server 프로토콜에서 공통적이다.
Target
필수사항. 앱서버가 메시지를 보낼 때, 메시지의 목적지를 식별할 수 있는 Target 을 명확히 해야만 한다. ‘to’ 필드를 사용해서 target 을 명확히 한다. 이 필드는 하나의 registration token, topic, notification key(한 단말 그룹으로 보내기 위한) 를 담을 수 있다.
Options
앱 서버는 클라이언트 앱으로 다운스트림 메시지를 보낼 때 다양한 옵션을 설정할 수 있는데, 예를들면 메시지가 다음 것으로 대체되어야만 하는 것과 같이 말이죠. 메시지 옵션의 전체 목록에 대해서는, 여러분이 선택해서 사용할 HTTP나 XMPP connection server 프로토콜에 대한 참조정보를 보면 됩니다. 공통적으로 사용되는 메시지 옵션들은 아래에 설명되어 있습니다.
Payload
다운스트림 메시지에 대해서, GCM 은 notification 과 data 두 가지 타입으로 페이로드를 제공합니다. Notification 은 2KB 제한이 있고 사용자가 식별할 수 있는 핵심요소들로 미리정의된 집합의 조건을 가진 경량화된 옵션이 있다. Data 페이로드는 4KB 까지 개인화된 key/value 쌍으로 개발자들이 보낼 수 있게 한다. Notification 메시지는 추가적인 데이터 페이로드를 넣을 수 있는데 사용자가 notification 을 클릭했을 때 전달된다.
User scenario
| How to send
|
|
Notification
| GCM 은 클라이언트 앱 대신에 최종 사용자 단말기에 자동적으로 메시지를 보여준다. Notification은 사용자가 식별할 수 있는 핵심요소들의 미리정의된 집합을 가지고 있다.
| notification payload 를 설정한다. 선택적인 데이터 페이로드를 가질 수 있다. 항상 조절할 수 있다.
|
Data
| 클라이언트 앱은 메시지들의 데이터를 처리하는 것에 책임이 있다. 메시지들의 데이터는 오직 개인화된 key/value 쌍을 가지고 있다.
| 오직 data 페이로드만 설정한다. 조절할 수도 있고 조절할 수 없을 수도 있다.
|
notifications 를 사용할 때는 GCM이 당신의 클라이언트 앱 대신에 notification을 표시하는 것을 처리하기를 원할 때 입니다. data 메시지를 사용할 때는 안드로이드 클라이언트앱에서 메시지가 표시되거나 처리하는 것을 당신이 다루기 원할 때 입며 또는 당신이 메시지를 직접 GCM connection 으로 iOS 단말기에 메시지를 보내기 원할 때 입니다.
앱서버는 메시지를 notification 과 data 페이로드 양쪽 모두를 포함해서 전달할 수 있다. 몇가지 경우에서, GCM이 notification 페이로드를 표시하는 것을 다룰수 있고 클라이언트 앱은 data 페이로드를 처리할 수 있다. 더 많은 정보와 예제를 위해선, 다음의 문서를 보세요. (https://developers.google.com/cloud-messaging/concept-options#notifications_and_data_messages)
Notifications and data in the message payload
Notification은 개발자에게 사용자가 보기 쉬운 전시 메시지(몇몇의 미리 정의된 핵심요소와 선택적 custom key/value 쌍으로 된)를 보내기 위한 쉬운 방법을 제공한다. Data 페이로드는 개발자의 오직 개인화된 key/value 쌍을 포함하고 있고, 클라이언트 앱이 메시지를 처리해야만 한다. 여러분은 notification 과 data 페이로드 모두를 가진 메시지를 보낼 수 있다.
Notification
notificaiton 을 보내기 위해선, ’notification’을 알림메시지의 사용자가 이해할 수 있는 부분을 위해서 미리정의된 핵심요소들의 집합으로 설정하는게 필수적이다. 예를들어, 여기 IM 애플리케이션에 JSON 형식으로 된 notification 메시지가 있다. 사용자는 단말기에서 제목으로 “Portugal vs. Denmark” 텍스트로 “great match!” 와 같은 메시지를 볼 수 있다고 기대하고 있다.
{ "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", "notification" : { "body" : "great match!", "title" : "Portugal vs. Denmark", "icon" : "myicon" } }
|
Notifications 은 랩이 비활성화일 때 알림통(tray)으로 전달됩니다. 활성화 상태인 iOS 앱에 대해서는, notifications 은 ‘didReceiveRemoteNotification:’ 으로 대신 전달되어 진다. 활성화 상태인 안드로이드 랩에 대해서는, notification 페이로드가 데이터 묶음 안의 ‘notification’키 기반으로 onMessageReceived() 에 전달되어 진다.
Data message
클라이언트 앱에 데이터 페이로드를 전달하기 위해서는 custom key/value 쌍으로 ‘data’ 를 설정해야 합니다. 데이터 메시지는 최대 4KB 의 페이로드를 가질 수 있다.
예를 들면, 여기에 위와 같이 똑같은 IM 애플리케이션의 JSON 형식으로 된 notification 메시지가 있는데, 정보는 ‘data’안에 캡슐화되어 있고 클라이언트앱이 내용을 해석하기를 바랄 것이다.
{ |
안드로이드에서는, 클라이언트 앱이 ‘onMessageReceived()’ 로 데이터 메시지를 받을 것이고 key/value 쌍에 따라서 처리할 수 있을 것이다. iOS 에서는, 메시지를 저장하고 앱이 구동중일때(foreground)만 전달하고 GCM connection 이 성립될 것이다.
Note 좀 더 플랫폼에 특화된 상세내용을을 기록해라.
- 안드로이드에서는, ‘data’ 페이로드는 액티비티를 실행하기 위해 사용되는 인텐트로 가져올 수 있을 것이다.
- iOS에서는, ‘data’ 페이로드는 ‘didReceiveRemoteNotification:’ 으로 찾을 수 있을 것이다.
만약에 앱이 백그라운드일 때 iOS 단말기로 custom key/value 로 구성된 메시지를 보내기를 원한다면, ‘ data’ 의 key/value 쌍에 'content_available’를 true 로 셋팅하면 된다. |
Hybrid messages with both notification and data payload
메시지를 받았을 때 앱의 행동은 notification 과 data 페이로드 양쪽을 포함하여 앱이 백그라운드이거나 포그라운드인 것에 의존적이다. - 근본적으로, 메시지를 수신한 시간에 앱이 활성화 상태이던지 아니던지간에~
- 백그라운드일 때, 앱은 알림통으로 notification 페이로드를 받고, 오직 notification 을 사용자가 탭했을 때 data 페이로드를 처리할 수 있습니다.
- 포그라운드일 대, 앱은 notification 이나 data 페이로드 모두를 받을 수 있습니다.
다음의 JSON 형식의 메시지는 ‘notification’ 과 ‘data’ 페이로드 모두를 담을 수 있습니다.
{ "to" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx...", "notification" : { "body" : "great match!", "title" : "Portugal vs. Denmark", "icon" : "myicon" }, "data" : { "Nick" : "Mario", "Room" : "PortugalVSDenmark" } } |
Commonly used message options
이 단원은 간단한 다운스트림 메시지를 보낼 때 가장 공통적으로 사용되는 몇몇 옵션들을 더 자세히 조사합니다 : collapsible messaging(collapsible은 가장 최근의 메시지가 큐안에 있는 이전 메시지를 덮어쓰는 것 입니다.), 다중발송, 메시지 우선순위 그리고 메시지의 수명 설정에 대해서 입니다.
Collapsible and non-collapsible message
Non-collapsible message
non-collapsible 메시지는 각각의 메시지가 각 단말기로 전달된다는 것을 시사한다.(내포한다.) non-collapsible 메시지는 몇몇 유용한 내용을 전달하는데, 데이터를 가져오기 위해 서버에 접속하는 모바일 애플리케이션에 대해 ‘ping’ 을 하는 것과는 대조적으로 말이죠.
메시지들은 notification 메시지들을 제외하고 기본적으로 non-collapsible 인데, notification 메시지들은 항상 collapsible 이다. GCM 은 전달 순서를 보장하지 않는다.
non-collapsible 메시지들의 몇몇 전형적 사용방법으로는 채팅메시지나 중요한메시지들입니다. 예를들어, IM 애플리케이션에서, 당신은 모든 메시지를 전달하고 싶을텐데, 왜냐하면 모든 메시지가 다른 내용을 가지고 있기 때문이죠.
Note: collapsing 없이 100개의 메시지 제한으로 저장될 수 있다고 봅시다. 만약에 제한에 도달했을 때, 모든 메시지들은 제거될 것입니다. 단말기가 다시 온라인 상태가되면, 제한에 도달했음을 나타내는 메시지를 받을 것입니다. 애플리케이션은 그 상황을 적절하게, 전형적으로 앱서버로부터 전체 동기화 요청에 의해서 처리할 수 있을 것입니다.
Collapsible message
collapsible 메시지는 메시지가 아직 단말기에 도달하지 않았을 때 같은 collapse key 를 가진 새로운 메시지에 의해서 대체될 수 있다는 것입니다.
collapsible 메시지의 두가지 일반적인 사용 경우는 Send-to-Sync 메시지와 notification 입니다. Send-to-Sync 메시지는 서버로부터의 데이터를 동기화 시키기 위해 모바일 애플리케이션에 말하는 “ping”같은 것 입니다. 한가지 예로 스포츠 애플리케이션에서 사용자의 최종 스코어를 갱신하는 것 입니다. 오직 가장 최근의 메시지만 의미가 있을 것 입니다.
GCM은 언제든지간에 단말기 당 앱서버에 의해 사용되어지는 최대 4가지의 다른 collapse key들을 사용할 수 있습니다. 다른 말로 하면, GCM connection server 는 각각의 다른 collapse key로 동시적으로 4개의 다른 collapsible Send-to-Sync 메시지들을 한 단말기당 저장할 수 있다는 말이다. 만약에 GCM 이 유지하는 4개의 collapse key를 초과한다면, 어떤 키가 유지될지에 대해서 어떤 보장도 하지 않습니다.
iOS에서, 앱서버가 Send-to-Sync 메시지를 보내야 할 필요가 있을 때 content_available 를 설정해야 합니다. 비활성화된 클아이언트 앱은 백그라운드에서 여러분의 로직을 실행할 것이고, 포그라운드일 경우에는 메시지를 didReceiveRemoteNotification:. 로 메시지를 전달할 것입니다.
|
Which should I do?
Collapsible 메시지는 성능 관점에서는 좀 더 나은 선택이고, 여러분의 애플리케이션이 non-collapsable 메시지를 사용할 필요가 없게 제공되어집니다. 그러나, 만약 collapsible 메시지를 사용하겠다면, GCM이 최대 4가지의 다른 collpase key에 대해서만 언제든지간에 등록된 토근당 GCM Connection server 에 의해서 사용되어지는 것만 허용합니다. 여러분은 제한된 숫자를 초과해서는 안되는데, 말하자면 예측할 수 없는 결과들을 야기시킬 수 있기 때문입니다.
Use scenario
| How to send
|
|
Non-collapsible
| 모든 메시지는 클라이언트 앱에 중요하고 전달되어져야만 한다.
| notificaiton 메시지들을 제외하고, 모든메시지들은 기본적으로 non-collapsible 이다.
|
Collapsible
| 새로운 메시지가 있을 때 클라이언트 앱에 무관한 메시지는 오래된 메시지로 바꿔버리는데, GCM이 그 오래된 메시지를 교체합니다.
| collapse_key 파라메타를 설정하면 됩니다.
|
Setting the priority of a message
다운스트림 메시지에 대해서 전달 우선순위를 할당하는 2가지 옵션이 있습니다. 보통 그리고 높은 우선순위. 높음과 보통 우선순위 메시지 전달은 다음과 같이 동작합니다.
- High Priority. GCM 은 높은 우선순위의 메시지들을 즉시 전달하려고 하는데, GCM 서비스가 가능할 때 그리고 당신의 앱서버로 네트워크 연결을 열었을 때 잠자고 있는 단말기를 깨우는 것을 허용한다. 예를들어, 인스턴스메시지, 채팅, 음성전화알림과 같은 앱들처럼 일반적으로 네트웍연결을 개방할 필요가 있고 GCM 이 단말기로 메시지를 전달하는 것을 보장합니다. 만약에 메시지가 time-critical 하고 사용자의 즉작적인 반응이 요구된다면 높은 우선순위로 설정하고, 조심해야 할 것이 있는데 높은 순위로 메시지를 설정하는 것은 일반 우선순위 메시지들과 비교해서 좀 더 베터리를 닳게 하는 원인이 된다는 것입니다.
- Nomal Priority. 보통 우선순위는 메시지 전달의 개본 우선순위입니다. 보통 우선순위 메시지들은 잠자고 있는 단말기에 대해서 네트워크 연결을 개방할 필요가 없고, 메지시 전달은 베터리를 아끼기 위해서 지연될 것입니다. 시간에 민감하지 않은 메시지들에 대해서는, 이메일 통지나 다른 데이터를 동기화해야하는 경우처럼 전달 우선순위를 보통으로 선택합니다.
iOS 클라이언트 앱에선, 보통과 높음이 APNS 우선순위 레벨5와 레벨10이 비슷하다. iOS 명확한 행동에 대한 모든 자세한 내용은, APNs 문서를 보세요. 안드로이드 명확한 행동에 대한 자세한 내용은, Doze 와 App Stanby 에 대한 최적화 문서를 보세요.
여기에 잡지 구독자에게 알리기 위한 보통우선순위 메시지의 예제가 있는데, 새로운 내용을 다운로드 할 수 있다는 것 입니다.
{ "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...", "priority" : "normal", "notification" : { "body" : "This week’s edition is now available.", "title" : "NewsMagazine.com", "icon" : "new", }, "data" : { "volume" : "3.21.15", "contents" : "http://www.news-magazine.com/world-week/21659772" } } |
Setting the lifespan of a message
GCM 은 일반적으로 메시지들이 보내지면 메시지들을 즉시 전달한다. 그러나, 항상 그런 것은 아닙니다. 예를 들어, 안드로이드 플랫폼의 경우에는, 단말기가 꺼져있거나 인터넷 연결이 안 되어 있을 경우에는 이용할 수 없습니다. 또는 보내는 쪽에서 단말기가 그들 스스로 ‘delay_while_idle’ 플래그를 사용하여 활성화 될 때까지 메시지들이 전달되지 않도록 요청할 것입니다. 마지막으로, GCM은 의도적으로 지나친 리소스 사용과 부정적인 영향을 주는 베터리 수명으로부터 애플리케이션을 보호하기 위해서 메시지들을 지연시킵니다.
이러한 일어났을 때, GCM은 메시지들을 저장하고 가능한 실행할 수 있게 전달한다. 대부분의 경우에서 메시지 전달이 잘 되는 반면에, 늦은 메시지에 대해서도 잘 전달되지 않는 몇몇의 애플리케이션들이 있을 수 있습니다. 예를 들면, 메시지가 걸려오는 전화나 영상 통화 알림이라면, 그 알림은 전화가 끝나기전까지 짧은 시간에 의미가 있을 것입니다. 또는 특정 메시지가 어떤 이벤트에 초대받았는데, 이벤트가 끝난 후에 알림을 받게 되어 쓸모없을 경우가 있습니다.
여러분은 ’time_to_live’ 인자를 사용할 수 있는데, HTTP 와 XMPP 요청 모두를 지원하고, 메시지의 최대수명을 명시합니다. 인자의 값은 0부터 2,419,200초 까지고, GCM이 메시지를 저장하고 다시 전달하기를 시도하기 위한 최대시간에 상응합니다. 요청들은 4주라는 최대기간의 기본값의 필드를 포함할 수 없습니다. ??
여기에 이 기능을 위한 몇몇 사용예시가 있습니다.
- 걸려오는 전화의 영상통화
- 이벤트 초대의 파기
- 달력 이벤트
메시지의 수명을 정하는 다른 이점은 GCM이 절대 메시지들을 ‘time_to_live’값을 0초로 throttle 하지 않는 다는 것입니다. 다른말로, GCM은 메시지가 전달되어지도록 “지금 즉시 당장” 최선의 노력을 보장한다는 것 입니다. ‘time_to_live’ 값이 0을 가진 메시지들은 즉시전달되어질 수 없다는 것을 명심하고, 그것들은 폐기될 것 입니다. 그러나, 어떤 메시지들은 저장되어질 수 없기 때문에, 알림을 보내기 위한 최고의 대시시간을 제공할 것 입니다.
여기에 TTL을 포함한 JSON형식의 요청에 대한 예제가 있습니다.
{ "collapse_key" : "demo", "delay_while_idle" : true, "to" : "xyz", "data" : { "key1" : "value1", "key2" : "value2", }, "time_to_live" : 3 }, |
현재, time_to_live 는 iOS에 대한 메시지 알림에 대해서는 지원하지 않습니다. |
Receiving messages from multi-senders.
GCM은 같은 클라이언트 앱으로 메시지를 보내기 위한 다중 parties를 허용합니다. 예를 들어, 어떤 클라이언트 앱이 여러 기고자로 이루어진 기사 서비스를 한다고 가정하고, 그들중 각각이 새로운 기사를 쓸 때 메시지가 보내져야한 하는데요. 메시지가 URL을 포함해서 클라이언트 앱이 기사를 다운로드 할 수 있습니다. 한 장소에서 모든 보내는 동작을 중앙집중화 하는 대신에, GCM은 당신에게 기고자들 각각에게 메시지를 보낼 수 있는 능력을 줄 것 입니다.
이게 가능하게 하려면, 각각의 발송서버가 그 자신의 senderID를 생성해야만 합니다. 어떻게 GCM senderID를 획득하는지에 대한 정보에 대해서는 당신의 플랫폼에 대한 클라이언트 문서를 보세요. 등록요청을 했을 때, 클라이언트 앱은 여러번 token을 가져올텐데, 매번 audience field 의 서로 다른 senderID로 가져올 것 입니다.
마지막으로, 앱서버에 대응하는 등록토큰을 공유하면(GCM 등록 클라이언트/서버 handshake를 완료하기 위해), 자신의 인증키를 사용해서 클아이언트 앱으로 메시지들을 보낼 수 있습니다.
Note 다중 sender 에는 100개의 제한이 있습니다.
Lifetime of a message
앱서버가 GCM으로 메시지를 올리고 메지시 ID 를 돌려받았을 때, 메시지가 단말기로 이미 전달되었다는 것을 의미하지는 않습니다. 더 정확히 말하면, 전달을 위해 인수가 끝난 것을 의미합니다. 많은 요인들에 의존하여 메시지가 인수되어진 후에 메시지들에게 어떤 일들이 일어날까요.
최상의 시나리오는, 단말기가 GCM에 연결되었을 때, 그리고 화면이 켜져있으면 거기에는 어떠한 throttling 제한도 없을 것이며, 메시지는 바로 전달될 것 입니다.
단말기가 GCM에 연결되었지만 idle 상태일 때는, 메시지는 ‘delay_while_idle’ 플래그가 true 로 설정되어 바로 전달될 것 입니다. 그 외에는, 메시지들은 단말기가 깨어날 때까지 GCM connection server 에 저장될 것 입니다. 그리고 ‘collapse_key’ 플래그가 한가지 규칙을 수행할 것입니다: 만약에 메시지가 이미 같은 collapse key로 전달을 위해 저장되어있고 기다라고 있다면, 오래된 메시지는 폐기될 것이고 새로운 메시지가 대체할 것입니다. 그러나, collapse_key 가 설정도어 있지 않다면, 새로운 것이나 오래된 것이나 향후 전달을 위해 저장될 것입니다.
만약에 단말기가 GCM에 연결되어 있지 않다면, 메시지는 연결이 성립될 때까지 저장될 것입니다(collapse key 규칙을 다시 고려하라). 연결이 성립되었을 때, ‘delay_while_idle’ 플래그가 있음에도 불구하고 GCM은 단말기로 모든 기다리는 메시지들을 전달할 것입니다. 만약에 단말기가 다시 연결되지 않는다면(예를들어어, 단말기가 공장도 초기화 된다면), 결국에 메시지는 타임아웃될 것이고 GCM 저장소에서 폐기될 것입니다. 타임아웃 초기값은 4주인데, ’time_to_live’ 값이 셋팅된 것 이외의 경우가 해당됩니다.
마지막으로, GCM이 단말기로 메시지를 전달하려고 시도하려느데 앱이 설치되어있지 않을때, GCM은 바로 그 메시지를 폐기시키고 등록토큰을 무효화시킬 것 입니다. 미래에 그 단말기로 메시지를 보내려고 할 때 ’NotRegistered’ 에러를 가지게 될 것 입니다.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
반응형