Local Notisfication in ios application

Creating and Processing Local Notifications

Local notifications are scheduled for a future date by creating a UILocalNotification object. When creating the notification you can also specify the type of notification(s) to send, a badge, alert or sound.

If a local notification arrives on the application that is not running in the foreground, the notification is delivered (that is, the alert shown, the badge set, sound played). If the notification is an alert, a dialog is shown to the user, along with an option to open the application. If the user chooses to open the app, the method didFinishLaunchingWithOptions in the application delegate is called passing in the local notification object.
If the application is running when a local notification is received, the method didReceiveLocalNotification is called, again, passing in the local notification object.

Screenshots

The app I’ve written to work with notification has a range of buttons to schedule various types of notifications:
Once you choose an option, the notification is scheduled – to keep things simple, in my application I’ve set all notifications to arrive in 60 seconds. The screenshot below shows an incoming notification when the app has been put into the background.

The screenshot below is an alert I display from within the method called when a notification arrives.

Methods in the App Delegate

The application delegate contains the two methods needed for managing incoming notifications. The method didFinishLaunchingWithOptions is shown below. Notice the check of the launchOptions parameter early in the method, if this value is nil, this is a standard application startup. If the value is not nil, the application was started based on a notification presented to the user – in this case I show an alert along with a few debug messages, including the payload data received from the notification (more on this below).

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  // Handle launching from a notification
  UILocalNotification *notification = [launchOptions objectForKey:UIApplicationLaunchOptionsLocalNotificationKey];
 
  // If not nil, the application was based on an incoming notifiation
  if (notification) 
  {
    NSLog(@"Notification initiated app startup");
 
    // Access the payload content
    NSLog(@"Notification payload: %@", [notification.userInfo objectForKey:@"payload"]);
 
    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Launched with Options" 
                              message:@"Notification initiated app startup" 
                              delegate:self cancelButtonTitle:@"Ok" 
                              otherButtonTitles:nil];
    [alert show];
    [alert release];
  }
 
  // Reset the badge
  [application setApplicationIconBadgeNumber:0];
 
  // Create and initialize the window
  window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
 
  // Create test view controller
  vc = [[TestViewController alloc] init];
 
  [window addSubview:vc.view];
  [window makeKeyAndVisible];
 
  return YES;
}

The second method in the application delegate is didReceiveLocalNotification
 which will be called when a notification arrives while the applications
 is running. In this method I show an alert and also write the 
notification payload to the debug console. For the payload, I am 
creating an array of objects, packaging the array within a dictionary 
and passing the later along with the notification. 

- (void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification 
{
  UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Launched with Options" 
                            message:@"Incoming notification in running app" 
                            delegate:self cancelButtonTitle:@"Ok" 
                            otherButtonTitles:nil];
  [alert show];
  [alert release];
 
  NSLog(@"Incoming notification in running app");
 
  // Access the payload content
  NSLog(@"Notification payload: %@", [notification.userInfo objectForKey:@"payload"]);
}

Scheduling a Local Notification

The buttons shown in the screenshot above are how we initiate creating and scheduling a local notification. Before handling each event there is some common code for creating a UILocalNotification object, setting the fire date and populating the data (payload) that will accompany the notification.

- (void)buttonPressed:(UIButton *)button
{
  UILocalNotification *localNotification = [[[UILocalNotification alloc] init] autorelease];
 
  if (!localNotification) 
    return;
 
  // Current date
  NSDate *date = [NSDate date]; 
 
  // Add one minute to the current time
  NSDate *dateToFire = [date dateByAddingTimeInterval:60];
 
  // Set the fire date/time
  [localNotification setFireDate:dateToFire];
  [localNotification setTimeZone:[NSTimeZone defaultTimeZone]];
 
  // Create a payload to go along with the notification
  NSArray *array = [NSArray arrayWithObjects:@"Value 1", @"Value 2", nil];
  NSDictionary *data = [NSDictionary dictionaryWithObject:array forKey:@"payload"];
  [localNotification setUserInfo:data];
 
  if (button == buttonAlert || button == buttonAll)
  { 
    // Setup alert notification
    [localNotification setAlertBody:@"Incoming Local Notification" ];
    [localNotification setAlertAction:@"Open App"];
    [localNotification setHasAction:YES];      
  }
 
  if (button == buttonBadge || button == buttonAll)
  {
    // Set badge notification, increment current badge value
    [localNotification setApplicationIconBadgeNumber:[[UIApplication sharedApplication] applicationIconBadgeNumber] + 1];
  }
 
  if (button == buttonSound || button == buttonAll)
  {
    // Setup sound notification
    [localNotification setSoundName:UILocalNotificationDefaultSoundName];     
  }
 
  // Schedule the notification        
  [[UIApplication sharedApplication] scheduleLocalNotification:localNotification];
}

