CODEWITHSUNDEEP
iosbackgroundmultitasking
NewXcoder
NewXcoder

Reputation: 715

Can I detect what cause the "applicationWillResignActive" calling?

I know "applicationWillResignActive" will be called when you tap the Home button or the Sleep/Wake button. And it is also called when an interruption(like a native call) occurs. But how can I indentify which one result in this method and do some different implement?

Upvotes: 1

Views: 1127

Answers (1)

J_D
J_D

Reputation: 3596

You cannot directly identify all reasons, but you can narrow it down a little bit.

If the home button is pressed and the application is sent to background, your app will receive a applicationDidEnterBackground: call on your UIApplicationDelegate. Note that you will receive this after the applicationWillResignActive: call, so it may not help you.

You could also register a listener for Audio Interruption 

AudioSessionInitialize (
                        NULL,                          // 'NULL' to use the default (main) run loop
                        NULL,                          // 'NULL' to use the default run loop mode
                        audioSessionInteruptionListener,  // a reference to your interruption callback
                        self                       // data to pass to your interruption listener callback
                        );

If audioSessionInteruptionListener is invoked and the state is kAudioSessionBeginInterruption before applicationWillResignActive:, then you know that the interruption is caused by a Phone Call or the Alarm. I do not think that you can have more information.

EDIT

Actually, I think that you can go even a little further and identify a Phone Call vs Alarm interruption. Now this has not been tested, it is simply to give a starting point for more investigation.

I remember having a callback registered to trap audio routes, and when a phone call was received, the audio routed changed from Speaker/Earphone to None to Receiver. So I guess that you could trap the AudioInterruption using the method descrived above, and trap the audio route change. If the audio route becomes Receiver, then the interruption was a phone call. Otherwise, it was something else, like the alarm.

I was targetting iOS 5.0, so it may not be available for prior versions, you would have to confirm with the doc.

Upvotes: 4

Related Questions