NullPointer to get status from Facebook

[Kiva]

Hi guys,

I have a problem when I want to get the Facebook status for my user.
I use the good scope => user_status
And in my code, I do this:

List<StatusPost> statuses = facebook.feedOperations().getStatuses(id);

Id is the user id from FacebookProfile.

When this line is executed, I get this exception:

java.lang.NullPointerException
at org.springframework.social.facebook.api.impl.json. PostMixin$LikesCountDeserializer.deserialize(PostM ixin.java:130) [:]
at org.springframework.social.facebook.api.impl.json. PostMixin$LikesCountDeserializer.deserialize(PostM ixin.java:126) [:]
... 67 more

I have gone into this code that I put here:

public Integer deserialize(JsonParser jp, DeserializationContext ctxt) throws IOException, JsonProcessingException {
   JsonNode tree = jp.readValueAsTree();
   return tree.get("count").getIntValue();
}

And when I debug it, the Json tree is something like this:

{"data":[{"id":"1234","name":"toto"},{"id":"12345","name":"titi"}]}

So when the code executes get("cout"), it's normal that the exception comes.

I don't understand where hat I have wrong.

Someone can help me ?

Thanks.

[habuma]

Sometimes Facebook gives back "likes" as a simple count...other times, it gives back a list of references for those people who have liked the post. As it is written now, the deserialization code in Spring Social Facebook is written to work with the counts and will fail when it encounters a reference list. I've filed this as a bug at https://jira.springsource.org/browse/SOCIALFB-33 to more gracefully handle either situation.

[habuma]

There are really two parts to addressing this problem:
- Ensuring that no NullPointerException is thrown when there isn't a "count" field (this is a bug)
- Actually fetching the elements in the "data" field into some property of the Post object (this is an improvement)

SOCIALFB-33 addresses the bug and I've pushed some changes that keep the NPE from happening. SOCIALFB-41 describes the improvement, but I've not addressed that yet.

Addressing SOCIALFB-41 is actually quite simple and I could do it at any time. But I'm hesitant to do it until I get some clear understanding of why the "data" field doesn't always (in fact, often doesn't) include all of the likes data.

For example, https://graph.facebook.com/407963083...50394134258306 will return a post whose "likes" field says that there are 3 people who have liked the post, but where the "data" field only includes 1 of those who have liked it. Why? What makes this more confusing is that https://graph.facebook.com/407963083...34258306/likes will give you the data for all 3 people who have liked the post. If it were a privacy/permissions issue, then I'd expect to get only 1 in both cases. And I doubt it's a paging issue; why do paging for so few entries?

This is either a bug in Facebook's Graph API or there's a specific reason for it. If it's the former, then I would hope that Facebook fixes it. In the latter case, I just want to understand the reason so that I can properly document the API binding.

Until I get clarification on why this happens, I'm not going to implement SOCIALFB-41 because I don't want Spring Social to return inconsistent data unless I can explain the inconsistencies. I've asked about this at http://facebook.stackoverflow.com/qu...the-likes-data and hope to gain some understanding on the issue soon.

[habuma]

Following up on that previous message: When I visit https://graph.facebook.com/407963083...50394134258306 today, I get back the data for all 3 people who have liked the post. Yesterday, I was only getting the entries for 1 of those people. What changed?

If it was a bug, then it's theoretically possible that the bug was fixed. It is Tuesday, after all, and Tuesday is when new code gets pushed out at Facebook. However, I see nothing in the change log that specifically points to this issue, and I still have other examples (from my personal feed) that still exhibit the behavior.

Another theory (proposed by Spring Social community member Morten Andersen-Gott) is that it may have to do with the "eventual consistency" of the persistence stores under the covers at Facebook. Perhaps yesterday I was hitting a node that hadn't been fully replicated yet. This sounds like a reasonable explanation, but as I said, I still have examples where the inconsistency still hasn't been resolved; I'd expect "eventual consistency" to occur within a day.

I simply am looking for a definitive answer on why this happens so that I can properly document the API binding so that users of the binding will know what to expect.

[habuma]

One more followup: I've issued a bug with Facebook for this issue: https://developers.facebook.com/bugs/197991043611104

As that bug says...
- Requesting https://graph.facebook.com/407963083...50394134258306 without an access token gives back Post data showing that 3 people have liked the Post and includes the references for all 3 liking users.
- Requesting the same endpoint with an access token gives back Post data indicating the 3 users have liked the Post, but only including a reference for one of those users.
- Requesting https://graph.facebook.com/407963083...34258306/likes (with or without an access token) gives back the references for all 3 users who have liked the Post.

If this is a permissions issue where 2 of those users have locked down their privacy, then I'd expect them to be hidden in all 3 cases (especially the case where no access token is given). If it's not a permissions problem, then I'd expect to get references for all 3 users in all 3 cases.

[Kiva]

Thanks for your feedback.

Do you know when the version 1.0.1 will be release or if a milestone is expected ?

Edit: Thanks too for your work

[habuma]

Regarding 1.0.1: The primary thing to do is to close a couple of bugs that must be put away before 1.0.1 (I don't want to release with any known bugs). Beyond that, there are a few minor API binding enhancements that I'd like to work in. There won't be a milestone.

I'm shooting to get the bugs closed this week and be 1.0.1 ready by mid-to-late next week. But then that bumps up against the Thanksgiving holiday, so I might hold off on pushing a release until the week after Thanksgiving (again, assuming everything is ready at that time).