iPhone iPad,and ios4 Beginer: How to Send a Crash Report from your iPhone, iPad ...

iPhone iPad,and ios4 Beginer: How to Send a Crash Report from your iPhone, iPad ...: When an iOS application crashes the system generates a crash report and stores it on your mobile device. The next time you connect your dev...

How to Send a Crash Report from your iPhone, iPad or iPod touch:

When an iOS application crashes the system generates a crash report and stores it on your mobile device. The next time you connect your device (iPhone,iPad or iPod touch) to iTunes (when you sync your device in iTunes), iTunes downloads this crash log to your computer. These crash reports can be very helpful in finding and fixing the problems. So we, developers, need these crash reports. There are two ways to send them to us.

1. Have iTunes send them automatically
The first time you setup and sync your iOS device with iTunes it asks you if you would like to send a diagnostic information to Apple anonymously. If you say yes, iTunes would collect any crash reports found during syncing and send them to Apple. Subsequently, they would be forwarded to the app developer. If you want iTunes to send crash reports automatically here is what you need to do:
    •    Connect your device.
    •    In the iTunes window, under the DEVICES section of the sidebar you should see your device. If you right click (control click) on your device a contextual menu will display.
    •    Choose Reset Warnings option.
    •    Sync your device.
When you sync you would see the following dialog:

If you click OK, iTunes will automatically forward all crash reports on your device to Apple which, in turn, will send them to us.
So far, we received just one crash report this way. We would highly recommend to send your crash reports manually.
2. Send Crash Reports to us manually
If you don't want iTunes send reports automatically, you can still send them to us manually.
First, you need to make sure that your iTunes are set up properly. You need to repeat all steps described above (I am repeating them here just for the convenience sake):
    •    Connect your device.
    •    In the iTunes window, under the DEVICES section of the sidebar you should see your device. If you right click (control click) on your device a contextual menu will display.
    •    Choose Reset Warnings option.
    •    Sync your device.

When you sync you would see the following dialog:

Click No Thanks.
Now you need to navigate to the folder where iTunes copied any crash reports. This depends on what platform you are using.
Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/[DEVICE_NAME]

[USERNAME] is the user's login name for the computer. [DEVICE_NAME] is the name of the iPhone, iPad or iPod touch, for example, Elena's iPad.

Since we will need crash reports, please send .crash files only. Here is an example of a random crash report name: mappocket_2011-06-26-204442_etchijovs-iPad.crash. As you can see, the crash report file name has following structure: [APP_NAME]_[DATE]_[DEVICE_NAME].crash.


for more detail:http://www.leapingbytes.com/blog/ios_crash_reports

Understanding and Analyzing iOS Application Crash Reports:
When an application crashes, a "crash report" is created which is very useful for understanding what caused the crash. This document contains essential information about how to symbolicate, understand, and interpret crash reports.
Introduction
Understanding Low Memory Reports
Analyzing Crash Reports
Symbolication
Exception codes
Related Documents
Document Revision History

Introduction
When an application crashes on an iOS device, a "crash report" is created and stored on the device. Crash reports describe the conditions under which the application terminated, in most cases including a complete stack trace for each executing thread, and are typically very useful for debugging issues in the application. If you are an iOS developer, you should look at these crash reports to understand what crashes your application is having, and then try to fix them.

Low memory reports differ from other crash reports in that there are no stack traces in this type of reports. When a low memory crash happens, you must investigate your memory usage patterns and your responses to low memory warnings. This document points to you several memory management references that you might find useful.


Crash reports with stack traces need to be symbolicated before they can be analyzed. Symoblication replaces memory addresses with human-readable function names and line numbers. If you get crash logs off a device through Xcode's Organizer window, then they will be symbolicated for you automatically after a few seconds. Otherwise you will need to symbolicate the .crash file yourself by importing it to the Xcode Organizer. See Symbolication for details.

This document also talks about exception codes, another useful information for identifying the cause of the crash.

