[Android] Google Cloud Messaging (GCM): Messaging Concepts and Options

메시지 구성 요소

앱 서버는 기본 구성 요소(대상, 메시지 옵션 및 페이로드)로 부터 다운스트림 메시지 요청을 작성합니다.

Target (필수)

앱 서버가 메시지를 보내면 메시지의 목적지를 식별하는 대상(target)을 지정해야합니다. to 필드를 사용하여 대상(target)을 지정합니다. 이 필드에는 signle registration token, a topic 또는 a notification key (디바이스 그룹 보내기를 위한)가 포함될 수 있습니다.

Option

앱 서버는 클라이언트 앱에 다운 스트림 메시지를 보낼 때 다양한 옵션을 설정할 수 있습니다. 예를 들면, 메시지를 후속 메시지로 대체해야하는지 여부

Payload

다운스트림 메시징의 경우 GCM은 notification과 data라는 두가지 유형의 페이로드를 제공합니다. 알림(notification)은 2KB 제한 및 미리 정의된 사용자가 볼 수 있는 키 세트가 있는 가벼운 옵션입니다. 개발자는 Data payload를 사용하여 최대 4KB의 커스텀 key/value 쌍을 보낼 수 있습니다. Notification 메시지에는 사용자가 알림을 클릭했을 때 배달되는 optional data payload가 포함될 수 있습니다.

	Use scenario	How to send
Notification	GCM은 클라이언트 앱을 대신하여 최종 사용자 기기에 자동으로 메시지를 표시합니다. Notifications는 미리 정의 된 사용자가 볼 수 있는 키가 있습니다.	Notification payload를 설정합니다. Optional data payload가 있을 수 있습니다. 항상 접을 수 있습니다.
Data	클라이언트 앱은 data 메시지 처리를 담당합니다. Data message는 사용자 Key/Value 쌍만 있습니다.	Data payload만 설정합니다. 접을 수 있거나 접을 수 없습니다.

GCM이 클라이언트 앱을 대신하여 알림 표시를 처리하도록하려면 알림을 사용합니다. Android 클라이언트 앱에서 메시지를 처리하거나 디스플레이를 처리하려면 data message를 사용합니다. 직접 GCM connection이 있는 경우 iOS 기기로 메시지를 보내려면 data message를 사용합니다.

앱 서버는 Notification과 Data payload를 모두 포함하는 메시지를 보낼 수 있습니다. 이 경우, GCM은 Notification payload를 표시하고 클라이언트 앱이 Data payload를 처리합니다. 자세한 내용과 예는 메시지 페이로드의 알림 및 데이터를 참조하십시요.

Message payload의 Notifications과 Data

Notifications은 미리 정의 된 키와 Optional Custom Key/Value 쌍을 사용하여 유저에게 표시되는 메시지를 쉽게 보내는 방법을 개발자에게 제공합니다. Data payloads는 개발자의 Custom Key/Value 쌍만 포함되며 클라이언트 앱은 이 메시지를 처리해야합니다. Notification과 Data payloads가 모두 포함된 메시지를 보낼 수 있습니다.

Notifications

Notifications를 보내려면 Notification 메시지의 사용자에게 보여지는 부분을 미리 정의된 키 옵션을 세트를 사용하여 Notification을 설정합니다. 예를 들어, 다음은 IM 애플리케이션의 JSON 형식의 Notification 메시지입니다.

 {
    "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification" : {
      "body" : "great match!",
      "title" : "Portugal vs. Denmark",
      "icon" : "myicon"
    }
  }

앱이 비활성 상태 일 때 알림은 Notification tray에 전달됩니다. 활성 상태의 iOS 앱의 경우 Notifications는 didReceiveRemoteNotification: 에 대신 전달됩니다. 활성 상태의 Android 앱은 data bundle에 notification 키로 onMessageReceived()로 전달됩니다.

Data messages

클라이언트 앱에 data payload를 보내려면 Custom key/value 쌍으로 data를 설정합니다. Data messages는 최대 4KB의 payload를 가질 수 있습니다.

예를 들면, 아래와 같이 IM 응용프로그램에서 JSON 형식의 메시지가 있습니다. 여기서 information은 data로 캡슐화되고 클라이언트 앱은 내용을 해석해야합니다.

{
   "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
   "data" : {
     "Nick" : "Mario",
     "body" : "great match!",
     "Room" : "PortugalVSDenmark"
   }
 }

Android에서 클라이언트 앱은 onMessageReceived()에서 data messages를 수신하고 key/value 쌍을 처리할 수 있습니다. iOS에서 GCM은 message 저장하고 앱이 GCM과 연결되어있고 foreground에 있을 때만 전달합니다.

