Canvas app using the FaceBook 3.1 API? - facebook

I used to develop a few FB apps in the past (using the old rest-ased api), and now I'm considering to make them actually usable again by porting them to the new 3.1 API.
Sounds nice, but for some reason this is way harder than I should be...
So here are few questions:
Is there any example of a canvas app using the 3.1 API? Google did not give me anything useful
Is there still a difference between iframe and FMBL canvas applications? In my app settings, I checked the fmbl-option, but when I'm back at the app overview page, it still says it's an iframe app.
The SDK mentions the getUser() function to get the user-id, but how do I request the necessary permissions for my app? When I do some googling, I find even another solution which calls a specific url and then performs a callback. This solution however doesn't seem to php sdk at all!
Where is the documentation of the php-api? The only usable thing I find is this: https://github.com/facebook/php-sdk which consists only a few lines of code. And I suspect this is for having a fb login-button on your own website, not for a canvas app.

Firstly, good luck, and best wishes - you'll need it. Maintaining Facebook apps is way harder than it should be, because Facebook doesn't believe in legacy support, changes things all the time, and deprecates things quickly and completely. As a (former) Facebook app dev myself, I can tell you there is only one constant: apps will die if you leave them alone. As an app developer, Facebook owes you no favors, and it is vicious when it comes to breaking apps.
As for specifics: as of June 2012, Facebook has deprecated and removed FBML and the REST API, and there is no longer any difference between canvas apps and iFrame apps. This isn't a soft, "you shouldn't use it" deprecation - it's a hard, "your apps are now broken" deprecation. All apps are now iFrame apps, as there is no longer any other way to build them. The docs on how to build a canvas/iFrame app are here, and there's an auth migration guide that may be helpful in conversion. Oh, and you'll need to get your app running on HTTPS too, if you haven't already.
As for the rest of it, it sucks, but the only way you're really going to be able to maintain and get your application working is using the Open Graph API. Using the PHP SDK, you just run $facebook->api('/graph/url/here') - for instance, to get user information, run $facebook->api("/$userid"). You get the URLs off of the Open Graph docs - just grab everything after the graph.facebook.com bit and pass it to api(). It's another learning curve, and (depending on the complexity/modularity of your code) is anywhere from a lot to a nightmarish mountain of changes, and there are no drop-in replacements. Sometimes you can use the old REST api, but I doubt that will last very much longer either. It's painful, but that's how it goes. You're at the mercy of Facebook, because it's their data.
Upgrading apps involves a shift in thinking: apps are now literally just webpages surrounded by the Facebook chrome. There is now no difference between an external website that uses Facebook's api to pull in information and an app that runs inside of Facebook. It's for that reason, personally, that I've shifted to just that for my own app - an external website that just happens to use Facebook for most of its posting/sharing/user info needs.
For authorization, you request permissions via OAuth, using any number of methods. There are docs on how to do that over on Facebook as well. Specifically for the PHP api, you generate a URL using getLoginURL() and then redirect to it. Facebook eventually redirects back to a URL you specify with info about whether they authorized your app and such, after which you can do a getUser(). If you want fancy/slick/user-friendly popup dialogs without a bunch of redirecting, the Javascript SDK is your friend.

Related

Full Facebook PHP SDK app (no JS SDK). Is it even possible?

