loginWithFacebookSDK results in fault code "Server.Processing"

General
1

Logging in Android with:

loginWithFacebookSdk(activity, facebookFieldMapping, facebookPermissions, callbackManager, AsyncCallback<BackendlessUser>)

results in fault code: “Server.Processing” with fault message: “java.lang.NullPointerException”.(Not sure where the NullPointerException is coming from, as I provided the following field mappings and permissions:

Map<String, String> facebookFieldsMappings = new HashMap<>();
facebookFieldsMappings.put("email", "email");
facebookFieldsMappings.put("name", "name");
facebookFieldsMappings.put("gender", "gender");
facebookFieldsMappings.put("avatarFileUrl", "picture");



List<String> permissions = new ArrayList<>();
permissions.add("email");
permissions.add("public_profile");

When I switch to using:

loginWithFacebookSdk(activity, callbackManager, AsyncCallback<BackendlessUser>)

I then get the fault code: “3033” with fault message: “Unable to register user. User already exists.” Which leads to me to wonder: can’t the Backendless service log in a user who is already registered with a regular email (which matches the email from Facebook) and password, but who now decides to log in with their Facebook account? Shouldn’t Backendless just merge the users rather than throw a a user exists error?

Hoping for a response.

Thanks,

Ugo M.

2

Hi Ugo,

Just to make sure - are you using the latest SDK distribution? Did you download it from github?

Regards,
Mark

3

Hi Mark,

Yes, I’m using the the SDK distro from github.

Ugo

4

So, I deleted the existing user registered with email (that matches the Facebook provided email) and password in the Backendless Developer console, and then attempted a Facebook login using:

loginWithFacebookSdk(activity, callbackManager, AsyncCallback<BackendlessUser>)

But this time the result is another Backendless fault with code: “3012” and message: “Unable to register user. Property ‘name’ is required”.

This is just tiring at this point :-/

5

Hi, Ugo.

There are some issues with method loginWithFacebookSdk(activity, facebookFieldMapping, facebookPermissions, callbackManager, AsyncCallback<BackendlessUser>) that we are fixing right now, but could not reproduce your case with loginWithFacebookSdk(activity, callbackManager, AsyncCallback<BackendlessUser>) method. Just to make clear - did you build your backendless.jar from https://github.com/Backendless/Android-SDK project ? (execute gradle tasks “jar” and “copyJarToOut” in Android Studio).
Also, I noticed that in line facebookFieldsMappings.put(“avatarFileUrl”, “picture”); you’ve misplaced “picture” and “avatarFileUrl” - the facebook field (“picture”) should go first and your name for that field (“avatarFileUrl”) should go second.

We’ll let you know, when the issue is fixed. Thanks for reporting.

6

Did you fix Ugo? I tried to put on map “name”, for value “first_name”, but error remain

7

Hi, Diego!

The issue is fixed and will be released shortly. We’ll notify you on the release.

8

I write some code an noticed the issue.

I tried to remove “request” from user properties console, even if I need that value. After mapping correct values before loginWithFb, login worked. Now I cannot fetch email, and I included right permission :).

9

Hi Ugo,

I think the problem is about the requested field to facebook. You are asking for the “name” field, which is no longer available, and returns null, making your user ‘name’ property be null, and I guess this is a mandatory field in your backend.
Maybe you can ask for the ‘first_name’ and/or the ‘last_name’ from Facebook:

facebookFieldsMapping.put(“first_name”, “name”);

Cheers!

10

name is no longer available? Where did you read that?
And assuming it is true, how can I put insied “name” field of backendlessUser both name and surname of facebook?

11

The fix for this issue is already released. Please let us know if you encounter any difficulties with it.

12

When I noticed that issue I used versione 3.0.8.1.
When I read your comment I check on maven centrale bit versione is the same 3.0.8.1

13

Diego, the fix was on the server-side. Could you try it with the same version of the client library you already have?

Mark