Yeah, the library has its downs, but a lot of the intermittent errors you see - timeouts, blank results, etc. - are really from Facebook's side. I've had a rash of these and found a bunch of others having the same issues, e.g. at http://forum.developers.facebook.com/viewtopic.php?id=51557. The latest Facebook problem is with emails (only seeing proxy emails). All this flakiness keeps me constantly worried about what's going to break next on Facebook. Do you guys have similar problems?
On Feb 16, 3:25 pm, Jeff Schnitzer <[email protected]> wrote: > 1) No support for fql.multiquery. This is the single most important > API method that facebook provides. After a bit of practice, you stop > using any other API method for fetch queries. > > 2) A ton of complexity because they tried to give you the ability to > use both JSON and XML modes. This was dumb, they should have just > picked one or the other. Developers just want a Java API, the > protocol is just plumbing. > > 3) After you use the FB API for a while you will find various > cross-cutting types of return values that can (and must, if you want > your app to work) be retried. As an example, a few weeks ago FB > started producing "Incorrect signature" errors that work after a > retry. For 1-5% of all calls. It still hasn't been fixed. This > stuff pops up all the time - I constantly watch my error log and tweak > the FB calls based on what part of Facebook is on fire at the moment. > > 4) The FB API really doesn't lend itself to JAXB processing. It > doesn't have a rigid schema, you'll find all sorts of odd and annoying > things like JSON calls returning "{}" for an empty array and the fact > that error codes are returned in an entirely different schema. With > any luck, the facebook-java-api folks have coded around most of this > junk - but given the heavy reliance on machine-generated code, I > really doubt they got it all. I suggest sticking with the XML version > and even then watch out for edge cases like empty result sets. > > 5) When I last looked at the code (I wanted to add a hook for > multiquery), it was a mess. That was before there were official > releases of 3.0, so maybe it's improved now. > > Jeff > > > > On Mon, Feb 15, 2010 at 6:42 PM, Sekhar <[email protected]> wrote: > > I'm using facebook-java-api for an app that's about to go into > > production for Android and GWT. I thought the API was simple/clean, > > very easy to use tokens (for Android logins) and session, and has some > > useful extras like verifying session signature. Also, you can get the > > source (I've in fact addded an API call that's missing). > > > @Jeff, why do you think it's horrid? Just wondering if there's > > something I need to know before putting this in production. > > > On Feb 12, 11:36 am, Jeff Schnitzer <[email protected]> wrote: > >> On the server side, throw facebook-java-api in the trash. It's > >> horrid. The Facebook API, while kludgy as hell, is actually pretty > >> straightforward. Just make HTTP requests and parse the results with > >> your favorite JSON or XML parser (I use Jackson). > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
