FCM zwykle dostarcza wiadomości natychmiast po ich wysłaniu. Nie zawsze jest to jednak możliwe. Urządzenie może być na przykład niedostępne lub FCM może celowo opóźniać wiadomości aby uniemożliwić aplikacji zużywanie nadmiernej ilości zasobów i negatywny wpływ na żywotność baterii.
W takich przypadkach FCM przechowuje wiadomość i dostarcza ją tak szybko, jak to możliwe. W większości przypadków jest to w porządku, ale niektóre aplikacje wymagają wysyłania powiadomień bez opóźnienia. Na przykład powiadomienie o połączeniu przychodzącym lub zaproszenie na wydarzenie.
W Androidzie i internecie możesz określić maksymalny czas życia wiadomości. Wartość musi być czasem trwania od 0 do 2 419 200 sekund (28 dni) i odpowiada maksymalnemu okresowi, przez który FCM przechowuje wiadomość i próbuje ją dostarczyć. Domyślnie żądania, które nie zawierają tego pola, trwają maksymalnie 4 tygodnie.
W iOS możesz ustawić nagłówek apns-expiration w obiekcie
ApnsConfig. Więcej informacji znajdziesz w dokumentacji Apple na temat wysyłania
żądań powiadomień do
APNs.
Oto kilka możliwych zastosowań tej funkcji:
- Połączenia przychodzące w czacie wideo
- Wydarzenia z wygasającym zaproszeniem
- Wydarzenia w kalendarzu
Kolejną zaletą określania czasu życia wiadomości jest to, że
FCM nie stosuje ograniczania liczby wiadomości, które można zwinąć, do wiadomości z
wartością czasu życia danych (TTL) wynoszącą 0 sekund. Pamiętaj, że wartość ttl równa 0 oznacza
wiadomości, których nie można dostarczyć od razu, są odrzucane. Ponieważ
takie wiadomości nigdy nie są przechowywane, zapewnia to jednak najlepsze opóźnienie w wysyłaniu
powiadomień.
Oto przykład żądania, które zawiera 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"
}
}
}
}
Czas życia wiadomości
Gdy serwer aplikacji opublikuje wiadomość w FCM i otrzyma identyfikator wiadomości z powrotem, nie oznacza to, że wiadomość została już dostarczona na urządzenie. Oznacza to, że została zaakceptowana do dostarczenia. To, kiedy wiadomość zostanie dostarczona, zależy od wielu czynników.
Jeśli urządzenie jest połączone, ale w trybie uśpienia, wiadomość o niskim priorytecie jest przechowywana przez
FCM do momentu, aż urządzenie wyjdzie z trybu uśpienia. Jeśli ustawiono collapse_key, a
istnieje wiadomość z tym samym kluczem
zwijania i
tokenem rejestracji oczekująca na dostarczenie, stara wiadomość zostanie odrzucona, a jej miejsce zajmie
nowa wiadomość. Jeśli jednak klucz zwijania nie jest ustawiony, zarówno nowa, jak i stara wiadomość są przechowywane do późniejszego dostarczenia.
Jeśli urządzenie nie jest połączone z FCM, wiadomość jest przechowywana do momentu nawiązania
połączenia. Po nawiązaniu połączenia FCM
dostarcza wszystkie oczekujące wiadomości na urządzenie. Jeśli urządzenie nigdy nie połączy się
ponownie, wiadomość w końcu wygaśnie i zostanie usunięta z FCM
pamięci. Domyślny limit czasu to 4 tygodnie, chyba że ustawiono flagę ttl. Jeśli
aplikacja została odinstalowana, gdy FCM próbuje dostarczyć wiadomość na
urządzenie, FCM odrzuca tę wiadomość i unieważnia
token rejestracji. Kolejne próby wysłania wiadomości na to urządzenie spowodują błąd NotRegistered.
W przypadku urządzeń z Androidem, jeśli urządzenie nie połączyło się z FCM przez ponad
miesiąc, FCM nadal akceptuje wiadomość, ale natychmiast ją odrzuca. Jeśli urządzenie połączy się w ciągu 4 tygodni od wysłania ostatniej wiadomości z danymi
do niego, aplikacja kliencka otrzyma
onDeletedMessages()
wywołanie zwrotne.
Aby uzyskać więcej informacji o dostarczaniu wiadomości na platformach Android i Apple, możesz użyć panelu FCM raportowania FCM, który rejestruje liczbę wysłanych i otwartych wiadomości na urządzeniach Apple i Android oraz dane o wyświetleniach w aplikacjach na Androida.