Facebook 3.1.1 SDK breaks A LOT

Ah, of course. @haakon, thank you so much for clarifying it. After reading your reply post #15, I re-read your post #13 above, and it clicked. (I can’t believe I didn’t get it the first time around, especially since you did include facebook.request(“me/friends”) in the GET list. Yikes, I was blind.)

Thanks again!!

Naomi [import]uid: 67217 topic_id: 34416 reply_id: 139653[/import]

We’ve had an outstanding bug request on this new Facebook API issue since January 9th and can’t get anybody to respond to us. We provided sample code (their sample API code) to show the bug and they simply won’t respond to us.

We can’t drop back to build 990 because the custom notification tag issue was fixed in 996 and that is a show stopper too.

bug 20096 has been open with no response. http://bugs.anscamobile.com/default.asp?20096_d4djkrj5jbbsen14

Is anybody at Corona still listening to their clients?!?!? [import]uid: 120928 topic_id: 34416 reply_id: 140265[/import]

Hi All,

Thanks for this thread, it’s stopped me going mad debugging this issue. I have one stupid question if I may? How do I now get the publish permission when I need it? Do I just re-login or is there a better way?

Eg
1: Login (without publish)
2: Get friends etc
3: ??? (something to get the appropriate permission)
4: Post to users wall

I am trying to call the login function again (with the added permissions) - but all it does is open FB for a few seconds, returns to my app and fails. It doesn’t prompt the user to grant the additional permissions.

Thanks

Antony

[import]uid: 169392 topic_id: 34416 reply_id: 139670[/import]

We are looking at the issue now. [import]uid: 7559 topic_id: 34416 reply_id: 140270[/import]

Glad to hear Corona Labs is looking at the bug @cebodine reported. When testing all possible FB login routes (and login cancel routes) that users could make in my project, I found the very similar failure that @cebodine noted in the report, and I have not been able to sort out workaround short of killing the app – and yes, once killed, I don’t see the FB failure again. Very frustrating.

Edit: BTW, when it fails, I now get this error: Error: HTTP status code: 400

I’m using daily build 1008 (but plan on updating to the latest soon – perhaps after the FB related fixes get in.)

Naomi [import]uid: 67217 topic_id: 34416 reply_id: 140279[/import]

From our point of view only one user filed a bug report with recent Facebook issues. Generally when there is a major problem, we receive reports from multiple users reporting the problem. That’s generally a good gauge of bug or operator error. We are looking into this and will report back what we find.

-Tom [import]uid: 7559 topic_id: 34416 reply_id: 140282[/import]

Hum, do you mean that we should just not check for duplicate bugs and just reenter the same bugs over and over again? That sounds kinda strange to me :wink:

And i guess most people (at least i do) first think that they did something wrong (especially with Facebook), reason why you may not have received that many reports.

Anyway, thank you for taking care of this and keeping us informed, looking forward to see that working again.

Dim [import]uid: 100310 topic_id: 34416 reply_id: 140286[/import]

Tom,

Thank you for looking into this issue.

Naomi,

Thanks for the extensive testing scenarios. That is a lot of work and I’m sure it will help find the problems.

Chris [import]uid: 120928 topic_id: 34416 reply_id: 140362[/import]

Thanks for posting the test cases Naomi. That is very helpful.

-Tom [import]uid: 7559 topic_id: 34416 reply_id: 140365[/import]

Here’s the test process I went through. A lot of writing, but I thought I’d go through the code and the test cases to better understand the issue I have. The CASE 3 is the one that caused the Error 400. Is this normal? Is there a way to trap this type of error?

Please note, step 7 of CASE 3 indicates after crashing/killing the app, the FB related code works like a charm.

Not sure if this is of any help, but maybe it would help identify where the problems are?

Also, I really wish I don’t have to call facebook.logout() like I need to. I mean, once logged in, I’d rather not to bring up permission screen and keep asking the user to okay it.

Anyhow, here it goes:


CASE 1: SUCCESS (with a freshly wiped device with a new user)

