when i try and get the inactive device tokens from the feedback service i get the tokens but after that the service doesn't return anything.
is there any way for me to get all the tokens from all time?
i'm using PHP to get the tokens.
Server will return all inactive tokens since last time you asked for feedback. The way to quick test is,
Run feedback service once
Delete the app from phone
Again run the feedback service, you should get one inactive token.
Just make sure feedback service address is correct.
No there is not way to get the inactive tokens again once the APNS feedback is queried. Since there are no parameter available the service is provided as is:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3
Related
For now, I use the scope ?allow_signup=true&login=yourself to make users reauthorize when they connect their account. But this message would show when they go to that reauthorization page:
This application has made an unusually high number of requests to access your account. Please reauthorize the application to continue.
Actually, I am not making a high number of requests, I just want them to reauthorize without revoking their previous access token.
Is there any way I can let them do so without this message?
Turns out this message only appears if the user requests reauthorizes in high frequency. If we can make sure they are not reauthorizing within 1~2 minutes then it should be fine.
I have an app where I’m offering Auto Renewal Subscriptions. Here is how it currently works, when the user subscribes, it saves a Bool in UserDefaults as true, after that I can make a receipt request to see if the subscription has expired. My issue or what I don’t fully understand is the logic on how often to make that request, checking for authenticity every time the user launches the app seems like a lot, or do I need to save the expiration date in UserDefaults and just check a couple of days after the expiration date to see if the user renewed? This way we limit the requests we make to retrieve the Apple receipt.
Can someone share the logic used when checking for authenticity in an app using Auto Renewal Subscriptions?
The "right" way to do it is to manage everything server side (with some caching on the device in case the user is offline). Refreshing the receipt on the device is insecure, slow, and could make that annoying "Login with iTunes" prompt keep popping up for the user :)
It also prevents you from ever having complete analytics of your subscriber base since you can only get data points when they are active in the app.
What you would do is store the receipt file in a database after purchase, and refresh it there to keep the subscription status up-to-date. Then your app is asking your database if the user is subscribed (and caching the value in UserDefaults).
Here is a good blog post that outlines what the setup should look like: iOS Subscriptions are Hard
I have an ios app.
In which i have multi user account.So multiple user can Login.
When one user see other user profile and if that user is also online i want to notify him.
I can't get how to implement it.
If i have to continuously check some flag value on server if someone has checked their profile or how can i handle it?
Remote notifications is the way to do it. The logic on when and who has to be notified can be handled at the server.
You may have seen lots of apps asking for permissions to send notification. The downside being if the user denies that permission.
Polling from client side can also be one of the methods which can be used and but would require the client to do most of the computation.
So all in all, its a call you got to take considering what you are building.
I’m looking at the designing and developing a service for Push notifications, and am trying to understand the order of processing in the Apple App when it comes to Registering for Push Notifications and storage of the Token.
What I’m developing currently is a service that allows subscription to individual changes that happen to particular processing on our server.
When they happen, the phone user may receive a message of type “A”, “B”, or “C”.
The phone user has to “subscribe” to each of these types individually if they want them. Otherwise they can ignore it and not subscribe.
So User Fred, on Phone #4, starts our App, logs in, and then has the ability to turn on or off subscriptions to events that are sent as Push Notifications.
So I need to tie details from Fred’s login, to Phone #4’s device Token, with particular subscriptions.
So my particularly important questions are.
When the Phone connects to the APNS server to get its device token, is this automatic on app start? Or can this be initiated at a later step? Ie, after going through a loging screen on our app.
Can we (are we allowed to) store the device token on the phone in the App's data store?. Or, should the App be connecting to the APNS server every time the app is run?
How does the App know if it as already called the APNS server and retrieved a token, or as above, should it call the APNS server time the app is run?
Can we (are we allowed to) store the token in the App’s memory as it runs, so we can properly subscribe and unsubscribe for particular messages?
We need also to be able to list all the subscriptions that a particular user may have across all their devices so the user can remove old devices (if they change phones). Or can we rely upon data back from calls to the APNS – when we attempt to push a notification - to inform us that a device token is no longer valid?
Or is there some better way of tying this all together?
When the Phone connects to the APNS server to get its device token, is
this automatic on app start? Or can this be initiated at a later step?
Ie, after logging into our app.
After the app has started, the app gets the token by calling registerForRemoteNotificationTypes. This will prompt the user for permission, and call a callback with the device token if permission is granted.
Can we (are we allowed to) store the device token on the phone in the
Apps data store?. Or, should the App be connecting to the APNS server
every time the app is run?
You'll need to build an APN provider, which is a web server that calls apple to send the pushes. The thing to do with the token is post it to your server that uses the APN provider. The app doesn't connect to APNS, your provider does, and it does it when it has pushes to send.
Can we (are we allowed to) store the token in the App’s memory as it
runs, so we can properly subscribe and unsubscribe for particular
messages?
You can keep the token on the client, but you don't really need to. It's your web service that calls APN, so it needs to be kept aware of your users' subscription prefs.
We need also to be able to list all the subscriptions that a
particular user may have across all their devices so the user can
remove old devices (if they change phones). Or can we rely upon data
back from calls to the APNS – when we attempt to push a notification -
to inform us that a device token is no longer valid?
APN also provides a feedback service that you call in batch which returns the device tokens that are no longer valid. Not only can you use this service, but you must. Apple will get mad at apps that repeatedly send to no longer valid devices.
Or is there some better way of tying this all together?
Yes! Parse.com provides a nice wrapper on the client code, does the provider and feedback service, abstracts the idea of single devices to the idea of a "channel" which sounds like just what you need for multiple notification types A, B, C, provides a super-easy step by step setup, and loads of other useful cloud services for iOS. (I'm not affiliated, but a big fan).
I have implemented a couple of months ago the in app auto renewable subscription on two of my apps. I stored the old receipts of my users and contacted Apple from my server at the end of the subscription period to check if the subscription is still active.
I noticed that some of my users are being auto-renewed form the client code itself.
My app upon entry calls [[SKPaymentQueue defaultQueue] addTransactionObserver:myObserver] and when either SKPaymentTransactionStatePurchased or SKPaymentTransactionStateRestored is returned it calls my server to verify the receipt and give my users the subscription.
I have been trying for quite some time to understand the logic behind the transaction notification the client gets at the end of the renewal period. Does anyone knows why only some of the users get the notifications and the rest require the server to revalidate their receipts? I tried to think maybe it has got something to do with the call to addTransactionObserver. Maybe those users killed the app while it was in the background and entered the app again after the subscription period ended which caused the addTransactionObserver: to be fired and the notification to arrive.
If I can get all of my users to get this notification I wouldn't have to run the server calls anymore at the end of the subscription period as they would be fired from the client when needed.
Any insight would sure help understand this puzzle.
Thanks
Roi
My experience states you'll need to continue periodically verifying receipts on your server. I have noticed the same as you, that these new receipts are sent to the app inconsistently. I think Apple will send the receipt to the client if they happen to freshly launch the app within a certain time frame of the new renewal.