In my work we often need to build Facebook apps in the form of Facebook Canvas and Website. These apps are available on Facebook direclty (an iframe) and as mobile versions (outside Facebook, in the browser).
We are working with a code base which mixes Facebook JS SDK (authentication and authorization) with PHP SDK (API calls). I find it rather dirty, and not easy to understand for people freshly working on the projects.
It's inconvinient to make API calls with JS, and making them with PHP forces extending access tokens. Authenticating user with JS SDK involves client-side redirects which are ugly to be honest, as they usually occur moments after the current page starts rendering, and so on...
I googled a lot about separating these two SDKs but did not find a clear answer to my questions:
Is it possible to create Facebook app (Canvas, Website) which bases ONLY on PHP SDK? Check login status, login, permissions, making API calls, etc. Would signed request be enough?
Is JS SDK the only full-proof way to determine user's login status at any time?
This link seems to describe what I'm thinking of, however the docs are rather brief (which seems to be a problem of Facebook documentation in general). Can anyone suggest other sources that might help? Does anyone have experience with builing FB aplications based only on server-side?
Thanks.
EDIT:
The link I posted above covers the case of not using ANY SDK, so no, it's not what I'm looking for.
You can even create an App WITHOUT any SDK - with simple CURL calls, for example. So yeah, it is indeed possible to use the PHP SDK only, but the login process is much better with the JS SDK (no redirection needed) and you can´t auto-refresh a user session like it is possible with FB.getLoginStatus afaik.
In short, i would not recommend it, the JS SDK is the very best way to authorize users and refresh Access Tokens. I would only use the PHP SDK (or simple CURL calls) for stuff that MUST happen on the server, and for stuff that includes using the App Secret, for example.

What do I need to do to make my apps compliant with OAuth 2.0 before 2011-12-13?

I just got this email from Facebook:
Dear Developer,
As part of our continued efforts to migrate all apps to OAuth 2.0, we
opted in all apps using the new JavaScript SDK to OAuth 2.0 this
afternoon at 11am PT and reverted at 1:30pm because we noticed that
your app has not migrated. Please ensure that you have set the oauth
param in FB.init to true and that you are using FB.getAuthResponse to
obtain the access token.
Read more in the OAuth2 migration announcement, updates to the new JS
SDK blog post, or our JS SDK docs.
If your app was affected today, please ensure that you have made these
changes by December 13th, 2012 to avoid any disruption with your
users.
The email doesn't specify which app needs my attention, and I can't make heads or tails of it.
Can anyone tell me what I need to be doing here? I have seven apps:
Four were created solely because I needed an app ID (API key) to install the "Like" button on various sites. Do I need to add "oauth: true" to the FB.init() call on these pages? (None of them actually integrate with Facebook authentication. All they do is render Like/Send buttons, and hook into the Edge.create callback for tracking purposes.)
Two of my apps are just tabs that I've added to Facebook Pages, which pull in static HTML pages (hosted elsewhere) via iframe. There's no JavaScript or server-side code whatsoever. I presume I can leave these alone?
One is an off-the-shelf app from a third-party provider. Looking at their code, I see that their call to FB.init() already includes oauth: true.
Facebook does a really terrible job with developer documentation, explaining changes, and maintaining backward compatibility. I'm a pretty experienced developer, but it seems like you have to learn every nook and cranny of Facebook's (ever-changing and over-complicated) proprietary API suite just to use the simplest features. I'm not a Facebook app developer (and I don't want to become one); I'm just a guy who wants to use a few "Like" buttons and custom page tabs, preferably without having to wade through this nonsense every two months when Facebook decides to change everything around and break backward compatibility again.
Anyway, any guidance would be much appreciated!
If you didn't see any of the blog posts since May - here's a summary: https://developers.facebook.com/docs/oauth2-https-migration/
To answer your specific questions, the 4 apps used only for the social plugins don't really USE oauth - but adding the oauth:true param and making sure they still work shouldn't be a huge issue - it also explicitly indicates to facebook that you're using the new auth mechanisms on those app IDs, so you shouldn't have an email sent about those apps in future
If your other apps aren't actually using any authentication, you probably don't need to do anything - if there was a problem you'd have discovered it yesterday when the oauth migration was flipped on for apps - the non compliant apps would have ceased working correctly

Build a facebook app or web app?

