Over a year ago, we introduced Single Sign-On (SSO) for Android and iOS. Today, more than 350 million active users currently access Facebook through their mobile devices. Users logged into the Facebook for iOS or Facebook for Android app can use the “Login with Facebook” button and, in one-click through a permissions dialog, login to your app. This saves users from typing in an e-mail address and password for apps that require registered users. Since the launch of SSO, developers implementing it in their apps have enjoyed increased user registrations and access to the Graph API to build in-app social experiences.

SSO Product Update

We have made significant stability and performance improvements in SSO as well as making it a core part of enabling Social Mobile App Discovery that we announced last October. In addition, we created a simpler authentication flow for users who have already authenticated your app. If a user has previously given your app the requested permissions, SSO will immediately pass an OAuth 2 access token back to your app. For example, if you already have a connected Facebook user on your website or canvas app, users will be able to login faster into your mobile native apps.

Pro-tip 1: Include Facebook Login at User Registration

Apps will often only use SSO and Facebook Login when asking the user to enable Facebook features in the app. You should also include Facebook Login anywhere you prompt the user to Register for your app, often times when users launch your app for the first time. Users can enjoy a simplified registration process, and you can request the same information, such as e-mail address, that you would normally collect manually from the user.

Pro-tip 2: Store the user’s session in your app

After your user authenticates for the first time, you should immediately store the authentication result locally. This way, you can keep the user logged-in to your app without having the user re-authenticate each time. Here are some Android and iOS Code samples that demonstrate how you can easily do this in your app:

iOS Example: In the fbDidLogin delegate method, when the user has logged in via SSO, save the session:

- (void)fbDidLogin {
  NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
  [defaults setObject:[facebook accessToken] forKey:@"FBAccessTokenKey"];
  [defaults setObject:[facebook expirationDate] forKey:@"FBExpirationDateKey"];
  [defaults synchronize];
}

Then, when your app starts in the future, set the accessToken and expirationDate in your Facebook object if they exists:

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
if ([defaults objectForKey:@"FBAccessTokenKey"]
  && [defaults objectForKey:@"FBExpirationDateKey"]) {
  facebook.accessToken = [defaults objectForKey:@"FBAccessTokenKey"];
  facebook.expirationDate = [defaults objectForKey:@"FBExpirationDateKey"];
}

Android Example: When the user has logged in via SSO, save the session:

Editor editor = context.getSharedPreferences("facebook-session", 
                                             Context.MODE_PRIVATE).edit();
editor.putString("access_token", session.getAccessToken());
editor.putLong("expires_in", session.getAccessExpires());

When you app starts, in onCreate, restore the session if it exists:

SharedPreferences savedSession = context.getSharedPreferences
                                 ("facebook-session",Context.MODE_PRIVATE);
session.setAccessToken(savedSession.getString("access_token", null));
session.setAccessExpires(savedSession.getLong("expires_in", 0));

Pro-tip 3: Request only the permissions your app needs

We have streamlined the SSO permissions dialog, along with all permission dialogs in our recently announced Improved Auth Dialog. You should only request the permissions you need to get the user registered and using your app’s social features.

As part of our ongoing efforts to improve privacy protections for Facebook users, we've deprecated the 'offline_access' permission. Instead, you now have the option to extend the expiration of existing, valid access tokens for a limited amount of time without requiring the user to login again. Learn more about upgrading access tokens. Also, many apps incorrectly ask for 'publish_stream' when using our Feed Dialog. Your app only needs 'publish_stream' if it will be publishing to the user’s feed programmatically with the Graph API.

Pro-tip 4: Complete all iOS and Android Fields in your App Settings

Be sure to fill out every field related to your app in your app settings in the Native iOS App and the Native Android App fields. You can access these app settings for your app here. On iOS, If these fields are not configured, we will not be able to drive traffic to your app or the iOS App Store. In addition, we use the iOS Bundle ID to streamline authentication for users who have already authenticated your app.

In the coming weeks, we will be posting additional best practices for leveraging the Facebook Platform in iOS and Android Apps. Implementing SSO is the first step to taking advantage of improved distribution and engagement with the Facebook Platform in these environments.

Get started with our step-by-step documentation and sample code available in the iOS Getting Started and Android Getting Started guides.

This week we announced how to implement flashHideCallback to support "wmode=window". We are also announcing the following changes:

Getting SubscribedTo and Subscribers via Graph API

We are now providing the ability of reading a user's subscribers and subscribees list via the Graph API. To access this information, your app is required to have the user_subscriptions permission for the user, and friends_subscriptions permission for their friends' info. Refer to the documentation for SubscribedTo and Subscribers for more details.

To access a user's subscribers list, issue an HTTP GET request to the subscribers connection like the following:

https://graph.facebook.com/USER_ID/subscribers?access_token=...

Similarly, to access a user's subscribees list, issue an HTTP GET request to the subscribedto connection.

https://graph.facebook.com/USER_ID/subscribedto?access_token=...

The following PHP example demonstrates how to read the subscribed-to list:

<?php
  $app_id = 'YOUR_APP_ID';
  $app_secret = 'YOUR_APP_SECRET';
  $my_url = 'YOUR_URL';

  $code = $_REQUEST["code"];

  if (!$code) {
    // user_subscriptions and  friend_subscriptions permissions 
    // are required
    $dialog_url = "http://www.facebook.com/dialog/oauth?client_id="
     . $app_id . "&redirect_uri=" . urlencode($my_url)
     . "&scope=user_subscriptions";
    echo('<script>top.location.href="' . $dialog_url . '";</script>');
  } else {
    $token_url = "https://graph.facebook.com/oauth/access_token?client_id="
     . $app_id . "&redirect_uri=" . urlencode($my_url)
     . "&client_secret=" . $app_secret
     . "&code=" . $code;
    $access_token = file_get_contents($token_url);

    // Get request for the subcribed-to list
    $subscribedto_url =
      "https://graph.facebook.com/me/subscribedto?"
     . "access_token=".$access_token;
    $subscribedto_resp_obj =
      json_decode(file_get_contents($subscribedto_url), true);

    // Parse the return value and get the array of people subscribed to.
    // This is in returned in the data[] array
    $subscribedto = $subscribedto_resp_obj['data'];

    print_r($subscribedto);
  }