1 (scene A): facebook.login( myAppID, myFBListener, { “email” } )
* FB Connect button brings up FB log in screen
* User enters FB email address and FB password
* FB permission screen with email as part of the app requirement shows up
* User taps on Log in button
* Login process completes without a hitch and automatically triggers facebook.request( “me” ) in step 2

2 (scene A): facebook.request( “me” )
* Fetches login credential perfectly
* Saves login credential for the app
* Completes the scene A

3 (scene B): facebook.login( myAppID, myFBListener )
* This scene has FB Friend button
* Tapping on FB Friend button brings up FB permission screen (stating that the user has already authorized this app)
* User okays it, which automatically triggers the facebook.request( “me/friends” ) in step 4

4 (scene B): facebook.request( “me/friends” )
* Fetches friends list perfectly fine
* Loads the list of friends without a hitch
* Call facebook.logout()
Note: Without calling the facebook.logout() in key spot, moving on to the next step would trigger the “The operation couldn’t be completed. (com.facebook.sdk error 5.)” At least that’s what I remember happening. So I’ve kept facebook.logout() function in scene B everywhere it seems to need.

5 (scene B): facebook.login( myAppID, myPostListener, { “publish_actions” } )
* Each FB friend that was fetched in step 4 becomes a friend button
* Tapping on a friend button brings up FB permission screen (stating that the user has already authorized this app)
* User okays it
* automatically triggers facebook.showDialog( “feed”, attachment ) in step 6

6 (scene B): facebook.showDialog( “feed”, attachment )
* FB dialog pops up
* Tapping on Share button on FB dialog makes the post successfully
* Tapping on another friend’s button brings up FB dialog (without permission screen this time)
* All is good.


CASE 2: SUCCESS (with a freshly wiped device with a new user)

1 (scene A): facebook.login( myAppID, myFBListener, { “email” } )
* User skips the FB Connect button

2 (scene B): facebook.login( myAppID, myFBListener, { “email” } )
* This scene has FB Connect button this time (instead of FB Friend button).
* FB Connect button brings up FB Log in screen
* User enters FB email address and FB password
* FB permission screen with email as part of the app requirement come up
* User taps on Log in button
* Login process completes without a hitch and automatically triggers facebook.request( “me” ) in step 3

3 (scene B): facebook.request( “me” )
* Fetches login credential perfectly
* Call facebook.logout()
* Saves login credential for the app
* Upon successful save, automatically triggers facebook.login( myAppID, myFBListener ) in step 4

4 (scene B): facebook.login( myAppID, myFBListener )
* Immediately after the login process completes, FB permission screen comes up (stating that the user has already authorized this app)
* User okays it, which triggers facebook.request( “me/friends” ) in step 5

5 (scene B): facebook.request( “me/friends” )
* Fetches friends list perfectly fine.
* Loads the list of friends without a hitch
* Call facebook.logout()

6 (scene B): facebook.login( myAppID, myPostListener, { “publish_actions” } )
* Each FB friend that was fetched in step 5 becomes a friend button
* Tapping on a friend button brings up FB permission screen again (stating that the user has already authorized this app)
* User okays it, which automatically triggers facebook.showDialog( “feed”, attachment ) in step 7

7 (scene B): facebook.showDialog( “feed”, attachment )
* FB dialog pops up
* Tapping on Share button on FB dialog makes the post successfully
* Tapping on another friend’s button brings up FB dialog (without permission screen this time)
* All is good.


CASE 3: FAIL (with a freshly wiped device with a new user)

1 (scene A): facebook.login( myAppID, myFBListener, { “email” } )
* User skips FB Connect button

2 (scene B): facebook.login( myAppID, myFBListener, { “email” } )
* This scene has FB Connect button this time (instead of FB Friend button).
* FB Connect button brings up FB Log in screen
* User enters FB email address and FB password
* User closes the FB Log in screen (canceling the process)

* User is sent back to the scene with FB Connect button
* User taps on FB Connect button, which brings up FB Log in screen
* User enters FB email address and FB password and proceed to log in
* FB permission screen with email as part of the app requirement come up
* User closes the FB permission screen without tapping on Login button (canceling the process)

