9

I have a Video Chat application that I want to disconnect from a call when the device is locked, but stay connected when an SMS, calendar, low battery or any other type of notification is received. The problem is, I cannot figure out for the life of me how to determine what causes my app delegate's applicationWillResignActive selector to be called.

I have thought about implementing some kind of timeout where if applicationDidBecomeActive was not called within a certain number of seconds I would disconnect but that falsely assumes that a user will ignore or accept a received notification within that number of seconds.

Can anyone help me figure out a way to determine what caused the applicationWillResignActive selector to be called?

Many Thanks, Mason

jmason
  • 143
  • 1
  • 7
  • Did you check through all the UIApplication state changes here? http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIApplicationDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intf/UIApplicationDelegate – Luke Jul 21 '11 at 18:06
  • @Luke, Yes I did. I also read through [this](http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/CoreApplication/CoreApplication.html#//apple_ref/doc/uid/TP40007072-CH3-SW10) under the section _Responding to Interruptions_ but was not able to find anything helpful for solving my issue. – jmason Jul 21 '11 at 18:15
  • @Luke Also, when I checked the UIApplicationState in applicationWillResignActive the current state was *UIApplicationStateActive* – jmason Jul 21 '11 at 18:50
  • I am inclined towards the points raised in James' post - if you can disconnect your call when the device is locked & for all other runtime interruptions just keep it running... I would hope that the states covered by UIApplication would suffice. In your own point about applicationDidBecomeActive not being called within a time... you could write some setup code that gets a timeout value from the user when the app is run the first time - not sure how it would roll with Apple though. – Luke Jul 21 '11 at 21:10

2 Answers2

5

I think the short answer may be, that you can't really determine specifically what causes the resign call, however you can only plan according to if it actually goes in the background or not.

Check this link out where it details the steps multitasking takes.

http://www.cocoanetics.com/2010/07/understanding-ios-4-backgrounding-and-delegate-messaging/

Good luck, you seem like an awesome guy!

James Hall
  • 6,469
  • 6
  • 27
  • 28
  • 2
    Indeed you cannot tell specifically what causes the resign call but I did find a work around for my scenario. When a device is locked, AVFoundation stops sending captured frames to one's delegate. So when I am doing video calls, I know the device is locked when I stop receiving new frames after willResign has been called. Thanks James, you _are_ a pretty awesome guy. – jmason Aug 08 '11 at 19:37
0

In my case I was stopping the video capturing on NSNotification.Name.UIApplicationWillResignActive

Now, I'm using the: NSNotification.Name.UIApplicationDidEnterBackground

It isn't triggered when a message comes, or in case someone is calling to the capturing device.

Naloiko Eugene
  • 2,453
  • 1
  • 28
  • 18