6
votes

In my iPhone app, I want the user to be able to share a link on Facebook.

When they click "share", I use the following code to login to Facebook using the new SDK 3.1, then use FBRequestConnection in the completion handler (a simple publish_action).

[FBSession openActiveSessionWithPublishPermissions:@[@"publish_actions"] defaultAudience:FBSessionDefaultAudienceFriends allowLoginUI:true completionHandler:^(FBSession *session, FBSessionState status, NSError *error) {

    // Now call FBRequestConnection to post in the stream

}];

When the user has the Facebook app installed, it just delegates the login to the app. However when they don't, it opens the login page in a WebView.

In iOS 5, it opens Mobile Safari:

enter image description here

My problem is on iOS 6, I get the same flow but in a modal popup instead (on top of my app).

enter image description here

I have 2 issues with the popup:

1. Closing it

It cannot be cancelled or dismissed. In comparison, the HelloFacebookSample app from the SDK has the same popup but with a cross button to close it.

enter image description here

NOTE: now solved thanks to ravi, I was missing the Facebook resource bundle which contains the "close" image.

2. Accepting the permissions

On the second step of the popup (see screens above), pressing Okay doesn't do anything. Pressing the "X" calls the completion handler with an error, which is great, but nothing happens with Okay. Is this the right way to login to Facebook with the SDK 3.1? Am I missing a callback to react to the popup specifically?

Some more clarifications:

This only happens in iOS6 when the Facebook app is not installed and the Facebook account is not configured in the iOS settings.

Thanks!

2
+1 im having similar problem after FB is updated to 3.0SDk - iMeMyself
Might be a bug in the SDK. Just a note; Facebook encourages asking for publish permissions when you're actually publishing (and not when connecting): developers.facebook.com/docs/howtos/ios-6 - Kristofer Sommestad
Thanks Kristofer - by "execute a publish_action later on" I actually meant as soon as the login callback arrives. I think that should be OK - Romain
The reason that read and publish permission requests have been split has been to ensure that the user feels comfortable with an application before it starts posting on their behalf. Requesting publish permissions back-to-back after logging in is going to give you just as much of a drop off in permission acceptance. (Plus more actions you're expecting the user to take to get started) - James Pearce
For the moment the app doesn't do anything until the user chooses to post on Facebook, after which it logs in using openActiveSessionWithPublishPermissions, then posts using FBRequestConnection. Is that acceptable? From what I understand, you say I'll have to be careful when the app starts logging in to Facebook at startup? - Romain

2 Answers

7
votes

I can't comment as my reputation is less than 50, so trying to point out my observations as answer.

I too noticed this problem when using Facebook sdk3.1 on ios6. In my case I'm using the old style facebook object creation and call [facebook authorize:permissions] on it, but I modified the source code to always use "FBSessionLoginBehaviorForcingWebView" so that my login is always through in-app web login.

In my case I was missing FBUserSettingsViewResources.bundle and FacebookSDKResources.bundle, so I was unable to see the cross button (but I was able to tap on that spot and getting call back - (void)fbDidNotLogin:(BOOL)cancelled {) .

0
votes

I also encountered this issue and it does appear to be a known bug:

https://developers.facebook.com/bugs/539702426044893?browse=search_507daefc9af416244781488

I haven't resolved the issue yet, but for me it only seem to happen in the simulator. My app seems to always login through safari when installed on a device

Edit: So after a little more digging I came across this stack overflow thread: FBConnect login, share with a webview?

I realized that the dialog we're seeing is a uiWebView which is actually the fallback if the app is unable to open the dialog in safari. I was able to work around my issue my reseting my simulator, which would essentially clean out the cookies. From your screen shot I believe you are working in the simulator too. I wonder if you reset the simulator if you would have the same results?

From the menu iOS Simulator -> Reset Content and Settings...