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/
Related
I've just implemented the ATT request in my applications. It appears at the app first opening but I would like to show it again if the user wants to change his preferences from the app settings (internal).
I tried to call the requestTrackingAuthorization method again but it enters immediately to the completion handler. Is there a way to reset the status?
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.
I'm implementing an iOS app that handles a custom protocol.
Writing the method application(openURL:sourceApplication:annotation:) in my AppDelegate was easy but I'm left with a problem: I want that - once the user have done with the request - my app move to the background and send the user back to the caller sourceApplication (e.g. a browser, a QRCode reader, or any another app).
This is just like the difference between "tel:" and "telprompt:" url calls: in the former case the phone app remains active, in the latter case, after the call, the user is send back to the sourceApplication.
In order to let my app handle my custom protocol like "telprompt:" does, the only way I can think about is terminate the app once the user action is completed... but this is against iOS Human Interface Guidelines (they say "Don’t Quit Programmatically") and my app can be rejected by Apple.
On Android it is easy: you respond to an Intent with an Activity and when you call finish() on that activity the user is back to his previous app/browser/whatever.
Anyone knows a good way to achieve this on iOS?
Just to clarify:
my app don't call openUrl, it responds to openUrl requests from browser, QRCode reader, other apps;
I don't have to make phone calls;
when I handle a request I ask the user for some data, contact a server, and that's it: the interaction is finished and it would be very nice to drive the user back to previous app without let him use the home button.
I believe you should call openUrl when you are done, with the source app url in param.
That's what facebook does when you use the "connect with facebook" API.
I'm sending a Facebook app-invite from my iOS app, and am trying to implement a success/fail flow using blocks.
I have created a class to wrap my communication with the Facebook SDK which exposes a send invite method.
In that method, I have the following code:
[self.facebook dialog:#"apprequests"
andParams:params
andDelegate:self];
as explained in the documentation.
My wrapper class conforms to the FBDialogDelegate protocol, and I have implemented 5 of the delegate methods:
dialog:(FBDialog *)dialog didFailWithError:(NSError *)error,
dialogCompleteWithUrl:(NSURL *)url,
dialogDidComplete:(FBDialog *)dialog,
dialogDidNotCompleteWithUrl:(NSURL *)url
dialogDidNotComplete:(FBDialog *)dialog
The problem is that wether the user cancels the dialog or sends the request, the only method that is being called is the dialogCompleteWithUrl:(NSURL *)url method.
Can anyone explain this?
This seems to be an outstanding issue that has been reported several times. The fact that didComplete is called when the user presses the cancel button is indeed a valid action so it is by design that didComplete gets called. The documentation might be outdated and we have a task to fix it, but reporting a doc bug on our developer site will allow you to track the progress.
So to answer your question, if the user presses the 'x' button it should call didNotComplete. User pressing send or cancel will call didComplete as it is designed that way.
However, this person came up with a good workaround for FBDialog where you can probably do something similar, such as checking the value of the URL when it succeeded vs when the user presses cancel and have an if check that checks for that case.
Hope this helps.
im trying to make a call through the telpromt command:
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:#"telprompt://123456789"]];
The problem is, that when de code is run, it displays an UIAlertView not of my property, asking to confirm the call.
It has to buttons: Cancel and Call.
I want to programatically press the call button in the AlertView.
Is it possible ?
Thanks !
iOS does this to protect the user from malicious applications which would try to make random calls. Anytime there are integrations to the phone, SMS, twitter, facebook, etc. apple requires the user to accept and allow the application to perform the action. This is why the iPhone displays a UIAlertView asking the user wether they really want to make a call to the phone number you're providing.