?>

Improved Search Results on the Developer Site

We improved search results on the Dev Site. Search now includes Technical Q&A from Stack Overflow and Bugs. You can also filter your results to only show the type of information you are looking for (e.g., blog posts, documentation, API reference, technical Q&A, bugs).

manage_notifications Permission Now Required for Managing a User's Notifications.

As announced on the blog on July 29, 2011 and on the Roadmap, to read or manage a user's notifications we now require the manage_notifications permission. The "Require manage_notifications" migration has now been removed per our 90-day breaking change policy. For more information, see the User object documentation.

Upcoming Breaking Changes on February 1st 2012

• Removing FeatureLoader JavaScript SDK. As part of the OAuth2 migration, we announced that the FeatureLoader SDK is no longer supported as of October 1st, 2011. On February 1st 2012, we will remove FeatureLoader. Please ensure that your app is using the JS SDK.
• Removing canvas_name Field from Application Object We will be deprecating the canvas_name field in favor of namespace field on the application object on February 1st 2012.
• Removing App Profile Pages We will be deleting all App Profile Pages and redirecting all traffic directly to the App on February 1st 2012. For more information, please refer to the blog post.
• Removing REST support for Ads API We will be removing REST support for the Ads API on February 1st 2012. All Ads API developer must move their applications to use the Graph API.
• Improved Auth Dialog On February 1st 2012, all apps will be enabled for the improved dialog, but those that haven’t fully configured their dialog can disable the setting in the Developer App until February 15, at which time it will be turned on for all apps.

New Breaking Changes

• Pages Insights Metrics Deprecations. We are in the process of deprecating some old Page Insights. We announced this in a number of forums, but failed to outline this change in our Platform Roadmap per our breaking change policy. Our apologies. You can find a full list of the Insights to be deprecated from the Insights documentation. These Insights will be completely removed from API on Feb 15th 2012. Please make all necessary updates as soon as possible so that you can transition smoothly.

• Throwing an Exception for Invalid filter_key. We will throw an exception if you try to query the stream FQL table with an invalid filter key. Currently if you call stream.get with an invalid filter_key value, the query silently fails, and with this change we will be throwing an exception. Refer to FQL stream documentation for details on using a filter_key. This change will take effect on May 1st 2012.

Please refer to the Platform Roadmap for more info.

Bug Activity from 1/18/12 to 1/24/12

• 276 bugs were reported
• 51 bugs were reproducible and accepted (after duplicates removed)
• 26 bugs were by design
• 38 bugs were fixed
• 262 bugs were duplicate, invalid, or need more information

• Bugs fixed from 1/18/12 to 1/24/12

• typo
• Lost 500k fans after migrating Application Profile Page
• add photo tag via graph api returns TRUE, but tag doesn't add to photo
• type field in the friendlist graph api object is wrongly documented
• friendlist fql table should have the type parameter documented
• application profile page likes still didnt migrate after 3 weeks!
• Method to extend the access token generated from server side flow after offline access deprecation is unclear.
• Developer Blog has incorrect og:url tag
• All news feed about our game disappeared in facebook.
• application profile page likes still didnt migrate after 9 days!
• Old repository link in documentation.
• Like count doesn't migrate to new page after the migration
• Bug in max_recipients in Mobile Version (JS API)
• OAuth Documentation is inaccurate - Client + Server Authorization
• Open graph pages - it's not possible reach the admin pages
• Broken link to Javascript SDK in depricated message
• Pending Tester request not working
• Documentation missing details about user overrides to posting permissions
• Native iOS MFS goes blank after selecting recipient
• Open Graph Admin page does not show next to Like button
• Documentation error: code example for Facebook::getLoginUrl
• Like buttons and box not working (page could not be reached)
• Broken link in OAuth Dialog Documentation
• Documentation Bug - Main FB For Websites page still refers to pre-oauth2.0 cookie format.
• Request permission page does not render correctly on Windows Phone
• Inaccurate URL in Open Graph sequence diagram
• Some new insights values being returned as strings
• If a user does destroySession() in PHP SDK, they should be able to re-populated persistent data when doing getUser()
• Unable to unset app restrictions via graph api
• PHP SDK returns previous user's userId even though access_token has changed
• Consistency across examples in documentation (initializing all.js)
• Sudden hike in the number of api errors reported in insights page since Sept 6th
• Tutorial Documentation Error
• Aggregation previews only work for first aggregation created
• like button in hebrew is broken
• Documentation bug for Page/tabs/TAB_ID
• Unknown method error using FB.ui
• Display parameter not documented for getLoginUrl

• Facebook Stack Overflow Activity

  Activity on facebook.stackoverflow.com this week:

  • 145 questions asked
  • 39 answered, 27% answered rate
  • 86 replied, 59% reply rate

One of the Pro-Tips we mentioned late last year in our Games Tutorial to Developers creating Flash based Apps was to use wmode=opaque whenever possible. Setting wmode to any value other than "opaque" or "transparent" prevents any HTML content from being displayed at a higher z index than the Flash object. This results in Dialogs, Notifications and Ticker Flyouts being displayed under the Flash object and creates a pretty poor user experience on Canvas.

As a result when Canvas Apps set wmode to "window" or "direct" Facebook automatically hides the Flash object when any Dialogs, Notifications or Ticker Flyouts are opened. To help improve the user experience we have recently introduced a new parameter for FB.init in the JavaScript SDK called hideFlashCallback . This allows developers to specify their own behavior for the auto hiding of Flash objects with wmode=window or direct, so long as the custom behavior completes in 200ms or less. After 200ms we will hide the Flash Object automatically regardless.

