Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Facebook 3.1.1 SDK breaks A LOT
Started by haakon Dec 29 2012 08:39 PM

- - - - -
133 replies to this topic
[TOPIC CONTROLS]
Page 2 of 6 1 2 3 4 »
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#26

dimd

[GLOBAL: userInfoPane.html]
dimd
  • Contributor

  • 100 posts
  • Corona SDK

Damned! So much time wasted today.
Thanks to all to share your experiences, it's less time than it could have been.

I do too have the "The operation couldn’t be completed. (com.facebook.sdk error 5.)", even though my code used to seem perfectly fine before. I find extremely surprising that Ansca is not on top of this issue (there are more and more tutorials on the corona website which are just not working).

Anyway, if i understand properly, facebook.request to POST an image on a facebook wall doesn't work anymore.

facebook.showDialog should be used, but it seems it can't upload a picture from the device (actually i could not even get it to post a picture from a website).

So, basically, is there still an option to post a picture (like a display.save) to the user's wall or no?

Dim
uid: 100310 topic_id: 34416 reply_id: 140113


[TOPIC: post.html]
#27

cebodine

[GLOBAL: userInfoPane.html]
cebodine
  • Observer

  • 12 posts
  • Corona SDK

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?!?!?
uid: 120928 topic_id: 34416 reply_id: 140265


[TOPIC: post.html]
#28

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

We are looking at the issue now.
uid: 7559 topic_id: 34416 reply_id: 140270


[TOPIC: post.html]
#29

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

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
uid: 67217 topic_id: 34416 reply_id: 140279


[TOPIC: post.html]
#30

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

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
uid: 7559 topic_id: 34416 reply_id: 140282


[TOPIC: post.html]
#31

dimd

[GLOBAL: userInfoPane.html]
dimd
  • Contributor

  • 100 posts
  • Corona SDK

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 ;-)

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
uid: 100310 topic_id: 34416 reply_id: 140286


[TOPIC: post.html]
#32

cebodine

[GLOBAL: userInfoPane.html]
cebodine
  • Observer

  • 12 posts
  • Corona SDK

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
uid: 120928 topic_id: 34416 reply_id: 140362


[TOPIC: post.html]
#33

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

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

-Tom
uid: 7559 topic_id: 34416 reply_id: 140365


[TOPIC: post.html]
#34

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

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.)
uid: 67217 topic_id: 34416 reply_id: 140299


[TOPIC: post.html]
#35

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

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

Naomi
uid: 67217 topic_id: 34416 reply_id: 140367


[TOPIC: post.html]
#36

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

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
uid: 7559 topic_id: 34416 reply_id: 140369


[TOPIC: post.html]
#37

haakon

[GLOBAL: userInfoPane.html]
haakon
  • Contributor

  • 188 posts
  • Enterprise

Tom, read the whole thread; Works in 990, breaks in 991. :)
uid: 21746 topic_id: 34416 reply_id: 140370


[TOPIC: post.html]
#38

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

I was asking about Naomi's thread. I didn't see any build numbers mention.
uid: 7559 topic_id: 34416 reply_id: 140373


[TOPIC: post.html]
#39

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

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.
uid: 67217 topic_id: 34416 reply_id: 140377


[TOPIC: post.html]
#40

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

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
uid: 7559 topic_id: 34416 reply_id: 140381


[TOPIC: post.html]
#41

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

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:

        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
uid: 7559 topic_id: 34416 reply_id: 140382


[TOPIC: post.html]
#42

olavm

[GLOBAL: userInfoPane.html]
olavm
  • Contributor

  • 138 posts
  • Corona SDK

@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:

if fbCommand == "feed" then
  facebook.login(fbID, fbListener, {"publish_stream"})
else
  facebook.login(fbID, fbListener)
end


uid: 73434 topic_id: 34416 reply_id: 140387


[TOPIC: post.html]
#43

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

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.
uid: 67217 topic_id: 34416 reply_id: 140390


[TOPIC: post.html]
#44

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 26,062 posts
  • Enterprise

Isn't 990 the last build with the older Facebook SDK. I thought the problems started with 991.
uid: 199310 topic_id: 34416 reply_id: 140425


[TOPIC: post.html]
#45

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

I hate to add more to this saga, but I can't help myself. I had to test what would happen if I didn't call facebook.logout() after calling facebook.login( myAppID, myFBListener, { "email" } ) to fetch the user login credential -- on both build 991 and 1008.

