FCM thường gửi tin nhắn ngay sau khi tin nhắn được gửi. Tuy nhiên, điều này không phải lúc nào cũng khả thi. Ví dụ: thiết bị có thể không hoạt động hoặc FCM có thể cố ý trì hoãn tin nhắn để ngăn ứng dụng tiêu thụ quá nhiều tài nguyên và ảnh hưởng tiêu cực đến thời lượng pin.
Trong những trường hợp này, FCM sẽ lưu trữ thông báo và gửi thông báo đó sớm nhất có thể. Mặc dù điều này không có vấn đề gì trong hầu hết các trường hợp, nhưng có một số ứng dụng yêu cầu gửi thông báo ngay lập tức. Ví dụ: thông báo về cuộc gọi đến hoặc lời mời tham gia sự kiện.
Trên Android và Web, bạn có thể chỉ định thời gian tồn tại tối đa của một thông báo. Giá trị này phải là khoảng thời gian từ 0 đến 2.419.200 giây (28 ngày) và tương ứng với khoảng thời gian tối đa mà FCM lưu trữ và cố gắng gửi thông báo. Theo mặc định, những yêu cầu không chứa trường này sẽ có hiệu lực trong tối đa 4 tuần.
Trên iOS, bạn có thể đặt tiêu đề apns-expiration trong đối tượng ApnsConfig. Để biết thêm thông tin, hãy tham khảo tài liệu của Apple về cách Gửi yêu cầu thông báo đến APN.
Sau đây là một số trường hợp có thể sử dụng tính năng này:
- Cuộc gọi đến trong cuộc trò chuyện video
- Sự kiện lời mời sắp hết hạn
- Sự kiện trên lịch
Một lợi ích khác của việc chỉ định thời gian tồn tại của thông báo là FCM không áp dụng tính năng điều tiết thông báo có thể thu gọn cho các thông báo có giá trị thời gian tồn tại là 0 giây. Xin lưu ý rằng giá trị ttl bằng 0 có nghĩa là
những thông báo không thể gửi ngay lập tức sẽ bị loại bỏ. Tuy nhiên, vì những thông báo như vậy không bao giờ được lưu trữ, nên điều này mang lại độ trễ tốt nhất cho việc gửi thông báo.
Dưới đây là ví dụ về một yêu cầu có chứa ttl:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
},
"apns":{
"headers":{
"apns-expiration":"1604750400"
}
},
"android":{
"ttl":"4500s"
},
"webpush":{
"headers":{
"TTL":"4500"
}
}
}
}
Vòng đời của một thông báo
Khi máy chủ ứng dụng đăng thông báo lên FCM và nhận lại mã thông báo, điều đó không có nghĩa là thông báo đã được gửi đến thiết bị. Thay vào đó, trạng thái này có nghĩa là quảng cáo đã được chấp nhận để phân phối. Thời điểm tin nhắn được gửi đi phụ thuộc vào nhiều yếu tố.
Nếu thiết bị đã kết nối nhưng ở chế độ Nghỉ, thì FCM sẽ lưu trữ thông báo có mức độ ưu tiên thấp cho đến khi thiết bị thoát khỏi chế độ Nghỉ. Nếu bạn đặt collapse_key và có một thông báo hiện có cùng khoá thu gọn và mã thông báo đăng ký đang chờ gửi, thì thông báo cũ sẽ bị loại bỏ và thông báo mới sẽ thay thế thông báo cũ. Tuy nhiên, nếu bạn không đặt khoá thu gọn, thì cả tin nhắn mới và tin nhắn cũ đều được lưu trữ để gửi sau này.
Nếu thiết bị không kết nối với FCM, thì thông báo sẽ được lưu trữ cho đến khi
thiết lập được kết nối. Khi kết nối được thiết lập, FCM sẽ gửi tất cả thông báo đang chờ xử lý đến thiết bị. Nếu thiết bị không bao giờ kết nối lại, thì thông báo cuối cùng sẽ hết thời gian chờ và bị loại bỏ khỏi bộ nhớ FCM. Thời gian chờ mặc định là 4 tuần, trừ phi bạn đặt cờ ttl. Nếu ứng dụng đã bị gỡ cài đặt khi FCM cố gắng gửi thông báo đến thiết bị, thì FCM sẽ loại bỏ thông báo đó ngay lập tức và vô hiệu hoá mã đăng ký. Những lần gửi thông báo sau này đến thiết bị đó sẽ dẫn đến lỗi NotRegistered.
Đối với thiết bị Android, nếu thiết bị chưa kết nối với FCM trong hơn một tháng, thì FCM vẫn chấp nhận thông báo nhưng sẽ loại bỏ ngay lập tức. Nếu thiết bị kết nối trong vòng 4 tuần kể từ tin nhắn dữ liệu gần nhất mà bạn gửi đến thiết bị, thì ứng dụng khách của bạn sẽ nhận được lệnh gọi lại onDeletedMessages().
Để có thêm thông tin chi tiết về việc gửi thông báo trên nền tảng Android hoặc Apple, bạn có thể sử dụng trang tổng quan báo cáo FCM. Trang tổng quan này ghi lại số lượng thông báo được gửi và mở trên thiết bị Apple và Android, cùng với dữ liệu về số lượt hiển thị cho các ứng dụng Android.