Hi folks,

I have feedback from one of my testers that my game quits when he receives (but does not answer) an incoming call.

I'm honouring applicationWillResignActive:


...which is called and responds perfectly when someone presses the sleep button on the iPod.

As far as I'm aware (from reading apple's documentation), an incoming call should call the same method. Is there something else I'm missing?

Is there some other way I can fake the interruption of an incoming call on the iPod?

you need to respond to applicationWillTerminate for all those situations. Incoming calls, home button presses etc. terminate your app so responding to applicationWillTerminate gives you the chance to save your game data (as long as it's done in under 5 seconds).

Zwilnik Wrote:you need to respond to applicationWillTerminate for all those situations. Incoming calls, home button presses etc. terminate your app so responding to applicationWillTerminate gives you the chance to save your game data (as long as it's done in under 5 seconds).

Sure. I'm already doing this. From the Apple's own documentation below, an incoming call (unanswered, as per my original question) causes a call to applicationWillResignActive, and not applicationWillTerminate:

---

1.The system detects an incoming phone call or SMS message, or a calendar event occurs.
2.The system calls your application delegate’s applicationWillResignActive: method. The system also disables the delivery of touch events to your application.
3. The system displays an alert panel with information about the event. The user can choose to ignore the event or respond to it.
4. If the user ignores the event, the system calls your application delegate’s applicationDidBecomeActive: method and resumes the delivery of touch events to your application.
5. If the user responds to the event, instead of ignoring it, the system calls your application delegate’s applicationWillTerminate: method. Your application should terminate as usual, saving any needed contextual information to return the user to the same place in your application upon your next launch.

After terminating your application, the system proceeds to launch the application responsible for the interruption.

If the user presses the Sleep/Wake button on a device while running your application, the system calls your application delegate’s applicationWillResignActive: method, stops the delivery of touch events, and then puts the device to sleep.

---

This makes it sound like tapping the sleep button should cause exactly the same behaviour as an incoming call.

However, it does not. I have an app that crashes/quits on an incoming, unanswered call, but NOT when the user hits the sleep button. I'd greatly appreciate any help in discovering the cause of this discrepancy.

Ah, I missed the word "unanswered" in the OP

Do you still get console output within the applicationWillResignActive function when you're testing with the sleep button tap? If so a few printf's might be worthwhile to try and spot the crash point.

Zwilnik Wrote:Ah, I missed the word "unanswered" in the OP

Do you still get console output within the applicationWillResignActive function when you're testing with the sleep button tap? If so a few printf's might be worthwhile to try and spot the crash point.

Yep - I can debug applicationWillResign on my iPod.

The problem is that I'm getting exits (I don't even know if they're crashes!) on an iPhone that I don't own, and can't test myself. What's baffling is that - as far as I can tell - there should be identical functionality: both applicationWillResignActive.

I'm hoping to personally see it happen on my brother's phone tonight. I'll drag the Mac over and see if I can debug what's happening there...

Curious little problem, this, innit?

It is quite possible that you don't implement touchesCancelled:withEvent: or motionCancelled:withEvent: and you crash because of code that should be called when touchesEnded:withEvent: or motionEnded:withEvent: is never called.

longjumper Wrote:It is quite possible that you don't implement touchesCancelled:withEvent: or motionCancelled:withEvent: and you crash because of code that should be called when touchesEnded:withEvent: or motionEnded:withEvent: is never called.

Well that's certainly true. I'm definitely not creating those.

If it were one of those crashing, would I not see the same issue on the iPod when touching the 'sleep' button?

Hmm.

Okay - found the bug. I had separated my openAL sound stuff into multiple files which rather screwed up calls within the interruption listener I set up here:


I've fixed the problem... I think.

So, how do I test that interruption listener on an iPod?

The sleep button doesn't do it.
The Home button doesn't do it.
Calendar notifications don't do it.

Only incoming calls on an iPhone seem to do it. There must be something else, surely?

If your game allows background iPod music playing and you have the home button double-click set to iPod, you can use it to show the inline control, maybe that will do it?

Setting a timer or alarm with the Clock app should do it (at least I think that's how I tested audio interruptions way back when).

Frank C. Wrote:Setting a timer or alarm with the Clock app should do it (at least I think that's how I tested audio interruptions way back when).

Lovely! I tried a calendar event before and that didn't work. The clock does. Perfectly. I found the bug within about 12 seconds.

Thank you so much. If you're ever around London I'll buy you a beer!