I need to use Notifications via APNS in my iPhone App.
But as I read specification, I see the Token can be changed on APNS side and I have to update token on Provider side to receive notifications right.
But what will happen when Provider creates Notification and will pass it to APNS and in this time the token will be already changed?
Will I receive a Notification with old token? Will provider be notified that token expired?
Should I solve it so, that after registering I will update my Provider with info "YOU CAN SEND NOTIFICATIONS" and make a NSTimer job to update this state while app is running?
According to this:
http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html#//apple_ref/doc/uid/TP40008194-CH103-SW2
Thanks
If your app registers for notifications at launch, and implements the methods specified in the documentation, it will be sure to get the correct token.
If your app keeps track of what the token used to be, it can send an update to the provider as needed (or just every time it gets a token whether it has changed or not).
If the token has changed, and the provider tries to push using the old token, the provider will be notified by the push notification server that the token is not valid.
Related
my app's apple push notification certificate is expired. Before expiration server used curl.. Now I renewed it and used JWT for sending notification on my server..
Now, I'm trying to send push notifications to users. Can I use the device token from certificate back then or do I have to change the code from app to get new token? Thanks
As explained here in 'Figure 6-6, Managing the device token', if the device token needs no refresh, you can use it with your new backend implementation without any changes needed on client-side.
No matter what, you need to check and send the device token to your server on each app launch to ensure that you have the newest device token.
I'm trying to send push notification for iOS via Google cloud functions but it returns error that The provided registration token is not registered. But I've checked it by debugging my app and the FCM registration token is correct. After that I've tried to send push notification via Firebase console to single device by providing FCM token but it failed due to Unregistered registration token. How this happens because there is no issue with device FCM token?
I think it should be some careless mistake, you should make sure the things below:
The token is same with -[FIRMessagingDelegate messaging:(FIRMessaging *)messaging didReceiveRegistrationToken:(NSString *)fcmToken]
The GoogleService-Info.plist is downloaded from the same account with your Firebase push console.
Updated to the latest Firebase SDK.
From the Google Firebase document are some description of your error The provided registration token is not registered.
The provided registration token is not registered. A previously valid
registration token can be unregistered for a variety of reasons,
including:
The client app unregistered itself from FCM.
The client app was automatically unregistered. This can happen if the user uninstalls the application or, on iOS, if the APNS Feedback
Service reported the APNS token as invalid.
The registration token expired. For example, Google might decide to refresh registration tokens or the APNS token may have expired for iOS
devices.
The client app was updated, but the new version is not configured to receive messages. For all these cases, remove this registration token
and stop using it to send messages.
I also got a similar error. Something like this.
FirebaseMessagingError: The provided registration token is not registered. A previously valid registration token can be unregistered for a variety of reasons. See the error documentation for more details. Remove this registration token and stop using it to send messages.
So I simply generated a new token and replaced it with the old one.
And it started working fine.
I also got a similar error on the released build iOS device.
The provided registration token is not registered. A previously valid registration token can be unregistered for a variety of reasons. See the error documentation for more details. Remove this registration token and stop using it to send messages.
I fixed it by reuploading correct .p12 certificate on the firebase messaging
I got a mail from firebase support team:
"In your case, please note that you can only upload up to 2 APN certificates. One for development and another for production. Since one of the APN certificates is invalid, you should delete the incorrect one. To be able to delete an APN certificate, the user must have an 'owner' permission/role. Upon checking, you don’t have enough permission to make this change. I suggest you reach out to the project owner to request the necessary permission or to delete the APN certificate.
Just to add, As of I/O 2017, developers can use either auth keys or certs for their APNs. We recommend that you use auth keys because they are easier to configure and do not expire. If both cert and an auth key is uploaded, our server will use the auth key.
Our system can not validate auth keys like it does certificates. We do not have a way of validating that APNs will accept them without sending an actual message. With certs, we open a connection to APNs before accepting them, and if they are invalid APNs reject them and we can return the error to the user."
I was experiencing this issue and it turned out that our server was sending a bad notification payload for a certain use case. When this happened, Firebase would send a return code of 400 and unregister the token.
The fix for us was to fix the use case sending the bad payload. The error in our payload was due to "DeviceTokenNotForTopic". Be sure to check that you aren't getting errors when posting notifications prior to when you get in this bad state.
Our company send push notification from the server side with the APNS token obtained from device, and we are currently migrating over FCM.
My question is once the user upgrades to the new app using the FCM token, will the old APNS token still work?
I am asking because the current design of the app has a disconnect and it could wait up to an hour before the device updates the server with the new FCM token. During that time, the server will continue to send push notifications with the old APNS token, and we want to make sure user is still able to receive them.
If anyone can give any insight on that, that will be great! Thanks!
Yes , it will as long as you use the correct device token and uploaded the .pem file but make sure to separate the usual token from FCM token , regarding firebase you should upload .p12 development & dis files , there is no big deal behind firebase it also sends the push content to apns
My push notifications provider wants me to send a device-unique token to the server, which is not possible, as I figured out after hours of searching (neither with keychain nor identifierForVendor etc).
So atm server stores tons of inactive tokens (after app is reinstalled, token is being refreshed). What is the workaround in this situation?
If you are talking about the notification APN token to the server, the server can cull them when they attempt to use them.
The Apple Push Notification server will let them know the token is invalid.
I am using Amazon SNS for mobile push notification and the AWS SDK in my swift based iOS Application. Everything works great, but I notice some weird behavior when I disable notification from the iOS Settings and then I turn off notifications under my application entry in Settings. If I turn notifications off, the enabled flag on the AWS SNS console is still set to true.
In some cases, the enabled flag will flip correctly to false. In those scenarios, when I try to re-enable notifications in the iOS Settings, the enabled flag will never flip back to true. Any idea why this is happening? Is there anyway to get this to set appropriately in real-time?
Thanks in advance.
There is no interaction between Amazon SNS and devices, SNS interacts only with platform providers (GCM, APNS, Baidu, WMS, etc.)
An endpoint can become disabled in Amazon SNS for several reasons:
The device token has changed you have not updated the endpoint with the new token. In this scenario, the push notification will fail to this device because the current endpoint token is invalid. Based on the APNS feedback, the endpoint will be set to DISABLED. Device token can change if:
application version is upgraded,i
iOS version is upgraded, or
potentially if device is reset.
The advice here is to verify the token change by your application on startup by matching the freshly obtained token with the one saved in NSUserDefaults store and if different, update it locally after updating the SNS endpoint.
This is likely why when you re-enable notification in device settings, "the enabled flag will never flip back to true".
The device owner has removed the application and while the app is not installed, an SNS notification is sent to the device. At this point, APNS provides feedback of an invalid token and the endpoint is DISABLED by SNS. This may take up to 24 hours due to async nature of APNS callbacks for disabled endpoints.
SNS notification is sent to an endpoint with a token that was not generated for the application or environment. For example, the endpoint was generated manually and is a random combination of valid hex chars of 64 length.
If SNS notification with a valid token destined for a SANDBOX (APNS_SANBOX) environment of the application was inadvertently sent to PRODUCTION (APNS) environment. In this scenario, SNS accepts the token but fails on the first push notification and the endpoint will be DISABLED based on APNS feedback.
The blog post shared by Rohan is a great resource for mobile token Management.
Amazon SNS disables the endpoint in response to feedback from APNS that indicates the push token is invalid. SNS is not aware of what action is performed on the device to make the token invalid; it merely sets the status based on APNS feedback messages.
You should review the Mobile Token Management blog post for specifics and best practices to handle disabled endpoints.