Overview – complaints
When you begin developing Facebook applications you will quickly discover it’s a painful process.
Documentation is generally out of date since the API changes so frequently, so you have no assurance of what you’re reading is still relevent.
Documentation is generally out of date since the API changes so frequently, so you have no assurance of what you’re reading is still relevent.
Facebook Connect vs. Social Plugins
When integrating with Facebook you can either put components or widgets on your own site (e.g. the Like button) called Social Plugins, or have a Facebook application, which is fronted (proxied) by Facebook but ultimately served by your server called Facebook Connect.The latter case is what we we’re developing and requires people accessing your site to install your application first. This then appears in their list of applications on their profile page.
FBML vs. iframes
You have two choices when developing a Facebook site, one is to develop in FBML, which is HTML with a few Facebook extensions; and the second is to develop an iframe which is served directly from your server (not intercepted by Facebook) and appears embedded inside the Facebook page.
Developing in FBML means Facebook hits your server with a request for a particular page, interprets all the FBML tags (e.g. ) and substitues them with proper HTML and Javascript, and serves them up to the client.
Developing an iframe application means you’re serving content directly to the client with no Facebook intervention. There is one important caveat to this which is using XFBML. This is a series of tags just like FBML, but instead of Facebook’s servers intercepting and replacing them with HTML before serving them to the client, a client-side Javascript library does this after they’ve been received on the browser.
So the process of an iframe with XFBML is this:
- The client browser accesses your application through a URL like http://app.facebook.com/your-app which includes an iframe in the middle.
- The browser requests this iframe which is linked to your site through whatever URL you’ve configured.
- Your server serves the HTML and XFBML document directly to the client, including a declaration for a Facebook javascript.
- The Facebook javascript then executes onces the page has loaded, reading all the tags and turning them into HTML, including hitting the Facebook server to pull down content.
The advantage of this is discussed here. The main deciding factor for us was speed: the little Facebook chat which appears on the bottom right of every Facebook page is large and slow to render. You can avoid the overhead of loading that with every click by running your site through an iframe, since the outer window is not reloaded each time.
The downside is the delay on the browser when the page loads. If you have Facebook XFBML tags on the page these will appear only after the Javascript has executed, called the Facebook server to receive the data and rendered them on the page.
So your users will see a delay before the comments box or like button appear, with the animated “loading” icon.
So your users will see a delay before the comments box or like button appear, with the animated “loading” icon.
A consideration for Ruby on Rails developers opting for the FBML method (instead of iframe) is Facebook makes all requests to your server a POST.
This obviously breaks all your RESTful routes and means you’ll probably have to manually write all your routes for every action in your routes.rb file.
This obviously breaks all your RESTful routes and means you’ll probably have to manually write all your routes for every action in your routes.rb file.
Regardless of whether you choose FBML or iframe, the Facebook API is available to you client or server side. On the server side we used the Facebooker gem which provides a convenient wrapper around the API, such as ensure_authenticated_to_facebook.
We tried to keep hits to facebook to a minimum since they add about an extra 400ms to the response time. You can also achieve this by querying the Facebook API client side.
An inconvenience with developing Facebook applications from behind a firewall in your office is you cannot test without deploying. And due to the numerous quirks there’s a lot of hit and miss style development: try something see if it works, nope, repeat until it works.
Having to do a deployment every 30 seconds makes this problem even more tedious until you give up and start developing on the server (yikes!).
Having to do a deployment every 30 seconds makes this problem even more tedious until you give up and start developing on the server (yikes!).
Steps for getting started:--
1) Create a facebook app via facebook developer
2) Edit settings of app:-- fill canvas url, canvaspage name, site url, essentially
3) Note api secret and api key
4) Install facebooker as a gem or plugin
5) If facebooker plugin not properly installed, download plugin from github and copy to rails app plugin folder and run rake task of setup facebooker
6) Now you’ll have facebooker.yml in config folder, fill your api key and api secret
7) Now we need to create a cross-domain receiver file for Facebook Connect to callback on. Luckily, facebooker can do that for us, but make sure you have configured your facebooker.yml file correctly, or the generator will bomb out:
script/generate xd_receiverIssues Encountered:--1)Invalid Argument Given URL is not allowed by the Application configuration. Error coming while opening login window of facebook
Solution:-- Change siteurl value from localhost:3000/businesses to localhost:3000/2)Loginerror.php after filling login credentials.
Solution:- Site url value should not be blank, it should contain url of application 3)Infilinte loop:- request going in infinite loop, from website controller.
Solution:-- comment out protect from forgery
No comments:
Post a Comment