플랫폼별 세부 정보는 다음과 같습니다.

• Android: Data payload는 Activity를 시작하는데 사용된 Intent에서 가져올 수 있습니다.
• iOS: Data payload는 didReceveRemoteNotification: 에서 찾을 수 있습니다.

앱이 백그라운드에 있을 때 iOS 기기로 Custom key/values 만으로 구성된 메시지를 보내려면 Data에 Custom key/value를 설정하고 content_available을 true로 설정합니다.

Notification과 Data payload가 모두 포함된 Hybrid 메시지

Notification과 Data payload가 모두 포함된 메시지를 수신할 때의 앱의 동작은 앱이 백그라운드에 있는지 아니면 포그라운드에 있는지에 따라 다릅니다.

• 백그라운드에 있을 때: 앱은 Notification tray에서 Notification payload를 수신하고, 사용자가 Notification을 탭할 때만 Data payload를 처리합니다.
• 포그라운드에 있을 때: 앱은 두 페이로드를 모두 사용할 수 있는 번들을 받습니다.

Notification과 Data가 모두 포함된 JSON 형식의 메시지는 다음과 같습니다.

  {
    "to" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx...",
    "notification" : {
      "body" : "great match!",
      "title" : "Portugal vs. Denmark",
      "icon" : "myicon"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }

일반적으로 사용되는 메시지 옵션

가장 일반적으로 사용되는 옵션 중 하나인 Collapsible Messaging(축소 가능한 메시지), Using Multiple Senders, 메시지 우선 순위 설정 및 메시지 수명(Lifespan)에 대해서 설명합니다.

Collapsible and non-collapsible messages

Non-collapsible messages (축소할 수 없는 메시지)

Non-collapsible messages는 각 개별 메시지가 장치에 배달됨을 의미합니다. Non-collapsible messages는 모바일 애플리케이션에서 데이터를 가져오기 위해 서버에 연결하는 "ping"과 달리, 유용한 콘텐츠를 전달합니다. Messages는 항상 collapsible한 Notification Message를 제외하고 기본적으로 Non-collapsible 입니다. GCM은 전달 요청을 보장하지 않습니다.

Non-collapsible 메시지의 일반적인 사용 사례는 채팅 메시지 또는 중요한 메시지입니다. 예를 들어 IM 응용프로그램에서는 모든 메시지 마다 다른 콘텐츠가 있기 때문에 모든 메시지를 전달하려고 합니다.

Note: 축소되지 않고 저장할 수 있는 메시지 수는 100개로 제한됩니다. 한도에 도달하면 저장된 모든 메시지가 삭제됩니다. 디바이스가 다시 온라인 상태가 되면 제한에 도달했음을 나타내는 특수한 메시지가 수신됩니다. 애플리케이션은 일반적으로 앱 서버에 전체 동기화를 요청하여 상황을 적절하게 처리할 수 있습니다.

Collapsible messages (축소 가능한 메시지)

Collapsible Message는 아직 장치에 전달되지 않은 경우 동일한 Collapse 키가 포함된 새로운 메시지로 대체 될 수 있는 메시지입니다.

Collapsible Message의 두가지 일반적인 사용 사례는 Send-to-Sync 메시지 및 Notifications 입니다. Send-to-Sync 메시지는 모바일 애플리케이션에 서버의 데이터를 동기화하도록 지시하는 "ping"입니다. 예를 들어 사용자에게 최신 점수를 업데이트하는 스포츠 애플리케이션이 있습니다. 가장 최근의 메시지만 관련됩니다.

GCM은 주어진 시간에 기기별로 앱 서버에서 사용할 수 있는 최대 4개의 서로 다른 Copllapse 키를 허용합니다. 즉, GCM Connection 서버는 각기 다른 Collapsible 키를 사용하여 기기별로 4개의 서로 다른 Collapsible Send-to-Sync 메시지를 동시에 저장할 수 있습니다. 이 개수를 초과하면 GCM은 4개의 Collapse 키만 유지하며 어떤 키가 유지되는지에 대해서는 보장하지 않습니다.

iOS에서는 앱 서버가 Send-to-Sync 메시지를 보내야할 때 content_available을 설정해야합니다. 비활성 클라이언트 애플리케이션은 백그라운드에서 로직을 실행하지만 포그라운드 애플리케이션은 didReceiveRemoteNotification:에 메시지를 전달합니다.

어느 것을 사용해야 하나?

애플리케이션에서 Non-Collapsible Message를 사용할 필요가 없는 경우 Collapsible 메시지는 성능 측면에서 더 나은 선택입니다. 그러나 Collapsible 메시지를 사용하는 경우 GCM은 주어진 시간에 등록 토큰 당 GCM Connection 서버가 사용할 수 있는 최대 4개의 서로 다른 Collapse 키만 허용합니다. 이 개수를 초과해서는 안되면, 예기치 않은 결과를 초래할 수 있습니다.

	Use scenario	How to send
Non-collapsible	모든 메시지는 클라이언트 앱에 중요하므로 전달될 필요가 있습니다.	Notification 메시지를 제외한 모든 메시지는 기본적으로 Non-collapsible 입니다.
Collapsible	클라이언트에게 무의미한 이전의 관련 메시지를 렌더링하는 새로운 메시지가 있을 때 GCM은 이전 메시지를 대체합니다.<ㅠr>예: Send-to-Sync 또는 오래된 Notifications	collapse_key 매개 변수를 설정합니다.

메시지 우선 순위 설정

다운 스트림 메시지에 배달 우선 순위를 할당하는 두가지 옵션이 있습니다. Normal 과 High Priority. Normal과 High Priority의 배달은 다음과 같이 동작합니다.

• High priority: 이것은 Notification Messages의 기본 Priority 입니다. GCM은 우선 순위가 높은 메시지를 즉시 전달하려고 시도합니다. 가능한 경우 잠자기 상태의 기기를 깨우고 앱 서버에 네트워크 연결을 오픈합니다. 예를 들어 인스턴스 메시징, 채팅 또는 음성 통화 알림이 있는 앱은 일반적으로 네트워크 연결을 열고 딜레이 없이 GCM이 메시지를 기기에 전달하도록 해야합니다. 메시지가 시간에 민감하여 사용자의 즉각적인 상호작용이 필요한 경우 High Priority를 설정합니다. 메시지를 High Priority로 설정하면 Nomal Priority메시지와 비교했을 때 배터리가 더 많이 소모된다는 점에 유의해야합니다.

• Normal priority: 이것은 Data 메시지의 기본 Priority입니다. Normal Priority 메시지는 절전 모드 상태의 디바이스에서 네트워크 연결을 열지 않으며 베터리를 절약하기 위해 지연 될 수 있습니다. 새 이메일 또는 동기화 할 다른 데이터의 알림과 같이 시간에 민감하지 않은 메시지의 경우 Normal Priority를 선택하십시요.

유효한 값은 "high"와 "normal" 입니다.

iOS 클라이언트 애플리케이션의 경우 Normal과 High Priority는 APNs 우선순위 레벨 5와 10과 유사합니다.

다음은 잡지 구독자에게 새로운 콘텐츠를 다운로드 할 수 있다는 사실을 알려주는 Normal Priority 메시지의 예입니다.

{
  "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"
  }
}

