I’ve been maintaining RFacebook for the last 9 months or so, and recently I haven’t had the time to maintain it. Unfortunately, I don’t have any current projects that actually use the Facebook platform on a daily basis, so I have had to rely primarily on patches from the community (thank you!) and bug reports from other developers.

When I wrote the initial library, I was fairly new to Ruby and proper language idioms. Needless to say, this has led to some not-so-great designs that are difficult to fix while maintaining backward-compatibility. In particular, the direct access to the API via method_missing has turned out to be problematic for some people. Also, the so-called facepricot chaining (which gives quick access to XML parsing) is particularly poorly designed and I would like to get rid of it if possible.

Ideally, RFacebook 1.0 would do away with the cruft and simplify some of the design. As I considered certain aspects to redesign, I definitely re-evaluated Facebooker, a very solid looking Gem and plugin from Chad Fowler and some other experienced Ruby guys. Much of the improvements I would like to make to RFacebook are already present in Facebooker - API objects converted to Ruby objects, API methods are Ruby-ified, solid documentation, simplified Rails support, etc. Since RFacebook 1.0 would break a lot of applications (with the removal of facepricot and others), I am considering deferring to Facebooker for future Rails Facebook development. I am a big fan of not reinventing the wheel, and I feel that the Facebooker team has already achieved the improvements that RFacebook needs.

Through the process of writing and maintaining RFacebook, I’ve definitely learned quite a bit about Ruby, Rails, behavior-driven development, and the community around it all. Your comments, feedback, and encouragement helped make it a valuable experience. However, at this time I would really like to take on some new projects.

Regardless, I definitely do not want to leave existing RFacebook developers hanging. If you want to take over the RFacebook project, please let me know via the comments. I have also contacted the Facebooker developers to see if they are interested in a compatibility module (which I would write) for Facebooker to ease the transition from RFacebook to Facebooker. Please let me know your thoughts.

Hey everyone, RFacebook 0.9.8 is released. The core API has been cleaned up a bit (although Facepricot is still in there, I plan on deprecating it in version 1.0 in favor of something much less hackish). The biggest change is that the plugin is now COMPLETELY separate from the Gem. This means that you’ll need to reinstall your plugin this time around:

The good part is that the Gem is easier to update on a less-frequent basis, while the plugin can get some serious work/reworking without requiring a Gem release each time. Also, everything should be Rails 2.0 compatible now. Let me know if you still experience any issues with Rails 2.0.

It has been a while since I’ve updated RFacebook, and I finally have the time to do so. Again, I’m always looking for dedicated help, since my time is limited as it is. The project has gotten quite involved, and recent API changes + the Rails 2.0 release has complicated it somewhat.

In spite of the backlog of bugs and feature requests, you should see some improvements over the next few weeks. I plan on slimming down the code as much as possible, as well as removing some poorly designed portions of the library. I’ll have a few interim updates (0.98 and 0.99), but RFacebook 1.0 will have a much more solid core, with the Rails extensions pulled exclusively into a plugin.

Please let me know your biggest complaints with RFacebook (features, bugs, and code design) so that I can address them all fully. Good luck Facebooking!

Unit Tests Come to RFacebook

Finally, RFacebook on Rails has a unit testing suite. You can now run Rails testing like any other well-behaved Rails plugin. My apologies - this was a long time coming.

RFacebook Looking for Developers

The RFacebook project has been maintained mostly by myself, in addition to the very helpful patches of a few others (Evan Weaver and Scott Nedderman, to name just a few). In the coming months I will be quite busy, and I am looking for other developers that can help maintain the project.

To help ease new developers into the library, I’ve done a few things starting with version 0.9.2 of the gem:

• Cleaned up the core - the API library is now cleaned up of cruft and is much easier to understand
• Better documentation - the core API library is extensively documented, and the plugin extensions are getting better documentation as well.
• Unit testing is well-separated - it is fairly simple to see where to place unit tests for any one component of RFacebook. Unit tests are organized into separate tests for Rails controller, model, sessions, plugin initialization, and core API calls.

Hopefully there are some great Rails developers that would like to contribute to what I think has become a pretty solid library, thanks to the already sizeable contributions of its users. With continuous vetting by tons of small developers, and a few large ones (like Causes), RFacebook should continue to provide a great, simple way to get into the Facebook Platform.

The newest RFacebook gem is released. This release should fix some more session issues, as well as give you better backtraces inside Facebook (when using the Facebook Debug Panel).

Short list of changes:

