5 Things I’ve Learnt About Facebook Application Development
by Kah Hong
Over the last four weeks, a significant amount of my time has been spent on developing Facebook applications. While it hasn’t been a stroll in the park by any means, it has been slightly easier than I had anticipated. Granted, there were occasional obstacles and roadblocks that got in the way, and the usual suspects like bugs that made development more frustrating, but my prior knowledge in PHP and MySQL did come to good use during the assignment.
Developing on the Facebook platform and utilising the Facebook API was still a virgin experience for me, and the following are probably the top five things that I wish I’d known a month ago:
Facebook passes additional parameters in the URL
This statement on its own is not really a big deal, but it mattered because the framework on which I built the application on was CodeIgniter, which is particularly sensitive with what is passed in the URL. I realised this only when I tried to deploy the application, and even after exercising my Google-fu and executing various solutions which I found on technical forums and the like, Facebook and CodeIgniter still refused to be nice to one another. I had little choice but to abandon this choice of framework and to recode the application from scratch, which was pretty much a lesson learnt.
The number 2147483647
This was a particularly careless oversight on my part, and it brought about an unnecessary inconvenience to the team. Apparently, the newer Facebook users have user IDs that are larger than what a 32-bit integer can store, and BIGINT should have been used instead of INT as the data type. The disastrous consequence of this was that one of my team members couldn’t test out nor interact with the application as he had only recently signed up for an account with Facebook.
Stylesheets are cached, or something like that
Changes made to the style sheet won’t be reflected on the Facebook application immediately, and being unaware of this led to much frustration when attempting to iterate minor design improvements. It made it seem as if the expected changes weren’t being implemented, resulting in a sense of self-doubt or confusion and ultimately more furious amendments to the style sheet, which of course were largely ineffective. A better option than waiting for the changes to take effect would be to rename the style sheet and edit the page to point to the new style sheet, but of course doing a multitude of simple adjustments can easily scale to a large hassle.
FBML when necessary
There are instances when API calls return a String instead of an Array, or vice versa, which throws up some error on PHP. I had been dependent on these API calls to pull simple user data, when FBML would have been a much easier alternative. Amending the code to use the latter not only clearly improved the user experience, but made the code much neater as well. Why the API call behaves inconsistently, I’m still not quite certain.
It’s a lot easier the second time round
Following the Facebook application development assignment, I decided to code another application for the seminar assignment, and rather unsurprisingly it wasn’t difficult at all to do. I reused most of the code from the first assignment while making changes to the functions and database queries accordingly, and after slapping on a design I pretty much had a prototype in less than a day. I guess if I had learnt to develop a Facebook application before the assignment, I wouldn’t have made the mistakes mentioned above. All this, of course, is just hindsight bias at play.
I’m really glad that I got the opportunity to develop an application on the Facebook platform, and doing so increased the relevance of my PHP and MySQL knowledge. The best is that I got to learn all this as part of school, and within such a limited period of time as well. I definitely can’t wait to build more Facebook applications soon.