iOS Calling methods from separate views

[HarryWorksInc]

I have an game in which when the user accepts a phone call or gets a text-message or ect. I want to pause the game. In the App Delegate my GameView Controller are accessed as so:

[B] .h file [/B]
#import <UIKit/UIKit.h>

@class MainViewController;
@class GameViewController;

@interface StarFighterAppDelegate : NSObject <UIApplicationDelegate> {
    UIWindow *window;
    MainViewController *mainViewController;
    GameViewController *gameViewController;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet MainViewController *mainViewController;
@property (nonatomic, retain) IBOutlet GameViewController *gameViewController;

@end 
[B] .m file [/B] 
- (void)applicationWillResignActive:(UIApplication *)application {  // Need!!!!!!!!
    /*
     Sent when the application is about to move from active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message) or when the user quits the application and it begins the transition to the background state.
     Use this method to pause ongoing tasks, disable timers, and throttle down OpenGL ES frame rates. Games should use this method to pause the game.
     */
	
	[gameViewController PauseAction];
}

- (void)applicationDidBecomeActive:(UIApplication *)application {  // Need!!!!!!!!
    /*
     Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.
     */
	
	[gameViewController PlayAction];
}

but this isn't working. Their are no errors but this doesn't do anything. Can somebody help?

 

[chown33]

Instead of just blindly hoping this works, add some NSLogs and collect a chain of evidence that what you think should be happening is, in fact, happening.

That would include an NSLog in each of the methods shown, which will confirm the method is called (or not).

It would also include testing whether the ivars are nil or not, and if non-nil, whether the objects in question are the actual objects that are in control.

If you discover a break in the chain of expected evidence, say an NSLog does not appear or the output is not as expected, then you know where to focus your attention. If all the expected evidence appears, however, then you at least have some evidence you can post, and the code to go with it.

This is a basic debugging skill: break the problem into separate parts, each of which must demonstrate (with tangible evidence) that it is occurring at the correct place, and with the correct data, in the overall sequence.