The result was identical. It surprised me. I thought the issue was introduced when FB SDK was updated, but it looks like that was not the root cause of the issue.

-------------------------------------------
Edit: I was testing on wrong build. I needed to test on 990 and 1008 to see the difference. And the result was not identical. It was different like night and day. The case 4 result detailed below is with 1008 which incorporated updated FB SDK. My post #46 shows the case 4 result with 990 that uses un-updated FB SDK.
-------------------------------------------

I followed the CASE 2 procedure -- meaning, I did not intentionally cancel the login process because I really wanted the FB login process to work:

CASE 4: (modified version of CASE 2 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
* Do not call facebook.logout() here -- I commented it out from the script
* 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
* Then the screen goes back to my app, while I also get Error: HTTP status code: 400
* My app screen says Facebook login failed.
* User closes the login fail notice.

5 (scene B): facebook.login( myAppID, myFBListener )
* The screen updates to show FB Friends button.
* Tapping on it launches facebook.login( myAppID, myFBListener )
* Which brings up FB permission screen again (stating that the user has already authorized this app)
* Tapping okay triggers Error: HTTP status code: 400 again.
* My app screen says Facebook login failed.
* User closes the login fail notice.
* And this step 5 repeats itself over and over.
* All the other parts of the app appears to behave and function as expected. I just can't go anywhere beyond this step 5 with FB feature of the app.
* So I killed the app and relaunched it.

6 (scene B) -- tapping on FB Friends button brings up friends list (the buttons) without asking for FB permission, and it works smoothly without a hitch.

So it appears, adding the facebook.logout() was absolutely necessary to avoid the error 400. I think it was haakon who identified and posted the need to add facebook.logout() in some other thread somewhere -- thank you (and if it was someone else, whoever it was, thank you.) It was frustrating process, but this really got me trapping all sorts of potential errors that could crash my app.

Also, you wouldn't encounter this issue if you don't need the login to require email as part of the parameter (and if so, you may not need to call facebook.logout). In my app, under this specific path user takes, it is necessary.

Anyhow, I hope this test result helps others who come across the same error.

Naomi
uid: 67217 topic_id: 34416 reply_id: 140422


[TOPIC: post.html]
#46

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

OMG, Rob, thanks for pointing that out. How terrible. I totally misread the earlier post. Should not have downloaded the 991 at all. Urrrrrrgh. This is turning into a nightmare. I'll download 990. I guess I have to go through this whole bloody test process again (if I am to follow through with this pain-in-the-neck test procedure.)

Edit: OMG, pardon my language above. I was so exasperated that I couldn't help myself.

Lo and behold. 990 DID NOT THROW ANY ERRORS! And it worked soooo smoothly that I can cry.

So, it was the Facebook SDK upgrade that caused this issue after all. And with the 990, I don't need to call facebook.logout at all. I hope Corona Labs can implement the fix.

Anyhow, please see my test case below.

Naomi

CASE 4: (app built with 990, test process is the modified version of CASE 2 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
* Do not call facebook.logout() here -- I commented it out from the script
* 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 )
* Behind the scene, it calls facebook.login( myAppID, myFBListener ), 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.
* Do not call facebook.logout() here -- I commented it out from the script

6) (scene B): facebook.login( myAppID, myPostListener, { "publish_actions" } )
* Each FB friend that was fetched in step 5 becomes a friend button
* If the friend is not already registered with the app, tapping on the friend's button 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 WORKS EXTREMELY WELL.

THE USER HAD TO AUTHORIZE THE APP ONLY ONCE! PERFECT.

P.S. Just to be clear, as far as the user is concerned, all he/she sees is the initial FB login screen. Once the user logs in, the next thing he/she sees is the app screen with rows of friends' names. If a friend is already registered with the app, tapping on the friend initiates a match game for this app. If a friend is not already registered, tapping on the friend brings up the FB dialog (without pausing to ask for the user's FB permission.) Works really like a charm when built with 990.
uid: 67217 topic_id: 34416 reply_id: 140430


[TOPIC: post.html]
#47

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

Naomi,

Thank you for all your testing and confirmation. I also verified that the error doesn't occur in build 990 but does happen in build 1013 so it's related to the new Facebook SDK or Corona's integration.

From my testing and reading, it looks like Facebook made some changes in the Login process. I determined that the error is coming from the permissions used in the Login. I can trigger the error every time by logging in and getting User info or posting a message. If I then log out and log back in, the error will happen on the first or second Facebook access. If I remove the permissions from the Logon, I never see the error. Changing to a different permission doesn't change anything.

