Below are five tips on using Facebook’s API. These techniques were all used in TripConnect’s Travel Profile Application that allows Facebook users to add a travel interests to their Facebook profile. I know they work in this app, but they may not be the perfect solutions.The first two tips are specific to the JAVA kit. The others are more general.1) Installation – I saw several posts in the Developer Forum on users having trouble installing the Java kit in Eclipse. I didn’t have much of an issue . All that was needed was to create the com.facebook.api package in the src folder, move all the java files into this folder, drop the two jar files (browselauncher and json) into my libraries folder, add these libraries to my ANT User libraries and build… No issues.

2) FacebookRestClient.java -does not have a method to pull the userid. So after calling facebookRestClient.auth_getSession(authToken) to establish the session, I found no way to get the userid. Odd… All I did was add one method:

public int getUserId() { return _userId; }

to FacebookRestClient.java

3) What to do with the Session id – Store this in your application’s session manager, but don’t store it forever (e.g., don’t store it in the database). You can try to ask the user to ‘remember me’, but there is no guarantee that the user will do this for you. The JAVA api doesn’t gather or store the expiration value for the session so if you want to be slick and test for expiration, you’ll need to modify the API to collect it for you. Regardless, if the session expires or you just don’t have one for this user, then you need to redirect to

http://www.facebook.com/login.php?api_key=YOUR_API_KEY&v=1.0

as stated in the authentication guide.

4) setFbml – is the call you have to make to set content on a User’s Profile Page. We found the best way to set content is to use fb:ref and pass in a URL that you host for the content that you want to display. fb:iframe will not work for the profile object. Note that the contents of the URL that you pass are stored in a Facebook cache.

In the developer’s forum, many users have asked about how to update/reset the cache. Some have tried doing this w/ a script on cron and storing session id’s. Even if you get this to work (I haven’t seen a fool proof approach), you are creating a potential scalability issue if your lucky enough to have lots of users sign up for your app.

The best method is to have the app update the obect if/when users access your app. Facebook provides an Edit Url which you can use to point to a canvas page with links to update the application data. Once the user does an update, your application can reset the cache. Here’s how we do it:

• Edit URL points to a canvas page with a bunch of links on tools users can enhance their travel profile.
• Each link points to http://www.facebook.com/login.php … . The next attribute in the query string is used to point to the tool in the TripConnect application.
• Since your inbound links are bouncing through http://www.facebook.com/login.php , you’ll get an auth_token parameter which can be converted to a session id.
• Once you have a new/valid session id, you can call facebookRestClient.fbml_refreshRefUrl(URL) (which will update the cache) followed by a facebookRestClient.profile_setFBML(“<fb:ref url=\”” + URL + “\”/>”) (which insures that fbml for the user’s profile is set correctly.

It’s not perfect but should work in many situations.

5) Your callback URL – The easiest thing to do with the Callback URL is to redirect it back to
http://www.facebook.com/login.php which will give the user the opportunity to add the application. But doing this blindly and without checking the current state can lead to problems. For example, if the user already added the app and an auth_code was passed in, then redirecting back will cause a message to appear to the user – “You already added this app”. Our logic on this callback URL does the following:

If an auth_code was not passed in then redircect back to http://www.facebook.com/login.php
else if the user is already a member, then render an appropriate page
else (user is not a member and auth_code was passed in) then send the user to the Add App page. (http://www.facebook.com/add.php?api_key=YOUR_API_KEY

Regarding the last use case – this seems to be either a defect or oddity in Facebook’s authentication which can happen if the user adds the app, then removes it, then tries to add it again. Since the user added it once before, Facebook doesn’t present the page to add it again.

One issue with the last use case is the add.php is a full page (w/ nav…), but the call to your Callback URL is supposed to return only the content frame. You’ll need to frame bust your response using something like the following:

<meta http-equiv=”refresh” content=”0;url=http://www.facebook.com/add.php?api_key=YOUR_API_KEY”/>
<script type=”text/javascript”>
if (top.location != location) top.location.href = location.href;
</script>

Updated June 14, 2007: The facebook wiki has updated documentation on the callback URL.

The callback page now does, theoretically, double-duty. In the previous world of the Facebook API, your callback page would get called back when the user visited login.php, and it would be a GET with a &auth_token= (and whatever else you wanted to pass around). If, however, the user visits apps.facebook.com/yourapphere/, then the callback is called to serve the “canvas”. In that case, it gets a POST.

See Your Callback Page for all the details.