Aug 2012 Update:
iOS 5 and greater have introduced safer APIs for doing things after modals have animated into / out of place using completion blocks:
[self presentViewController:myModalVC animated:YES completion:^{}];
[self dismissViewControllerAnimated:YES completion:^{}];
Pre-Aug 2012 Answer:
I encountered a similar problem when dismissing modal one and then presenting modal two in rapid succession. Sometimes modal two would show after the modal one was dismissed and sometimes modal two wouldn't appear at all and that made me very sad.
Looks like a race condition to me...
Putting a 1+ second delay on the caller of the method that presented modal two, showModalTwo, made modal two appear every time after modal one was dismissed:
- (void)didDismissModalOne {
[self performSelector:@selector(showModalTwo:)
withObject:someNumber
afterDelay:1.0f];
}
This confirmed a suspicion that there was some sort of race condition between the dismissal of modal one and the presentation of modal two. Putting a delay on the caller, however, is inelegant and did not guarantee that the race condition wouldn't re-appear under other circumstances.
The problem
Turns out that UIViewControllers have a public property, modalViewController, that gets set up when presentModalViewController:animated: is called and torn down when dismissModalViewControllerAnimated: is called. The catch is that it doesn't get torn down synchronously, so it's possible to create a race between removing the old value of modalViewController and setting up a new value in the following way.
- Present modal one.
myViewController.modalViewController now points to modal one
- Dismiss modal one. Background process to tear down
myViewController.modalViewController has started, but myViewController.modalViewController the still points to modal one
- Present modal two,
myViewController.modalViewController] now points to modal two
- System callback fires, setting
myViewController.modalViewController to nil, this interrupts the process of modal two animating in and the result is the user never sees it.
The race starts on step 2 and manifests on step 4.
The solution
My solution was to put a guard condition on the method that presented modal two to ensure that myViewControoler.modalViewController was nil before attempting to present modal two.
-(void)showModalTwo:(NSNumber *)aParameter {
if (self.modalViewController) {
[self performSelector:@selector(showModalTwo:)
withObject:aParameter
afterDelay:0.1f];
return;
}
// You can now present the second modal safely.
}
Worked like a charm. A more elegant solution might include a timeout.
Post script
I really didn't like the polling aspect of this solution. @Nimrod suggests, in the accepted answer to this question, that you can safely initiate the presentation of modal two from the viewDidDisappear: method of modal one. I liked the sound of this event driven approach, but after doing a full implementation in my use case I confirmed that the race condition persisted when presenting modal two using a callback inside viewDidDisappear:. The only way to be absolutely sure that modal two will be presented is to poll inside the parent view controller until you're absolutely sure that self.modalViewController is nil. Then and only then is it "safe" to pop modal two.
Best Solution
Correct me if I'm wrong, but UIImage does not conform to NSCopying, therefore you can't successfully copy it.
What you probably want to do is retain the image. If self.currentpicture is a 'retain' property, it will automatically release the previous object and retain the new one, so just do this:
Otherwise do it yourself:
In both cases you still have to call [self.currentpicture release] when you no longer need the image. Usually you would do that in the 'self' object's dealloc method.