This How-To will walk you through the process of creating a temporary dynamic screenshot of your Flash App and replacing the Flash Object with this image within 200ms. This allows Dialogs to display correctly and creates a more pleasing user experience.

The How-To is divided into the following sections:

1. Creating a Dynamic Screenshot in Flash
2. Enabling ActionScript to JavaScript Communication
3. Using a Data URI
4. Setting up the hideFlashCallback Functionality
5. Source Code for the Example App

Developers are expected to be familiar with JavaScript and ActionScript 3.0 in order to continue.  

Creating a Dynamic Screenshot in Flash

The first step will be to implement a method within your Flash App that creates a dynamic screenshot of the Stage object, compresses this into a JPEG format and then Base64 encodes this string. Fortunately there are public libraries available that will take care of most of these steps. For this example we will use: http://www.blooddy.by/en/crypto/ or feel free to use any lib that you prefer.

Next we will create the ActionScript exportScreenshot method that will return our screenshot data string, ready for use.

ActionScript

import by.blooddy.crypto.Base64;
import by.blooddy.crypto.image.JPEGEncoder;

...

private function exportScreenshot():String {
  var scale:Number = 0.25;
  var result:String = null;
  var blurFilter:BlurFilter = new BlurFilter(3, 3, BitmapFilterQuality.HIGH);

  var bData:BitmapData = new BitmapData(stage.stageWidth * scale,
    stage.stageHeight * scale,false,0x0);
  var matrix:Matrix = new Matrix();
  matrix.scale(scale, scale);

  bData.draw(stage, matrix);
  bData.applyFilter(bData, bData.rect, new Point(0, 0), blurFilter);

  var jpgBytes:ByteArray = JPEGEncoder.encode(bData,80);
  if (jpgBytes) {
    var screenshotBase64:String = Base64.encode(jpgBytes);
    if (screenshotBase64) {
      result = screenshotBase64;
    }
  }

  return result;
}

Walking through the code line by line you will notice that we are scaling the image to 25% of the full Stage dimensions. This is to reduce the size of our screenshot image and increase overall performance. Next we apply a BlurFilter to smooth out the jagged edges that result. Finally we encode our Bitmap as a JPEG, base64 encode it and then return the string.  

Enabling ActionScript to JavaScript Communication

Now that we have a method in our Flash App that can create a dynamic screenshot image we will need to support JavaScript communication from within the Flash Object. This will allow us to create a screenshot dynamically through a JavaScript call.

To do this we will need to import the ExternalInterface class in our Flash App and register a callback method.

ActionScript

import flash.external.ExternalInterface

...

ExternalInterface.addCallback('exportScreenshot', exportScreenshot);

The code registers a callback method called exportScreenshot in JavaScript allowing us to call our ActionScript method of the same name from JavaScript directly.  

Using a Data URI

Next we will create a image HTML element that will contain our dynamic screenshot and replace the Flash Object temporarily. To implement this we will use a Data URI allowing us to define the image data inline without having to make any requests back to a web server, increasing our performance.

Note: This is only available in modern browsers, Internet Explorer 8 and above. For IE7 and below you will have to fallback to a static image and cannot use the method described in this How-To.

In the HTML below we define a div HTML element that will contain our Flash content and directly underneath, a div HTML element that contains our img element that will hold our screenshot image. Finally we set both of these elements to have absolute position within a relative positioned parent. This allows us to place the img element beneath our Flash Object.

HTML

<div id="allContent" style="position:relative;">
  <div id="flashContent" style="position:absolute">
    <div id="flashHolder"></div>
  </div>
<div id="imageContent" style="position:absolute; top: -10000px;">
  <img id="screenshotObject"
    src="blank.gif"
    style="margin: 0 auto; display:block;" />
</div>

After we call the exportScreenshot method from JavaScript to get our dynamic screenshot, we set the dimensions of our img element to match the Flash Object, move the Flash Object out of the display area and put the screenshot image in it's place.

JavaScript

// Call the Flash Actionscript method to create the dynamic screenshot
var screenshotData =
  document.getElementById('flashObject').exportScreenshot();

// Set the screenshot image data as a base64 encoded data URI
// in the img src attribute
document.getElementById('screenshotObject').src = 'data:image/jpeg;base64,'
  + screenshotData;

// Set the screenshot img dimensions to match the Flash object tag.
document.getElementById('screenshotObject').width = flashObject.width;
document.getElementById('screenshotObject').height = flashObject.height;
  
// Move the Flash object off the screen and put the screenshot in it's place
document.getElementById('flashContent').style.top = '-10000px';
document.getElementById('imageContent').style.top = '';

Setting up the hideFlashCallback Functionality

The last step is putting all of this code together and executing it based on the hideFlashCallback callback. To do this, we wrap our JavaScript code (above) into a function called displayFlashScreenshot and create a new method hideFlashScreenshot which will do the reverse: hide our screenshot and then display our Flash Object again. Basically, when a Dialog is opened we want to execute displayFlashScreenshot to display our screenshot and when the Dialog is closed we want to execute hideFlashScreenshot to display our Flash content.

Next we create a new method onFlashHide to handle the open/close state and assign it to the hideFlashCallback parameter in FB.init. In onFlashHide we check the info.state property and then call the corresponding JavaScript method.

JavaScript

function displayFlashScreenshot() {
  // Call the Flash Actionscript method to create the dynamic screenshot data
  var screenshotData =
    document.getElementById('flashObject').exportScreenshot();

  // Set the screenshot image data as a base64 encoded data URI
  // in the img src attribute
  document.getElementById('screenshotObject').src = 'data:image/jpeg;base64,'
    + screenshotData;

  // Set the screenshot img dimensions to match the Flash object tag.
  document.getElementById('screenshotObject').width = flashObject.width;
  document.getElementById('screenshotObject').height = flashObject.height;
        
  // Move the Flash object off the screen and place the screenshot img
  document.getElementById('flashContent').style.top = '-10000px';
  document.getElementById('imageContent').style.top = '';
}

