FCM:onNewToken vs FirebaseInstanceId

Question

Firebase已弃用此com.google.firebase:firebase-messaging:17.1.0版本中的一些消息传递调用.这篇文章很好地解决了这些变化.

问题:有人可以告诉我,如果不实施这是不好的做法onNewToken,而只是在每个应用程序启动时调用下面的块这对于Android人来说可能看起来过分,但从iOS的角度来看感觉就像家一样.

FirebaseInstanceId.getInstance().instanceId.addOnSuccessListener(this) { instanceIdResult ->
    // Just use this call 
    val newToken = instanceIdResult.token
    Log.i("newToken", newToken)
}



@Override
public void onNewToken(String s) {
    super.onNewToken(s);
    // Leave this unimplemented
}

我更熟悉iOS,它onNewToken在每个应用程序发布时调用它.因此,对于iOS,我在那里放置逻辑以确定我的后端是否需要更新.

getInstanceId()文档说This generates an Instance ID if it does not exist yet, which starts periodically sending information to the Firebase backend.这让我想我可以调用FirebaseInstanceId.getInstance().instanceId.addOnSuccessListener每次启动.

Answer 1

一件非常重要但还没有人提到的事情：

如果您仅在应用程序启动后检查当前设备令牌，则当您的应用程序处于后台时（当然），您可能会丢失更新令牌的事件，并且您将无法从服务器接收远程推送消息直到用户再次启动应用程序并将新令牌发送到服务器。

在您的应用程序处于后台时也可以调用该回调的全部目的是防止丢失后端消息（如果您的应用程序或其某些重要功能在很大程度上依赖于推送通知，则这一点很重要）。请务必注意，此回调不仅会在您首次注册设备时向您发送令牌，还会：Called if InstanceID token is updated. This may occur if the security of the previous token had been compromised.

所以：

有人可以告诉我，不实施 onNewToken 而只是在每次应用程序启动时调用下面的块是否被认为是不好的做法这对 Android 人来说可能看起来有些过分，但从 iOS 的角度来看却是家常便饭。

是的，不实现 onNewToken() 实际上是一种不好的做法。

Answer 2

首先,我对任何逻辑表示高度怀疑,这些逻辑表明,如果iOS中的某些内容正常,那么它在Android上就可以了!

Android和iOS之间的推送消息传递的实现是非常不同的.在Android上,它依赖于Play服务,后者在另一个进程中运行.在iOS上,它完全不同.参与规则根本不完全相同.

请注意,建议的令牌检索方法是通过回调.这表明令牌生成本质上是异步的.换句话说,在应用程序启动时(无论你以何种方式实际定义),管理到令牌的后台内容可能还没有完成.当你提出要求时,可能根本没有任何令牌可用.谁知道需要多长时间？当系统告诉你准备就绪而不是猜测它什么时候准备就绪时,你最好只接受令牌.遵循建议的实施路径.

Answer 3

尽管文档说这onNewToken是在第一次应用程序启动时调用的，但事实并非如此。这就是为什么我在需要 Id 时FirebaseInstanceId分别使用的原因，虽然该应用程序已经运行了一段时间，但之前尚未被调用。（所以我们在我们的项目中都做了）getToken()onNewToken

我观察到的是 Firebase 将onNewToken在我通过FirebaseInstanceId. 似乎以这种方式获取令牌会启动 Firebase 服务中的某些内容。

但是，它以这种方式工作，并且对于我们当前的项目来说已经足够了。

编辑：作为getToken()中FirebaseInstanceId得到了最近弃用，请参阅阿瑟·汤普森的答案。