I had a look into a few airline apps around there. This posed some questions, I couldn't find an answer to and would like to ask you as well. My questions won't have any code but aim more at the procedural level of such applications.
The first thing I wondered: When I use an airline app for booking a ticket for example, I guess that my smartphone will be registered in a database on a web service somewhere. Usually the companies will send you push notifications for further updates. This would imply to me that the device token by the APNS is saved in a database table "devices" for example, such they could find my device later on and send me notifications.
To make my question clearer I think about the flow of the user that way:
Open airline app for first time
User is being asked if he will allow push notifications
User confirms
APNS is providing a device token
The web service of the airline will save that device token in their database
If an update is necessary, use the device token in the DB and send
an update to the client
That would be the "easy" way to identify my users by their device token. But what would be the "standard" way of keeping track of registered devices?
To build upon my first question, I would like to expand this example a little bit. Most of the airline apps have the feature within the app to save a ticket as a passbook pass. I we take into account that the user has already accepted push notifications for the app he would be registered and listed on the web server with a device token for future reference.
As far as I know, passkit will send a web request to the airline server that they would have to parse in order to communicate with the passkit server. But in this request contained is a push token requested by the passbook app to receive updates.
Now I would think, that you have two different device tokens for the same user? I don't think you just can use the existing device token for pushing messages to the client in the database?
So how do you solve such an issue? If you have a user in your database registered and the airline provides a ticket as passbook pass, how can passbook interact with this data correctly afterwards?
I hope I could make my point in my questions :)
Thank you
what would be the "standard" way of keeping track of registered devices?
Whenever user starts your app you will get a callback
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken{
// associate device token with your username and send this to your server
}
Please note that device token keeps changing . From Apple docs
you cannot save a device token and use it for future reference. You need to update it for every run. Your server need to sync it's database of tokens.
Edit ..
Flow of user
To make my answer clearer I think about the flow of the user that way:
Open airline app
User is being asked if he will allow push notifications
User confirms
You provide device token and username to your server.
If your server now needs to send push notification it uses the most recent token and
send it to APN.
Related
I’m developing IOS app which do calls to the server. I want to allow users to use web services from ios app only after subscription was made, no login required
How to identify whether IOS REST caller have active subscription, without “login with apple” ? I saw several apps is able to do “premium” calls to server right after subscription was made.
You could do it this way:
An account ID is automatically created when the app is started for the first time. This happens unnoticeably in the background.
The account ID is sent with every API request. The server then only checks whether this account ID has a premium status.
If the user buys the premium status, update the account ID on the server side.
This is just a short description without any advice on security and best practices. Please implement this solution only if you know what you are doing. By the way, this approach is also used by ivpn.net.
I have iOS application where new data arrives each hour on server.
When new data arrives, I would like to notify user if there is something of interest for him, based on his alert definitions.
I learned that only way to achieve that is APNS (Background tasks are not an option for regular precise waking up and fetching data so far I can tell after reading a lot).
I don't want to add registration/login requirements for user.
Is it possible and aligned with Apple standards to retrieve device token and send it to server each time with each alert request created by user, so that I can notify him/her by push notification once it is fulfilled?
So I can pair device token with alert request in database on server.
I don't want to implement apps feature and to go through effort of implementing APNS both client and server side only to get application rejected by Apple. Therefore, any reference to if it is possible or not, personal experience or working solution proposal is much appreciated.
Unfortunately, iOS uses a UUID as "device token" and it changes frequently and randomly (to protect privacy) so unless your application handles users one way or another, you won't be able to pair users with devices.
A solution might be that when your application installs for the first time and opens, you generate a unique id, it can be a UUID or some random string and save it to the keychain or if possible loses are okay, just save it to userDefaults. Keychain persists between app install and even is the user switches phones and you can use this uuid as "user per device"
So my client wants an app that works like this:
one user presses a button on his device
other user(s) get a push notification
no third party server
So I have been looking into the Apple Push Notification Service but I don't want to have a third party "provider" server. Would it be possible for an iPhone to act as a "provider"?
I have already looked at this question which sounds like what I want to do but I am not satisfied with the answer. More specifically:
Would encrypting the APNs key with another key hardcoded into the app be secure enough? Any other ideas for dealing with that issue?
The tokens will always stay the same for a given app for a given device, right? If that's the case, I can deal with creating the token database. If that's not the case, my app won't work.
Will Apple accept such an app?
Would encrypting the APNs key with another key hardcoded into the app be secure enough?
I believe the main issue is you'll need to deliver APNS certificate and private key with your app, and renew it when needed (on all devices). Regardless of it being encrypted or not, if it is available for your app, it might become available for attacker (by dumping its plaintext representation from memory, or by disassembling your decryption code) and make it possible to impersonate your app. So no, it is not secure.
The tokens will always stay the same for a given app for a given device, right?
Not really. Documentation claims that a device token is not a unique ID that you can use to identify a device. Device tokens can change after updating the operating system on a device. As a result, apps should send their device token.
Will Apple accept such an app?
I believe there were no precedents because of the reasons above.
I am using apns notification for my app, and for this i am storing the apns device token in my sql database.
The issue is that every time the user deletes or installs the app, it generates a new device token and this gets stored in the database, since the same user can have multiple devices, I cant update the token for that user and a new record gets created. this has let to many records for the same device and same user. it might lead to performance issue later.
Please help. How do I fix the issue storing multiple tokens for same user.
Sorry for replying late, we fixed the issue by running another job which used to delete APNS token stored in database other than the latest one.
Our database stored APNS tokens for each user and each device. Depending upon these uniqueness. only latest tokens for each device is kept in database to prevent multiple notification on same device.
another solution is to use upset (insert or update), if any device already has a token then update the same with new one or insert.
I feel IOS should provide reliable API to handle this. The present Delete token API is not reliable.
I've used the following tutorial to implement push notification in my app.
http://www.raywenderlich.com/32960/apple-push-notification-services-in-ios-6-tutorial-part-1
And it works for development version. But I had include a device token in the payload (php) file.
Does this need to be the same for distribution as well. Do I need to gather all the device tokens from active users and send distribution push notifications, one by one?
I thought I would be able to do a broadcast without keeping track of all active device tokens. Is this not the case?
App is already on app store by the way.
Thanks.
Yes, you have to keep track of their device tokens. Also keep in mind that the device token might change for a single device, even though that doesn't happen frequently.
If you think that's too much trouble, you can use some service like Parse.com to do that for you, using their SDK.