UISwitch 调用 Restful API 调用失败,想要恢复 UISwitch 值

发布于 2024-11-18 04:49:08 字数 1102 浏览 3 评论 0原文

我的应用程序是一个 VOIP 电话工具箱。

我有一系列 UISwitch 控件,用户可以使用它们来更改其设置,例如,如果他们想要更改其来电显示设置。

当用户更改设置时,我需要通过其 Restful API 调用电话平台。如果 Restful 调用失败,那么我想将交换机重置回之前的设置。例如,如果用户打开来电显示,并且由于连接失败而失败,我希望开关恢复到关闭状态。

我在 switchChangedValue 方法中实现了这个,但是它创建了一个令人讨厌的循环。当发生故障时,我将 UISwitch 设置为其之前的设置,但它又再次调用 switchChangedValue 方法,该方法失败,依此类推。

这是我的 switchChangedValue 方法的一部分,欢迎任何想法。

//Check if its a valid response from the XSI server
if ([bs getHTTPResponseCode] >= 200 && [bs getHTTPResponseCode] < 300) {
    //This is the successful case       
}
else
{

    // I throw an alert here            

    //Id really like to change the UISwitch back if it goes wrong but it causes a bad loop.     
        if (buttonstate == false){
        [switchbutton setOn:YES animated:YES];
                    //This invokes my switchChangedValue again 

    }
    else if (buttonstate == true){
        [switchbutton setOn:NO animated:YES];
                    //This invokes my switchChangedValue again
    } else{
        NSLog(@"Something went bad");
    }


[bs release];

My application is a VOIP telephony toolbox.

I have a series of UISwitch controls, which the user can use to change their settings, for example if they want to alter their caller id settings.

When the user changes the setting I need to make a call to the Telephony platform over its Restful API. If the Restful call fails, then I would like to reset the switch back to its previous setting. eg If the user turns caller ID on, and it fails because of a connection failure, I would like the switch to revert back to off.

I implemented this in my switchChangedValue method, however it creates a nasty loop. When a failure happens I set the UISwitch to its previous setting, but it in turn calls the switchChangedValue method again, which fails and so on looping

Here is part of my switchChangedValue method, any ideas welcome.

//Check if its a valid response from the XSI server
if ([bs getHTTPResponseCode] >= 200 && [bs getHTTPResponseCode] < 300) {
    //This is the successful case       
}
else
{

    // I throw an alert here            

    //Id really like to change the UISwitch back if it goes wrong but it causes a bad loop.     
        if (buttonstate == false){
        [switchbutton setOn:YES animated:YES];
                    //This invokes my switchChangedValue again 

    }
    else if (buttonstate == true){
        [switchbutton setOn:NO animated:YES];
                    //This invokes my switchChangedValue again
    } else{
        NSLog(@"Something went bad");
    }


[bs release];

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

猫烠⑼条掵仅有一顆心 2024-11-25 04:49:08

您可以尝试这样的操作:

在标头中声明此内容:

BOOL _fireAPICall;

每当初始化您所在的特定类时将其设置为 YES:

- (id)init {
    if (self = [super init]) {
        ...
        _fireAPICall = YES;
        ...
    }
    return self;
}

然后:

if (_fireAPICall) {
    if ([bs getHTTPResponseCode] >= 200 && [bs getHTTPResponseCode] < 300) {
        // success
    } else {
        // failure
        _fireAPICall = NO;
        [switchbutton setOn:!buttonstate animated:YES];
    }
} else {
    _fireAPICall = YES;
    // handle case where switch is turned off if necessary
}

这是假设当用户手动打开时您没有进行 API 调用不过,关闭开关 - 是这样吗?

已在上面更新!

You might try something like this:

Declare this in your header:

BOOL _fireAPICall;

Set it to YES whenever the particular class you're in is initialized:

- (id)init {
    if (self = [super init]) {
        ...
        _fireAPICall = YES;
        ...
    }
    return self;
}

Then:

if (_fireAPICall) {
    if ([bs getHTTPResponseCode] >= 200 && [bs getHTTPResponseCode] < 300) {
        // success
    } else {
        // failure
        _fireAPICall = NO;
        [switchbutton setOn:!buttonstate animated:YES];
    }
} else {
    _fireAPICall = YES;
    // handle case where switch is turned off if necessary
}

This is assuming that you're not making an API call when the user manually turns the switch off, though - is that the case?

Updated above!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文