function hideFlashScreenshot() {
  // Move the screenshot img off the screen and place the Flash object
  document.getElementById('flashContent').style.top = '';
  document.getElementById('imageContent').style.top = '-10000px';
}

function onFlashHide(info) {
  if(info.state == 'opened') {
    displayFlashScreenshot();
  } else {
    hideFlashScreenshot();
  }
}

FB.init({
  appId  : 'APP_ID',
  hideFlashCallback : onFlashHide
});

For more information on the hideFlashCallback parameter see the JavaScript SDK Docs.  

Full Source Code for the Example App

Download the source code for the Example App which includes the HTML, JavaScript and ActionScript code referenced in the examples above.

This week, we launched the improved auth dialog and over 60 new Open Graph apps.

Approving Open Graph Actions

We are now approving Open Graph Actions. If you are new to the Open Graph, please review the Tutorial on how to use the Open Graph to integrate your app with Facebook. Please review and check your Actions against the required criteria prior to submission.

Writing Questions via Graph API

We recently announced the ability to read questions via the Graph API. We are now adding the option to write them. To create a question for the current user, issue an HTTP POST to the questions connection like this:

  curl -F 'access_token=...' 
       -F 'question=What is your favorite color?' 
       https://graph.facebook.com/me/questions

Here's a PHP example that shows the optional parameters: options and allow_new_options -- and how to post a question as a Page using its access token:

<?php
  $question = 'What are you doing this weekend?';
  $options = json_encode(array('Hiking','Watching a movie','Hacking'));

  $page_id = 'YOUR_PAGE_ID';
  $app_id = 'YOUR_APP_ID';
  $app_secret = 'YOUR_APP_SECRET';
  $my_url = 'YOUR_URL';

  $code = $_REQUEST["code"];

  echo '<html><body>';

  if (!$code) {
    // manage_pages permissions is required for accounts the user
    // has access to, and posting to the Page
    $dialog_url = "http://www.facebook.com/dialog/oauth?client_id="
     . $app_id . "&redirect_uri=" . urlencode($my_url)
     . "&scope=manage_pages";
    echo('<script>top.location.href="' . $dialog_url . '";</script>');
  } else {
    $token_url = "https://graph.facebook.com/oauth/access_token?client_id="
     . $app_id . "&redirect_uri=" . urlencode($my_url)
     . "&client_secret=" . $app_secret
     . "&code=" . $code;
    $access_token = file_get_contents($token_url);
    $accounts_url = 
         "https://graph.facebook.com/me/accounts?" . $access_token;
    $response = file_get_contents($accounts_url);

    // Parse the return value and get the array of accounts - this is
    // returned in the data[] array.
    $resp_obj = json_decode($response,true);
    $accounts = $resp_obj['data'];

    // Find the access token for the Page
    $page_access_token = '';
    foreach($accounts as $account) {
         if($account['id'] == $page_id) {
           $page_access_token = 'access_token=' . $account['access_token'];
           break;
         }
    }

    // Post the question to the Page
    $post_question_url = 
        "https://graph.facebook.com/" . $page_id . '/questions' .
    "?question=" . urlencode($question) .
    '&options=' . urlencode($options) .
    '&allow_new_options=false' .
    "&method=post&" . $page_access_token;

    echo file_get_contents ($post_question_url);
  }
  echo '</body></html>';
?>

Questions may be removed by issuing an HTTP DELETE to their id. More information is available in the Question documentation, User documentation, and Page documentation.

Subscribe to the Developer and HTML5 blog

We recently built an Email Settings dashboard that lets you easily manage your subscriptions to the Developer and HTML5 blog. To access your email settings, click on the arrow on the top right and select "Email Settings."

Improved Search typeahead on the Dev Site

We want to help you more quickly access the information you need on the Developer Site. The search typeahead now includes Bugs along with Apps and Documentation.

Policy Training Videos

We added two policy training videos to help new developers better understand our Platform Policies and Promotion Guidelines.

Upcoming Breaking Changes

• Removing FeatureLoader JavaScript SDK. As part of the OAuth2 migration, we announced that the FeatureLoader SDK is no longer supported as of October 1st, 2011. On 2/1/2012, we will remove FeatureLoader. Please ensure that your app is using the JS SDK.
• Removing canvas_name Field from Application Object We will be deprecating the canvas_name field in favor of namespace field on the application object on 2/1/2012.
• Removing App Profile Pages We will be deleting all App Profile Pages and redirecting all traffic directly to the App on 2/1/2012. For more information, please refer to the blog post.
• Removing REST support for Ads API We will be removing REST support for the Ads API. All Ads API developer must move their applications to use the Graph API.
• Improved Auth Dialog On February 1, 2012, all apps will be enabled for the improved dialog, but those that haven’t fully configured their dialog can disable the setting in the Developer App until February 15, at which time it will be turned on for all apps.

Please refer to the Platform Roadmap for more info.

Bug Activity from 1/11/12 to 1/17/12

• 310 bugs were reported
• 32 bugs were reproducible and accepted (after duplicates removed)
• 22 bugs were by design
• 26 bugs were fixed
• 115 bugs were duplicate, invalid, or need more information

• Bugs fixed from 1/11/12 to 1/17/12