Understanding Low Memory Reports
When a low-memory condition is detected, the virtual memory system in iOS relies on the cooperation of applications to release memory. Low-memory notifications are sent to all running applications and processes as a request to free up memory, hoping to reduce the amount of memory in use. If memory pressure still exists, the system may terminate background processes to ease memory pressure. If enough memory can be freed up, your application will continue to run and no crash report will be generated. If not, your application will be terminated by iOS because there isn't enough memory to satisfy the application's demands, and a low memory report will be generated and stored on the device.
The format of a low memory report differs from other crash reports in that there are no stack traces for the application threads. Memory usage of each process is reported in terms of number of memory pages, which as of this writing are 4KB each. You will see "(jettisoned)" next to the name of any process terminated by iOS to free up memory. If you see it next to your application's name, that confirms the application was terminated for using too much memory. Otherwise, the cause of the crash was not memory pressure. Look for a .crash file (described in the next section) for more information.
When you see a low memory crash, rather than be concerned about what part of your code was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. Memory Allocations Help lists detailed steps on how to use the Leaks Instrument to discover memory leaks, and how to use the Allocations Instrument's Mark Heap feature to avoid abandoned memory. Memory Usage Performance Guidelines discusses the proper ways to respond to low-memory notifications as well as many tips for using memory effectively. It is also recommended that you check out the WWDC 2010 session, Advanced Memory Analysis with Instruments.
Important: The Leaks and Allocations instruments do not track graphics memory. You need to run your application with the VM Tracker instrument (included in the Instruments Allocations template) to see your graphics memory usage. VM Tracker is disabled by default. To profile your application with VM Tracker, click the instrument, check the "Automatic Snapshotting" flag or press the "Snapshot Now" button manually.

Back to Top
Analyzing Crash Reports
Unlike the low memory reports, most crash reports contain stack traces for each thread at the time of termination. This section discusses these reports.
Symbolication
The most interesting part of a crash report is the stack trace of your application at the time execution halted. This trace is similar to what you would see when stopping execution in the debugger, except that you are not given the method or function names, known as symbols. Instead, you have hexadecimal addresses and executable code - your application or system frameworks - to which they refer. You need to map these addresses to symbols. The logs do not contain symbol information when they're written out. You have to symbolicate the logs before you can analyze them.
Symbolication - resolving stack trace addresses to source code methods and lines - requires the application binary that was uploaded to the App Store and the .dSYM file that was generated when that binary was built. This must be an exact match - otherwise, the report cannot be fully symbolicated. It is essential that you keep each build distributed to users (regardless of the details of that distribution) with its .dSYM file.
Important: You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use the “Build and Archive” command then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.

Xcode's "Archive" command makes it easy keeping the matching binary and the .dSYM. When you use the "Archive" command (by choosing "Archive" from the "Product" menu or by pressing Shift+Command+B), Xcode will gather the application binary and the .dSYM containing symbol information together and store them in a location in your home folder. You can find all of your archived applications in the Xcode Organizer under the "Archived" section. Xcode will automatically search archived applications when symbolicating crash reports, and you can submit archived applications directly to iTunes Connect ensuring that the application and .dSYM that you have archived match what you release.
Xcode will automatically symbolicate all crash reports that it encounters, if it has the .dSYM and application binary that produced the crash report. Given a crash report, the matching binary, and its .dSYM file, all you need to do for symbolication is to add the crash report to the Xcode Organizer. Open the Xcode Organizer, select the “Devices” tab, select “Device Logs” under “LIBRARY” on the top of the sidebar, click the "Import" button and select the .crash file. When it's done, Xcode will automatically symbolicate the crash report and display the results.
Exception codes
About 16 lines into the crash log, you will see a line that starts with the text followed by one or more hexadecimal values, which are processor-specific codes that may give you more information on the nature of the crash. You may tell from these codes if the application crashed due to a programming error (for example, a bad memory access, an exception, etc), or if the application was terminated for some other reason, for example:
    •    The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread.
    •    The exception code 0xbad22222 indicates that a VoIP application has been terminated by iOS because it resumed too frequently.
    •    The exception code 0xdead10cc indicates that an application has been terminated by iOS because it held on to a system resource (like the address book database) while running in the background.
    •    The exception code 0xdeadfa11 indicated that an application has been force quit by the user. Force quits occur when the user first holds down the On/Off button until "slide to power off" appears, then holds down the Home button. It's reasonable to assume that the user has done this because the application has become unresponsive, but it's not guaranteed - force quit will work on any application.
Note: Terminating a suspended app by removing it from the multitasking tray does not generate a crash log. Once an app has suspended, it is eligible for termination by iOS at any time, so no crash log will be generated.

    •    Analyzing Crash Reports
    •    Unlike the low memory reports, most crash reports contain stack traces for each thread at the time of termination. This section discusses these reports.
    •    Symbolication
    •    The most interesting part of a crash report is the stack trace of your application at the time execution halted. This trace is similar to what you would see when stopping execution in the debugger, except that you are not given the method or function names, known as symbols. Instead, you have hexadecimal addresses and executable code - your application or system frameworks - to which they refer. You need to map these addresses to symbols. The logs do not contain symbol information when they're written out. You have to symbolicate the logs before you can analyze them.
    •    Symbolication - resolving stack trace addresses to source code methods and lines - requires the application binary that was uploaded to the App Store and the .dSYM file that was generated when that binary was built. This must be an exact match - otherwise, the report cannot be fully symbolicated. It is essential that you keep each build distributed to users (regardless of the details of that distribution) with its .dSYM file.