I want to develop an online application and I am considering EITHER building a website with community features built in or building ONLY a facebook app. I was wondering if other people have had to make the same decision and what things I will need to consider.
The website I want to build will be an educational portal where people can make and take tests online
I disagree with some of the other answers here. There is a huge difference between a) trying to advertise a new place on the web and b) trying to advertise a new functionality of an existing place. Even if this new website would offer a very tight integration with Facebook and some other social platforms. Keep in mind: facebook users really don't like to leave facebook, no matter what the reason would be. That's why the click-through rate for the advertisements is so embarrassingly poor: http://en.wikipedia.org/wiki/Facebook#Company
That said you can of course always do both: build a website and offer the same functionality through a facebook app. However my opinion here is that if you're application only offers its users a single functionality, you'll be better off just doing the latter.
What exactly is the advantage you expect by creating a Facebook-ONLY-App for that?
If it's only about taking tests you can still build a "normal" portal and include some of the Facebook-functionality through the JavaScript-SDK, like posting to the wall, Single-Sign-On, find your friends and so on. This way the user still has the choice if he wants to connect with Facebook or not. This way you also don't minimize your userbase to Facebook-users
(yeah I know, "everyone" has Facebook these days... ;) Still not everyone wants it to be connected to every single site he's using through Facebook)
Considering this comment:
Well I guess its easier for people to recommend my app if it is a facebook app, is the main reason I want to know if facebook is a good option – Zubair Mar 3 at 14:51
Build a website and then add the Facebook 'like' button. See: http://developers.facebook.com/docs/guides/web/#plugins
You should put a Twitter button as well:
http://twitter.com/about/resources/tweetbutton
In my opinion you have to develop both. First develop you website. Although facebook is having millions of users But in my opinion you cannot implement every thing as freely as you can in your web application than facebook application. You should have a website and a page on facebook. You can integrate other facebook social plugins on your website to interact with facebook.
From monitization point of it is easy for new users on website than application on facebook. Other reason website especially related to educational purposes have a huge click through rate which you cannot find on facebook application advertiser.
What is the goal of the website?
If its to make money dont do a facebook app, you have far more control of your site by designing it entirely yourself.
If you want social networking features there are plenty of APIs you can tie in to which will provide you with functionality and allow you to link into facebook / twitter etc.
A website would look more professional, it would allow you to gather statistics on unique hits, revisits etc, having your own database of users means you can gather information and market your site more specifically ( which users took which tests).
A website also allows you to monetize it by adding advertisement if that is your goal, and you can gain search engine rankings.
If you want to get publicity for your website you can use facebook by creating a group / page for the site and promoting it that way.
Also your own website wont leave you vulnerable to changes in Facebook, what if you put in all this work and in a year the terms change and a portion of your app is now in violation of the terms. What if you want to add X feature and facebook wont allow it?
Basically your site = 100% in your controll, thats a big advantage to you. With facebook you loose that advantage but maybe gain a little in being able to use more of their features. Personally id always go for my own site.
You should go for the website first, then add the social elements in the website.
Like you can enable users to login using there facebook credentials. Like/share Button.
And later on, you can also go for the facebook app, when you want to shoot for much much more traffic. Therefore, whenever you think that you have figured out what exactly you want out of your application then only go for it, otherwise try your options with website. Because once your facebook app is up, you will get hell lot of traffic.
Let me know if you need help in creating facebook application or social elements enabled website. I have built an Facebook Easy API on top of all facebook features, which will enable you to easily access anything on facebook and meanwhile reducing your work effort.
You first build it like web app and use Graph API and FBConnect to use Facebook functionalities. Then you need to create a facebook app version also because getting facebook traffic is also required. People from facebook most like come to facebook app then to another web.
You will not need to convert it to facebook app, it will be just less in width and it would be a facebook iframe app. as I some where read that facebook is depreciating fbml and iframe app is recommended.
So now you can make both things, as I think , test app can have flexible layout so that you don't need to change width for facebook iframe. So you can both things by doing one.
thanks
i'm pretty sure many people will not agre with me, but IMHO you should focus on build a good Web-App that work well also on Mobile-Phones. keep it simple, intuitive, responsive, lightweight, cross-browser and straight to the point.
if your only concern is about "recommend your app to other people" make it SEO and Multi-Language too. google will do the rest.
then if you want make your app bold, slowly and planty of useless stuffs start to add all the facebook widget you want.
PS: i'm also on facebook, twitter,
flickr, google etc etc, i'm also
sharing photos, links and usefull
stuffs, my google rss reader is full
of links with tons of nice things, well i
have never had a minute to look at it, when i need something i just start searching google
I agree with most of the answers here—a native website is the way to go. Personally, I don't trust/like FB apps. Dunno what they do, and given the number of scammers out there and FB's lack of responsibility (IMO), I rarely if ever use an FB app.
Creating the website gives users choice about whether they want to share results/integrate with their FB wall/profile. Users don't like to be forced into something.
And in the spirit of adventure that is typical of SO, it's always more fun to build your own website than to build a template-based (sort of), boring and nearly irrelevant (drowning in a sea of other poorly made apps) FB app. But that's just my 2¢
In your case, I would do a hybrid. First, build your website, but integrate it with Facebook via connect. This way you can concentrate on building your value added services and let Facebook worry about the community.
I would also not ignore the Facebook app. Now, with iframes being fully supported on Facebook, you can adapt your existing site to work within Facebook with minimal effort, as long as you keep this requirement in mind when building your original application.

