The second time I tried to authorize an app in Facebook it gives me back a window
You have already authorized app name. Press okay to continue.
The question is what is called back/delegate that is called after I press okay, because I somehow need a way to remove the login view controller after this
The callback is the same as when you wasn't authorized. Same process.
Back in your application you don't even have to (and even can't) make the distinction.
In your UIApplicationDelegate, be sure that the - (BOOL)application:handleOpenURL: method calls - (BOOL)handleOpenURL: on the Facebook object.
Related
I have an in-house app which is used by staff but the chances are the device it is used on could become consumer facing. With that in mind I want to ensure that should the staff forget to logout when they switch apps or just reopen the app that I have a command in there to effectively log them out.
After researching I think the best way for me would be to use:
optional func applicationWillEnterForeground(_ application: UIApplication)
and then force the app to go to the login page or the reverse so that when app enters background it forces the app to the logout URL.
Which do you think would be best and how can I use that command to then add in the chosen URL as described above?
So, while I agree with #Rakesha-Shastri in that ""app enters background it forces the app to the logout URL" This seems like bad UX. The first one where you display the login page on returning from background seems fine. It is important that the user is able to resume his work where he left off after logging in again," there does need to be a way, in-case a user is gone too long, that the credentials have passed. It seems in your case, that every time the user LEAVES or CLOSES the app, you want this to be unauthenticated. What if the user gets a phone call? Should it do that? You may want to use Timer, of say some period of time, 2-5 minutes maybe.
Any who, what you can do is force the user to have to RESTART the app, by either presenting a controller that has NO CAPABILITY of going anywhere, therefore forcing a restart, or providing a button that sends them to a login screen you have implemented.
Note:
I would definitely indicate to the user, "due to purposes of security, each time you exit the app, it requires an authentication to re-access. Please log back in". Then provide a button to the login screen.
As you did not provide code, and I'm not going to do this for you, a direction to take this would be to utilize optional func applicationWillEnterForeground(_ application: UIApplication) alongside with getting the current UIViewController. I would google how to do that. Then from there, you can create a new UIViewController that presents this button back to the login screen.
During the initial app installation everything works as exptected: application:didRegisterForRemoteNotificationsWithDeviceToken: is called after the prompt *"APP Would Like To Send You Push Notifications"* is accepted or rejected. But if the app is deleted, and reinstalled again I'm getting a weird behaviour: that delegate method is called BEFORE user had a chance to accept or reject the prompt, right after it appears...
In my app I need to perform some UI action after a user accepts or rejects that prompt, and I don't see any other option other than using the above delegate method (and it seems not to work after re-install)
Any help is greatly appreciated.
I've got an iOS app in which it starts differently if the user has been logged in through Facebook account or not.
So the application flow is as follows:
1- I call app delegate, which creates a navigationController and shows it.
2- In the root view controller, it checks if the user is logged in or not. By default (for example during the first boot) it loads view controllers as not logged in, showing only contents for not logged user. if the user is logged with Facebook account it sends requests to a server and shows the contents for logged in user. The requests start with didupdatelocation delegated method, from which it gets the current location.
3- there are many places in which the app asks if you want to log in. If the user gets correct login, it creates a new navigation controller, as in app delegate, and displays it. The problem is that in this way it doesn't call the method didupdatelocation, and so it doesn't get current location and doesn't make any request to server.
How can you suggest me to solve the problem?
Your design should not rely on didUpdateLocation to be called. This method is called at non-predictable intervals by the system.
One way to force it to call however, is to stop the locationManager and start it again.
startUpdatingLocation
stopUpdatingLocation
However, I recommend you consult the CLLocationManager Class Reference and re-design your login check accordingly.
I have the following problem, I would like to know if there is something implemented by facebook or if you know a workflow to avoid this issue.
Basically I use facebook SDK to login, the app send me to the browser, and instead of clicking cancel or Accept/OK, I click home button and get back to the app.
In that case I don't receive any callback from facebook SDK.
Also, facebook have a delay when you click cancel or ok button, so when you get back to the app you don't know exactly if you are going to receive the callback or not by 2-3 seconds aprox.
My current solution is giving a delay of 3-4 seconds and check if you are already connected or not, and show the buttons again if you are not connected. It's a really bad approach, but I can't find something better for that.
You're supposed to handle this in your AppDelegate's applicationDidBecomeActive method:
- (void)applicationDidBecomeActive:(UIApplication *)application
{
// Handles activation with regards to returning from iOS 6.0 authorization dialog or from fast app switching
[FBSession.activeSession handleDidBecomeActive];
}
Docs here: https://developers.facebook.com/docs/reference/ios/current/class/FBSession/#handleDidBecomeActive
and
https://developers.facebook.com/docs/ios/ios-sdk-tutorial/authenticate/
As the title says, my project will never bring up the FB login screen until I have called
[facebook logout];
This makes sense when I've already logged in, but it happens on startup as well (i.e. the user is not yet logged in).
Hmmm...I've just tried resetting contents and settings in the simulator, and that seems to have fixed the problem. For my own peace of mind, why when I close the simulator and rerun the project does it not revert to either a state where the app is 'new' and hasn't been run before, or to a resume state - whereby the logged in user info would be available immediately?
On my device I have just tested this:
Fresh install
Open app, login via FB Connect
Close app, remove from running in background apps
Reopen app
Try to login, no response until I first click logout
So is it somehow retaining the fact that it has logged in before? If so, is there a "loggedInAlready" variable or something similar that I can check against?
Added this to didFinishLaunchingWithOptions
if([facebook isSessionValid])//if already able to log in
{
[self loginToFacebook];//attempt to login automatically on startup
}
Seems to have solved the problem. I guess that because I had:
if([facebook isSessionValid]){
[facebook login];
}
in the login button press, that when it resumed it was still in a valid session and so the button press wouldn't do anything until the logout button ended the session.
Now it automatically checks if the session is valid on startup, and if so it logs straight in for me.
:-) All's well that ends well.