During the development of Reader for Facebook I ran into all kinds of issues with the Facebook API. I started with the goal of building a relatively simple application that would allow users to login to Facebook, retrieve their newsfeed, and have it read back to them using a Text to Speech engine.
At the time I started the app AVSpeeachSynthesizer wasn’t available within the iOS SDK so I ran into the wall trying to get Flite and OpenEars to work. It didn’t help that I was trying to do so in MonoTouch (it wasn’t yet Xamarin). I eventually got it working only to swap it all out when the new iOS APIs were released to do so natively. Little did I know the pain was just starting.
As I developed Reader, I worked my way through the Facebook API and identified that the combination of a Graph API call to me/home and the API’s for posting comments and likes would be all I’d need. With the API documentation in hand I set on my way to build the core Reader Facebook interactions.
Along the way I ran into lots of unexpected twists and turns that resulted in me spending way more time then I wanted combing through Stack Overflow posts trying to make sense of the Facebook API and the results I was seeing (which often didn’t line up with my expectations).
Low Res Images
For some reason the Facebook API often returns really low resolution images for photo posts. The resolution is so low that showing anything more then a tiny thumbnail isn’t possible. In order to work around the low resolution images returned from the main me/home graph API call, I’m making a second batch request for all the “photo” posts to retrieve all the available images and choosing an appropriate sized image for display. Unfortunately, for a subset of photo posts the graph API request to retrieve the images fails without any meaningful error message. My best guess is that there is some sort of permission on these posts that prevent the list of images available to be retrieved through the API. Regardless, the result is an occasional low resolution photo being displayed in Reader.
Newsfeed Filters Don’t Work
Somewhat recently I wanted to allow users of Reader to choose what filter to use when retrieving posts from Facebook. Although the default “newsfeed” filter is likely to be the most popular, it would be nice to allow folks to filter who they hear in Reader for Facebook by selecting from available filters (Friend Lists, Apps, etc.). Unfortunately, the Facebook API in many cases doesn’t pay any attention to the filter being passed in the me/home?filter=XXXX graph API request.
Random API Errors with Unexpected Side Effects
On the day Reader for Facebook was approved my wife rushed to the app store to download a “real” copy (she had a beta build on her phone). An hour or two later she called asking for a refund. It turns out that she was posting comments through the app that were returning errors, so she tried several times each time getting the same error. Despite the error, her comment was posted to Facebook multiple times. For some reason the Facebook API will return an error for certain calls but the action requested via the request will go through which makes it difficult for an app developer to appropriately handle. An API call that returns an error shouldn’t have any side effects.
Newsfeed is different via the API
In addition to the above “errors” API developers also have to deal with the fact that the results from the Facebook API don’t match up with what users see on Facebook. In Reader, I’m requesting the users home newsfeed, however, the items returned often times don’t match up with what is available in the newsfeed from within the Facebook app (or website). I’m still not sure what causes this, but it definitely leads to unexpected inconsistencies that users notice.
That’s a small sample of the Facebook API issues I ran into while developing Reader for Facebook. Based on my experiences I’m not sure I’d build anything substantial via the Facebook API. The API is too inconsistent and unreliable. I still believe leveraging the Facebook SDK and API to create social “hooks” for your app is worth considering but for more substantial integrations the pain isn’t worth the “payoff”.