when to properly store or delete users device token - ios

Okay so im coding this app in iOS. Got the Push Notifications down pretty good. I just have one question. Would it be wise of me to store a users device token when they login and delete it when they logout, or keep it forever and basically only update it when a user logs in.
I guess what im seeking is.. best practices for storing and renewing device tokens.
My main issue is this.. when a user logs out... dont they expect to no longer receieve push notifictions. How does facebook approach this? From my understanding if i log out of my FB account through the FB app. It no longer sends me Notifications, am i correct? Im not a big FB user lol

I store mine using NSUserDefaults when the user logs in (and send it to my back end) and then delete it when the user logs out. Multiple reasons for this, A: It could change, there aren't really any specific docs saying if it will remain the same across devices with a backup/restore (but NSUserDefaults will). B. Also if a different user logs in on the same device you'll want the device token to then be connected to that user.
In the didRegisterForRemoteNotificationsWithDeviceToken you can check to see if the device token is the same as the one stored in userdefaults and update it if need be.
Generally speaking if the user logs out they no longer expect to receive notifications. And certainly if another user logs in on their device, they expect to receive notifications for that user. And yes this is how FB App works, or really any social media app. You wouldn't expect to get notifications if you are logged out.

Related

iOS APNs only after authentication sign-in within app?

I've looked through Apple's documentation on APNs and I can't seem to figure out if what I'm looking for is possible. I'm trying to create an app that only sends out push notifications after you have signed into the app. I want there to be a public section of the app that anyone can access, but I am hoping to utilize the push notifications to send information I don't necessarily want the public to see.
Can anyone tell me if that's impossible, or if I've missed some documentation somewhere that will get me through what I'm looking for? Thanks in advance.
Definitely possible! I actually just recently had to solve this problem :)
Like some of the users mentioned, one way to do it is just to position when you prompt to allow push notifications. If you wait until a user is logged in to ask you can solve this problem by assuming every user who's said yes has logged in.
See below for some things to think about before choosing this solution!
The hard part is going to be some of the edge cases you may run into. Some things to think about right off the bat might be:
Make sure to think about what happens if a user signs out again after signing in. Using this solution, that user would continue to receive the push notifications after sign out because they would have already accepted push notifications while they were signed in.
Think about when you ask them if they would like to receive push notifications. Of course, you can ask them only when they've signed in, but you're missing access to all of the signed-out users if you ever want to attempt to get them to sign in and become (i'm assuming) premium users. If you choose to ask them before they've created an account you have the ability to send them messages in the future, even if they are different than the messages you send to your signed in users.
I ran into these issues when we were creating ToggleHQ and it was a pain (there are more edge cases too that might take some more time to write up haha).
We ended up assigning a device to a specific user on login so you can send messages to just those devices (logged in) OR to all devices (consider these the public notifications). You can also send notifications to logged in users that have enabled certain types of notifications, but, that's another story.
One more note: It's often best to ask users if they want push notifications with a popup that explains a bit more about the benefits prior to showing the standard apple popup. That way you can ask them again later if they say no without sending them to the Apple Settings :) What we ended up doing in our own apps (and suggesting others do too) is to find the first point in your app where a user could see the value in push notifications, and ask them then!
Hope this helps!
Yes that is possible.
The app will only receive notifications after it requests permissions from the user. Some more info.
So if you don't want unauthenticated users to get notifications, you can simply have the app ask for notification permissions after the user is authenticated.
Your app can receive push notifications only after user allows push notifications to receive.
To send push notification from your app, you need to call some Web API from your app.
Hope this helps!

FBSDKAppInviteDialog invite successfully sent, but no notifications received

What I'm doing?
I'm trying to send invitation to my Facebook friends using FBSDKShareKit.
Is it working?
YES – but only with test users (and not with real users).
What's the problem?
Getting push notification for the invitation
Getting notification inside Facebook app
Able to see invitation
If app installed then Facebook will redirect to app else will open AppStore for Installation.
These all working fine – but only with test users and not with real users accounts.
Some facts :
My Facebook app is live and publicly available.
The app I'm trying to invite for is not live yet. So I'm using an app id of other app. However this is working (as I've explained above).
With real user accounts its working – showing success once I invite to other users, but they will never receive push and inside app notification about that invitation.
Your suggestions ?
As you know this is something really strange ! Its working with test users and not with real users, what I'm doing wrong?
Any thing that I'm missing?
How do I make sure that it'll surely work with real accounts when my app will go live!
The answer to my question I got while writing the question, as I've written it too long, I decided to keep it here and give a answer.
I was not getting push/notifications for real users as I'm trying to invite the users who've already authorised my app. As it require for those real users to remove my app from their Facebook's Settings [Settings > Apps] and then if I'll send him a request they will get it.

Push notification, is it the device token all we need, or more?

I'm reading over this previous thread because I was having a problem converting the device token to something I could send in a POST. That problem is solved, and my token is being sent properly to the server, which we store in a user's account record.
That is all I need to do, right? If we notify using that token, it will go to that user, and only that user? Or am I missing something really critical here?
When you say 'user' do you mean that your app can have different users log in and out?
To handle this, you can set up a table to map user_id to push_token and device_id. You should also add an enabled flag to this map - which means the user is currently logged in on that device.
Conceptually, while a device has only one push token, it may have many users, and a user may have many devices.
When a user signs into your app on a device you send user_id, push_token and device_id and set enabled=TRUE in your table. If this user/device combo never existed, add to your table.
When a user signs out of your app on a device you send user_id and device_id and set enabled=FALSE in your table.
When an event occurs that would trigger a push to user with user_id then you can look up what push_tokens are associated to that user_id and enabled=TRUE. Then you can simply push to those tokens.
#dmorrow is right. In addition, you need to make a .pem certificate with the same app id to make server push notifications work, check this ANSWER

Register an iphone App in a web service

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.

Foursquare API Disconnect User

I have users who have authorized foursquare to connect to my app but then have subsequently deleted their account on my app. I use the foursquare real time push api and foursquare keeps pushing checkins of users who no longer use my app. Right now I just ignore them, but I'd like to make an API call to disconnect these users from my app so I stop recieving their pushes. I can't find anything on that in the docs. Any pointers?
Foursquare doesn't provide a way to programmatically disconnect users. There are security implications here, and the only way a Foursquare user should be able to disconnect any of their apps is after they have logged in with their credentials on foursquare.com.
I suggest that there are worse security implications in not having a way to do this, especially with the real-time (push) API. Most users are not savvy enough to go into Foursquare.com to remove an app, especially since apps make the connection pretty seamlessly. Once someone deletes an app, having the app's server continue to get push messages every time that user checks-in is a privacy issue.

Resources