Minimize didFinishLaunchingWithOptions Processes on launchOptionsLocation key discovery?

Question

I have location processing newly implemented in my app, testing in foreground and background with satisfactory results. The application is monitoring significant location changes as well as several regions. I have not yet figured out if I will get the same results when the app is suspended or terminated. As I understand it, when the app is woken from these states it will be as if the app just started except the launchOptionsLocation key will be found in the launchOptions Dictionary param. My question is, can I allow the app delegate to proceed as normal and assume all is well? Is it necessary to intercept all the view setup code?

The very first lines in my didFinishLaunchingWithOptions:launchOptions method are:

NSManagedObjectContext *context = [self managedObjectContext];
if (!context) {
    //Handle Error
}

self.sharedLocationHandler = [[[TTLocationHandler alloc] init] autorelease];
self.siteLogger = [[[ProjectSiteLogger alloc] initWithOptions:nil] autorelease];
self.siteLogger.locationHandler = self.sharedLocationHandler;
self.siteLogger.managedObjectContext = context;

In all likelihood, this covers all that I need in order to respond to the location event. I could easily test for the location key in launchOptions and skip the entire remainder of the method, though I am not sure what unforeseen complications that may entail. I also question what would result then if a user happened to start the app intentionally while it was in that incomplete state having no views set up at all.

Is this something that has been tried, is it even necessary at all? I don't see how to test this as I don't know of a way to stay connected to Xcode debugger when the app is suspended.

---Additional Updated Info----

Initial testing on a day of carrying test phone around, my location processing seemed to do all the tasks I wanted it to with no changes to appDelegate. So I presume that wake from suspend/term came up and executed the full appDelegate procedure even though no view controllers ever became visible. So, while it seems that it is not required to alter the startup procedures, may there still be a performance or battery concern that would make it prudent to cut the appDelegate procedure short and minimize processing?

Answer 1

After a good bit of testing and tweaking I find:

1. The app will wake from inactive or termed with no issues.
2. My location methods ran and completed regardless of the changes to the App Delegate.
3. When I cut the app delegate processes short, I did have intermittent start issues as anticipated.

Even though there were no apparent performance benefits, I went ahead and separated out the view setup code and added a flag so that it would not be run unless the application was being presented in the foreground. It just seems right to run no more processing than needed. The code I ended up with is:

// Initialize a flag
BOOL needsViewsSetup = YES;

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{
    // All my response to location events are handled in the these two classes
    self.sharedLocationHandler = [[[TTLocationHandler alloc] init] autorelease];
    self.siteLogger = [[[ProjectSiteLogger alloc] initWithOptions:nil] autorelease];
    self.siteLogger.locationHandler = self.sharedLocationHandler;
    self.siteLogger.managedObjectContext = self.managedObjectContext;

    // check launchOptions, skip all the views if there we were woken by location event
    if (![launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey]) {
        [self confirmDataExistsAtStartup];
        [self setupTabbarWithViews];
    }

    return YES; 
}

Then you have the views setup:

-(void)setupTabbarsWithViews 
{
    // Code to setup initial views here

    // ending with flag toggle to prevent repeat processing
    needsViewsSetup = NO;
}

And in application will enter foreground:

- (void)applicationWillEnterForeground:(UIApplication *)application
{
        if (needsViewsSetup) {
           [self setupTabbarWithViews]; 
        }
}

Note: My application is not running location services in the background, only listening for significant location changes and geofence.