Detecting the type of iPhone interrupt

Question

I can detect that the iPhone went to sleep and came back from sleep, by using the applicationWillResignActive and applicationDidBecomeActive. But how do I find out what kind of interrupt it was. I am making an audio player application, and need to keep the audio playing when the iPhone goes to sleep (which I know how to do). But I need to interrupt the audio when a message, alarm or low battery interrupt occurs. Also I need to resume the audio when the event is over.

So how do I differentiate between these different interrupts.

Answer 1

That information is probably not available to your app, but here's some things to try.

A. In applicationWillResignActive:, check the NSNotification's object and userInfo properties to see if there are any hints there.

B. Register to receive all notifications posted to the default notification center:

[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(didReceiveNotification:)
                                            name:nil
                                          object:nil];

Your method will be called when anything is posted. Log the notification object and userInfo dictionary and maybe you will see a useful notification being posted. If you find one, you can register just for that.

C. This is the most hacky, but you might be able to get access to the alert that is displayed if it is a message or battery warning. Alerts are displayed in a UIWindow over your app's main UIWindow. You could register for UIWindowDidBecomeVisibleNotification, then look at the window's subviews to see if you can find an alert or some other useful clue.

All of the above methods would be relying on undocumented behavior to work, and could possibly get your submission rejected from the App Store. None of them involve private method calls, though you could argue that observing an undocumented notification name counts as private API. In the end, Apple's opinion is the only one that will matter.

Personally, I'd try it, making sure the code fails gracefully if and when the system changes.

Answer 2

Use an audio session?