• Like count doesn't migrate to new page after the migration
• 503 error returned from Object Debugger
• redirect loop in native iPhone application for mobile web (something went wrong)
• The mobile web example application is FUBAR
• Approved status for global reads incompletely deployed
• Go To App link broken on new app pages for Connect apps
• Can’t get the photo id when mail attachment is a photo
• all.js not supporting oauth 2.0
• Can't Create New Facebook Page on My Apps > Settings > Advanced > Contact Info
• Typo in Core Concepts › Graph API › Permissions
• keytool part of JDK, not ADK
• New bug tracker doesn't email when FB employee responds
• Cannot make test users friends
• Send dialog returns a 500 error.
• Javascript Error on Canvas load prevents app from loading in IE8
• Calling FB.login to solicit certain perms seems to invalidate existing token when user hits cancel
• News Feed stats are not being calculated for story type / ref param
• JS Unload event not triggered on FB toaster click
• like feature not working
• Feature Request:L API to read App Namespace
• Real Time Subscriptions does not support feed for pages, documentation states it should
• Comment box style bug
• Linter/Debugger ignores Open Graph Meta-Informations from App-Subpages
• Groups should show which users are not verified
• fbsr_ cookie specifies subdomain
• Mixed content bug for IE on Comments

• Facebook Stack Overflow Activity

  Activity on facebook.stackoverflow.com this week:

  • 244 questions asked
  • 87 answered, 36% answered rate
  • 165 replied, 68% reply rate

At f8, we announced Timeline and the Open Graph - the next generation of the platform which enables people to tell their stories through the apps they use. The Open Graph has already had a significant impact on music, news, and video, but this was just the beginning. Starting today, developers can build apps that let people add anything they love to their Timelines - whether it is eating, traveling, shopping, running or taking pictures.

As a part of the this launch, more than 60 apps are going live today - including Pinterest, Rotten Tomatoes / Flixster, Foodspotting, Gogobot, and more. These are great examples of how the Open Graph brings experiences to Facebook. The developers took things that users already enjoy and made it easy for users to express them on their timeline.

If you are new to Open Graph, please check out the tutorial on how to use the Open Graph to integrate your app with Facebook. If you've already submitted Open Graph actions, we are starting to approve actions that meet our guidelines today, and hope to have all actions previously submitted approved within the next month.

The apps launching today are just starting to demonstrate the types of self-expression that are possible with the Open Graph. There are many more stories to tell and great apps to tell them. Get started today!

Over the past few months, we’ve been testing and iterating on the new Auth Dialog to incorporate feedback from users, developers and other third parties. By introducing new ways for people learn about an app and giving them more control over their data, we believe this update will benefit both users and developers. Today, we’re making the improved version available and announcing the migration plan for developers.

More Control & Clarity for Users Similar to the inline privacy controls people have when they post content, we are introducing a new, inline privacy setting that allows a user to control who can see their app activity on Facebook. With this setting, people can share their app activity with as large or small an audience as they'd like.

We have added headline and description areas, so developers can help people can learn about their apps before installing them. There is also a new area of the dialog to let people know when they're installing a Timeline app, which will share their activity in the app on Facebook. As we've previously described, we encourage developers to carefully consider their users' expectations and whether they should build separate in-app privacy controls.

Optional Permissions It’s important for people to understand how permissions like 'publish_stream' and 'create_events' are used, so we’re moving extended permissions to a second screen, so they’re easier to review, and we’re making them optional for users. With this change, we’re also providing a new area that lets developers explain why they are requesting the optional permissions.

As part of our ongoing efforts to improve privacy protections for Facebook users, we are also deprecating the 'offline_access' permission. Instead, we are providing developers a method to reset the expiration time for valid, existing access tokens when a user interacts with their app.

There are no changes required for most apps, but developers utilizing the 'offline_access' permission will have until May 1, 2012 to update their apps. Learn more about upgrading access tokens.

Authenticated Referrals Along with the new dialog, we are making Authenticated Referrals available to developers. If you're building a social app, where all of your users are Facebook users, this new product will streamline the authentication process. By enabling the feature, the permissions dialog will be displayed inline when people click any link to your app on Facebook, enabling you to personalize people's experiences the moment they arrive at your app.

Implementation & Required Steps The new Auth Dialog is starting to rolling out today for web, mobile and desktop apps. You can start using it in your app by enabling the “Enhanced Auth Dialog” setting in the Developer App. When you upgrade to the new dialog, be sure to also provide a compelling, headline and description via the Developer App and verify that your apps don’t break if users deny optional permissions (see tutorial).

On February 1, 2012, all apps will be enabled for the improved dialog, but those that haven’t fully configured their dialog can disable the setting in the Developer App until February 15, at which time it will be turned on for all apps.

We appreciate the feedback we’ve received during the development of the new dialog over the past few months. If you have any questions or any additional thoughts, please post them to the comments below.

This week, we published a How-To on using ETags with the Graph API, announced increased ticket availability for our upcoming Mobile Hack and launched the following changes:

Improved Comments Box for Mobile

We've updated the Comments Box to optimize the experience for mobile visitors and more closely resemble the mobile Facebook experience.

The social plugin automatically displays the new view based on user agent, but developers can choose to show the classic web view by specifying mobile="false".

Graph API Now Supports Filters for the Home connection

A new parameter filter is now supported by the Graph API Home connection. The Home connection is used to retrieve a user's newsfeed, which can now be filtered via the filter parameter. Supported values are listed in the user's stream_filter table. For more information check out the docs.

Infinite Scrolling for the Apps and Games Dashboard

The Apps and Games Dashboard has been updated to support infinite scrolling for the "Friends Using", "Recommended Games", "Recommended Apps" and "Newest" category tabs. After selecting a tab, users can now continually scroll the list of content to get additional recommendations for great Games and Apps they might be interested in.

Breaking Change: User Support Email is Now Required for Apps

Today we're announcing that the User Support Email field in the Developer App will be required for all apps on April 1st 2012. By setting a support URL and email address developers can utilize both their own help center from their site as well as receive email disputes from the Facebook dispute flow.

The User Support Email field can be updated in the Developer App under Settings > Advanced > Contact Info.

Breaking Changes effective this week

