views:

93

answers:

1

I am developing an application that, because I can't use a custom time interval to schedule local notifications, has to create N local notifications to simulate a timed schedule. The application does this once for every X objects (let's call them calendar events for now). So a user can have 100 calendar events, each with 20 local notifications to remind the user once every few minutes/days/weeks/whatever.

Here's where it gets tricky: Let's say one of those notifications goes off 2 minutes from now, and one goes off 3 minutes from now. Say I ignore the first one, but tap the action button to go to the application on the second one. My handler method didFinishLaunchingWithOptions:in the application delegate is not being called; the application goes straight to the home screen. The only way I can seem to get a method to respond to the application being loaded in this manner is with applicationDidBecomeActive:.

How can I handle these notifications? Even within applicationDidBecomeActive:, I can't access the notifications through [[UIApplication sharedApplication] scheduledLocalNotifications] because they seem to be cleared before that method is called.

Thanks!

A: 

Hi Jason,

Few things to note:

Maximum number of UILocalNotification

You gave the scenario that each 'calendar event' will need about 20 local notifications, and you expect a typical user to have up to 100 calendar events. That would make 2,000 UILocalNotification. You may want to note that iOS4 limits the number of UILocalNotification to 64 per app.

See: UILocalNotification Class Reference

An application can have only a limited number of scheduled notifications; the system keeps the soonest firing 64 notifications (with automatically rescheduled notifications counting as a single notification) and discards the rest


Handling UILocalNotification

Since iOS4, apps no longer launch exclusively via application:didFinishLaunchingWithOptions:

application:didFinishLaunchingWithOptions: is called only once when the app is launched from a non-background state (eg. first launch by user, previous launch was killed by iOS to conserve memory, user killed the app from the multitasking bar, device was restarted).

So there are actually three different scenarios to consider handling UILocalNotification in iOS4 (which is where multitasking has been introduced).

When your app is backgrounded, the place to handle notifications is via application:didReceiveLocalNotification:, which fires in two scenarios:

  1. When user taps the 'View' action button to 'launch' your app from the alert notification while your app is backgrounded
  2. When the notification fires while your app is running in the foreground.

application:didFinishLaunchingWithOptions: handles just one scenario:

  1. When user taps the 'View' action button to launch your app from the alert notification while your app is not running in the background

UILocalNotification *localNotif = [launchOptions objectForKey:UIApplicationLaunchOptionsLocalNotificationKey]; if (localNotif) [self showLocalNotif:localNotif];

Devices that do not support support multitasking (eg iPhone 3G) will not use scenario 1 at all, but exclusively scenario 3.

In scenario 2, you handle your own notification, including displaying any appropriate UIAlertView or doing some action.


Now, the last thing to note is that notifications that are triggered while the app is not running in foreground and are ignored by user (ie. user did not tap 'View' action button) will not trigger scenario 1 or 3. They will not deliver any notification to your app at all on subsequent launches.

You're right that you can't access these notifications any more via [[UIApplication sharedApplication] scheduledLocalNotifications] because they've already been expired at the time of notification.

Hope this helps!

junjie