Home » , » Upgrading from 3.0 to 3.1

Upgrading from 3.0 to 3.1

Written By IWANCIANJUR1 on Kamis, 04 Oktober 2012 | 10.32





There are a few simple - yet important - changes between v3.0 and v3.1 of the Facebook SDK for iOS.
The main purpose of the upgrade is to bring compatibility with iOS v6.0 and its native Facebook support. Using v3.1 of the SDK means that your apps benefit greatly from that support when it is available, but that they automatically fall back to use the previous app-switching or web-based authentication flows on older versions of the operating system.

Additional Framework Dependencies

To benefit from this capability, apps built with v3.1 of the SDK will need to have two new framework dependencies added: 'Accounts', 'AdSupport' and 'Social'. To add these, go to the 'Linked Frameworks and Libraries' section of the project target's Summary pane, and click the 'plus' button to add them:

Note: You should use the 'Optional' flag for iOS6-specific frameworks if you would like your app to also build for older versions of the operating systems.
Once done, your Project Navigator should look something like this:

Asking for Read & Write Permissions Separately

You are now required to request read and publish permission separately (and in that order). Most likely, you will request the read permissions for personalization when the app starts and the user first logs in. Later, if appropriate, your app can request publish permissions when it intends to post data to Facebook.
You cannot request read and publish permissions simultaneously using iOS6's Facebook support, and if you attempt to, the SDK will take the user through a less-optimal app-switching or web-based authentication flow.
Asking for the two types separately also greatly improves the chances that users will grant the publish permissions, since your app will only seek them at the time it needs them, most likely when the user has a stronger intent.
Therefore, if your app previously used v3.0 of the SDK, you will need to remove usage of openActiveSessionWithPermissions:allowLoginUI:completionHandler: and replace it with openActiveSessionWithReadPermissions:allowLoginUI:completionHandler: (or even more simply, openActiveSessionWithAllowLoginUI).
Later, when your app needs to publish back to Facebook, you should use reauthorizeWithPublishPermissions:defaultAudience:completionHandler: to seek the additional permissions.
Similarly, you should update the deprecated reauthorizeWithPermissions:behavior:completionHandler: with its two replacements reauthorizeWithReadPermissions:completionHandler: and reauthorizeWithPublishPermissions:defaultAudience:completionHandler:.
It is important that you do not simply attempt to call the two individual methods back-to-back to replace either of the deprecated functions.

Changes in Handling Facebook Login Cancel Flow

In v3.0, to properly users canceling the authorization flow by clicking on say the device home button you were instructed to add this code to your app delegate's applicationDidBecomeActive: method:
if (FBSession.activeSession.state == FBSessionStateCreatedOpening) {
    [FBSession.activeSession close];
}
In v3.1, remove this logic otherwise you'll see that user's logging in via iOS6 may show a login failure the very first time round. Instead replace the code with the following new method that has been defined in FBSession:
[FBSession.activeSession handleDidBecomeActive];

0 komentar:

Spoiler Untuk lihat komentar yang masuk:

Posting Komentar

Artikel Senggang

 
Copyright © 2012. ARTIKEL SENGGANG . All Rights Reserved.
Company Info | Contact Us | Privacy policy | Term of use | Widget | Advertise with Us | Site map
Template modify by U S Sunda

Welcome In Artikel Senggang

Member Login

Lost your password?

Not a member yet? Sign Up!