Logging out and back in, is the key to when I saw the error happen. Internally the permissions are only sent to Facebook when you call Login AND the session is not active (e.g., logged out).

It seems that Facebook wants you to set permissions the first time you log in a user and not for every log in after that. You would need to add back permissions if the user cancelled your App's access or needed to add additional permissions. (You must log out and log back in to set new/additional permissions.)

Under the hood there is no need to call the FB Login API for every command, except when your app is started or you determined that the user has logged out. You must call the Login API when the app first starts because that's what initializes the FB Connect module. Calling the Login API (without permissions) does no harm because it only does an actual FB login if it finds the session isn't active (e.g., the user is not logged in).

Can you try implementing the above sequence (not adding any permissions to the Login, except for the first time) to see if that works for you with the latest Corona build?

I'm still looking at this, but I'm not sure there is anything we can fix internally. This may be a change in the way Facebook wants to handle Login, so changing how we call the interface may be all that's needed to keep the error from happening.

One other note about Facebook errors. The Corona sample code will have a Lua runtime error if FB returns an error. That's because it's treating the event.response as a json table when it's really an error string. I posted the fix in comment #41.

I should note that we are using the latest Facebook SDK without modification. We add code to interface Corona to their SDK but we can't troubleshoot or debug issues that may be in their code. For most third party libraries that are used in Corona, if we find bugs we try to report them but need to wait for the author to fix them. I don't know if that's the case with Facebook, but I'm sure there are bound to be bugs/errors (as found in all code).

Thanks,
Tom
uid: 7559 topic_id: 34416 reply_id: 140440


[TOPIC: post.html]
#48

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

Hi Tom, thank you for the detailed note. I appreciate you taking the time to explain. From what you noted, it sounds like I should further edit my code to achieve the behavior I want. I'll give it a shot and see if I can make my app built with 1008 to flow the same way as it does with 990. I will report back once I have a chance to work on it.

Thanks again!

Naomi

Edit: BTW, I will download 1013 just to make sure I'm working with the same build.
uid: 67217 topic_id: 34416 reply_id: 140545


[TOPIC: post.html]
#49

olavm

[GLOBAL: userInfoPane.html]
olavm
  • Contributor

  • 138 posts
  • Corona SDK

I am seeing memory leaks every time the Sample Code makes a Facebook Request. The ones below and some other similar ones. Should I post a bug report? Will Apple reject apps because of this leak?

FBRequest (64 Bytes) UIKit forwardTouchMethod
__NSCFString (64 Bytes) Foundation -[NSString initWithUTF8String:]
uid: 73434 topic_id: 34416 reply_id: 140568


[TOPIC: post.html]
#50

Naomi

[GLOBAL: userInfoPane.html]
Naomi
  • Corona Geek

  • 2,303 posts
  • Corona SDK

Hey, haakon, if you are annoyed by me making giant posts under this thread, please let me know, and I'll move it to a new thread. (I think it's related, and so I think it's okay, but I never know how others feel & think, and I have no intention of offending you.)

@Tom, I was thinking of completely redoing my FB related code so that there's only a single instance of facebook.login call after the app is launched. If I implement it that way, my app wouldn't make facebook.login call twice. It will make the facebook.login call only if the app is killed and restarted (or when the user taps on the FB connect button the first time.) But from what you posted on #47, I'm not sure if it would make any difference. With both CASE 5 and CASE 6, I make facebook.login call with permission only once (at the time of signing in and authorizing the app.) All other facebook.login calls do not include permission (because every possible permissions required for the app is now included in the very first facebook.login call.) The app also never logs out of FB in both CASE 5 and CASE 6. So my finding is different from what you found to be the issue. So I'm wondering if it's worth the trouble removing second and subsequent facebook.login calls.

Besides, how would the app know if/when user deauthorizes the app from his/her FB account or logs out of FB when these things are done outside the app. If I'm not calling facebook.login, but just facebook.request, I'm assuming that the event.type would only return "request" and not "session"... Does facebook.request return event.phase with "loginFailed" or "loginCancelled" too? If it does, I could work with this and see if single login call would solve all my woes.

Naomi
uid: 67217 topic_id: 34416 reply_id: 140776



[topic_controls]
Page 2 of 6 1 2 3 4 »
 
[/topic_controls]