UIActionSheet taking long time to respond

Question

I am creating a UIActionSheet on actionSheet:clickedButtonAtIndex delegate method.

- (void)actionSheet:(UIActionSheet *)actionSheet clickedButtonAtIndex:(NSInteger)buttonIndex     
 if(buttonIndex == 1){

        [self.myFirstView removeFromSuperview]; 

        if (!self.mySecondView) {
            [[NSBundle mainBundle] loadNibNamed:@"MySecondView" owner:self options:nil];
        }
        [self.mySecondView setFrame:CGRectMake(0, 0, 320, 480)];

        [[UIApplication sharedApplication].keyWindow addSubview: self.mySecondView];

        UIActionSheet * action = [[UIActionSheet alloc]initWithTitle:@""
                                                            delegate:self
                                                   cancelButtonTitle: nil
                                              destructiveButtonTitle: deleteContacts
                                                   otherButtonTitles: cancel, nil];
        action.tag = 102;
        [action showInView:self.view];
        [action release];

    }

I handle the click event of this UIActionSheet in the exact same method as above.

if(actionSheet.tag == 102){

    if(buttonIndex == 0){
        if([[NSBundle mainBundle] loadNibNamed:@"MyThirdView" owner:self options:nil]) { 
            [self.myThirdView setFrame:CGRectMake(0, 0, 320, 480)];
            [[UIApplication sharedApplication].keyWindow addSubview:self.myThirdView];
        }
        [self.mySecondView removeFromSuperview]; 

        [self.doneButton.target performSelector:self.doneButton.action withObject:self.doneButton.target];

        [self performSelector:@selector(RemoveView) withObject:self afterDelay:3.0];

    }
}

The problem I am facing is that, the UIActionSheet takes too much time to respond. When I click on the UIActionSheet button, its in a frozen state for 2 or 3 seconds, before myThirdView loads. I am not able to understand, whats the response delay in this case as the first thing I do in the UIActionSheet button click event method is to load myThirdView. The rest of the code is executed only after the code to load the myThirdView. But even the first line of code seems to execute after a delay. Any suggestions?

Crosswise

does it work when you change [action showInView:self.view]; to [action showInView:self.mySecondView]; ? – Waterhouse

It works. But no significant change in response speed of action sheet. – Crosswise

I think the right answer should be combining the answers of The Saad and Andrew Zimmer. The code that should be running on the background thread is this line of code [self.doneButton.target performSelector:self.doneButton.action withObject:self.doneButton];. The rest of the code including the RemoveView method should be running on the main thread. Special mention to Gabriel for simulating a button touch action. – Crosswise

First, I'm an anti-ARC coder myself, so I have some tips. Second, I'm kinda edgy about the way you wrote navigation, it looks messy but I can't give any suggestions with this minimal viewpoint. Tiptime: 1st, breakpoints to see what thread stuff is happening with. 2: performSelectorOnMainThread instead of performSelector. 3: Don't release the UIActionSheet until after callbacks are executed. 4: Ensure "self" still exists. 5: use breakpoints and step-thru to measure speed of handling functions – Septillion

Answer 1

Question. Does the UIActionSheet freeze, or does it disappear and the 3rd view isn't visible for 2-3 seconds?

This could be due to 1 of 2 problems.

1. If the entire action sheet freezes, then you are doing some heavy lifting when you init that 3rd view, you are loading some core data, or a lot of assets, or something that is taking a long time. If this is the case, you'll need to reformat HOW you load that 3rd view. I'd suggest pushing any heavy loading to the background (this means if you have a lot of images in your xib, you may need to load them in code).

2. The other possibility, is you are adding the 3rd view BELOW the 2nd view, and then not hiding the 2nd view for 3 seconds (done by performing the selector with a delay). If this is the case, simply remove the delay.

I made a couple of classes to help me time executions and find the bottlenecks in my code, it seems like they might help you now. http://forrst.com/posts/Code_Execution_Timer_for_iOS_Development-dSJ

Factor

Answer 2

this is perhaps due to this

[self performSelector:@selector(RemoveView) withObject:self afterDelay:3.0];

make an other methods and do this in that method. like this

[self viewRemover];

and in viewRemover

-(void) viewRemover
{
    [self performSelector:@selector(RemoveView) withObject:self afterDelay:3.0];

}

so your code will be like this now

