In the process of debugging the problem described in
this thread , I have found a troubling variation in the response of some iPhones to an SMS Text Message interruption as it is handled by the built-in SMS Text Message app. This variation seems to be the cause of the problem discussed in that other thread.
Here is what my iPhone 4 does when an SMS Text Message is received:
AppDelegate: applicationWillResignActive. This is called when the SMS alert view asks if I want to dismiss the message or reply right now. My app is still visible behind the alert view, but it is inactive.
I tap on "Reply" to the SMS Text Message.
AppDelegate: applicationDidEnterBackground is called as the SMS Reply window takes over the full screen.
I send the SMS reply, press "Home", and relaunch my app (actually, just bring it out of background).
AppDelegate: applicationWillEnterForeground and applicationDidBecomeActive are both called, and everything is fine.
But, on an iPhone 4 used by a beta tester in Sweden, the sequence is a little different (confirmed by some custom logging in an ad hoc build):
AppDelegate: applicationWillResignActive is called just as before when the SMS alert view becomes active. So far everything is the same.
The user taps on "Reply" to the SMS Text Message. At this point the Swedish phone does something different. The alert view briefly disappears, but before it can be replaced by a full-screen SMS Text Message window, my app gets a:
AppDelegate: applicationDidBecomeActive (what the?)
AppDelegate: applicationWillResignActive (what the?)
AppDelegate: applicationDidEnterBackground
in quick succession. In other words, during the brief interval between when the SMS alert view is tapped and when the full-screen SMS message window takes over, my app is briefly told to go active and then told to go inactive. There seems to be some delay in the SMS Text Message app on this Swedish iPhone 4.
Why is this a problem? Because my app's response to applicationDidBecomeActive is to attempt to resume my Audio Session. But the iPhone is in some strange mode where this is not allowed - probably because the SMS Text Message app did not really intend to allow another app to activate its audio session between the time the first alert view is answered and when the SMS app goes full screen. The result is I get an error return from my AudioSessionSetActive(TRUE) (error = "!cat"), which I dutifully display for the user. I feel like I have been misled by the OS. It tells me I may go active, but then refuses to allow me to do something that active apps are allowed to do.
Can anyone confirm my findings with regard to the sequence of AppDelegate calls that occur when receiving and replying to an SMS text message while your app is running?
SMS Text Interruptions
Linear Mode