• Request 2.0 Migration: This will be set to enabled on 1/15/2012 for all apps after which only Requests created via the Dialog API or the Graph API will affect the Bookmark Counter. This completes our migration to Request 2.0 from FBML Requests which have become unsupported as of 1/1/2012.
• Requests 2.0 Efficient: The Request 2.0 Efficient migration will be enabled for all apps over the next few days. Please make sure to update your apps now to respect the updated request ID format to avoid any disruption of service. On 1/15/2012 this setting will be set to enabled for all apps. For more information please see the Requests docs.

Breaking Changes effective on February 1, 2012

• Removing canvas_name Field from Application Object We will be deprecating the canvas_name field in favor of namespace field on the application object on 2/1/2012.
• Removing App Profile Pages We will be deleting all App Profile Pages and redirecting all traffic directly to the App on 2/1/2012. For more information, please refer to the blog post.

Bug activity between 1/3 and 1/10

• 268 bugs were reported
• 63 bugs were reproducible and accepted (after duplicates removed)
• 35 bugs were by design
• 25 bugs were fixed
• 116 bugs were duplicate, invalid, or need more information

Reported bugs fixed between 1/3 and 1/10

• Broken link in documentation
• Documentation: event message.send not listed
• Application unable to make wall posts
• Stop beating around the bush with requests
• App Display Name cannot be similar to the name of any apps built by Facebook.
• Style of Facebook Like button is wrong when posting to Facebook
• Top 25 eCommerce Property (gap.com) Being Consistently Blocked by "Like" button Spam Filter
• Feed story throws a fatal when 'ref' params include 'accepted' characters (_/-)
• Syntax Error in all.js
• Javascript error in https://connect.facebook.net/en_US/all.js
• Wrong Information about managing applications via API
• graph api documentation lists FQL field name for birthday
• conflicting statements on login_url validity period
• Documentation Still References Unsupported SDKs
• Created and Subscribed lists do not work properly
• Feed Dialog showing captcha and done with error page.
• Same last name and first name from graph
• Messages sent in Messaging UI are fanned out to WL via XMPP with the same To and From addresses (causes "Someone on Facebook" bug in WL)
• FB.api call to act on actions and objects are not fully documented
• FQL Impression data missing since 10/13
• FB.UI causing "Permission Denied" in IE7/IE8
• Getting "Sorry, something went wrong." when opening a stream.publish dialog in iOS
• Expired fbjs_{app_id} value stops login with new code
• The documentation for open graph read permissions is incorrect
• Open Graph Documentation incorrectly describes og:determiner

Activity on facebook.stackoverflow.com this week

• 141 questions asked
• 59 answered, 42% answered rate
• 99 replied, 70% reply rate

A few weeks ago we announced Mobile Hacks coming to New York and Boston.

Already, many East Coast developers have signed up to attend. We are now releasing additional tickets for these events:

New York on January 18th at the New York Sentry Centers, 730 3rd Ave, New York: Sign up

Boston on January 20th at Le Méridien Cambridge-MIT, 20 Sidney Street, Cambridge: Sign up

At these all-day events you will learn about building social mobile apps and then hack on your own apps. We will cover iOS, Android, and mobile web (HTML5) app development.

Planned Agenda:

• 11:00am - Registration Open + Lunch
• 12:15pm - Facebook Platform on Mobile: Intro
• 12:30pm - Web Apps (HTML5) development
• 1:15pm - Native App development (IOS, Android)
• 2:00pm - Break
• 2:30pm - Native Distribution for Web Apps: Phone Gap
• 3:00pm - Partner presentation
• 3:30pm - Q&A
• 4:30pm - Hack + Dinner
• 9:00pm - App Presentation & Awards
• 10:00pm - Event Close [In Boston Hack will go on until 11pm]

Attendance cost is $25 (free for students at the Boston event) and registration is first-come, first-serve. Awards will be given to the best apps presented at the event.

Imagine if you could only get data from an API when things have changed or there is new data? Well, you do not have to imagine anymore, the Facebook Graph API now supports HTTP ETags. ETags support on the Facebook Platform can help you reduce bandwidth consumption and client-side overhead by suppressing output when making Graph API calls. In addition, clients (especially mobile devices on slow connections) can increase performance and reduce data usage when calling the Graph API with ETags.

This is how it works:

1. When you make a Graph API call, the response header includes ETag with a value that is the hash of the data returned in the API call. Pull this ETag value and use in Step-2.
2. Next time you make the same API call, include the If-None-Match request header with ETag value pulled from step-1 for this API call.
3. If the data hasn’t changed, the response status code would be 304 – Not Modified and no data is returned.
4. If the data has changed since last pull, the data is returned as usual with a new ETag. Pull the new ETag value and use for subsequent calls.

Note: While ETags help reduce the data traffic, the If-None-Match GET will still count against the throttling limits for your app and must not be performed at a frequent rate. We recommend only do it for data that doesn’t change frequently like user’s friends, likes, photo albums, photos etc. Do not use it for news feed, messages etc.

The ETag is calculated using the entire response from the API call including its formatting. Developers should be aware that the formatting of API response output may be impacted by the user agent string. Therefore, calls originating from the same client should keep the user agent consistent between calls.

Example:

Install Firebug and Modify Headers add-ons on Firefox.

Fetching user’s friends: https://graph.facebook.com/me/friends?access_token=<token> returns friends data in JSON output and ETag in the response header. You can quickly test by visiting the Graph API Doc and clicking on the Friends sample link that auto generates access token for the session user and makes this API call.

Next create the If-None-Match request header in the Modify Header add-on tool with the ETag value pulled from the Firebug. Make sure the header is enabled (green lit).

Now call the friend Graph API again - https://graph.facebook.com/me/friends?access_token=<token>. Note that the API returns no data and the status code is ‘304- Not Modified’:

PHP Code Example:

