title: UIAlertViewDelegate method didDismissWithButtonIndex gets called while the phone is sleeping/locked
body: <p>I have a UIAlertView who's didDismissWithButtonIndex delegate method calls pops the view controller (same class, it's the alertview delegate and the viewcontroller) to return the user to the previous screen. The issue is that when you lock the phone before the [alert show]; is called, <strong>something</strong> is calling didDismissWithButtonIndex while the phone is locked. Since the response to that is to pop the view controller, which releases and deallocs it, I crash on the callback.</p>
  
  <p>What is causing this phantom button press? Seems like a framework bug, but I hate jumping to that conclusion. I'm definitely not hitting the button, because I hit a breakpoint in my code right before it's displayed. Then I lock the phone. Then I continue. I see it do the show, return to the event loop, and then, while the phone is still locked, hit my breakpoint in didDismissWithButtonIndex. There are a few internet/forum postings about similar spurious delegate calls, but no concrete answers. </p>
  
  <p>This is on the simulator, and the device, both OS 2.2 and OS 3.0. I'm assuming I'm missing something, but what?</p>
  
  <p>Update: Yeah, I created a simple project with just two view controllers, where when the 2nd view controller displays it creates the alert, and shows it. Then I NSLog in the delegate method, and when the phone is locked, it fires once while locked, and then again when it's unlocked and the button is clicked...2 log messages. But when not locked, there's only one.</p>
  
  <p>I guess I'll open an issue, but it seems awfully obvious to have survived this long without anyone complaining. :-) I'm going to try and work around it by making an isActive flag value when the willResignActive/didBecomeActive notifications arrive, and if the app isn't active skipping the delegate body.</p>
  
  <p><strong>Update</strong> I went ahead in July after I posted this and created radar 7097363 for this issue. There's been no response.</p>
  
  <p>The workaround in practice works quite well, checking the active status when processing the delegate, and skipping the action if the the app is inactive.</p>