Facebook app - Where to start?

I have read many articles about facebook apps, but I can't find anything what I need. Is it possible to create an App for Facebook with HTML/ CSS / Jquery without to using FBML and load this app from my server? Is it possible to use in this app the facebook functions like share, add app to my account etc? Is there any doku or example apps, where I can take a look?
Thanks
Nik
What delayed my app getting to work was realizing that the canvas URL request is HTTP POST - not HTTP GET as otherwise usual. A simple way to start is looking at example apps that have their source code open. There're examples both for PHP and python at the developer pages. A good example of a simple facebook app that uses google app engine is runwithfriends
FBML is in the process of deprecation in favor of the Graph Api for quite a while now.
Excerpt from http://developers.facebook.com/docs/reference/fbml/:
We are in the process of deprecating FBML. If you are building a new application on Facebook.com, please implement your application using HTML, JavaScript and CSS. You can use our JavaScript SDK and Social Plugins to embedded many of the same social features available in FBML. While there is still functionality that we have not ported over yet, we are no longer adding new features to FBML.
The Graph Api is easily accessible through JavaScript.
For a quick start you can use this page as a start.
First of all, fbml is not supported anymore. so forget about that.
You can write your fb app in many languages, for example you can do it in Ruby on Rails, PHP, or C#/ASP.NET etc, whatever you prefer (although you might want to look if there are some frameworks available for your platform, for using facebook. will make your life easier).
Then, setup your app from facebook developer to match your ip, and you're set to go

Creating Facebook App

Im new to facebook applications. I recently created a webapp that consisted of html & php. But recently Ive decided that integrating my webapp within facebook would be useful. Any tips on where to start? Ive looked over developers.facebook.com and im confused. It appears they are in the process of updating. Ive come across a few guides but there from a few years ago. This app will run completely within facebook and im probably gonna have to rewrite all the code. Any guides or suggestions?
Thanks!
You didn't specify the programming language you're using but if you're developing asp, start by looking into Facebook c# sdk here: http://facebooksdk.codeplex.com/
If you're using any other language (i.e. php), try looking into respective software dev. kits (i.e. facebook php sdk). They will facilitate your job in comparison to starting raw development all by yourself.
Tim, if you want to get into the business of working with Facebook, you need to know right away that they are always in the process of updating. That being said, you should learn some Facebook terminology so you can do more research and figure out what you want to do.
Applications that run within the Facebook interface are called Canvas Apps. Your application is hosted on your own server, and Facebook simply adds an iframe in their UI that points to your app's URL.
Another way to go to create a webapp that uses your own design, but still utilizes a single sign-on system from Facebook. This used to be called a Connect App but now they don't really have a name for it. Basically, you can use Facebook's authorization system to pull Facebook user data into your own database, which basically eliminates the need for a registration page. The authorization system prompts the user to allow your app to get specific data about them - once they authorize it, your app has access to do whatever the user gave it permission to do.
The best document to wrap your brain around is about authentication: http://developers.facebook.com/docs/authentication/
Give that a whirl, and good luck!