使用Core Location

1.In addition to adding the Core Location framework to your target, you also have to import the framework’s header

file into files that need to know about Core Location classes

#import <CoreLocation/CoreLocation.h>

2. CLLocationManager

定义: comform the delegate

@interface WhereamiViewController : UIViewController <CLLocationManagerDelegate>
{
CLLocationManager *locationManager;
}

init:

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
if (self) {
// Create location manager object

locationManager = [[CLLocationManager alloc] init];

// And we want it to be as accurate as possible
// regardless of how much time/power it takes
[locationManager setDesiredAccuracy:kCLLocationAccuracyBest];
// Tell our manager to start looking for its location immediately
[locationManager startUpdatingLocation];
}
return self;

}

3.set deletegate at :initWithNibName

// There will be a warning from this line of code; ignore it for now
[locationManager setDelegate:self]

4.implement delegate method:

- (void)locationManager:(CLLocationManager *)manager
didUpdateToLocation:(CLLocation *)newLocation
fromLocation:(CLLocation *)oldLocation
{
NSLog(@"%@", newLocation);
}

- (void)locationManager:(CLLocationManager *)manager
didFailWithError:(NSError *)error
{
NSLog(@"Could not find location: %@", error);
}

If you are running Whereami on the simulator, you’ll have to simulate its location once Whereami is running. When
you run an application from Xcode, a bar appears at the bottom of the editor area with several icons. Click the
icon in this bar and then select a location from the drop-down list

Compare Target-action and Deletgate:

Let’s compare delegation with another object-oriented approach to callbacks: target-action pairs. You used target action
pairs with the UIButtons in your Quiz application from Chapter 1. In a target-action pair, you have a target
object that you send an action message when a particular event occurs (like a button tap). A new target-action pair
must be created for each distinct event (like a tap, a double tap, or a long press). With delegation, you set the delegate
once and then can send it messages for many different events. The delegate will implement the methods that
correspond to the events it wants to hear about

Before sending an optional message, the object first asks its delegate if it is okay to send that message by sending
another message, respondsToSelector:. Every object implements this method, which checks at runtime whether an
object implements a given method. You can turn a method selector into a value that you can pass as an argument with
the @selector() directive. For example, CLLocationManager could implement a method that looks like this:
- (void)finishedFindingLocation:(CLLocation *)newLocation
{
// locationManager:didUpdateToLocation:fromLocation:
// is an optional method, so we check first.
SEL updateMethod = @selector(locationManager:didUpdateToLocation:fromLocation:);
if ([[self delegate] respondsToSelector:updateMethod]) {
// If the method is implemented, then we send the message.
[[self delegate] locationManager:self
didUpdateToLocation:newLocation
fromLocation:oldLocation];
}
}

为防止互相的Strong reference 导致的对象release 问题， CLLocationManager’s delegate property is not a
strong reference. But it is not a weak reference, either. To maintain backwards-compatibility with non-ARC versions
of iOS, delegate properties are __unsafe_unretained. 既然不是Strong ,也不是weak,　而是为了兼容性，设置成__unsafe_unretained, 所以需要

在dealloc 中设置为nil.

5.

Because delegate is unsafe unretained instead of weak, it is not automatically set to nil when the object it points to
is destroyed. You have to do that yourself in the delegate object’s dealloc method.
In WhereamiViewController.m, override dealloc.
- (void)dealloc
{
// Tell the location manager to stop sending us messages
[locationManager setDelegate:nil];
}
It is a little deceptive on our part to have you implement dealloc for WhereamiViewController. Why? Because the
WhereamiViewController will never be destroyed in this application – the dealloc method you just implemented
will never be called. The Whereami application needs the WhereamiViewController from beginning to end, so the
WhereamiViewController always has an owner.
However, many controller objects in your applications will get destroyed, and some of these will be delegates of
other objects. As you go through this book, you’ll start to see which controllers in an application get destroyed and
which stick around for the life of the application. For now, it is best to be safe, learn the ropes, and implement
dealloc for WhereamiViewController to set the locationManager’s delegate to nil.
In the next chapter, we’ll give Whereami a user interface. Right now, let’s take a look at how to work with the
debugger that comes with Xcode.

Diagnosing crashes and exceptions
While you can set breakpoints yourself to break on a particular line, it would be nice if the debugger would
automatically set a breakpoint on any line that causes your application to crash or that causes an exception to be
thrown.
To get the debugger to do this, we need to add a breakpoint for all exceptions. Select the debug navigator. Then, at
the bottom of the navigator area, click the + icon and select Add Exception Breakpoint.... Then, click the Done
button on the panel that pops up (Figure 4.13)

Preprocessing
The Compile Sources build phase can be broken into two steps: preprocessing and compiling. The goal of the
preprocessing phase is to create an intermediate file for each implementation file (.m). The intermediate file is still
Objective-C code like the implementation file, but, as we will see, the intermediate file can get very large.
To create an intermediate file, the preprocessor resolves all the preprocessor directives in the implementation file.
Preprocessor directives are statements prefixed with the pound symbol (#), like #import. The resolution of a
#import statement replaces the import statement with the contents

Compiling
Once the preprocessor has finished, the generated intermediate files are compiled. Compiling an intermediate file
takes the Objective-C code and turns it into machine code. This machine code is stored in an object file, one for each
intermediate file.
The compiling phase – the transition to machine code – is where we see most of our errors as programmers. When
the compiler doesn’t understand our code, it generates an error. We call errors generated during this phase compiletime
errors or syntax errors. Compile-time errors are typically misplaced semicolons, unbalanced square brackets ([])
or curly ones ({}), spelling or capitalization errors.

Linking
An object file contains the machine code for the methods implemented in the implementation file. However, within
an implementation file, you use code from other implementation files. For example, WhereamiViewController.m
uses the startUpdatingLocation method, and the machine code for that method is in the object file generated from
CLLocationManager.m.
Instead of copying the code for this method into the object file for WhereamiViewController.m, the compiler leaves
a link to the object file for CLLocationManager.m. The Link Binary With Libraries phase is where these links are
resolved. For short, we just call it the linking phase.