FCM:onNewToken与FirebaseInstanceId

时间:2018-07-12 01:30:55

标签: android firebase firebase-cloud-messaging

Firebase已弃用com.google.firebase:firebase-messaging:17.1.0版本中的某些消息传递调用。该post很好地遍历了这些更改。

问题:有人可以告诉我不实施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,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

6 个答案:

答案 0 :(得分:7)

首先,我对任何逻辑上都持怀疑态度,这些逻辑认为,如果iOS上的某些事情可以解决,那么在Android上就可以了!

Android和iOS之间的推式消息传递实现非常不同。在Android上,它取决于Play服务,后者在另一个过程中运行。在iOS上,情况完全不同。交战规则根本不一样。

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

答案 1 :(得分:4)

尽管文档说onNewToken在第一个应用程序启动时被调用,但不是。这就是为什么我需要FirebaseInstanceId时分别使用getToken()onNewToken的原因,尽管该应用程序已经运行了一段时间,但之前没有调用过onNewToken。 (所以我们都在我们的项目中都做过)

我观察到的是,在我通过FirebaseInstanceId获取令牌之后,Firebase将立即调用getToken()。似乎以这种方式获取令牌会在Firebase服务中启动某些操作。

但是,它可以那样工作,对于我们当前的项目来说已经足够了。

编辑:由于FirebaseInstanceId中的import boto3 dynamodb = boto3.resource('dynamodb') table = dynamodb.Table(table_name) max_key = table.item_count 最近被弃用,请参考Arthur Thompson的回答。

答案 2 :(得分:2)

在每次启动应用程序时调用FirebaseInstanceId.getInstance().getInstanceId().addOnCompleteListener是一个选项(不必要的选项),onNewToken专门用于为您提供令牌可用时的访问权限。

请注意,每次启动应用程序时调用FirebaseInstanceId.getInstance().getInstanceId().addOnCompleteListener都将要求您处理令牌尚不可用的情况,使用onNewToken可以避免这种情况。

答案 3 :(得分:1)

非常的重要信息,没有人提及:

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

拥有可以在您的应用程序处于后台时调用的回调的全部目的是防止丢失后端消息(如果您的应用程序或其某些重要功能在很大程度上依赖于推送通知,则很重要)。请务必注意,此回调不仅会在您首次注册设备时为您提供令牌,而且还会alsoCalled if InstanceID token is updated. This may occur if the security of the previous token had been compromised.

所以:

  

有人可以告诉我,不实现onNewToken而是在每次应用程序启动时仅调用以下代码块是否被认为是不好的做法,这对于Android用户来说似乎过分了,但从iOS的角度来看却像家一样。

是的,不实现onNewToken()实际上是一个坏习惯。

答案 4 :(得分:0)

onNewToken()函数的工作方式与其前身onTokenRefresh()相同。

在您的帖子请求中实现第一个区块,并等待令牌。这保证了令牌(或异常)将返回。但是,不能保证该令牌永远保持不变。与onTokenRefresh()相似,onNewToken()在为相应的应用程序实例生成令牌时触发,依次应使用并替换为获得的旧令牌。

我的answer here有更多详细信息。

答案 5 :(得分:0)

让我们简化这个等式-您应该同时做这两个事情。

在我们的应用中,我们没有手动检查FirebaseMessaging.getInstance()。getToken(),但确实设置了onNewToken覆盖。这对大多数用户有效,但是我们有些人会停止接收通知,除非他们重新安装该应用程序。

因此,如果您确实要确保始终拥有最新的令牌,则需要在此处同时进行。在启动时使用getToken()进行检查,以确保您没有错过任何更新,并订阅onNewToken以在应用程序启动之间发生更改时得到通知。 Firebase文档确实暗示了这一点,尽管说实话可​​能更清楚:

Screenshot of Firebase documentation