Step by Step Guide to Porting Your Facebook App to Bebo

This is a guest post by Blake Commagere, creator of the “monsters” series of applications on Facebook, Bebo, and other social networks.

How much work is it?

Several Facebook developers have still not ported their apps to Bebo despite the ease with which it can be done. The team at Bebo has gone to great pains to ensure that porting your app from Facebook to Bebo is very, very little work. Given that you can access Bebo’s audience of 80 million users by spending just a little time on it, you should begin your port immediately – my applications (Zombies, Vampires, Werewolves & Slayers) took me about 9 hours total to port over. Here’s a quick guide to help you get started:

Two very important decisions to make:

  1. Whether you allow cross-platform functionality.
  2. Whether you use the same code base.

Allowing cross-platform functionality

Cross-platform functionality is simply any set of features that allow users on Facebook to interact with users on Bebo. In general, this is not a good decision because it is a non-trivial amount of work and will add value to your application in very, very few instances.

  1. While the average Internet user may have accounts on a few social networks, they are only active on one.
    • Keep in mind that engineers are an exception to this rule, but most users are NOT engineers
    • Very few active users on both networks means very few that would need a seamless experience between the two networks.
  2. Transferring a user’s settings from one network to another would require authenticating them against both social networks.
    • This would either have to be done by Facebook and Bebo through some sort of collaboration
    • Or, you will have to authenticate the user by prompting for them to log into one social network from an experience in the other – a very confusing user experience.
  3. Any tables indexed by user_id will have to be indexed by social_network and user_id to prevent collisions.
  4. Friend graphs do not map across the networks – i.e., your Facebook friends do not directly correlate to your Bebo friends.

There are cases where cross platform functionality does make sense and is not much work. If your app creates a synchronous experience with strangers – for example a flash poker game – then the user can be presented with a room that allows them to play poker against members of many different social networks and creates a larger community. However, functionality that allowed you to transfer your poker history and settings from Facebook to Bebo is a feature that would likely get very little use and add a non-trivial amount of work to your porting effort.

Using the same code base

Bebo has gone to great lengths to make using your same code base for both Bebo and Facebook very easy. In general, this is a very good decision for the following reasons:

  • Your feature set will always remain in synch
  • Bug fixes only have to happen in one place

If you are using MVC architecture, then you should be able to reuse your models and controllers with very little adjustment. As Bebo does not yet have FBJS support, the view portion of your application will require some work if you use FBJS.

If your app is not using an MVC architecture and you extensively use FBJS, then your code will have several places where you have to case out the different social networks and it may be worth branching your code base rather than reusing it.

Recommended Steps

(assumes you want to use the same code base and are not allowing cross-platform functionality)

  1. Ensure you are using 64 bit integers for your user ids (e.g. in MySQL bigint rather than int).
  2. Create a top level configuration file that determines whether the connection is coming from Facebook or Bebo and sets a parameter or define establishing which network has connected to you.
  3.    * You can do something like this:    * if ($_REQUEST['fb_sig_network'] == 'Bebo')    define('CURRENT_SOCIAL_NETWORK', 'Bebo');else    define('CURRENT_SOCIAL_NETWORK', 'Facebook');
  4. Merge the client APIs for Facebook and Bebo. You can start with the Facebook API and add cases that handle connecting to either Facebook servers or Bebo servers based on the parameter you established in Step 1. (Note: I am hoping to open source a merged client API for Facebook and Bebo in the very near future – this will make this step unnecessary!)
  5. Handle any cases where you relied upon aspects of the Facebook API that are not yet supported by Bebo. These API calls aren’t supported by Bebo yet:
    • AuthCreate/getsession (but this is coming very soon)
    • Admin.getAppProperties/Set AppProperties
    • Batch:run
    • Users.hasAppPermission
    • Users.getstatus
    • Friends.getlist
    • Datastorage
    • Marketplace
  6. If using FBML, handle any cases where you use facebook tags not yet supported by Bebo. Keep in mind: FBML is supported by Bebo – it SNML has the same syntax, but you do NOT have to switch from using to. Bebo allows you to use either! Currently, here are the tags not yet supported by Bebo:
    • mobile
    • require log-in attribute
    • page-edit-admin-header
    • visible to connection
    • attachment preview
    • if is-in network tag
  7. If you want to build functionality supported by Bebo but not Facebook, handle those cases properly. Here are the API components on Bebo that do not exist on Facebook:
    • Bands
    • Playlists
    • Songs of Bands
  8. Keep in mind that Bebo does not yet support FBJS (SNJS), but that will be coming very very soon! Additionally, pre-load SNQL launches the week of 6/02/08, so use it!
  9. Abstract out Facebook specific links or references. For example, anything specified here: will most likely not be as trivial as replacing the word “facebook” with “bebo” in these urls.
  10. Release on Bebo and enjoy!

About the Author

Blake was a Founder at, which later became Blake is also the creator of the superviral Zombies, Vampires, and Werewolves games on Facebook. Prior, he led the development of the Causes on Facebook application. Blake was also an early engineer on Plaxo’s client team and a founding engineer at BuildForge (acquired by IBM).