* User is sent back to the scene with FB Connect button
* User taps on FB Connect button again
* This time, user chooses to go through FB login process, which automatically triggers facebook.request( “me” ) in step 3

3 (scene B): facebook.request( “me” )
* Fetches login credential perfectly
* Call facebook.logout()
* Saves login credential for the app
* Upon successful save, automatically triggers facebook.login( myAppID, myFBListener ) in step 4

4 (scene B): facebook.login( myAppID, myFBListener )
* FB permission screen comes up (stating that the user has already authorized this app)
* User okays it, which triggers facebook.request( “me/friends” ) in step 5

5 (scene B): facebook.request( “me/friends” )
* FB permission screen comes up (stating that the user has already authorized this app)
* User closes the screen without tapping on okay
* It sends the user back to scene B with FB Connect button

6 (scene B): facebook.login( myAppID, myFBListener )
* User taps on FB Connect button again, which brings up FB permission screen again (stating that the user has already authorized this app)
* User taps on okay to the FB permission screen
* App crashes with Error: HTTP status code: 400

After restarting the app, I come back to Scene B straight away.
7 (Scene B): facebook.login( myAppID, myFBListener )
* This scene has FB Friend button this time (instead of FB Connect button). ( Edit: copy & paste caused mis-information. Here, the button now shows FB Friend. I’ve corrected it.)
* Tapping on FB Friend button appears to automatically okay FB permission and fetch FB friends list, which is equivalent to reaching the step 6 of case 2 without any interruption as far as the user experience is concerned. (And this is the type of user experience I’d like to offer after the user logs in to FB and authorizes the app just once.) [import]uid: 67217 topic_id: 34416 reply_id: 140299[/import]

Glad to hear it’s helpful. I’ve corrected some mis-information caused by copying & pasting the steps.

Naomi [import]uid: 67217 topic_id: 34416 reply_id: 140367[/import]

Naomi, is the failing sequence something that just started (e.g, with build 991) or is it there in the current release build (971)? We upgraded Corona to the latest Facebook SDK (3.1.4) in build 991 and trying to sort out if we have a regression problem or not.

Thanks,
Tom [import]uid: 7559 topic_id: 34416 reply_id: 140369[/import]

Tom, read the whole thread; Works in 990, breaks in 991. :slight_smile: [import]uid: 21746 topic_id: 34416 reply_id: 140370[/import]

I was asking about Naomi’s thread. I didn’t see any build numbers mention. [import]uid: 7559 topic_id: 34416 reply_id: 140373[/import]

Hey, Tom, my current project throws out bazillions of errors when I try using older daily build. Let me see if I can reproduce error like this with my previous game that was built with 894. Either way, it involves a bit of work to get the test environment set up. (The last time I worked on Beetle Bounce, it was set up for Android version. Changing it back to iOS with debug statements enabled, plus wiping the device for new user, etc… will take a bit of time – and I’m not even sure if the game itself is set up to go through the same path for the CASE 3 procedure…) Anyhow, I’ll report back…

Naomi

Edit: BTW, my test cases were done with daily build 1008. While setting up the device and test environment, I’ll fetch 991. I will first test Beetle Bounce with 894. If it doesn’t help with the test properly, I’ll see if my current project runs on 991.

Edit 2: Okay, how stupid (I’m calling myself stupid here, by the way.) While I set up BB for the test and built it, 991 downloaded fast enough, and my current project runs fine. I’ll go through all 3 test cases and report back. [import]uid: 67217 topic_id: 34416 reply_id: 140377[/import]

Thanks for all the work Naomi. I did confirm I get Error 5 (status 400) from the Facebook sample app and found this is a common issue with Facebook 3.0 SDK. It looks like there are a couple things that can cause this error. The first caused by sending the same message/photo multiple times. Facebook thinks this is spam and returns an error. The other issue is when you try to post when the session is closed. I need to see if this is what’s happening in your failed case.

You can read more about the issue here: http://www.abdus.me/ios-programming-tips/com-facebook-sdk-error-5-irritating-isnt-it/