Important: You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use the “Build and Archive” command then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.


Xcode's "Archive" command makes it easy keeping the matching binary and the .dSYM. When you use the "Archive" command (by choosing "Archive" from the "Product" menu or by pressing Shift+Command+B), Xcode will gather the application binary and the .dSYM containing symbol information together and store them in a location in your home folder. You can find all of your archived applications in the Xcode Organizer under the "Archived" section. Xcode will automatically search archived applications when symbolicating crash reports, and you can submit archived applications directly to iTunes Connect ensuring that the application and .dSYM that you have archived match what you release.
Xcode will automatically symbolicate all crash reports that it encounters, if it has the .dSYM and application binary that produced the crash report. Given a crash report, the matching binary, and its .dSYM file, all you need to do for syllabication is to add the crash report to the Xcode Organizer. Open the Xcode Organizer, select the “Devices” tab, select “Device Logs” under “LIBRARY” on the top of the sidebar, click the "Import" button and select the .crash file. When it's done, Xcode will automatically symbolicate the crash report and display the results.

Exception codes:
About 16 lines into the crash log, you will see a line that starts with the text followed by one or more hexadecimal values, which are processor-specific codes that may give you more information on the nature of the crash. You may tell from these codes if the application crashed due to a programming error (for example, a bad memory access, an exception, etc), or if the application was terminated for some other reason, for example:
    •    The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread.
    •    The exception code 0xbad22222 indicates that a VoIP application has been terminated by iOS because it resumed too frequently.
    •    The exception code 0xdead10cc indicates that an application has been terminated by iOS because it held on to a system resource (like the address book database) while running in the background.
    •    The exception code 0xdeadfa11 indicated that an application has been force quit by the user. Force quits occur when the user first holds down the On/Off button until "slide to power off" appears, then holds down the Home button. It's reasonable to assume that the user has done this because the application has become unresponsive, but it's not guaranteed - force quit will work on any application.

Getting Start With ios -4 Programing

Getting Started with iOS -4
Programming:

Welcome to the world of iPhone programming! That you are now holding this Blogs shows
that you are fascinated with the idea of developing your own iPhone (and iPad) applications
and want to join the ranks of the tens of thousands of developers whose applications are
already deployed in the App Store.

Successful programming requires that you first know your tools well. Indeed, this couldn’t be more true for iPhone programming — you need to know quite a few tools before you can even get started.
Hence, this chapter describes the various relevant tools and information you need to jump on
the iPhone development bandwagon.Without further ado, it’s time to get down to work.

Obtaining the iphone SDK:

To develop for the iPhone, you first need to sign up as a registered iPhone developer at http://developer
.apple.com/iPhone/program/start/register/. Registration is free and provides you with access to the
iPhone SDK (software development kit) and other resources that are useful for getting started.

After signing up, you can download the iPhone SDK.

Before you install the iPhone SDK, make sure you satisfy the following system requirements:

1 Only Intel Macs are supported, so if you have another processor type (such as the older G4
or G5 Macs), you’re out of luck.

2. Your system is updated with the latest Mac OS X release.

An actual iPhone/iPad is highly recommended, although not strictly necessary. To test your application,
you can use the included iPhone Simulator (which enables you to simulate an iPhone or an
iPad). However, to test certain hardware features like GPS, the accelerometer, and such, you need to
use a real device.
When the SDK is downloaded, proceed with installing it (see Figure 1-2). Accept a few licensing
agreements and then select the destination folder in which to install the SDK.

If you select the default settings during the installation phase, the various tools will be installed in
the /Developer/Applications folder

Components of the iPhone SDK:

The iPhone SDK includes a suite of development tools to help you create applications for your iPhone,

iPod touch, and iPad. It includes the following:

➤➤ Xcode — Integrated development environment (IDE) that enables you to manage, edit, and

debug your projects

➤➤ Dashcode — Integrated development environment (IDE) that enables you to develop webbased

iPhone and iPad applications and Dashboard Widgets. Dashcode is beyond the scope

of this book.

➤➤ iPhone Simulator — Provides a software simulator to simulate an iPhone or an iPad on your Mac.

➤➤ Interface Builder — Visual editor for designing user interfaces for your iPhone and iPad

applications

➤➤ Instruments — Analysis tool to help you both optimize your application and monitor for

memory leaks in real time

The following sections discuss each tool (except Dashcode) in more detail.

Xcode

To launch Xcode, double-click the Xcode icon located in the /Developer/Applications folder (refer to

Figure 1-3). Alternatively, go the quicker route and use Spotlight: Simply type Xcode into the search box

and Xcode should be in the Top Hit position.
Figure 1-4 shows the Xcode Welcome screen.