The deadline for enforcement of the new Facebook Developer Principles and Policies has passed and now all the application developers that violate those rules will be punished. The actions taken against the apps will range from simple warnings, suspension of certain functionality to the outright disablement of the app according to the “severity” of the violation, the developer’s history of compliance and the impact of the violation on the users of the application.

These new changes to the Developer Principles and Policies will slow down the growth of new applications significantly. The auto pop-up permission requests, bookmark reminders will be considered as violations. The stream stories can no longer be used as methods for users to invite friends to the applications and soon Facebook will disable all the viral channels of communication (notifications, requests) and leave developers with only the dashboard counters and the Inbox.

Added to this, as outlined in the Facebook Developer Roadmap, Developers will be able to obtain the users’ primary email addresses and the formatting of the canvas will change to better outline the brand of the application. To me this looks like Facebook is slowly “pushing away” the applications from Facebook.com to better highlight that they are the creations of third party developers, not Facebook itself.

As I reckon, employing the FBJS call might be a better thing to do as users may not readily give your application permission to print stories to their walls whenever you want. In fact, let me present the case of why you should ONLY use the FBJS call for all the feed story publishing needs in your application.

What Facebook.streamPublish does is show a feed form to the user which has two choices, either to publish the story contained in the form to the user’s profile or skip it. And before I proceed on feed forms, a legal advice here. You cannot show feed forms to the user whenever your application feel likes, but you have to present the user a choice as he/she takes any action on your application, if they would like to have a feed story printed on their profile page and then only. The clause that mandates this behavior is DPP.VI.1 which says “You must not display a Feed form unless a user has explicitly indicated an intention to share that content, by clicking a button or checking a box that clearly explains their content will be shared.”. Moving on, a typical feed form looks like this:

You can supply the title(Fappside.com – Facebook News), the link of the title, the description text, thumbnail paths which will be resized to 90×90 pixels, other custom properties(Founded and Category), and action links(Become a Fan). The arguments have to be passed in a JSON array alongwith some other parameters. The function is of the form:

I will detail two parameters only, the rest you can find explained here.
auto_publish: If this is set to true, and the currently logged in user has already given your application stream_publish permission, the user won’t see the feed form and instead the story will get published automatically. If you set AUTO_PUBLISH false, the feed form will show up no matter what.
target_id: This argument tells on whose behalf to submit the story. If this is set to null, it defaults to on behalf of the user currently logged in. If it is the ID of a Facebook Page and the currently logged in user is the admin of that page, the story is published to the wall of the Page, on behalf of the page.

Here is some example code to print a story using Facebook.streamPublish in PHP, FBML & FBJS. I am assuming you have a application already set up and you have a FBML canvas page.

The above setup will print a feed story that looks like this by default:

and like this when the See More link in the feed story is clicked:

That’s it with the Facebook.streamPublish method. Do let me know in the comments section if you find anything while doing this yourself, interesting or annoying. Now onto the tip I promised.

This is actually handy and we have been looking for it since sometime. The Add Bookmark feature on the application canvas pages, instead of relying on the humility of the sole link in Facebook’s bottom navigation bar with the application icons to work its magic. All you have to do now is embed the FBML <fb:bookmark /> on your canvas pages and a pretty button will be rendered. It even works on profile tabs. If the user has already bookmarked your application, Facebook will know that beforehand and won’t show the button. There may also be situations where you want to know in your code if a specified user has bookmarked your application or not, and for that use the following FQL query, where $uid is the ID of the user you want to learn about.

I think I have talked enough uptil now. I am looking for topics to write on that may interest you, so if you already know what you like to see, holler here and I will take note, and might do something. Looking forward to a conversation now with you in the comments section.

The Facebook Platform has just recovered from about 10 hours of degraded performance.

Application developers were complaining about various FBML related problems from as long as 11 hours ago. 6 hours ago it was almost impossible to access a FBML canvas application. The errors ranged from FBML timezone renders to even basic HTML table renders (which by the way still continue to show for various apps). To reduce these kind of errors we suggest to turn off the canvas quick transitions option.

It is noteworthy to mention that today is Tuesday and the performance issues were directly connected to Facebook’s weekly code-push, which occurs on Tuesdays, and that today’s code-push included the updated stream story structure, where stream stories can contain just 1 image with limited number of lines and a Read More link.