Facebook API Changes

Jul 22, 2008 at 5:45 PM

I haven't heard back from Nikhil since that original contact, but I've started working on the API changes already. I've mainly focused so far on the API methods that no longer require a current session key (and so can take any user ID for their action), but I've made some other updates where I could find some easy wins:

  • Added AdminService.cs and AdminIntegrationPoints.cs (for getting allocations only, at this point)
  • Added InNewProfile property to IFrame/FacebookApplication.cs
  • New FacebookRequest constructor that takes a requiresSession parameter
  • Changed FbmlService.RefreshContentHandle to not require session
  • Changed FbmlService.RefreshContentLink to not require session
  • Added FbmlService.RefreshImageSource
  • Added FacebookApplicationType.cs enum
  • Added applicationType parameter to Core/FacebookSession.cs
  • Set appropriate enum value in FacebookClientSession.cs, FacebookInfiniteSession.cs, and FacebookServerSession.cs
  • Added ApplicationType property to FacebookSession.cs
  • Changed ProfileService.GetFbml to not require session key for Web apps
  • Added overload to ProfileService.GetFbml to handle new type optional parameter
  • Added overload to ProfileService.SetFbml to handle new profile_main parameter and not require session key for Web apps
  • Added UsersService.SetStatus overload to accept user ID and not require session key for Web apps
  • Added EmailUser and InfiniteSession values to the Permission.cs enum
  • Changed PermissionsService.cs IsPermissionGranted to not require session key for Web apps
  • Added UnrestrictedFields constant to User.cs

I haven't had a chance to test any of this, so it's all very preliminary. I'm going to work on it again tonight. I'd prefer to have Nikhil review it, add me as a developer, and thus do a proper beta release but I'll make it publicly-accessible as soon as I can if that avenue isn't available soon enough.

Bill

Jul 22, 2008 at 5:48 PM
The reason I've added code that determines whether it's a desktop or Web application is because a valid session key is still almost always required for desktop applications. There was no good way to distinguish the two when you were working in Core, so I added it to the FacebookSession constructors since those are generated in the FrameworkWeb and FrameworkDesktop code. Those are the two places where we can unequivocally state whether we're working with a desktop or Web application.

Bill
Jul 22, 2008 at 10:31 PM

I was about to-do this as well, but since you've already done some of this, if you have a link, I'll be more than happy to test.

I'll also be working on any other missing pieces over the next several days, so when I'm done, I'll be more than happy to to send you a link to that.

thanks - Fruber.

 

Jul 22, 2008 at 10:33 PM

One item that I see first that I'd add would be the notifications.Send, it looks like you didn't cover that yet - is that true?

thanks


wcbrown wrote:
The reason I've added code that determines whether it's a desktop or Web application is because a valid session key is still almost always required for desktop applications. There was no good way to distinguish the two when you were working in Core, so I added it to the FacebookSession constructors since those are generated in the FrameworkWeb and FrameworkDesktop code. Those are the two places where we can unequivocally state whether we're working with a desktop or Web application.

Bill



Jul 22, 2008 at 10:54 PM
The notifications changes are on my agenda for tonight. That plus all of the feed changes and the new API methods. I'm going to F8 tomorrow but I plan to work on it plenty in the five or so hours I'll spend in the air.

Bill
Jul 22, 2008 at 11:14 PM

cool, well let me know if you want me to work on any bits - I'll be more than happy to share some of the load.

thanks.

 


wcbrown wrote:
The notifications changes are on my agenda for tonight. That plus all of the feed changes and the new API methods. I'm going to F8 tomorrow but I plan to work on it plenty in the five or so hours I'll spend in the air.

Bill



Jul 23, 2008 at 4:04 PM
Edited Jul 23, 2008 at 4:32 PM
I will be very interested in how you get on with this Bill (& Fruber), I am gradually understanding the framework, but quite a way off being able to help update easily and worried my iframe app will disintegrate on enforced switch over :( 

Just been looking at  http://www.new.facebook.com/ and trying to see what is going to need changing (I know I am way behind, but can only spend so much time on this)

Trying to find my profile FBML on a boxes tab, but cant see a boxes tab?

Will keep eye on your posts
Thanks,
Matt







Jul 25, 2008 at 10:25 PM
Edited Jul 25, 2008 at 10:26 PM
It looks like, once users flip over to the new design, they stop getting news feeds published using the old API.  So I'd be really happy to see that touched up in the toolkit. :)  I'm also pretty far off from being qualified to code for the toolkit, but I'm glad to help however else I can.
Jul 26, 2008 at 12:19 AM
Edited Jul 26, 2008 at 12:20 AM
It's a little weirder than that:
"During the user preview period, Feed stories submitted through the APIs will appear on both old and new profiles. The old Feed API calls (feed.publishStoryToUser, feed.publishActionOfUser, and feed.publishTemplatizedAction) will render the appropriate Feed story on the old profile, and render one line stories on the new profile. The new Feed API call (feed.publishUserAction) will work as expected on the new profile, and will render one line Feed stories on the old profile. All Feed stories will be aggregated and shared in News Feed as they are today." from the Wiki
I still have the bundle work to finish up, but I've got just about everything else done already. I haven't heard anything further from Nikhil since that initial contact despite repeated attempts to contact him via email and IM. Time is running out, to be sure. So by Monday I will either have a beta up on Facebook.NET or at a new project called fb.net, which will be the home of the fork until I can get it folded back into this project. Of course, I am hoping for the former.

I'll keep you guys updated on this discussion forum...

Bill
Jul 26, 2008 at 8:23 PM
Hi Bill,

If you need it I can give some time to testing and possibly code review over the weekend if you drop me an email at chris.allen [@] cnewtechnology.com

Rgds,
Chris
Jul 28, 2008 at 10:20 PM
Thanks! I didn't do much development over the weekend, mainly just publishing the fork. But I will keep you in mind and you can decide whether or not to participate.

Bill
Aug 15, 2008 at 12:54 AM
It's even more insidious than Bill was suggesting -- since Facebook.NET calls api.facebook.com instead of api.new.facebook.com, news feed items don't work for anyone who adds the application after moving over to the new facebook.  I've posted my analysis of the problem here.
Aug 15, 2008 at 10:13 PM
Yes, I saw that API URL change recently. I'm not sure Facebook could've handled this transition worse. Aside from the moving target and perennially-inaccurate documentation, they've also been adding features to the new profile. And as you noted in that linked forum post, they've "announced" the end of the transition in the answer to an FAQ on a Wiki page that isn't prominently linked anywhere. I wish I had cornered one of the Platform devs at F8 instead of just chatting with a guy on Facebook Connect.

Bill