When using FCM rest API to send a message to an app that has been removed from a device, the FCM api is returning a status code of 200 instead of a 400 or 404 as expected. The app has been uninstalled for about a week and many push attempts have been made with all tests returning a code of 200
So I am wondering :
is there an expected time period before FCM knows that an app has been uninstalled and therefore the token is invalid ?
is there something that the app has to do when acquiring the token for FCM to properly mark the token as invalid when the app is removed ?
firebaser here
There's no definite period on when the token will be invalidated. You don't need to add any implementation for token validation when the app is uninstalled.
There can be instances that if no new token is generated, the old token will still be valid even if the app is uninstalled. Best practice for token management is just to retrieve the latest token and use it. If you determine in some way that the app is unstalled, just remove the token from your server as part of token monitoring. Just a side note that FCM should not be used to determine if an app is installed/uninstalled.
Related
In my app, the FCM token is sent to the server immediately after issuance.
The server receives the client FCM token, stores it, and sends a message to the FCM token for the client when needed.
However, on iOS devices, even if the client uninstalled the app, the result of sending on the server is showed as a success.
(For Android devices, failure(NotRegistered) is received. this is the ideal result.)
{
"multicast_id":****************,
"success":1,
"failure":0,
"canonical_ids":0,
"results":[
{
"message_id":"0:**********************"
}
]
}
Can you explain why the result on the sever showed that the sending FCM tokens was succeded even when the client uninstalled the apps?
As showed on the following document, it says "failure" with the result "NotRegiestered".
Is this only for Android?
So, how can I get these results on iOS?
https://firebase.google.com/docs/cloud-messaging/concept-options#lifetime
Finally, when FCM attempts to deliver a message to the device and the app was uninstalled, FCM discards that message right away and invalidates the registration token. Future attempts to send a message to that device results in a NotRegistered error.
Can you tell me how to get the result as "failure" like in Android when sending the token to client who uninstalled the apps?
To classify the client that uninstalled the app, i should get the result of failure(NotRegistered) like Android.
[The same issues]
FCM detect app uninstall on IOS (firebase cloud messaging push notifications)
https://developer.apple.com/forums/thread/88332
I am using the Huawei Push Toolkit to send push messages to customers. There is a mechanism where the push tokens of each device are often refreshed, so a token used right now might be different than a token used, say, a day ago.
The issue was that if we try to send a push to a token that was valid only yesterday, the response is:
{ "code": "80000000"
"msg": "Success",
"requestId": "161615569495608835000107"
}
However, naturally, the device didn't receive the push because it was in the meantime refreshed. If sending it to the most up-to-date push token, the response is still the same and the device does get the message.
Why didn't the API return a different response, say, the error code `80300007` (all tokens invalid) in the first scenario? This is consistently replicated even for tokens older than 1 day (tested as far back as a 25 days old token).
reference
The endpoints tested were: https://push-api.cloud.huawei.com/v2/.../messages:send
and https://push-api.cloud.huawei.com/v1/.../messages:send
Both have the same behavior.
The situation you experience with the device token is normal for the Push server and it is about the information flow and the return value is just a presentation of the current node. To explain briefly 1. The Access Token is used only for the authentication interface. If the AT does not expire after the authentication succeeds, no error is reported. 2. The server pushes messages through the Push interface. If success:80000000 is returned, the Huawei Push server has received the messages, but this does not mean that the messages can be pushed to the terminal.
1 Are FCM token and Instance Id one and the same?
In my next questions, I suppose there aren't.
2. Is it possible to register an app instance ID twice to the same topic?
FCM token and Instance Id expire and are refresh.
3. Do we need to subscribe to a topic again after a token refresh?
I suppose we do.
4. Should we listen to a FCM token refresh or to an Instance Id refresh?
I am confused because the Firebase iOS API to register to a topic is:
[[FIRMessaging messaging] subscribeToTopic:#"news"]
It is not explicit which token is involved. My guess is that the internal logic uses the Instance Id because the server API endpoint is https://iid.googleapis.com/iid/v1/IID_TOKEN/rel/topics/TOPIC_NAME
However the Firebase documentation only mentions FCM token refresh and how to monitor them.
The InstanceID and the Token are different. See an explanation of the InstanceID in my answer here, and a general explanation for the token in my answer here.
Usually tho, the token (when printed) contains the InstanceID as well. It may be a format Google chose to make sure that the token is unique, or to connect it to a specific device. I can't say for sure.
There is no way that you can duplicate a subscription. Whenever a token is refreshed, the corresponding subscriptions are kept by the new token.
No. See #2.
It uses the token. The InstanceID is just the ID for the app instance. The token is what FCM needs to send the message.
I'm migrating to the FCM v1 API (https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages) from the legacy API (https://firebase.google.com/docs/cloud-messaging/http-server-ref) to send push notifications.
I want to know if is there some way to retrieve the canonical_id related to the token (registration_id) just like in the legacy API.
I have found nothing about it in the docs, only that the result is a Message object, and if an error occurs it returns a FcmError Object.
If I can't retrieve the canonical_id I think I would end up receiving errors of invalid / not registered token after some time (or am I wrong?), and would have to invalidate them in my database, if the user doesn't use the app during a reasonable amount of time.
AFAICT, canonical_ids haven't been used since the legacy api. See my answer here.
Registration tokens don't get invalidated on a regular basis, just on a few scenarios, where onTokenRefresh() is actually called and thus must be handled on the client side (resend the new token towards your server).
I was going through updated official APNS documentation and it clearly says,
All developers should migrate their remote notification provider servers to the more capable and more efficient HTTP/2-based API described in APNs Provider API.
But the new APNs Provider API doesn't seem to have old APNS Feedback Service. They have changed endpoint URLs which doesn't have feedback service endpoint. Also looks the error codes are upgraded now, which includes below error code,
Unregistered -
The device token is inactive for the specified topic.
So aren't we suppose to call the APNS Feedback service anymore?
My major problem is I'm using javapns api version 2.2 for iOS push notifications for which I'm not able to find any update which will help me to cope up with this new changes.
I think the new doc is clear :
There's an HTTP status code for the case that was previously reported by the Feedback Service :
410 - The device token is no longer active for the topic.
In addition, there's a JSON data key named timestamp in the response body :
timestamp
If the value in the :status header is 410, the value of this key is the last time at which APNs confirmed that the device token was no longer valid for the topic.
Stop pushing notifications until the device registers a token with a later timestamp with your provider.
Therefore, the HTTP response in the new API covers the functionality that was previously covered by the Feedback Service. Since the Feedback Service is not mentioned in the new doc, we can safely assume that it's not part of the new API.
If you are using an old library such as javapns, which still uses the old API, I'm assuming that it still uses the Feedback Service too. The old API is likely to still be supported by Apple for a while.