if(actionSheet.tag == 102){

    if(buttonIndex == 0){
        if([[NSBundle mainBundle] loadNibNamed:@"MyThirdView" owner:self options:nil]) { 
            [self.myThirdView setFrame:CGRectMake(0, 0, 320, 480)];
            [[UIApplication sharedApplication].keyWindow addSubview:self.myThirdView];
        }
        [self.mySecondView removeFromSuperview]; 

        [self.doneButton.target performSelector:self.doneButton.action withObject:self.doneButton.target];

    [self performSelectorInBackground:@selector(viewRemover) withObject:nil];

    }
}

Jestude

While debugging, the control doesn't enter the RemoveView method. Maybe it has something to do with withObject:nil in self performSelectorInBackground. Anyways the delay problem is still not sorted. – Crosswise

Oh and btw, if viewRemover is editing visible objects on the screen, DON'T do it in a background thread. This causes intermittent problems, not fun to debug. – Factor

Answer 3

User interface actions run in the main thread and only occur when your method ends. So, MyThirdView will not appear until the other instructions have finished. The only thing I can figure is delaying that is:

[self.doneButton.target performSelector:self.doneButton.action withObject:self.doneButton.target];

If you are doing any heavy calculation or net conection, for sure that is the reason.

OTOH, I think you'd better modify that line:

[self.doneButton.target performSelector:self.doneButton.action withObject:self.doneButton];

if you want to simulate a button touch action.

Dynatron

No significant difference made. – Crosswise

Answer 4

How big is your third view. if the nib file needs to load too much, you may be waiting for a lot to happen, also if you have to change some UI elements and your blocking the UI thread, you will hault your app until a timeout occurs and the app will shift some things to compensate..

the route I take with this is dispatch_async and dispatch_sync

// This will release the UI thread which may be blocking your calls.
// You can use any of the DISPATCH_QUEUE_PRIORITY_.... values to set how important this block is.
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
    // this command will get added to the stack and return without a hitch.
    // the block will be run the next time the main runloop ends.
    dispatch_async(dispatch_get_main_queue(), ^{
        // do some UI work that can happen without a hitch, and does not impact the calling block
    });

    // this command will act much the same. but will pause the background execution 
    // of this block until the runloop has executed this and returned.
    dispatch_sync(dispatch_get_main_queue(), ^{
        // do some UI work that must be completed to continue.
    });

});

doing too much in the UI thread will pause the execution of things that get stacked on the queue. Shipping all code to the background thread and only skipping to the UI thread when you need to alter the UI is a better and more responsive way to code your iphone app.

I hope this helps :)

Irrelevant

This block of code has been a life saver for me. MAKE SURE TO NOT PASS AUTORELEASE OBJECTS TO IT. Since it's a block, sometimes you feel like you can. – Factor

I am currently using arc. But I believe the block retains and releases the objects it has a hold on all by itself. Does it not ?? – Irrelevant

I'm not sure if it does when you are using ARC, so you might be fine. Passing autoreleased objects between threads is rather disastrous if you aren't on ARC though. I've been burned by this in the past. – Factor

but a block is not quite a thread. the block freezes the current objects that are used across them. handling the retain and release itself. using dispatch you should be ok. as long as the block is created while the objects are still alive. – Irrelevant

Hmm, looking elsewhere it seems that you are correct. I wonder what cause all those object released crashes.. Maybe because the object was outside of the scope of the method? Related: #4984229 – Factor

Answer 5

in Swift 4: I wrapped the code with this block

DispatchQueue.main.async {

// your code to show action sheet.

}

for example

DispatchQueue.main.async {

            let alert = UIAlertController(title: "Options", message: String("What do want to do?"), preferredStyle: UIAlertController.Style.actionSheet)

            alert.addAction(UIAlertAction(title: "Open", style: UIAlertAction.Style.default, handler: {(action:UIAlertAction!) in
                self.myOpen(code: self.codes[indexPath.row])
            }))
            alert.addAction(UIAlertAction(title: "Delete", style: UIAlertAction.Style.default, handler: {(action:UIAlertAction!) in
                self.myDelete(indexPath: indexPath)
            }))
            alert.addAction(UIAlertAction(title: "Cancel", style: UIAlertAction.Style.default, handler: {(action:UIAlertAction!) in
                print("Cancel")
            }))

            self.present(alert, animated: true, completion: nil)

        }

Nixie