Use of background/foreground methods in AppDelegate

Question

I'm planning to implement multi-task in my app. I can see many methods here to do that in the AppDelegate like applicationWillResignActive, applicationDidEnterBackground, applicationWillEnterForeground, ...

But.... I don't see the way they should be used, nor why they are not in the ViewControllers... Nor what they are here for.

I mean : when the app enter in background, i don't know on which view my user is. And back, when the app comes into foreground, how would I know what to do and what I may call, to update the view for example ?

I would have understood if those methods where in each view controller, but here, I don't see what they can be used for in a concrete way...

Can you help me to understand the way to implement things into those methods ?

Suckling

Answer 1

Each object receive a UIApplicationDidEnterBackgroundNotification notification when the app goes in background. So to run some code when the app goes in background, you just have to listen to that notification where you want :

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

Don't forget to release the listener when you don't need to listen to it anymore :

[[NSNotificationCenter defaultCenter] removeObserver:self];

And best of the best, you can play the same way with the following notifications :

• UIApplicationDidEnterBackgroundNotification
• UIApplicationWillEnterForegroundNotification
• UIApplicationWillResignActiveNotification
• UIApplicationDidBecomeActiveNotification

Suckling

I always forget the name of the notification. It's nice to hop on Stack-Overflow and see it right there! – Mcginn

I think the selector should be appHasGoneInBackground: -- it takes an argument of type NSNotification *. – Ctesiphon

@Greg:Where do you see that ? – Suckling

The documentation for -[NSNotificationCenter addObserver:selector:name:object:] specifies that the selector will be called with an NSNotification * argument. (developer.apple.com/library/mac/#documentation/Cocoa/Reference/…) – Ctesiphon

I can't find these notifications. Are they removed from the newest SDK (iOS7)? – Obvolute

@Alexander it works for me. make sure you aren't dismissing the notification before you call the method – Lucite

Answer 2

They are not in any of your view controllers because iOS adopts a 'delegate' design pattern, where you can be assured that a method will fire upon a class (in this case, the App Delegate for your application) when required.

As a learning process, why don't you just put NSLog's in those methods to see when they're fired?

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
{    

    // Override point for customization after application launch.
    NSLog(@"didFinishLaunchingWithOptions");
    [self.window makeKeyAndVisible];

    return YES;
}


- (void)applicationWillResignActive:(UIApplication *)application 
{
    /*
     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.
     */
    NSLog(@"applicationWillResignActive");
}


- (void)applicationDidEnterBackground:(UIApplication *)application 
{
    /*
     Use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later. 
     If your application supports background execution, called instead of applicationWillTerminate: when the user quits.
     */
    NSLog(@"applicationDidEnterBackground");
}


- (void)applicationWillEnterForeground:(UIApplication *)application 
{
    /*
     Called as part of  transition from the background to the active state: here you can undo many of the changes made on entering the background.
     */
    NSLog(@"applicationWillEnterForeground");
}


- (void)applicationDidBecomeActive:(UIApplication *)application 
{
    /*
     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.
     */
    NSLog(@"applicationDidBecomeActive");
}


- (void)applicationWillTerminate:(UIApplication *)application 
{
    /*
     Called when the application is about to terminate.
     See also applicationDidEnterBackground:.
     */
    NSLog(@"applicationWillTerminate");
}

Shag

I understand when they are fired, what I don't understand is what concretely I would be able to write into these methods as I dont know which is the active ViewController. – Suckling

There is no 'active' view controller, this is OO programming. The better question to ask is; "when one of these methods is fired upon my one-and-only app delegate, how do I ensure important classes know about it?". That, is a design issue and not a programming one. You might for example have Controller objects listening to Notifications fired within those app delegate methods, or you might just pass them to a Controller directly. – Shag

I'm not sure to be ok with you. On my point of view it's really a question about what is actually displayed on the screen. Depending on what the user was doing when such events happens, the way you will manage them will differ. Or perhaps we are just saying the same thing with two different ways. – Suckling