Firebase Cloud Messaging - нужны ли канонические идентификаторы GCM?

Question

Я читал о канонических идентификаторах в GCM и как они помогают исправлять отправку повторяющихся push-уведомлений и с защитой. Но теперь с Firebase Cloud Messaging (FCM) эта проблема все еще существует?

Я регистрация часть была взята от разработчика, и мы просто ждать маркеров обновления согласно ниже:

public class MyFirebaseInstanceIDService extends FirebaseInstanceIdService { 

    @Override 
    public void onTokenRefresh() { 
     // Get updated registration ID 
     String refreshedToken = FirebaseInstanceId.getInstance().getToken(); 
     Logger.d("Refreshed FCM token: " + refreshedToken); 
    } 
} 

Некоторой информацию о канонических идентификаторах можно найти here.

Answer 1

Update:

Недавно я вернулся к этой теме на канонических идентификаторах и заключил следующее.

В FCM кажется, что канонические идентификаторы больше не используются (или, по крайней мере, крайне редко) из-за того, как работает Instance ID service. Проще говоря, служба работает, что на один экземпляр приложения будет только один действительный токен.

Если старый токен истекает (по какой-либо причине), FCM запускает событие tokenRefresh, где вы получите новый токен регистрации, и где вы также должны обрабатывать его соответственно (в onTokenRefresh()).

---

Короткий ответ, да. Это по-прежнему необходимо.

Ожидается, что метод onTokenRefresh() запускается всякий раз, когда токен действительно обновляется. Оттуда ответственность разработчика заключается в том, чтобы отправить токен регистрации на сервер приложений.

BUT в том случае, если вы не смогли получить новый токен регистрации (например, забыли сохранить его, удалить и иметь только предыдущий регистрационный токен и т. Д.), Это может привести к вы (разработчик), чтобы отправить в сторону предполагаемого недействительного регистрационного токена. Вот когда появляются канонические идентификаторы.

Я думаю, вы можете рассматривать Canonical IDs как еще одну меру безопасности, чтобы разработчики все еще могли удерживать действительный токен регистрации. Подробная информация о Canonical ID (как это обрабатывается и прочее) упоминается в документах FCM here.