The php code demonstrates ETags while fetching user’s friends. The code pulls the ETag from the response header and then call the same API again while passing the ETag value in the If-None-Match request header. Notice that the response for the second call is 304 – Not Modified.

  <?php

    $app_id = 'YOUR_APP_ID';
    $app_secret = 'YOUR_APP_SECRET';
    $my_url = 'YOUR_REDIRECT_URL';

    $code = $_REQUEST["code"];

    echo '<html><body>';

    // Auth the app using the server side OAuth 2.0
    if(!$code) {
        // get permission from the user to publish to their page.
        $dialog_url = "http://www.facebook.com/dialog/oauth?client_id="
         . $app_id . "&redirect_uri=" . urlencode($my_url);
        echo('<script>top.location.href="' . $dialog_url . '";</script>');
    } else {
        // get access token for the user
        $token_url = "https://graph.facebook.com/oauth/access_token?"
         . "client_id=" . $app_id 
         . "&redirect_uri=" . urlencode($my_url)
         . "&client_secret=" . $app_secret
         . "&code=" . $code;
        $access_token = file_get_contents($token_url);

        // get user's friends now we have the access token
        $friend_url = 'https://graph.facebook.com/me/friends?' . 
                    $access_token;

        // initialize curl if not yet initialized
        if (!$ch) {
          $ch = curl_init();
        }

        /*
         * Disable the 'Expect: 100-continue' behaviour. This causes CURL
         * to wait for 2 seconds if the server does not support this 
         * header.
         */
        curl_setopt($ch, CURLOPT_HTTPHEADER, 'Expect:');
        // set the URL to Graph API URL
        curl_setopt($ch, CURLOPT_URL, $friend_url);
        // we want header in the output
        curl_setopt($ch, CURLOPT_HEADER, true);
        // but do not display the curl output
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        // execute the curl and get the info
        $response = curl_exec($ch);
        $info = curl_getinfo($ch);
        
        // extract the http code, header and body
        $http_code = $info['http_code'];
        $headers = substr($response, 0, $info['header_size']);
        $body = substr($response, -$info['download_content_length']);
        
        // convert header string into an associate array and extract the ETag
        $headers_arr = http_parse_headers($headers);
        $etag = $headers_arr['Etag'];

        echo '<a href="' . $friend_url . '"/>' . $friend_url . 
                '</a/> <br /><br />';
        echo 'HTTP Code: ' . $http_code . '<br />';
        echo 'ETag: ' . $etag . '<br /><br />';

        /*
         * Execute the same API curl call while passing the
         * ETag value in If-None-Match request header
         */
        echo 'Executing the same API call with request header <br/> 
                <b/>If-None-Match: '. $etag . '</b/> 
                returns : <br/><br/>';
        curl_setopt($ch, CURLOPT_HTTPHEADER, array('If-None-Match: ' . 
                    $etag));
        $result = curl_exec($ch);
        $http_code = curl_getinfo( $ch, CURLINFO_HTTP_CODE );

        echo 'HTTP Code: ' . $http_code . '<br />';

        curl_close($ch);

    }
    echo '</body> </html>';

    /*
     * Function to convert header string into associative array
     * Source - http://php.net/manual/en/function.http-parse-headers.php
     */
     
     function http_parse_headers( $header )
     {
        $retVal = array();
        $fields = explode("rn", preg_replace('/x0Dx0A[x09x20]+/', 
                    ' ', $header));
        foreach( $fields as $field ) {
            if( preg_match('/([^:]+): (.+)/m', $field, $match) ) {
                $match[1] = preg_replace('/(?<=^|[x09x20x2D])./e', 
                        'strtoupper("")', strtolower(trim($match[1])));
                if( isset($retVal[$match[1]]) ) {
                    $retVal[$match[1]] = array($retVal[$match[1]], 
                                $match[2]);
                } else {
                    $retVal[$match[1]] = trim($match[2]);
                }
            }
        }
        return $retVal;
     }
  ?>

Sample Code Output:

https://graph.facebook.com/me/friends?access_token=<access_token>

HTTP Code: 200
ETag: "84a290085a1bb6df44534ac017bfed800c407a15"

Executing the same API call with request header If-None-Match: "84a290085a1bb6df44534ac017bfed800c407a15" returns : 

HTTP Code: 304