I haven’t confirmed it yet but it could be the new Facebook SDK has added more safeguards and we are violating that in some way.

BTW, HTTP 400 is “Bad Request” so that makes sense in terms of what I found.

-Tom
[import]uid: 7559 topic_id: 34416 reply_id: 140381[/import]

If you are using the Facebook sample code and you get the Facebook error 5, it will crash the app because of a Lua error (shows up as a Pcall error in the console). The reason is the event.response is treated as a json table when it’s actually an error string. Here is a code snippet that fixes the problem:

[code]
else
– Post Failed
statusMessage.textObject.text = “Post failed”

– Added **1/25/2013
if type( event.response ) == “string” then
print( "Error message: " … event.response )
else
printTable( event.response, “Post Failed Response”, 3 )
end
end
[/code] [import]uid: 7559 topic_id: 34416 reply_id: 140382[/import]

@Tom: @haakon is right. The dreaded com.facebook.sdk error 5 occurs if you give the {"publish\_stream"} argument for "me" and "me/friends" requests. Solution:

[lua]if fbCommand == “feed” then
facebook.login(fbID, fbListener, {“publish_stream”})
else
facebook.login(fbID, fbListener)
end[/lua]

[import]uid: 73434 topic_id: 34416 reply_id: 140387[/import]

WAIT. OMG, I made a few changes to my script, went back to daily build 1008, and I can no longer reproduce the error 400. What the… Lemme build it for 991 and I’ll report back with the result.

Edit: OMG, I spoke too soon. I can still get Error: HTTP status code: 400 with build 1008 after all (and it’s probably the same with 991 – just took a while to thoroughly test this with my app.) How to reproduce it has something to do with how I cancel the FB process. I’ve used three different ways to cancel the process:

  1. There’s this “cancel” button on the FB permission/login screen to cancel it.

  2. The second method is just closing the browser window by simply returning to the devices home screen by tapping on the device’s home button (the one with the square icon at the bottom of the device) and relaunching the app.

  3. The third method to cancel the process is by simply closing the FB permission/login screen by tapping on the browser’s double square icon (which shows what web pages are open), x’ing out all browser windows, then pressing the device’s home button, and then relaunching the app.

I’m a bit too tired to methodically check every possible combination of which cancellation method would trigger the error 400. I’ve done some combination of these methods without really paying much attention. All I can say at this point is, maybe this is too much of an edge case to even worry about. If a user really wants to mess with the app, what can the app do about it…?

Other than this, I’d say with all of the error trapping procedures I implemented to my script, the latest Facebook implementation is working fine. Sigh. Sorry about all the noise I’ve made.

Now I’m moving on to implement Facebook score API.

Naomi


Here’s my finding after going through the 3 test cases. I don’t know if it’s relevant or helpful at this point. All I can tell is, there’s definitely changes in how errors are handled with the updated Facebook SDK.

Please note, I have not commented out multiple facebook.logout that I needed to use with the daily build 1008. I don’t know how it would behave with daily build 991 if I remove what appears to be quite unnecessary facebook.logout calls that I needed to add for daily build 1008.

Please also note, I have not tested how it goes with posting on friend’s wall without using facebook.showDialog call. Meaning, I have not tested the following method with the daily build 991:
facebook.login( myAppID, myPostListener, { “publish_actions” } )
facebook.request( feedMyFriend, “POST”, attachment )

As I noted on my post #20 above, POST method causes Error: HTTP status code: 403 when I tried it with daily build 1008. (It might still be the case even with daily build 991, especially if this error is caused by Facebook no longer permitting this method.)

Anyhow, here’s the result:

CASE 1: SUCCESS (works just like the daily build 1008)

CASE 2: SUCESS (works just like the daily build 1008)

CASE 3: STRANGE FAILURE
EDIT: I’m editing this out. I’ve added some error trapping scripts, and it wouldn’t fail like previously described. [import]uid: 67217 topic_id: 34416 reply_id: 140390[/import]

Isn’t 990 the last build with the older Facebook SDK. I thought the problems started with 991. [import]uid: 199310 topic_id: 34416 reply_id: 140425[/import]