I have been using 'stream.publish' in the past, going off the most recent examples on their site I have tried using 'feed' but was getting some strange results (images not pulling through unless the application was running from a tab).
http://developers.facebook.com/docs/reference/javascript/FB.ui/
I was wondering what the differences are, if there are any other methods and when I should use them?
stream.publish is used for posting to the current users wall, as you know. You can use "feed" to post to a friend's wall, and "apprequests" to send a notification (Requests 2.0).
https://developers.facebook.com/docs/reference/dialogs/requests/
I use all three. While I've had issues with images appearing in the past, I haven't had recent issues. I believe it was just caching issues Facebooks side. Make sure you don't have restrictions on your server for loading images, like checking the referer to make sure they are on your site.
Related
I am currently attempting to retrieve the news feed from my Facebook home feed to include into an app. I know this used to be able to be done with the API however I have heard that it has since been removed. Is there any other way that you know of that would work or has it been added back into the API? It doesn't make sense why they would remove it.
No, there is no way to get a user’s feed via API. That used to be possible in the very early days (API v1), but has long since been removed.
It doesn't make sense why they would remove it.
Apart from user privacy (I don’t want my posts getting analyzed by some shady app with a developer located in $godKnowsWhere, just because they appeared on the feed of a friend of mine who might be using questionable apps), Facebook considers this a “core feature” – and 3rd-party apps are not supposed to replicate those in the first place. Facebook wants to make money from showing me ads when I view my feed, so allowing any other app to perform the same functionality would just mean loss of revenue.
I notice Facebook makes changes every so often. For example, it's html page structure changes every so often (if you write a like count scraper, then all of a sudden your scraper is broken one day).
Also I noticed URLs of the form https://www.facebook.com/video.php?v=100000000000000 started redirecting to https://www.facebook.com/{pagename}/videos/100000000000000 .... Probably the redirection will stay the same but I wonder - does Facebook publish these changes in behavior or how do you keep up with them?
I wasn't even sure this was the right place to post but I couldn't find a facebook stackoverflow community....Thanks!
If you build functionality off the Graph API there is a changelog, and versioning support e.g. you can build against a specific version and keep using functionality even though it is removed in later versions.
https://developers.facebook.com/docs/apps/changelog
I have this really odd problem. The bosses in the office decided to do facebook tracking by using the [FBSettings publishInstall:<appIDhere>] in the app delegate. This works because the graph.facebook.com/<appID>/activities, etc are called, and Facebook returned true.
However, the problem is that this is NOT showing up in the dashboard. The app_activate shows up just fine, it's just that the app install is not showing at all.
So, my questions are:
Why is it that the install is not read correctly? The call is made and facebook response. Why is it that it's not showing up in the dashboard?
Does facebook do any other filtering? For example, if I delete the app and then reinstall, should the app be counted to have installed twice? In this case, the call to graph.facebook.com/ is made twice to send the MOBILE_APP_INSTALL activity. After this, does facebook do any other filtering? e.g. they remember device tokens, etc?
I am not quite sure how facebook differentiate using the URL scheme. I presume that this is to differentiate people who upgraded compared to people who installed. How does the fb<appid> help as a URL Scheme?
Thank you in advance for all your help.
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.
Could someone tell me how this could be done?
http://l.yimg.com/p/social_buttons/facebook-share-iframe.php?u=http://www.lifehacker.com
This is basically a Facebook share button that is used by Yahoo in one of their blogs. The reason I am interested in this is because
1. it is very fast.
2. Has very few requests to facebook servers, unlink the Facebook iframe like button.
I currently use the Facebook Iframe button and it makes lot of requests to the fbcdn servers.
It looks to me like you're asking about manually tacking the count on the end of a plain graphic:
http://l.yimg.com/p/social_buttons/facebook-share-iframe.php
If so, what you're talking about is generating a graphic (ie: png, but you can do jog, as well() and maybe using an fb api to get at the current count, if you're not tracking it yourself. Using the API isn't trivial to set up or use, but after you get the pieces in place, fairly intuitive to use.
If you're talking about just doing a different button, I'd advise against it. That's just how that facebook feature works. It's great because it out of the box, though it does have requests to fb servers for it to work.