Facebook.Client 0.9.91-alpha is a step backwards for logging in to FB

Question

I have been using the 0.8.5-alpha version of the Facebook.Client SDK and wanted to move upto the latest 0.9.91-alpha since the API indicates it supports ability to login via the app but fallback to login with browser.

Session.ActiveSession.LoginWithBehavior("email,public_profile,user_friends", FacebookLoginBehavior.LoginBehaviorAppwithMobileInternetFallback);

However this does not work and is in fact not implemented at all.

To make things worse the 0.9.91-alpha version has changed the way the login works for LoginBehaviorWebViewOnly method.

In 0.8.5-alpha there was a simple async API

Task<FacebookSession> LoginAsync(string permissions)

that would open a browser popup to manage the broswer based authentication before returning you to you app.

In the 0.9.91-alpha this API has gone to be replaced with a new API

void LoginWithBehavior(string permissions, FacebookLoginBehavior behavior)

This API does not make use of async and forces us of a callback handler to be used

Session.OnFacebookAuthenticationFinished += OnFacebookAuthenticationFinished;

(And no you can't make it async with TaskCompletionSource - see next paragraph)

This still opens a webview as before except when the login finishes there is a uri protocol navigation event (from the FB login page) attempting to launch any app that has registered the protocol

fb446785792148002://authorize/#state={"0is_active_session":1

This is not handled by the Facebook.Client so causes you app to close and re-open again.

This is a very poor implementation as your app is already open. The redirect should be consumed without causing your app to close and re-open.

Practically this makes very hard to use since it is forcing apps to go through startup twice. If apps implement things like extended splash screen this approach does not work.

The Facebook.Client should update its

void DialogWebBrowserOnNavigating(object sender, NavigatingEventArgs navigatingEventArgs)

to handle the end of the login flow and return to the app without forcing a close/re-open

Answer 1

FacebookLoginBehavior.LoginBehaviorAppwithMobileInternetFallback is indeed not implemented and will be taken out. There is no way to detect the presence of app on WP8.0. This might be doable in WP8.1, and we can try and implement it there.

The async/await mechanism for the login has been taken out because the Login APIs were getting fragmented. One API for LoginWithApp - which cannot be async/await because login is done out of process, another for LoginAsync, which did a Webview based login - in process. We had to accommodate two more ways of login - WebAuthBroker on Windows - which could be awaited and Browser based login - which could not be. Each of these methods has their own idiosyncrasies and having different login mechanisms for each would create even more fragmentation. Thus, the need to have the single callback handler. This is how it is done on iOS/Android as well. So, the C# version is in line with what Facebook considers the standard practice.

About the Webview based login now invoking the fb redirect, the reason for that is that your Webview based login now acquires an SSO token which can be silently extended. If we replace it with the version you are suggesting, that will only grant you a 60 day token that cannot be extended. In light of that, the decision to go with the fb redirect was taken.

About the UriMapper being invoked twice. That seems to be a platform issue. There is nothing specific we do. The issue is documented here without resolution.