Facebook 3.1.1 SDK breaks A LOT

Naomi · February 14, 2013, 12:26pm

@Tom and @cebodine, I’d like to know what Tom means by _ “make it work as before.” _

Does this mean re-working the code _ “to store the facebook request context globally” _ is not necessary? I’ve been re-working my code today, because otherwise, facebook requests are failing after successfully executing a series of requests in one scene (i.e., successfully executing CASE 5 or CASE 7.) If re-working my code is not necessary, I’d rather wait for additional fix before I proceed further. So, is what Tom looking into related to this? Please let me know.

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

Tom · February 14, 2013, 12:54pm

@Naomi,

This means making each call to facebook.login update the listener, whereas in the current implementation (build 1028 and newer), only the first facebook.login sets it. Before build 1028 each login call would update the listener so we introduced a regression bug with our fix. [import]uid: 7559 topic_id: 34416 reply_id: 142799[/import]

Naomi · February 14, 2013, 1:03pm

@Tom, thank you so much for the explanation. It sounds like I don’t need to rework my code then. That’s a relief.

Thanks again,
Naomi
[import]uid: 67217 topic_id: 34416 reply_id: 142802[/import]

cebodine · February 14, 2013, 1:17pm

@Tom,

Just to be clear, the listener called should be the listener that was in effect at the time that the request or dialog was sent. That is the only way that multiple concurrent Facebook requests can be correlated.

Ideally, that would mean adding an additional parameter to facebook.request to specify the listener for that specific request.

Thanks [import]uid: 120928 topic_id: 34416 reply_id: 142803[/import]

Tom · February 14, 2013, 3:15pm

@cebodine, we are looking to fix what we broke with build 1028 changes. At this time we cannot add new parameters or APIs because it won’t be compatible with Android, which we haven’t updated to the latest SDK. We will update the Android SDK after we get some much needed Android issues out of the way. [import]uid: 7559 topic_id: 34416 reply_id: 142809[/import]

Tom · February 14, 2013, 7:45pm

@cebodine, the login listener regression bug is fixed and should be available in the next daily build (1030). [import]uid: 7559 topic_id: 34416 reply_id: 142827[/import]

haakon · February 15, 2013, 5:19am

Hi,

1030 works fine, but broke our own plugin for facebook native share dialog, since you have moved your own code into a plugin (Enterprise).

Error Domain=com.facebook.sdk Code=7 “The operation couldn’t be completed. (com.facebook.sdk error 7.)” UserInfo=0x1ab85fd0 {com.facebook.sdk:NativeDialogReasonKey=NativeDialogInvalidForSession}

Thus we need this piece of code inserted in your plugin asap (we should have submitted to Apple today, but need to wait for you to update):

#import <facebooksdk> #import <facebooksdk> int PluginNativeFacebook::ShowDialogForReal( lua_State *L) { UIViewController *viewController = fRuntime.appViewController; const char *txt = lua_tostring( L, 1 ); const char *img = lua_tostring( L, 2 ); const char *url = lua_tostring( L, 3 ); int listenerIndex = 4; if (NULL == fListener) { if ( CoronaLuaIsListener( L, listenerIndex, kEvent ) ) { CoronaLuaRef listener = CoronaLuaNewRef( L, listenerIndex ); fListener = listener; } } [FBNativeDialogs presentShareDialogModallyFrom:viewController initialText:[NSString stringWithFormat:@"%s", txt] image:[UIImage imageWithContentsOfFile:[NSString stringWithFormat:@"%s", img]] url:[NSURL URLWithString:[NSString stringWithFormat:@"%s", url]] handler:^(FBNativeDialogResult result, NSError *error) { // Only show the error if it is not due to the dialog // not being supporte, i.e. code = 7, otherwise ignore // because our fallback will show the share view controller. if (error && [error code] == 7) { NSLog(@"Not supported"); NSLog(@"%@", error.debugDescription); char status[] = "error"; DispatchEvent(true, status); } else { NSLog(@"Supported, what next?"); NSString *alertText = @""; if (error) { alertText = [NSString stringWithFormat: @"error: domain = %@, code = %d", error.domain, error.code]; } else if (result == FBNativeDialogResultSucceeded) { NSLog(@"Posted successfully"); char status[] = "success"; DispatchEvent(true, status); } else if (result == FBNativeDialogResultCancelled) { NSLog(@"Cancelled"); char status[] = "cancelled"; DispatchEvent(true, status); } else if (result == FBNativeDialogResultError) { NSLog(@"Got an error"); char status[] = "error"; DispatchEvent(true, status); } else if (![alertText isEqualToString:@""]) { NSLog(@"%@", alertText); char status[] = "error"; DispatchEvent(true, status); } else { NSLog(@"Just an error, not sure why"); char status[] = "error"; DispatchEvent(true, status); } } }]; return 0; } int PluginNativeFacebook::ShowDialog(lua_State *L) { NSLog( @"Show Dialog, Native Facebook Plugin, version %s.", version); Self *provider = ToLibrary(L); provider->ShowDialogForReal(L); return 0; } [import]uid: 21746 topic_id: 34416 reply_id: 142869[/import]

walter · February 15, 2013, 10:24am

If the error is generated by the invocation of your code/plugin, then this isn’t an issue with our Facebook implementation.

In other words, if you are calling your own native wrapper for facebook functionality, then our code will not have an impact on your code’s behavior. In fact, none of our code would be executed at all, since you are using your own version instead. [import]uid: 26 topic_id: 34416 reply_id: 142895[/import]

haakon · February 15, 2013, 10:31am

Walter,

you are holding the facebook session in your plugin, which is not accessible from our plugin. It worked perfectly before you moved your facebook code into a plugin.

