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.
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've been approached by a client to try and figure out if we can send notifications when the user of our app is on the checkout page of another app.
In this specific instance, they want us to send a notification when the user is on Amazon's checkout page.
Is this even feasible? I'm stumped to be honest. The best I can think of is to send a notification when a third party is opened, but not when they are on a specific part of the the third party app.
No, all apps are sandboxed and can't access such information about other apps.
I'd be fairly sure that, even if possible, such push notifications wouldn't be viewed kindly by apple. Trying to hijack another apps flow, is probably a big no no
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!
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.
I'm trying to find a best way to send invitation to facebook friends from iOS App.
In the recent api release, I found facebook is restricted the invite policy.
After searching around, I summarize my finding here:
Feed (Graph API user/feed) is used to post message on user's own wall, then friends could seen from their own portal if the feed has mention the friends.
Pro: message could be customized and including pictures etc.
Con: mention 10 people max, also need user interaction in app.
If user just post a message in their own wall, only friends comes to his page could see it, but not possible for notifying friends.
Request (Graph API user/apprequests) is used to send an request directly to friends, there are two kinds of request: User to User and App to User
User to User request scenarios (I'm interested in the first scenario)
The recipient is a friend of the sender and has not installed the app. This is considered an Invite.
Pro: Seems the proper way of invite, friends will receive notification and popup.
Con: Includes maximum 50 friends, and also need user interaction.
The recipient is a friend of the sender and has installed the app.
The recipient has installed the app. In this case the sender and recipient do not need to be friends.
App to User Request: friends will receive a message from the app, but the message is only sent to user who already has the app installed, so this is not useful to me.
So it seems my best shot is to use User to User request. So my app could provide user a list of 50 and ask him/her to confirm sending in the facebook webdialog. But what if user want to request to all their friends, sometimes 500+. Seems facebook is tighten this up to promote their Mobile App Install Ads, or App Center. Ads is another topic. I already have the App Center setup, but how should I let user's friends know about this?
I've been searching for three days, but couldn't get a ideal solution. Folks, suggestions or solution? Thanks in advance!
I've been looking into ways to do this myself and my strong suspicion is that Facebook are trying to discourage / deprecate this feature.
They haven't yet updated the 'Requests' system into their new API (you have to include the old headers to do it), despite pretty much all other features being ported over to the new system.
As you mention, they now have mobile app install ads which they're quite keen to push
And finally, Open Graph: personally, whilst as a developer I'd love to give people the option for people in my app to invite their friends over Facebook, as a user I can see why this would be annoying.
There's a large potential for these requests to be spammy if sent to many users at a time, and also they're quite unnatural, they go against the idea of OG which is that, your friends actions are fluidly put onto their wall where you can see it and choose to investigate / install the app yourself if it sounds interesting.
i.e. the idea now is that app promotion on Facebook is done more naturally and encouraged by usage rather than explicitly forcing requests