15

Facebook セッションを開くと、すべてがうまくいき、完了ブロックが呼び出されます。

[FBSession openActiveSessionWithReadPermissions:nil allowLoginUI:allowLoginUI 
completionHandler:^(FBSession *session, FBSessionState state, NSError *error) {
                                             NSLog(@"openSession handler");
                                     }];

ただし、後で追加のアクセス許可を要求すると、新しい完了ブロックだけでなく、両方の完了ブロックが呼び出されます。

    [FBSession.activeSession reauthorizeWithReadPermissions:
    [NSArray arrayWithObject:@"user_photos"] 
completionHandler:^(FBSession *session, NSError *error) {
                    NSLog(@"reauthorize handler");
                }];

これはバグですか、それともこのようになるはずですか? どうすればこの動作を回避できますか? 呼び出し後に完了ブロックを削除することは可能ですか?

Scrumptious サンプルを調べたところ、動作はまったく同じです。アプリが公開許可を要求すると、公開完了ブロックが呼び出され、ログイン ブロックが再度呼び出されます。

iOS5 と Facebook-ios-sdk 3.1.1 でテストしています

4

2 に答える 2

5

API の Facebook のドキュメントから収集できたものから、これは意図された動作です (良い設計ではありませんが、それは別の話です)。

completionHandler パラメータの説明のスニペット:

「... FBSession オブジェクトは、セッションの状態が変わるたびにブロックを呼び出します」

解決策を提供することはできませんが、回避策を提供できます。

// <Your description of why the workaround is needed.
//
// REF: http://stackoverflow.com/questions/12751635/facebook-ios-sdk-3-1-1-fbsession-completionhandler-not-removed
//
__block BOOL workaroundOneTimeRunFlag = NO;

[FBSession openActiveSessionWithReadPermissions:nil allowLoginUI:allowLoginUI completionHandler:^(FBSession *session, FBSessionState state, NSError *error)
{
    if (!workaroundOneTimeRunFlag)
    {
        workaroundOneTimeRunFlag = YES;

        // Your handler was executed for the first time
        // Run some code...
    }
}];
于 2012-12-15T17:45:06.603 に答える
3

これはバグではなく、どちらのハンドラーも SDK によって意図的に呼び出されます。docsに記載されているように、openActiveSession へのハンドラーは、セッション状態の変更が発生するたびに呼び出されます。追加の権限を要求すると、状態が FBSessionStateTokenExtended に変更されます。したがって、最初のハンドラーが呼び出され、次に reauthorizeWithReadPermissions で指定した明示的なハンドラーが呼び出されます。

于 2012-10-09T20:17:48.400 に答える