We can’t force the user to login twice, one time with your plugin and one time with our plugin. So either you must implement the native share dialog in your plugin, or make the facebook session globally available like it was before. Or do you have any other suggestions? [import]uid: 21746 topic_id: 34416 reply_id: 142898[/import]

haakon · February 15, 2013, 11:02am

I’ve tested some more. If I haven’t logged in with Coronas facebook.login, our plugin works. As soon as we log in with facebook.login, the com.facebook.sdk Code=7 error shows up when we try to invoke the native share dialog.

However, with my code example posted, you know as well as I do that implementing the native share dialog is a 10 minute job for you at most, at least in the enterprise static library, now that you have moved the code into a plugin. And it’s even a much voted for feature in your new feature request section…

We’ll submit to Apple with daily 1027 since that works fine for us, but I sure hope you’ll do something about this soon. I mean, it took 7 weeks to solve the com.facebook.sdk Code=5 error, so maybe you can make up for that by implementing the native share dialog today

Yeah! [import]uid: 21746 topic_id: 34416 reply_id: 142901[/import]

haakon · February 15, 2013, 11:34am

There’s still a bug in 1030:

The operation couldn’t be completed. (com.facebook.sdk error 5.)

Steps to reproduce

Login with facebook
Turn off internet connection
Try to do something with Facebook (request me/friends for instance)
Fails with error 5
Turn on internet connection
Try to do something with Facebook (request me/friends for instance)
Result: Facebook is now completely borked, the only way to restore Facebook operations is to exit the app and start anew.

Can the developer responsible for the facebook integration PLEASE put some pride in making a robust facebook implementation and actually TEST it? Unbelievable that we have to go so many rounds. [import]uid: 21746 topic_id: 34416 reply_id: 142912[/import]

Naomi · February 15, 2013, 1:21pm

Here’s a quick update regarding the daily build 1030 as it applies to my project – it’s working perfectly for me! I tested all possible route, and everything is working smoothly. At this point, I don’t expect any aspect of FB in my app to break. Woohooo!! Thanks for the fix!

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

cublah · February 15, 2013, 1:58pm

You could just check for connectivity before you do any Facebook commands, if no connectivity then display message (which you should do anyway) not perfect but would solve it most of the time. [import]uid: 8697 topic_id: 34416 reply_id: 142937[/import]

haakon · February 15, 2013, 2:04pm

@cublah, yes, I know. The problem is that exceptions in the sdk/integration completely breaks all FB functionality, and Corona needs to handle it.

I’ve implemented the workarounds needed, and we’re using daily 1027, so right now everything works as it should for us. We’re stuck at 1027, though, until Coronalabs fixes the native share dialog. The network bug is fixed like you suggested and can stay like that. [import]uid: 21746 topic_id: 34416 reply_id: 142938[/import]

walter · February 15, 2013, 2:20pm

@haakon, all calls to FBSession on the Corona side are silo’d in the plugin. So as long as you don’t require our facebook library, you won’t call into the plugin, thereby avoiding any conflict.

And from what you say, it looks like you are using our plugin alongside yours, so that explains your issues. [import]uid: 26 topic_id: 34416 reply_id: 142939[/import]

haakon · February 15, 2013, 2:38pm

@walter,

the error I found is not related to mixing 2 plugins. Mixing the plugins only affects the native share dialog.

I guess the only way we’ll get facebook integration WITH native share dialogs is to roll our own Facebook plugin from scratch? I was kind of hoping not having to do that, since you have already integrated with Facebook. Our plugin has just got the native share dialog implemented, not anything related to login, sessions or posting stuff to facebook… [import]uid: 21746 topic_id: 34416 reply_id: 142943[/import]

haakon · February 16, 2013, 1:53pm

Fixed. Rewrote the plugin to use iOS functionality instead of Facebook functionality:

SLComposeViewController\*fvc = [SLComposeViewController composeViewControllerForServiceType:SLServiceTypeFacebook];  
  
...

With that we were able to switch to daily 1030 and continue presenting the users with native share dialogs. [import]uid: 21746 topic_id: 34416 reply_id: 143042[/import]

cebodine · February 14, 2013, 12:53am

Hi Tom,

We are still experiencing problems with build 1028. In the call to facebook.login, we have been wrapping the listener parameter with a lua enclosure to provide context information to the listener:

 facebook.login( game.facebookAppId,  
 function(event)  
 listener(request, event)  
 end,  
 request.permissions  
 )

The request table includes all of the required data to send to facebook (path, method, attachment), and what action(s) to take upon receipt. This avoids having to define global variables and facilitated concurrent processing of multiple facebook requests.

With the latest build, we can confirm that the enclosure passed to the FIRST login call is now used for all subsequent listener invocations. To some extent, we might be able to work around this, but it will require blocking all user activity until each request is completed. This used to work quite well.

What we really need is the ability to pass a different listener for each facebook.request in the same manner as network.request. The current implementation requires the listener to depend upon global (or at least module level) variables to determine context. [import]uid: 120928 topic_id: 34416 reply_id: 142689[/import]

Tom · February 14, 2013, 2:53am

@cebodine, can you provide some code around the snippet you posted so we can see the context in which it’s used? If you prefer, you can email me directly something that I can test against to better understand the issue. tom at coronalabs dot com.

Have you seen any other issues in your test of 1028?

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

Naomi · February 14, 2013, 4:43am

A quick update to let you all know that Daily Build 1028 fixed the issue for me. The final issue that I had with the 1028 was something to do with a device that previously had FB error. I didin’t clean slate the device, and the newly built app got tripped by the lingering issue. Once I wiped the device and then installed the same app, the error went away.

Tom, thank you so much for fixing this!!!

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