friends_get should return List<Long> rather than T (type depending on which client you're using)

[GoogleCodeExporter]

In version 2.0.1, the FacebookRestClient friends_getAsList() method has
been deprecated (with no deprecation comments).

It seems like the face that FacebookRestClient returns a Document XML
object containing...:
<friends_get>
  <uid>222333</uid>
  <uid>1240079</uid>
</friends_get_response>
... is a throwback from the old facebook API and not a particularly usable
solution.

I imagine that most Java API users don't care much whether they're using an
XML or a JSON implementation of the client. Most developers will want to
just get a List<Long>, put it in a for loop and start iterating round it.

Should we consider either changing the method signature in
IFacebookRestClient so that this method returns List<Long> or alternatively
move the friends_getAsList() up to IFacebookRestClient as a fully-fledged
method to be implemented by all clients?

Original issue reported on code.google.com by david.j....@googlemail.com on 25 Sep 2008 at 8:25

[GoogleCodeExporter]

the thing is that for JSON/XML it should only return XML or JSON.  But for Jaxb 
that
does some object construction, it's return type should be more appropriate to 
the
method call..

So I might actually split the jaxb library into it's own api so that the method 
can
have more appropriate return types.  but that won't happen any time very soon..

Original comment by fern...@gmail.com on 30 Sep 2008 at 2:15

[GoogleCodeExporter]

I think that if we declare the type (List<Long>) then we defeat the purpose of 
having
a flexible interface.  Some people will still want to retrieve the response in 
the
format of the client (jaxb vs xml, etc).  I think it's important to keep the 
response
in the format of the chosen client since many people will be using an XML 
utility or
JSON utility or JAXB utility to parse responses.  However with that said, I do 
see
your point, the current approach does add extra complexity to what should be a 
simple
response - a list of ids.

Original comment by hahna...@gmail.com on 8 Oct 2008 at 3:18

[GoogleCodeExporter]

With the JAXB version, you get a FriendsGetRequest object then can call 
getUid() to
get a pre-parsed List<Long>.

That's fair enough, and when I raised this issue, I didn't properly understand 
the
strategy for JAXB vs. JSON vs. XML.

However, I do like the "asList()" method strategy. It means that no matter which
IFacebookRestClient implementation you choose, you can get hold of Java objects 
if
you want to (rather than XML or JSON). I guess it adds complexity to be able to 
pick
and choose like that, but it would be good to have one object that holds the 
state
and deals with communication with the facebook API and another object which 
deals
with the conversion into a suitable type (XML, Java objects)... That way, you 
could
have 2 conversion objects looking at the same Facebook Client object and get 
some
data as XML, some as JSON and some as Java Objects.

Original comment by david.j....@googlemail.com on 8 Oct 2008 at 8:16

[GoogleCodeExporter]

Request that this issue as it stands be closed. (apologies, I don't have 
permission).

Original comment by david.j....@googlemail.com on 8 Oct 2008 at 8:17

[GoogleCodeExporter]

thanx. we'll close this for now, since you do have an option.

I will try to file away the idea of separating concerns a little bit better 
between
initiating requests to facebook, and parsing and dealing with those requests on 
the
way back.. there might be a way to give people easy options.. :)

Original comment by fern...@gmail.com on 8 Oct 2008 at 3:12

• Changed state: Fixed