iPhone version - 5.1 (9B176)
Below is the series of events during Local Notification where in which didFinishLaunchingWithOptions
method is not invoked.
You are correct. The behavior is inconsistent with the documentation. Putting the documentation aside and focusing on actual behavior; The crux of the matter seems to be this: If your app becomes active by the user interacting with the notification you will receive a pointer to the notification, if the user taps your application icon directly you will not.
To illustrate. If you present an alert style notification and the user taps the action button, or if, as in your case, you present a banner notification and the user taps on that you will receive a pointer to the notification in one of two ways:
If your application was in the Not-Running state:
-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{
UILocalNotification *launchNote = [launchOptions objectForKey:UIApplicationLaunchOptionsLocalNotificationKey];
if (launchNote){
// I recieved a notification while not running
}
}
If your application is running in any state:
-(void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification{
// I recieved a notification
}
In the case where a user elects to cancel an alert style notification, that notification is gone.
The truly annoying an inconsistent part is that if you present a banner notification and the user taps your icon you seem to have no way of retrieving a reference to the presented notifications in the notification center. i.e. they do not appear in the [[UIApplication sharedApplication] scheduledLocalNotifications]
array, presumably because they are no longer scheduled but are now presented.
So in short; The documentation is wrong. And there are other annoying inconsistencies. If this behavior is a problem for you you should file a bug with Apple.