• added basic backtrace rendering to Facebook Debug Panel
• added “raw_xml” method to the Facepricot responses
• parsing of facebook.yml is more helpful when you specify absolute URLs instead of relative paths
• improved usage of fb_sig_session_key to create Rails sessions
• miscellaneous corner case fixes to url_for and redirect_to

Hope this helps people out. Initial feedback sounds like it is a pretty solid release.

The latest gem (0.8.8) adds support for mock ajax and Rails sessions when you are inside the Facebook Canvas. Detailed summary below

• Rails session[] and flash[] work (only ActiveRecord and PStore session containers, memcached store in a future release)
• Added in_mock_ajax? to all controllers, so that you know when you are handling a mock ajax operation
• Added support for a new url_for parameter, :mock_ajax => true, so that you can override the http://app.facebook.com rewriting (since mock ajax URLs have to be absolute)
• Fixed a bug where ampersands were being converted to &amp entities in URLs received from the API. Now, you can use fbsession.notifications_sendRequest(…).response, and the entities will automatically be gsub’ed with real ampersands

Thanks to everyone who filed bugs and contributed patches for this release! It’s looking pretty solid.

Another update - wow these are coming fast now. This weekend I finished up another fairly major upgrade to RFacebook: a true Rails plugin. Features include:

• fbsession and fbparams in both controllers and views
• automatic URL rewriting when you are in the Canvas (all URLs made relative to apps.facebook.com)
• acts_as_facebook_user
• a unique debug panel to help with common issues
• configuration via facebook.yml file
• easy SSH tunneling so that you can develop from your local machine
• no need to keep the plugin up to date - it stays up to date with the Gem

You can get all the information and documentation here: rfacebook.rubyforge.org.

Hope you enjoy the new features.

It’s been awhile since my last blog post, but things haven’t exactly been quiet on the Facebook API front. There are tons of apps going up on Facebook every day, and its been pretty exciting. Hopefully RFacebook has been helping you all get your ideas out there.

There’s now an official home page for RFacebook:

http://rfacebook.rubyforge.org/

This will hopefully have the latest docs and information about the Gem. There has also been some updates to the API syntax:

“Facepricot” Responses

Every RFacebook API call returns a Facepricot document. This is a wrapper for an Hpricot XML document. Note that ALL of the standard Hpricot methods still apply (you can even grab the original Hpricot document via xml.hpricot and use the Hpricot stuff directly). However, a Facepricot document gives you some neat methods that simplify your code. Now, you don’t have to type this:

sess.friends_get.search("//uid").map{|xmlnode| xmlnode.inner_html} // get an array of all friend UIDs
sess.friends_get.at("//uid").inner_html // get the first UID of friends

Instead, you can type this:

sess.friends_get.uid_list // get an array of all friend UIDs
sess.friends_get.uid // get the first UID of friends

Much cleaner. Hopefully that helps out.

Easier Logging

Another highly requested feature: logging. Now you can do:

sess.logger = MyLogger.new

or, if you use Rails

sess.logger = RAILS_DEFAULT_LOGGER

FacebookSession uses the “debug” log method on that logger to provide some useful behind-the-scenes information.

Caching

Yep, caching is built in now. If you make a call like cached_friends_get, the FacebookSession will automatically cache the response.

I suppose this will be my first “official” developer blog entry, so bear with me if it seems a little sparse. This summer I’ve been doing a ton of work with object oriented Javascript and AJAX, and up until today the AJAX part has been mostly simplified by Atlas webservice proxies. However, today I hit one of those problems that just hasn’t been very well documented by anybody else, so I thought I’d write something about it.

Basically, our application keeps a form of session state server-side, and it needs to be notified when the browser window is closed or refreshed. Clearly, the thing to do here is to hook into the window.onUnload event (side note for new Atlas developers: don’t use window.onUnload, use Sys.Application.unload.add([yourUnloadHandler]) instead).

So at first I just went happily along, sending the usual XmlHttpRequest when the page unloaded. However, this of course poses a problem with the asynchronous response from the server: by the time the response comes back, the page has unloaded and the callback function won’t exist anymore. This generates an ugly Javacript “function is not defined” error. In any case, here’s a nice little picture of what happens:

The solution here is to make sure that any AJAX requests that you make onUnload are make synchronously instead of asynchronously (SJAX?). This will ensure that the page doesn’t finish unloading before the server response comes back. Hence, the much happier picture below:

Bertrand Le Roy has a quick chunk of Javascript that you can use to do alter the XmlHttpRequest object to temporarily do only synchronous calls. Use this Javascript before any AJAX calls in your unload event, and you’ve solved your problem!