2

我正在发布请求并检查如下错误：

// Send request out on a background thread
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
    [postRequest performRequestWithHandler:^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error) {
        if ([urlResponse statusCode] == 200) {
            NSLog(@"Tweet Successful");
        }else {
            NSLog(@"Tweet Failed");
            if (responseData) {
                //  Use the NSJSONSerialization class to parse the returned JSON
                NSError *jsonError;
                NSArray *requestResponse =
                [NSJSONSerialization JSONObjectWithData:responseData
                                                options:NSJSONReadingMutableLeaves
                                                  error:&jsonError];

                if (requestResponse) {
                    NSLog(@"%@",requestResponse);
                } else {
                    NSLog(@"%@",jsonError);
                }
            }
        }
    }];
});

就请求而言，它似乎工作正常。我的意图是将失败的请求排队并在以后重试，或者不取决于错误以及到目前为止失败的尝试次数。我遇到的问题是我发现它经常出现失败，错误 34“未找到页面”实际上请求确实成功，按预期发布，并且可以在 Twitter 流中清楚地看到。

现在，如果我不能相信返回的错误代码，那么我真的不能继续重试。我如何确定它是成功还是失败？

最近的观察：

最近，我尝试直接从 Apple 照片应用程序发布照片，它向我发送了一条警告，上面写着“推文可能没有成功”。这很有趣，因为这基本上是我在这种情况下唯一的选择。这让我觉得即使是 Apple 也不得不承认，当退货未确认时，无法确定该帖子是否失败。

4

1 回答 1

2

根据在研究此问题时发现的每个示例，除了您正在使用的之外，没有一个使用任何其他 API，并且包括twitter 自己的文档中的这个示例，用于将照片发布到 API，它们都没有首先检查 urlResponse 代码。

似乎做过的最多的是twitter 文档中的这个示例，其中执行了 GET，然后处理了响应。请注意，它首先检查 responseData，如果存在，则将其视为成功。只有在没有 responseData 的情况下才会尝试查看错误。该示例不会打扰 urlResponse ......我在 10 分钟的谷歌搜索中看到的任何其他示例也没有。

（最后，我怀疑这很重要，或者可能是因为您清理了显示的示例，但是当您不执行任何 UI 时，您正在处理主队列上的错误。您可以在处理程序中进行处理立即,并将你所做的任何后处理传递给你试图显示它的任何 UI。我怀疑在主队列中对响应进行后处理,而不是在处理程序的队列中(如这里引用的两个示例所示以及我见过的所有其他示例）确实引起了问题，但我想知道它是否可以减少您看到的误报的发生率。至少，它会使您的响应和响应的任何 UI 显示更清洁，更高效。）

于 2012-09-27T22:16:46.600 回答