I had a similar problem.
Let's say I wanted to execute a loop of things that must be done sequentially
for (int i=0; i< 100; i++){
if (i==50){
<do some stuff and show alert>
}
}
Coming from the Java world, I was trying to figure out how to lock/unlock or synchronize the alert on a GUI/event thread. The closest that we get to that is really performSelectorOnMainThread: which manages to lock the GUI up where we expect it to do something. Creating a @synchronized block, using an NSLock, or NSConditionLock are also useless for this problem. But since I have to look into these low-level details, it just leaves a bad taste in my mouth for how crude and/or lacking the API really is. Since the UIAlertView really is asynchronous, the loop continues on.
There are people out there who will assume you haven't read the manual, don't know what you're doing, or tell you "its not the Apple way", but really at the end of the day we all just want to get our little bit of code working the way we expect it to, and your expectations are not unreasonable. The API for doing so is sometimes unwieldy, so you can (and will) write a lot of wrappers for methods that you will reuse in a "default" way.
Personally, I'd hope for a more elegant solution from Apple similar to the BlockingQueue approach in java.util.concurrent that you could push/pop operations and GUI and non-gui objects in a more sequential manner.
I understand your frustration and wanted to get this done myself, so I will explain what I did. I had to partition the loop that I wanted to do things in, where effectively the modal dialog (alert) became the logical "pivot".
I broke the original problem up into
for (int i=0; i<51; i++){
// Do stuff
}
// Show alert..
for (int i=51; i< 100){
// Do more stuff
}
I implemented a protocol that I made up called Command, that implement instance methods executeBeforeAlert for the first half of the problem, and executeAfterAlert for the second half of the problem.
I created another class called LoopAlertView that takes a Command, and calls
[command executeAfterAlert] in the alertView:clickedButtonAtIndex.
This gave me effectively the behavior that I wanted -- blocking on an operation until the dialog is dismissed.