메시지의 수명(lifespan) 설정하기

GCM은 일반적으로 메시지를 보낸 즉시 메시지를 전달합니다. 하지만, 이것은 항상 가능하지 않습니다. 예를 들어, 안드로이드인 경우 기기를 끄거나 오프라인으로 설정하거나 사용할 수 없는 상태일 수 있습니다. GCM은 앱이 과도한 리소스를 소비하거나 배터리 수명에 부정적인 영향을 미치지 않도록 의도적으로 메시지를 지연시킬 수 있습니다.

이 경우 GCM은 메시지를 저장하고 실행 가능할 때 즉시 전달합니다. 대부분의 경우 문제가 되지 않지만, 늦은 메시지가 전달되지 않을 수도 있는 몇 가지 애플리케이션이 있습니다. 예를 들어, 전화가 걸려오는 메시지 또는 영상 채팅 알림 메시지인 경우, 통화가 종료되기 전에 잠시 동안만 의미가 있습니다. 또는 메시지가 이벤트 초대장인 경우, 이벤트가 끝난 후에 수신하면 쓸모가 없습니다.

HTTP 및 XMPP 요청에서 지원되는 time_to_live 파라미터를 사용하여 메시지의 최대 수명(lifespan)을 지정할 수 있습니다. 이 파라미터의 값은 0에서 2,419,200 초까지의 기간이어야하며 GCM이 메시지를 저장하고 전달하려고 시도하는 최대 기간에 해당합니다. 이 필드를 포함하지 않는 요청의 최대 기간은 기본적으로 4주입니다.

다음과 같은 경우에 이 기능을 사용 가능합니다.

• 화상 채팅 수신 전화
• 만료되는 초대 이벤트
• 캘린더 일정

