C2DM의 기본적인 속성
* 서버에서 안드로이드 앱에 짧은 메시지를 보낼 수 있습니다. 이 서비스는 많은량의 내용을 메시지를 통해서 보내는데에 적합하지 않습니다. 대신, 서버에 새로운 데이터가 있다는 사실을 알려줌으로서 앱이 직접 이를 불러오는 방식을 취하는 편이 좋습니다.
* C2DM은 메시지가 도착했는지의 여부와 메시지의 도착 순서를 보증하지는 않습니다. 그러므로 만약 실시간 메신저를 만든다고 가정할 때, 이 메시지에 실제 본문내용을 첨부하는것은 적절하지 않습니다.
* 메시지를 받기 위해 안드로이드 앱이 동작하고 있을 필요는 없습니다. 시스템은 메시지가 도착하면 Intent 메시지를 뿌림으로서 어플리케이션을 동작시킬것입니다. 물론 앱은 브로드캐스트 수신과 권한에 대해 설정이 되어있어야 합니다.
* 이 서비스는 내장된 UI나 메시지 처리메소드등을 포함하진 않습니다. C2DM은 받아온 데이터 그대로를 앱에 전달만 할 뿐이고 이에 대한 처리는 앱상에서 이루어져야 합니다. 즉, 알림을 띄운다든가 UI를 보여준다든가 데이터를 동기화하는등의 모든 작업은 앱상에서 이루어져야 합니다.
* 이 서비스는 Market앱이 설치된 Android 2.2 혹은 그이상의 버전에서 사용할 수 있습니다. 단, 이는 Market을 통해서만 앱을 개발할 수 있다는 의미는 아닙니다.
* 이 서비스는 구글 서비스를 위한 기존의 연결을 사용합니다. 즉, 안드로이드 기기에서 사용자의 구글 계정이 설정되어있어야 합니다.
인증요소 * Sender ID : 앱 개발자의 Email 계정입니다. 메시지를 받을 안드로이드 앱을 구분하기 위하여 가입시에 사용됩니다.
* Application ID : 메시지를 받을 앱의 이름으로서, 각 앱은 manifest의 패키지 이름을 토대로 구분이 됩니다. 이는 메시지가 원하는 앱에 도달하도록 합니다.
* Registration ID : C2DM 서버에서 안드로이드 앱에 발행된 아이디로서, 메시지를 받도록 해줍니다. 앱은 이 ID값을 개발자의 서버에 보내고, 서버는 이 ID를 통하여, 특정 앱의 메시지를 받기위해 등록된 각각의 안드로이드 기기를 구분해 냅니다. 즉, Registration ID는 특정 안드로이드 기기상의 특정 앱을 구분하는데 사용됩니다.
* Google User Account : C2DM이 작동하기 위해서 안드로이드 기기는 적어도 하나이사의 로그인된 Google 계정을 필요로 합니다.
* Sender Auth Token : 개발자의 서버에 저장된 ClientLogin Auth 토큰은 Google 서비스에 접근할 수 있도록 합니다. 이 토큰은 메시지를 전송하는 POST요청의 헤더부에 포함됩니다.
C2DM의 진행 과정 * C2DM을 활성화 하기 : 안드로이드 앱이 메시지를 받기위해 등록하는 과정
1. 메시징 서비스를 사용하고자 할떄 가장 먼저 C2DM서버에 등록 Intent(com.google.android.c2dm.intent.REGISTER)를 보냅니다. 이 Intent는 Sender ID(앱에 메시지를 보내도록 허가된 계정으로서, 대개 앱 개발자의 메일주소) 와 Application ID를 포함합니다.
2. 만약 등록이 성공적으로 진행되었다면, C2DM 서버는 REGISTRATION Intent를 뿌림으로서 앱에 Register ID를 알려줍니다. 앱은 추후 사용을 위하여 이 Register ID를 저장해 두고 있어야 합니다. 참고로 Google측에서 정기적으로 이 값을 갱신할 수 있다는 점을 알아두세요. 그러므로 앱을 개발할 때, REGISTRATION Intent가 몇번이상 반복되어 뿌려질 수 있다는 사실을 인지하고 이에 적절히 응답할 수 있도록 앱을 개발하셔야 합니다.
3. 등록을 완료하기 위해서, 앱을 Register ID 값을 개발자 서버에 보내고, 개발자 서버는 이 값을 데이터베이스에 저장할 것입니다. Register ID값은 앱이 직접 등록을 해지하거나, 구글측에서 값을 갱신하기 전까지는 유효합니다.
* 메시지를 보내기 : 개발자 서버가 기기에 메시지를 보내는 과정
개발자 서버가 메시지를 보내기 위해서 앱은 Register ID값을 가지고 있으며, 개발자 서버에서도 이 값을 가지고 있어야 합니다. 또한 ClientLogin authorization token값이 개발자서버에 설정되어있어야 합니다.
ClientLogin 토큰은 특정 안드로이드앱에 메시지를 보낼 수 있도록 합니다. 하나의 개발자 서버는 하나의 ClientLogin토큰을 가짐으로서 하나의 앱의 다수의 Registration ID를 관리할 수 있습니다. 각각의 Registration ID는 특정 기기의 특정 안드로이드 앱을 가리킵니다. 아래는 개발자 서버가 메시지를 보낼때의 과정입니다.
1, 개발자 서버는 C2DM 서버에 메시지를 보냅니다.
2. Google은 이 메시지를 메시지 큐에 집어넣고, 안드로이드 기기가 활성화 되어있지 않은 경우를 위하여 보관해둡니다.
3. 안드로이드 기기가 활성화 되었을 경우(인터넷에 연결된 경우) 구글은 기기에 메시지를 보냅니다.
4. 기기상에서 시스템은 적절한 권한으로 Intent를 뿌림으로서 특정 앱이 메시지를 받도록 합니다. 이 과정은 앱이 작동하지 않은 상태에서 앱을 실행해주고 메시지를 받을 수 있도록 합니다.
5. 앱은 메시지를 적절히 처리합니다.
만약 앱이 더이상 메시지를 수신하기 원하지 않는다면 C2DM을 해지할 수 있습니다. (이후 C2DM 활성화 부분의 3번 과정 참조)
* 메시지를 받기 : 안드로이드 앱이 C2DM 서버에서 메시지를 받는 과정
1. 시스템은 메시지를 받고 메시지의 key/value 값을 추출합니다.
2. 시스템은 추출된 key/value 값을 com.google.android.c2dm.intent.RECIEVE Intent에 포함함으로서 특정 앱이 메시지를 받을 수 있도록 합니다.
3. 안드로이드 앱은 RECIEVE Intent에서 key값을 통하여 데이터를 받아오고, 이를 처리합니다.
* 사용자의 관점
안드로이드 기기 사용자가 C2DM 기능을 포함하는 앱을 설치할 떄, 앱이 C2DM 기능을 포함한다는 사실을 공지받고, 이를 승인함으로서 Android Market으로부터 권한을 부여받습니다. 개발자는 사용자가 C2DM 메시지를 더이상 받지 않도록 C2DM직접 해지기능을 추가할 수 있습니다. 앱의 삭제 또한 C2DM의 해지효과를 일으킬 수 있습니다.
Introduction
Here are the primary characteristics of Android Cloud to Device Messaging (C2DM):
•It allows third-party application servers to send lightweight messages to their Android applications. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the application that there is new data on the server, so that the application can fetch it.
•C2DM makes no guarantees about delivery or the order of messages. So, for example, while you might use this feature to tell an instant messaging application that the user has new messages, you probably would not use it to pass the actual messages.
•An application on an Android device doesn’t need to be running to receive messages. The system will wake up the application via Intent broadcast when the the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.
•It does not provide any built-in user interface or other handling for message data. C2DM simply passes raw message data received straight to the application, which has full control of how to handle it. For example, the application might post a notification, display a custom user interface, or silently sync data.
•It requires devices running Android 2.2 or higher that also have the Market application installed. However, you are not limited to deploying your applications through Market.
•It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.
Architectural Overview
This section gives an overview of how C2DM works.
This table summarizes the key terms and concepts involved in C2DM. It is divided into these categories:
•Components — The physical entities that play a role in C2DM.
•Credentials — The IDs and tokens that are used in different stages of C2DM to ensure that all parties have been authenticated, and that the message is going to the correct place.
Components
Mobile Device The device that is running an Android application that uses C2DM. This must be a 2.2 Android device that has Market installed, and it must have at least one logged in Google account.
Third-Party Application Server An application server that developers set up as part of implementing C2DM in their applications. The third-party application server sends data to an Android application on the device via the C2DM server.
C2DM Servers The Google servers involved in taking messages from the third-party application server and sending them to the device.
Credentials
Sender ID An email account associated with the application's developer. The sender ID is used in the registration process to identify a Android application that is permitted to send messages to the device. This ID is typically role-based rather than being a personal account—- for example, my-app@gmail.com.
Application ID The application that is registering to receive messages. The application is identified by the package name from the manifest. This ensures that the messages are targeted to the correct application.
Registration ID An ID issued by the C2DM servers to the Android application that allows it to receive messages. Once the application has the registration ID, it sends it to the third-party application server, which uses it to identify each device that has registered to receive messages for a given application. In other words, a registration ID is tied to a particular application running on a particular device.
Google User Account For C2DM to work, the mobile device must include at least one logged in Google account.
Sender Auth Token A ClientLogin Auth token that is saved on the third-party application server that gives the application server authorized access to Google services. The token is included in the header of POST requests that send messages. For more discussion of ClientLogin Auth tokens, see ClientLogin for Installed Applications.
Lifecycle Flow
Here are the primary processes involved in cloud-to-device messaging:
•Enabling C2DM. An Android application running on a mobile device registers to receive messages.
•Sending a message. A third-party application server sends messages to the device.
•Receiving a message. An Android application receives a message from a C2DM server.
These processes are described in more detail below.
Enabling C2DM
This is the sequence of events that occurs when an Android application running on a mobile device registers to receive messages:
1.The first time the application needs to use the messaging service, it fires off a registration Intent to a C2DM server.
This registration Intent (com.google.android.c2dm.intent.REGISTER) includes the sender ID (that is, the account authorized to send messages to the application, which is typically the email address of an account set up by the application's developer), and the application ID.
2.If the registration is successful, the C2DM server broadcasts a REGISTRATION Intent which gives the application a registration ID.
The application should store this ID for later use. Note that Google may periodically refresh the registration ID, so you should design your application with the understanding that the REGISTRATION Intent may be called multiple times. Your application needs to be able to respond accordingly.
3.To complete the registration, the application sends the registration ID to the application server. The application server typically stores the registration ID in a database.
The registration ID lasts until the application explicitly unregisters itself, or until Google refreshes the registration ID for your application.
Sending a Message
For an application server to send a message, the following things must be in place:
•The application has a registration ID that allows it to receive messages for a particular device.
•The third-party application server has stored the registration ID.
There is one more thing that needs to be in place for the application server to send messages: a ClientLogin authorization token. This is something that the developer must have already set up on the application server for the application (for more discussion, see Role of the Third-Party Application Server). Now it will get used to send messages to the device.
The ClientLogin token authorizes the application server to send messages to a particular Android application. An application server has one ClientLogin token for a particular 3rd party app, and multiple registration IDs. Each registration ID represents a particular device that has registered to use the messaging service for a particular 3rd party app.
Here is the sequence of events that occurs when the application server sends a message:
1.The application server sends a message to C2DM servers.
2.Google enqueues and stores the message in case the device is inactive.
3.When the device is online, Google sends the message to the device.
4.On the device, the system broadcasts the message to the specified application via Intent broadcast with proper permissions, so that only the targeted application gets the message. This wakes the application up. The application does not need to be running beforehand to receive the message.
5.The application processes the message. If the application is doing non-trivial processing, you may want to grab a wake lock and do any processing in a Service.
An application can unregister C2DM if it no longer wants to receive messages.
Receiving a Message
This is the sequence of events that occurs when an Android application running on a mobile device receives a message:
1.The system receives the incoming message and extracts the raw key/value pairs from the message payload.
2.The system passes the key/value pairs to the targeted Android application in a com.google.android.c2dm.intent.RECEIVE Intent as a set of extras.
3.The Android application extracts the raw data from the RECEIVE Intent by key and processes the data.
What Does the User See?
When mobile device users install an applications that include C2DM, they will get a permission from Android Market informing them that the application includes C2DM. They must approve the use of this feature to install the application. Depending on the implementation of the application, it may offer users the option of unregistering to receive messages. Uninstalling the application also has the effect of unregistering.
==============================
안드로이드 앱을 개발해야겠다고 마음먹고(물론 애플 앱도 있겠지만 개발의 편의상 이것 먼저) 오늘부터 시작한다. 이미 앱의 방향성과 구조는 생각해 둔 터라 하나하나 이제는 필요한 이론을 쌓는 중이고, 위의 C2DM은 애플 앱개발을 하면서 느낀 Push기능의 편의성을 그대로 잇기 위하여 사용할 기술이다. 우선 위의 출처에서 C2DM의 가장 기본적인 사항은 넘어가고 알아야 할 부분을 번역을 했다. 위에 특성란에서 밑줄 친 부분은 개발자가 꼭 알아야 할 사항이다. 가만보면 푸시서버를 못살게 구는 개발자들이 있는데 각각의 기능이 어떤 계기를 통해서 유래가 되었는지 생각히고 개발했으면 하는 바램이다. 그리고 부디 앞으로 개발하는동안 스마트폰의 특성상의 알수없는 예외와 오류들만 없기를 바랄 뿐이다.
댓글