Firebase 云消息传递 - GCM 规范 ID 是否仍然需要? [英] Firebase Cloud Messaging - Are GCM canonical IDs still necessary?

查看:15
本文介绍了Firebase 云消息传递 - GCM 规范 ID 是否仍然需要?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在阅读 GCM 中的规范 ID 以及它们如何帮助纠正发送重复推送通知并确保安全性.但是现在有了 Firebase Cloud Messaging (FCM),这个问题还存在吗?

I've been reading on canonical IDs in GCM and how they help to rectify sending duplicate push notifications and with security. But now with Firebase Cloud Messaging (FCM), does this issue still exist?

我的注册部分现在已经从开发者那里拿走了,我们只是等待令牌刷新如下:

I am the registration part has been taken away from the developer now and we just wait for a token refresh as per below:

    public class MyFirebaseInstanceIDService extends FirebaseInstanceIdService {

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

有关规范 ID 的一些信息可以在这里找到.

Some info on canonical IDs can be found here.

推荐答案

更新:

我最近重新审视了有关规范 ID 的这个主题,并得出以下结论.

I recently revisited this topic on Canonical IDs and have concluded the following.

在 FCM 中,由于 实例 ID 服务 有效.简而言之,该服务的工作原理是每个应用实例只有一个有效令牌.

In FCM, it seems the Canonical IDs are no longer used (or at the very least extremely rarely) because of the way the Instance ID service works. To put it simply, the service works that there would only be one valid token per App Instance.

如果旧令牌过期(无论出于何种原因),FCM 会触发一个 tokenRefresh 事件,您将在该事件中获得一个新的注册令牌,并且您还必须相应地处理它(在 onTokenRefresh() 中).

If the older token expires (for whichever reason), FCM triggers a tokenRefresh event where you would get a new registration token, and where you must also handle it accordingly (in onTokenRefresh()).

简短的回答,是的.这仍然是必要的.

onTokenRefresh() 方法应在令牌实际刷新时触发.从那里,开发者有责任将注册令牌发送到应用服务器.

The onTokenRefresh() method is expected to trigger whenever the token is actually refreshed. From there, it's the developer's responsibility to send the registration token towards an App Server.

但是在您无法获得新注册令牌的情况下(例如忘记保存、删除它并且只有以前的注册令牌等),这可能会导致您(开发人员)向本应不再有效的注册令牌发送.这就是规范 ID 发挥作用的时候.

BUT in an event where you weren't able to get a hold of the new registration token (e.g. forgot to save it, deleted it and only have the previous registration token, etc.), it may result to you (the developer) to send towards a supposed to be no longer valid registration token. That's when Canonical IDs come in.

我想您可以将规范 ID 视为另一种安全措施,以便开发人员仍然可以获得有效的注册令牌.FCM 文档 中提到了有关规范 ID(如何处理和填充)的详细信息这里.

I guess you can treat Canonical IDs as another safety measure so that developers can still get a hold of the valid registration token. Details about Canonical IDs (how it is handled and stuff) are mentioned in the FCM docs here.

这篇关于Firebase 云消息传递 - GCM 规范 ID 是否仍然需要?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