FCM:onNewToken与FirebaseInstanceId [英] FCM: onNewToken vs FirebaseInstanceId

问题描述

Firebase已弃用com.google.firebase:firebase-messaging:17.1.0版本中的某些消息传递调用.这篇帖子很好地介绍了这些更改.

Firebase has deprecated some of the messaging calls in the com.google.firebase:firebase-messaging:17.1.0 release. This post goes over those changes nicely.

问题:有人可以告诉我不实施onNewToken是否被认为是不好的做法，而是在每次启动应用程序时都调用以下代码:这对Android使用者来说似乎过分了，但感觉像是从家里来的iOS的观点.

Question: Can someone tell me if is it considered bad practice to not implement onNewToken and instead just call the below block each app launch This probably seems excessive to Android folks but feels like home from an iOS point of view.

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更加熟悉，iOS在每次 应用启动时都将其称为onNewToken.因此，对于iOS，我在此处放置逻辑以确定是否需要更新后端.

I am more familiar with iOS which calls its onNewToken equivalent on every app launch. So for iOS I put logic there to determine if my backend needs to be updated.

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.

getInstanceId() docs say This generates an Instance ID if it does not exist yet, which starts periodically sending information to the Firebase backend. This makes me assume I can just call FirebaseInstanceId.getInstance().instanceId.addOnSuccessListener each launch.

推荐答案

首先，我对任何逻辑上都持怀疑态度，这些逻辑认为，如果iOS上可以正常运行，那么在Android上也可以正常运行！

First of all, I'm highly skeptical of any logic that suggests that if something is OK in iOS, that it would be OK on Android!

Android和iOS之间的推式消息传递的实现截然不同.在Android上，它依赖于Play服务，后者在另一个过程中运行.在iOS上，情况完全不同.交战规则根本不一样.

The implementation of push messaging between Android and iOS is extremely different. On Android, it's dependent on Play Services, which runs in another process. On iOS, it's something completely different. The rules of engagement are simply not at all the same.

请注意，建议的令牌检索方法是通过回调.这表明令牌生成本质上是异步.换句话说，在应用启动时(无论您实际定义的是哪种方式)，可能都无法完成用于标记的后台工作.当您索要令牌时，可能根本就没有可用的令牌.谁知道需要多长时间?您最好在系统告知您准备就绪时仅接受令牌，而不要猜测何时准备就绪.遵循建议的实施路径.

Note that the suggested token retrieval method is via callback. That is suggesting that token generation is essentially asynchronous. In other words, at app launch (in whatever way you actually define that), the background stuff that manages to token might not be done with that yet. There simply might not be any token available when you ask for it. And who knows how long that takes? You're better off just accepting the token when the system tells you it's ready instead of making a guess about when it's ready. Follow the recommended implementation path.

这篇关于FCM:onNewToken与FirebaseInstanceId的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！