SDK 3.1：如何判断SDK是否使用iOS6帐户？ [英] SDK 3.1: How to tell whether SDK is using iOS6 accounts or not?

问题描述

如果我在iOS6中设置了Facebook帐户但是用户已将其关闭，那么SDK只会给我一个FBSessionStateClosedLoginFailed状态。从那时起，我无法判断用户是否已在iOS中关闭我们（案例1）或者没有在iOS中设置帐户并拒绝FB应用程序或Web应用程序（案例2）的许可。

If I have a Facebook account set up in iOS6 but the user has switched it off, the SDK just gives me a FBSessionStateClosedLoginFailed status. From that, I can't tell if the user has switched us off in iOS (case 1) or doesn't have an account set up in iOS and declined permission from the FB app or web app (case 2).

我需要提供的错误消息在两种情况下完全不同。在第一种情况下，我们需要告诉用户如何重新启用我们，但这些说明会让案例2中的某些人感到困惑。

The error messages I need to present are quite different in the two cases. In the first case, we need to tell the user how to switch us back on, but those instructions would be confusing for someone in case 2.

我尝试使用iOS帐户框架，但如果我关闭，我被告知即使有，也没有Facebook帐户。如果我成功进行身份验证，我还尝试写下帐户标识符，但如果我们关闭，accountWithIdentifier会失败。

I tried using the iOS Accounts framework, but if I'm switched off, I'm told there ARE no Facebook accounts even if there are. I also tried writing down the account identifier if I ever successfully authenticate, but accountWithIdentifier fails similarly if we are switched off.

任何人都知道如何找出我们的拒绝来自iOS或FB本身？

Anybody know of a way to find out if our rejection is coming from iOS or FB itself?

推荐答案

SDK的政策一般是如果某些操作正在进行中如果失败，来自操作系统的基础错误信息会冒泡到应用程序。 （当然并非所有失败案例都以OS API失败开始。）此策略的原因是支持更精确的错误处理和日志记录方案，如您所描述的方案。顺便说一句，如果你在SDK中找到一个不遵循这种模式的地方，那就是一个错误，请报告它。

The policy of the SDK in general is that if some operation is in the process of failing, the underlying error information from the OS is bubbled up to the app. (Of course not all failure cases start with an OS API failing.) The reason for this policy is to support more precise error handling and logging scenarios like the one that you describe. As an aside, if you ever find a place in the SDK that does not follow this pattern, it is a bug and please report it.

在这种情况下，FBSession正在传递处理程序的NSError对象，它将userInfo中的FBErrorInnerErrorKey值设置为OS返回的错误对象。为了向您的用户提供精确的错误消息，您可以在FBSessionStateClosedLoginFailed案例中使用这样的代码片段：

In this case FBSession is passing an NSError object to your handler, and it sets the FBErrorInnerErrorKey value in the userInfo to the error object returned by the OS. In order to provide a precise error message to your user, you can use a snippet of code like this in your FBSessionStateClosedLoginFailed case:

if (error) {
    NSError *innerError = error.userInfo[FBErrorInnerErrorKey];
    if ([innerError.domain isEqualToString:ACErrorDomain] &&
        innerError.code == ACErrorPermissionDenied) {
        NSLog(@"User dissallowed permissions via iOS 6.0 integration");
    }
}

希望这会有所帮助！

*更新*
刚在设备上试过这个并发现了两个错误;一个在iOS 6.0中，另一个在SDK中。 iOS 6.0的错误是当关闭开关时，操作系统不会传递NSError对象，因此没有内部错误。因此，使上述的一般解决方案不适用于所讨论的特定情况。第二个错误确实为您提供了使用SDK 3.1.1解决此问题的临时解决方案。

SDK 3.1.1中的错误是我们将error.userInfo [FBErrorLoginFailedReason]设置为FBErrorLoginFailedReason的值。在内部错误为NIL的情况下，您可以检查此原因值以确定应用程序的滑块设置为关闭。当在SDK中修复此错误时，对此的代码测试将会中断，因为我们将原因设置为与iOS 6相关的更合理的原因。这是在未来的构建中需要注意的问题。你的申请，如果你决定依赖这个价值。

The bug in the SDK 3.1.1 is that we set error.userInfo[FBErrorLoginFailedReason] to the value of FBErrorLoginFailedReason. In the case where the inner error is NIL, you can check for this reason value to determine that the slider for the app was set to off. When this bug is fixed in the SDK, then the code testing for this will break, however, since we will be setting the reason to a more logical reason related to iOS 6. This is a gotcha to watch out for in a future build of your application, if you decide to rely on this value.

这篇关于SDK 3.1：如何判断SDK是否使用iOS6帐户？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！