Every time the user open my app, I call forge.facebook.hasAuthorized to check if the user is already logged-in, and has authorized my app; if that is the case, I automatically log him/her into the app otherwise, I take him/her to a facebook login page.
The expected behaviour is that if the user has the Facebook app installed, and has already authorized my app, forge.facebook.hasAuthorized will return true (as is the case on Android). For some reason forge.facebook.hasAuthorized always return false on iOS, resulting in the user having to login using Facebook every single time.
I started seeing this behaviour after expending the facebook permission I request the user to authorize.
This is clearly an unacceptable behaviour for apps, which results in a seginficnt decrease in user engagement. Anybody knows how to solve it?
Answering my own question just in case somebody made the same silly mistake.
I had trailing spaces if some of my permissions, for example "user_likes " instead of "user_likes". Turns out that for some reason this causes a really weird behaviour.
Related
As the title suggests, I'm having an issue with the method ACAccountStore requestAccessToAccountsWithType:options:completion. I expect this method to only prompt the user for permission the first time it is called for my app, but it is being shown every time.
Is there some way of checking whether the user has granted permission so I don't have to request it? Or is there some other kind of magic that will stop this behaviour?
I find this very odd, since in an earlier version of the same app, the behaviour was as I expected - it only prompted for permission on the first call.
Answering my own question. Hopefully somebody will find this useful some day.
What seemed to be causing the problem was a mismatch between the permissions available to my app, in particular the basic read permissions, and the permissions I was requesting. While my app's Facebook page showed 'email' as a basic read-permission, it was requesting 'basic_info'. Once I changed the permission to 'email', the app asked once and didn't do so again.
I implemented Facebook login a while ago in my app, using the Parse tutorial:
https://parse.com/tutorials/integrating-facebook-in-ios
It seemed to be working just fine, and I released my application to the app store. I then changed, on my Parse dashboard, the app from regular to "Production", and I was wondering if this could cause my Facebook login to stop working.
The actual error message on the phone, which occurs after a user presses the Login button, then after hitting accept for the basic facebook permissions, it brings up an error message:
Could it be the production switch, or is there something else wrong here?
I think there are just two things that should cause this error. First and most possible one is the one you thought of it, so switching to the production. And the second could be some similar setting on facebook developer site. You shoould check there if the settings there are in production environment. I know I dont give you anything specific but I'll for problem there if I'll have the same problem.
I have a iOS app, the users can login and logout whenever they want.
In server side, I want to know which users are online.
I could do something like set the user online when the login webservice is called, and set it offline when the logout webservice is called. But, I can't be sure that the logout is always done, maybe the cellphone suddenly turned off, so the server will keep the user online, and when they try to login again he will get the error "sorry, you are already logged in"
Maybe I can do something with the feedback server (my app uses push notifications) but I don't know how fast it detects the user has gone offline...
In these cases I think the best think to do is that your App should ping your server every X seconds and update a kind of "last_online" field.
Then in your logic, you can consider for example that a user last seen online more than 3 minutes ago is to be considered offline.
Like you said, you can't trust the user to click "logout" so you can't assume that's the time he logged out.
Of course you can still let the user click logout manually.
I'm using
(void)openWithBehavior:(FBSessionLoginBehavior)behavior completionHandler:(FBSessionStateHandler)handler
to open my session, which works fine. After open, I then get my read permissions with:
(void)requestNewReadPermissions:(NSArray*)readPermissions completionHandler:(FBSessionRequestPermissionResultHandler)handler
This works fine, but for users signing in through Mobile Safari (or likely the Facebook iOS app, haven't tested), users get jumped back and forth twice (tap login in my app, jump to Mobile Safari, log in there, jump back to my app, jump back to Mobile Safari, approve permissions, jump back to my app.
Returning users - those who have signed out of my app (and token removed), also get a double-jump - each time Mobile Safari tells the user they've already approved the app.
I'm using openWithBehavior because I prioritize the native iOS login using FBSessionLoginBehaviorUseSystemAccountIfPresent. I don't see a version of this combined with an initial permissions request (such as openActiveSessionWithReadPermissions...).
I was hoping that, for subsequent logins, permissions would already be known via session.permissions but in testing that value is null until requestNewReadPermissions is called.
Is it possible to remove the double-jump from either or both scenarios (first user login, subsequent user login) yet still achieve the same permissions?
You can "init" your session with read permissions by calling the initWithPermissions: method. Then call openWithBehavior:completionHandler: which will do only 1 open call with the permissions you've already set.
I'm trying to setup my app to publish a simple post to a user's Facebook feed (image url, link, description). They don't need to use Facebook for anything else so the first time they click "Share" it needs to authorize the app, and the publish permissions.
If they have their credentials stored in the device as of iOS 6 they simply get two alert boxes and it's done with. But if they don't, or have an older version, it switches out to Safari for login. My problem is that it is then switching the user back to my app, then immediately back again to Safari to accept the publish permission. It's very jarring and unprofessional.
What I would like is for the page in Safari to change after the login to the permissions page so they can accept it, and THEN switch back to my app. I know this can be done because the popular Mixology app does exactly this behavior. Unfortunately Facebook keeps changing their SDK and all the information I find online is outdated.
I wrote up a solution here: FacebookSDK presents login UI twice to avoid the double switch.
Basically, you can use openActiveSessionWithPublishPermissions: to do what you want. However, you have to handle the special case where the user has signed in to Facebook from the device settings, which requires requests for read and publish permissions into two separate calls.