Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Few things to note:</p> <h2>Maximum number of UILocalNotification</h2> <p>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.</p> <p>See: <a href="http://developer.apple.com/library/ios/#documentation/iPhone/Reference/UILocalNotification_Class/Reference/Reference.html" rel="nofollow">UILocalNotification Class Reference</a></p> <blockquote> <p>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</p> </blockquote> <hr> <h2>Handling UILocalNotification</h2> <p>Since iOS4, apps no longer launch exclusively via application:didFinishLaunchingWithOptions:</p> <p>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).</p> <p>So there are actually three different scenarios to consider handling UILocalNotification in iOS4 (which is where multitasking has been introduced).</p> <p>When your app is backgrounded, the place to handle notifications is via application:didReceiveLocalNotification:, which fires in two scenarios:</p> <ol> <li>When user taps the 'View' action button to 'launch' your app from the alert notification while your app is backgrounded</li> <li>When the notification fires while your app is running in the foreground.</li> </ol> <p>application:didFinishLaunchingWithOptions: handles just one scenario:</p> <ol> <li>When user taps the 'View' action button to launch your app from the alert notification while your app <strong>is not</strong> running in the background</li> </ol> <p>Devices that do not support support multitasking (eg iPhone 3G) will not use scenario 1 at all, but exclusively scenario 3.</p> <p>In scenario 2, you handle your own notification, including displaying any appropriate UIAlertView or doing some action.</p> <hr> <p>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 <strong>not</strong> trigger scenario 1 or 3. They will not deliver any notification to your app at all on subsequent launches.</p> <p>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.</p> <p>Hope this helps!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload