Tag: request

TÌm hiểu cấu trúc dữ liệu request và response cho GCM.

Lần trước mình đã tìm hiểu cơ bản về Google  Cloud Message for Android (GCM).
http://tuantranf.wordpress.com/2013/04/16/android-notification-by-nodejs-1-google-cloud-messaging-for-android/
Tool hỗ trợ: Một add-on của chrome dùng để thực hiện request.
DEV HTTP CLIENT
Cottonballs:
Server giả lập trên local host để thay thế cho GCM. Thay vì gửi message đến GCM có thể gửi đến cottonballs để test.Ngoài ra có các chức năng tạo delay, failure để test.
Hôm nay mình sẽ tìm hiểu kĩ hơn về cấu trúc dữ liệu khi tạo request và giải mãi response từ server của GCM trước khi bắt tay vào thiết kế ứng dụng.
Nguồn http://developer.android.com/google/gcm/gcm.html

Cấu trúc dữ liệu request

Header của HTML

  • Authorization: key=YOUR_API_KEY
  • Content-Type:
    •  application/json (Nếu request là JSON)
    •  application/x-www-form-urlencoded;charset=UTF-8 (nếu request là plain text)

Cụ thể nội dung của Header sẽ như sau.(Vì mình chỉ dùng Json nên sẽ lược bỏ phần chú thích về plain text.

Content-Type:application/json
Authorization:key=AIzaSyB-1uEai2WiUapxCs2Q0GZYzPu7Udno5aA

Về dữ liệu JSON gửi đi:

{
// ID đăng ký của các device cần gửi (được quản lý trong DB)
"registration_ids":["4", "8", "15", "16", "23", "42"],
// Một số thiết định khác
// Tên group dùng để nhóm các notification cùng nhóm lại với nhau.
"collapse_key": "update",
// Thời gian sống sót của message trên server GCM khi failure do device offline.Mặc định là 4 tuần.
"time_to_live": 180,
// Đợi đến khi device idle thì mới gửi
"delay_while_idle": true,
// Tên package khi chỉ định chỉ gửi cho các device có pakage này
"restricted_package_name": "package_name",
// chế độ dryrun để test.
"dry_run": false,
// Dữ liệu cần gửi
"data": {
"score": "4x8",
"time": "15:16.2342"
}
}
Chú ý: Tổng kích thước của một lần gửi (RegistrationIDs + Options + Data) giới hạn là 4kb, khi số lượng Registration IDs càng nhiều thì dung lượng data giới hạn lại càng bé đi.

Giải mã GCM Response

Status code trả về khi gửi message
200 Message được xử lý thành công (POST OK).Thực tế có push đến từng device hay không thì ??? 🙁
Khi gửi thành công thì sẽ trả về thông tin của message.
400 Xử lý JSON đã gửi trướng hợp parse request thất bại, hoặc thiếu các mục yêu cầu trong JSON, phải sửa lại JSOn trước khi thử lại
401 Có lỗi thì xử ly đăng nhập, xác nhận của ID người gửi (YOUR_API_KEY)
5xx Các lỗi trong khoảng 500-599  lỗi của server GCM khi thực hiện request và sẽ thử lại nếu Header thiết định parameter Retry-After
Nội dung GCM response// Trường hợp gửi message đến 6 ID (IDs 4, 8, 15, 16, 23, và 42)
// 3 messages thành công , 3 thất bại ta sẽ có response JSON như sau
{"multicast_id": 216, // ID của message
"success": 3, // Số lượng xử lý thành công
"failure": 3, // Số lượng xử lý thất bại
"canonical_ids": 1, // ID of the last registration requested by your application là ID đăng ký cuối cùng trường hợp 1 device đăng ký nhiều ID
"results": [ // Kết quả gửi message
{ "message_id": "1:0408" }, // Message id 1 thành công , không cần gì (ID4)
{ "error": "Unavailable" },  // Cần gửi lại (ID8)
{ "error": "InvalidRegistration" }, // Lỗi dữ liệu đăng ký (ID15)
{ "message_id": "1:1516" }, // Gửi thành công (ID16)
{ "message_id": "1:2342", "registration_id": "32" }, // Gửi thành công như có yêu cầu update registration ID từ 23->23 (ID23)
{ "error": "NotRegistered"} // Lỗi ID không đăng ký / bị xoá do remove application trên device (ID42)
]
}

Conclusion

Hôm nay mình đã tìm hiểu về cấu trúc (format) dữ liệu khi request thông tin đến GCM server và giải mã response của GCM để xử lý retry hay hiển thị lỗi.