메시지의 수명(lifespan)을 지정할 때 또 다른 이점은 GCM이 0초의 time_to_live 값으로 메시지를 조절하지 않는 것입니다. 다시 말해, GCM은 "now or never" 로 전달되어야 하는 메시지에 대해 최선의 노력을 보장합니다. time_to_live 값 0은 즉시 배달할 수 없는 메시지는 삭제됨을 의미합니다. 하지만, 이러한 메시지는 저장되지 않으므로 알림을 보내는 데 가장 좋은 대기 시간(latency)을 제공합니다.

다음은 TTL을 포함하는 JSON 형식 요청의 예입니다.

{
   "collapse_key" : "demo",
   "delay_while_idle" : true,
   "to" : "xyz",
   "data" : {
     "key1" : "value1",
     "key2" : "value2"
   },
   "time_to_live" : 3
 }

현재 iOS의 Notification Messages에는 time_to_live가 지원되지 않습니다.

다중 발신자로부터 메시지 수신 (Receiving messages form multi-senders)

GCM은 동일한 클라이언트 앱에 여러 당사자(?)가 메시지를 보낼 수 있습니다. 예를 들어, 클라이언트 앱이 여러 참여자가 있는 기사 집계자(?)라고 가정합니다. 그들 각각은 새로운 기사를 발표할 때 메시지를 보낼 수 있어야 합니다. 이 메시지는 클라이언트 앱이 기사를 다운로드 할 수 있도록 URL이 포함될 수 있습니다. GCM은 모든 전송 활동을 한 곳에서 중앙 집중화 하는 대신, 각 참여자가 자체 메시지를 보낼 수 있는 기능을 제공합니다.

이를 가능하게 하려면 각 발신인이 고유한 발신자 ID(Sender ID)를 생성해야 합니다. GCM Sender ID를 얻는 방법에 대한 자세한 내용은 사용중인 플랫폼의 클라이언트 문서를 참조하십시요. 등록을 요청할 때, 클라이언트 애플리케이션은 매번 대상 필드에 다른 Sender ID로 토큰을 여러번 가져옵니다.

마지막으로, 등록 토큰을 해당 앱 서버(GCM 등록 클라리언트/서버 handshake를 완료하기 위해)와 공유하면 자신의 인증키를 사용하여 클라이언트 앱에 메시지를 보낼 수 있습니다.

Note : 멀티 Sender ID는 100 개로 제한되어 있습니다.

메시지 수명(Lifetime)

앱 서버가 GCM에 메시지를 게시하고 메시지 ID를 다시 받으면, 해당 메시지가 이미 기기로 전달되었음을 의미하지는 않습니다. 오히려 이것은 배달을 위해 받아들여 졌음을 의미합니다. 그것이 받아 들여지는 메시지는 여러가지 요인에 따라 달라집니다.

최상의 시나리오에서, 장치가 GCM에 연결되어 있고 화면이 켜져 있고 제한이 없으면 메시지가 즉시 전달됩니다.

장치가 연결되어 있지만 Doze 모드인 경우 low 우선 순위 메시지는 장치가 Doze 모드를 벗어날 때까지 GCM에 저장됩니다. 그리고 이것이 collapse_key 플래그가 역할을 하는 곳입니다. 동일한 collapse 키(및 등록 토큰)가 저장되어 있고 전달을 기다리는 메시지가 이미 있는 경우 이전 메시지가 삭제되고 새 메시지가 대체됩니다.(즉, 이전 메시지는 새 메시지로 축소됩니다.) 하지만 collapse 키가 설정되어 있지 않은 경우 새 메시지와 이전 메시지 둘 다 향 후 배달을 위해 저장됩니다.

기기가 GCM에 연결되어 있지 않으면 이 메시지는 연결이 설정될 때 까지 저장됩니다. 연결이 설정되면 GCM은 대기중인 모든 메시지를 기기로 전송합니다. 기기가 다시 연결되지 않으면 (예: 공장 초기화 된 경우) 메시지는 결국 시간이 초과되어 GCM 저장 장치에서 삭제됩니다. time_to_live 플래그가 설정되어 있지 않으면 기본 시간 초과 시간은 4주입니다.

마지막으로 GCM이 기기에 메시지를 전송하려고 시도하고 애플리케이션이 제거되면 GCM은 해당 메시지를 즉시 삭제하고 등록 토큰을 무효화합니다. 해당 장치로 메시지를 보내려고 하면 NotRegistered 오류가 발생합니다.

참고 사이트

• Google Cloud Messaging - Messaging Concepts and Options