Facebook gives users the ability to earn virtual currency by completing advertiser offers. For app developers, these offers can be a valuable additional source of revenue by helping them monetize users that may not otherwise pay for virtual currency. Today we’re launching in-app currency offers, which lets developers award users with their own in-app currency (e.g., Fred Currency in Fred's game) upon completing an offer.

Previously, developers were able to integrate Credits offers, where users earned Facebook Credits by completing offers. The new in-app currency offers product is in addition to the Credits offers product, and you can utilize either or both in your app.

In-app currency offers supports both Offerwall and Dealspot. An Offerwall implementation enables your app to open a Facebook dialog with an interactive list of advertiser offers. A DealSpot implementation lets you prominently spotlight one offer. For more details, please refer to our offers documentation.

We hope this new product provides you an additional source of revenue, and we look forward to seeing how you incorporate this new functionality into your apps. Please post your questions and feedback in the comments below.

This past week, we provided an update on our Facebook Platform SDKs, a retrospective of Platform changes in 2011 and launched the following changes:

Stories In Timeline App Tab

Stories published from an app using Feed dialog or Graph API will now show in the app's tab on the user's timeline. This is consistent with Open Graph actions published from an app showing in the app's tab.

Improved Insights for Web Sites

We made two improvements to tracking and reporting Insights for Web sites. We now unpack bit.ly URLs and track and report referrals to the underlying URL. As a result, you will now get accurate referral reporting when you use short bit.ly URLs in Facebook posts. We now also track and report URLs shared and clicked in comments within Insights.

Breaking Changes effective this week

• Requests 2.0 Efficient: The Request 2.0 Efficient migration will be enabled for all apps over the next few days. Please make sure to update your apps now to respect the updated request ID format to avoid any disruption of service. On January 15th this setting will be set to enabled for all apps. For more information please see the Requests docs.
• FB.Canvas.getPageInfo: The getPageInfo method now requires a callback function and no longer returns a value synchronously. For more information on this change please see this blog post.

Upcoming Breaking Changes on February 1, 2012

• Removing canvas_name field from application object: We will be deprecating the canvas_name field in favor of namespace field on the application object. See this blog post for more information.
• Removing App Profile Pages: We will be deleting all App Profile Pages and redirecting all traffic directly to the App. See this blog post for more information.

Bug activity from 12/27 to 1/3

• 131 bugs were reported
• 28 bugs were reproducible and accepted (after duplicates removed)
• 19 bugs were by design
• 12 bugs were fixed
• 56 bugs were duplicate, invalid, or need more information

Reported bugs fixed between 12/27 and 1/3

• Show Stream for Like Box shows only checkins
• max-width of photo incorrectly stated in Graph API doc
• Insights not updating
• Oauth Validation error throws Invalid signed request with Facebook C# SDK
• Broken cross-reference links in Advanced Topics -> FQL -> profile
• migrating old comments
• date_format not applied on all feed story properties
• Feed Dialog Produces Captcha Screens and Always Fails
• Friend's name for test account is missing
• Call to me/friends with a test user no longer returns name,first_name and middle_name fields
• Cannot set custom stream privacy from FB.ui feed dialog
• Requests 2.0 lose the "data" parameter on mobile browsers

Activity on facebook.stackoverflow.com this week

• 133 questions asked
• 47 answered, 35% answered rate
• 74 replied, 56% reply rate

Over the last few weeks, we have had several questions from developers as to which SDKs we support. We wanted to clarify that we provide support for the following:

• JavaScript SDK: source & documentation
• PHP SDK: source & documentation
• iOS SDK: source & documentation
• Android SDK: source & documentation

Please note that we are moving the location of the JavaScript SDK repository from connect-js to facebook-js-sdk and the location of the PHP SDK from php-sdk to facebook-php-sdk. Only the new repositories will be updated moving forward and the old repositories will be made private on April 1, 2012.

Reporting Issues

To report any bugs or issues with any of the above SDKs, please file a report in our Bugs Tool. We apologize for confusion caused by the Issues tabs in GitHub. We do not provide support for this channel and have since removed them from all of our GitHub repositories. We now have a dedicated team of engineers devoted to supporting developers and responding every day to bugs opened via our Bugs Tool

Cookies used by the SDKs

Our JavaScript and PHP SDKs support a common cookie format that allows you to access Facebook Platform from both client and server side code in a seamless fashion. Previously, we documented this cookie format. This resulted in many apps and SDKs taking a dependency on it. We would like to consider this cookie format to be an implementation detail so that we can make changes for security or other reasons, and advise apps not to take a direct dependency on the format. Rather than attempting to parse our cookies, we recommend that you use one of the above supported SDKs or use OAuth endpoints to directly authenticate and authorize users. Our Authentication Guide highlights how to perform authentication and authorization directly.

Deprecated SDKs

Throughout this past year, we have deprecated or removed the below SDKs. The fact that we no longer provide an official Facebook SDK for a given language/runtime, does not mean that you cannot write Facebook apps using those technologies. Rather, all of Facebook Platform (Graph API, Dialogs, etc.) can be accessed from any language or runtime with an HTTP library in a simple and straightforward way. In fact, many of our developers forgo our official SDKs completely and just use HTTP. We are simply deprecating these SDKs based on our need to reduce surface area and provide better support. We have no doubt that the various developer communities will create Facebook SDKs for these platforms over time.

• Python SDK: The Python SDK is deprecated. We intend on making the GitHub repository private on April 1, 2012.
• C# SDK: The C# SDK is deprecated. The GitHub repository will be made private on April 1, 2012.
• Facebook iPhone SDK: This SDK is deprecated and replaced by the iOS SDK. We have made the repository private.

Please leave any questions or feedback in the comments below.

As we near the end of 2011, we wanted to take a moment to recap the highlights from this year. Before doing so, we want to thank you for creating social apps that have delighted millions of users. From games to news, and music, we were excited and impressed by what you created this year. We cannot wait to see what we can build together in 2012.

New Products

We launched many new features that enabled more social and engaging user experiences:

• Comments Plugin and API
• Send Button and Dialog
• Subscribe Button
• New Insights (Distribution, Spam, Credits, and Page)
• Fluid Canvas
• Scores and Achievements API
• Open Graph and Timeline
• Social App Discovery on Mobile

New Tools for Developers

We focused on building new tools to help you develop apps more efficiently:

• Batch requests in Graph API
• New Developer App (with simplified UI, test users UI, groups for managing roles, integrated App Insights)
• Graph API Explorer
• New Bugs Tool
• Partnership with Stack Overflow for Technical Q&A
• Partnership with Heroku for easy hosting of Facebook Apps
• HTML5 Portal
• Rewrote Graph API, FQL, and SDK (JavaScript SDK, PHP SDK, iOS SDK, and Android SDK) documentation.

Transition to a Modern, Secure Platform

2011 was a year that we needed to streamline our Platform to make it more modern and secure. We know these sorts of changes were very painful and impacted many of you, but this was the right move for the ecosystem. We reduced the surface of Platform a great deal, which will enable us to provide better support in the future. These changes included:

• Removed App Directory and App Profile Pages
• Completed Legacy Auth to OAuth 2.0 & HTTPS transition
• Announced removal of FBML
• Announced Graph API parity with and deprecation of REST API

Toward a Stable Platform

Late 2010 we first introduced Operation Developer Love and continued our efforts throughout 2011. We heard loud and clear that developers wanted a more stable Platform. As a result, we made the following changes:

• Beta Tier
• 90 day breaking change policy
• Roadmap, Change Log, Bug Fix Log (found on our weekly updates)
• Redesigned Platform Live Status & API

In the new year we will continue to be focused on growth for your apps and working together to build social experiences for people across the web and mobile devices. Please post your thoughts in the comments below and keep the feedback coming.