iPhone Programming Tutorials » Matt Tuzzolo

Update: ELCImagePickerController

Matt Tuzzolo — Thu, 03 Mar 2011 00:23:14 +0000

I recently spent some time with ELCImagePickerController. For those of you who’ve worked with UIImagePickerController, you might have noticed one of its major drawbacks: you can only select one photo at a time. ELCImagePickerController solves this issue by cloning the UI of UIImagePickerController, but with the added bonus of allowing you to select multiple assets. Collin Ruffenach (@cruffenach), who authored the the first version of the picker, has done an awesome job of making ELCImagePickerController look, feel, and behave like a native image picker. For this post I’m going to go through some recent improvements I made to ELCImagePickerController and pass along some lessons learned from working with the AssetsLibrary Framework.

This is my first foray into the AssetsLibrary Framework which was introduced with iOS 4.0. If you’re not already familiar with the framework, I highly suggest checking out both of these posts:

Asset Libraries and Blocks in iOS 4

Cloning UIImagePickerController using the Assets Library Framework

These should give you a solid picture of how to work with ALAssetLibrary, ALAssetGroup, and ALAsset.

One of the obvious changes I’ve made to the project is a reorganization of the code. Classes are broken out for clarity as you can see here:

Old Tree:

New Tree:

I’ve also renamed several classes to avoid confusion w/ Apple’s and ELC’s respective classes.

On major change to the project is how you present the new ELCImagePickerController. This is mainly due to an issue we uncovered with a redundant call to [super init] which was causing a substantial memory leak. Here’s the new way of showing the image picker:

ELCAlbumPickerController *albumController = [[ELCAlbumPickerController alloc] initWithNibName:@"ELCAlbumPickerController" bundle:[NSBundle mainBundle]];ELCImagePickerController *elcPicker = [[ELCImagePickerController alloc] initWithRootViewController:albumController];
 
[albumController setParent:elcPicker];
 
[elcPicker setDelegate:self];
 
ELCImagePickerDemoAppDelegate *app = (ELCImagePickerDemoAppDelegate *)[[UIApplication sharedApplication] delegate];
 
[app.viewController presentModalViewController:elcPicker animated:YES];
 
[elcPicker release];
 
[albumController release];

One interesting optimization I was able to make was on the loading of large albums which was previously taking several seconds. Since ALAssetGroup uses a block to enumerate assets, I just fire off a reloadTable call after a short delay:

// Show partial list while full list loads
 
[self.tableView performSelector:@selector(reloadData) withObject:nil afterDelay:.5];

Then when the block is finished enumerating, it’ll call reloadTable as well. On an album with roughly 1500 photos, it was pretty tough to reach the bottom of the tableview before the block finished enumerating. So this is a pretty decent solution to the issue. Originally, I experimented with lazy loading the assets as the user scrolled through the table, but ultimately wasn’t able to get the performance I wanted out of it.

This release of ELCImagePickerController should perform faster, and with a smaller memory footprint than before. I hope you enjoy it.

You can follow me on twitter @matt_tuzzolo or get in touch with us at http://www.elctech.com

ps. for an extra bonus, check out [ELCAsset toggleSelection];

Implementing UITableView Sections from an NSArray of NSDictionary Objects

Matt Tuzzolo — Fri, 10 Dec 2010 23:35:06 +0000

If you’re working with a remote Web Service, your apps are probably displaying TableViews of objects. As soon as your dataset grows beyond 20 or 30 objects, it’s time to implement sections in your Table View. I’m going to show you how you can do this without too much trouble. In this example, we’ll use an array of dictionary objects (Books) to construct a single ‘sections’ dictionary that will be the basis for our TableView datasource.

Before we get started, you might want to clone the git repo containing the demo Xcode project for this post:

git clone git@github.com:elc/ICB_SectionedTableViewDemo.git

First let’s take a look at the UITableViewDataSource protocol methods that we’ll be using to get sections going:

    - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
    - (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section
    - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
    - (NSArray *)sectionIndexTitlesForTableView:(UITableView *)tableView {

These are the four methods needed to show section headers, as well as the section index (which is the scrubber on the right side). Normally, with a established dataset (say one that already contains at least one item that starts with each letter of the alphabet), you can take some short cuts and return 26 for numberOfSectionsInTableView, hard code an array of A-Z to use for titleForHeaderInSection, etc. I’ve done that a few times for static datasets, but it’s really the wrong solution if you’re pulling data from a user-generated or otherwise dynamic datastore.

Instead what we’ll do is build a new dictionary entirely. The keys of this dictionary will correspond to our tableview section titles, and the values for those keys will be arrays containing our dictionary objects; these represent cells in the tableview.

Let’s start by establishing our sections:

 
    BOOL found;
 
    // Loop through the books and create our keys
    for (NSDictionary *book in self.books)
    {
        NSString *c = [[book objectForKey:@"title"] substringToIndex:1];
 
        found = NO;
 
        for (NSString *str in [self.sections allKeys])
        {
            if ([str isEqualToString:c])
            {
                found = YES;
            }
        }
 
        if (!found)
        {
            [self.sections setValue:[[NSMutableArray alloc] init] forKey:c];
        }
    }

If you’re implementing this code as you go, make sure you’ve setup ‘sections’ as a NSMutableDictionary property of your datasource (which is usually just your UITableViewController). So after this block of code runs, you’ll have a dictionary with a key for each unique first character of book->title. So if your books are:

On Intelligence
On The Road
Ishmael
Dune

Your self.sections will be:

‘O’ => empty NSMutableArray
‘I’ => empty NSMutableArray
‘D’ => empty NSMutableArray

Notice that the keys in your NSDictionary aren’t sorted alphabetically. They would be if your initial datasource (self.books) was sorted alphabetically; but there’s no guarantee on that. I’ll show you how to deal with this in a minute.

So the next step is to populate the empty arrays in self.sections with the appropriate NSDictionary objects from self.books:

    // Loop again and sort the books into their respective keys
    for (NSDictionary *book in self.books)
    {
        [[self.sections objectForKey:[[book objectForKey:@"title"] substringToIndex:1]] addObject:book];
    }

Now the books are compartmentalized into their respective sections. Next we need to sort the books within each section:

    // Sort each section array
    for (NSString *key in [self.sections allKeys])
    {
        [[self.sections objectForKey:key] sortUsingDescriptors:[NSArray arrayWithObject:[NSSortDescriptor sortDescriptorWithKey:@"title" ascending:YES]]];
    }

Again, we’re basing our sort off @”title”. I’ll leave @”title” in here for readability, but it would be wise to pull this out into it’s own NSString *sortByProperty so you can easily change it should you decide you want to base your sections/sorting on Author, Publication Year, etc.

At this point you’ll probably want to drop this in too:

    [self.tableView reloadData];

So now that we’ve constructed our self.sections, we can finally implement the UITableViewDataSource protocol methods I mentioned above:

#pragma mark -
#pragma mark Table view data source
 
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
    return [[self.sections allKeys] count];
}
 
- (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section
{
    return [[[self.sections allKeys] sortedArrayUsingSelector:@selector(localizedCaseInsensitiveCompare:)] objectAtIndex:section];
}
 
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    return [[self.sections valueForKey:[[[self.sections allKeys] sortedArrayUsingSelector:@selector(localizedCaseInsensitiveCompare:)] objectAtIndex:section]] count];
}
 
- (NSArray *)sectionIndexTitlesForTableView:(UITableView *)tableView {
    return [[self.sections allKeys] sortedArrayUsingSelector:@selector(localizedCaseInsensitiveCompare:)];
}

This is where things get a little confusing. Since these methods are called with indexPath.section, which an NSInteger, and not the actual section key, we’re forced to get a little tricky. In order to make sure that our section indexes and section titles match up correctly AND are ordered alphabetically, we have to sort allKeys each time and then reference the resulting NSArray. It’s kind of ugly, but I’ve done all the annoying bracket matching for you already.

OK. So now that we have sections out of the way, let’s show some cells…

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
    static NSString *CellIdentifier = @"Cell";
 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier] autorelease];
    }
 
    NSDictionary *book = [[self.sections valueForKey:[[[self.sections allKeys] sortedArrayUsingSelector:@selector(localizedCaseInsensitiveCompare:)] objectAtIndex:indexPath.section]] objectAtIndex:indexPath.row];
 
    cell.textLabel.text = [book objectForKey:@"title"];
    cell.detailTextLabel.text = [book objectForKey:@"description"];
 
    return cell;
}

That’s it! You should have a great looking sectioned tableView. If you have any questions or comments, you can get a hold me@matt_tuzzolo on Twitter.

Adding Local Weather Conditions To Your App (Part 2/2: Accessing Google’s XML Weather API)

Matt Tuzzolo — Wed, 29 Sep 2010 19:36:36 +0000

In this Part 2 of ‘Adding Local Weather Conditions To Your App’, I’ll show you how to quickly add current temp, conditions, and today’s high / low temperature to your app.

If you’re lucky enough to already have the user’s zipcode or city and state, this should go very quickly for you. Otherwise, check out Part 1 (Integrating CoreLocation).

Let’s get started.

There are a handful of solid XML Weather APIs out there. The best one I’ve seen so far is Wunderground’s (it’s extremely well documented) but for the purposes of this tutorial, I decided to use Google’s “super secret” Weather API. It’s incredibly simple and should take care of all your basic weather needs. Though if you’re planning on releasing a production App, be sure to pick a public API and check out their TOS (some require API keys, or fees for production use). Here’s a good list of Weather APIs

Let’s look at some example calls to Google:

http://www.google.com/ig/api?weather=01451

http://www.google.com/ig/api?weather=nyc

http://www.google.com/ig/api?weather=Portland,OR

http://www.google.com/ig/api?weather=Jamaica

As you can see, there’s a bit of flexibility in how you can query the service. The one piece it’s lacking is querying by latitude and longitude. Lucky for you, I’ll show you how to use MKReverseGeocoder to determine your user’s City/State, which you can then plug right into the GET request. First, let’s take a quick look at the XML that comes back from the API:

="1.0"?>
  ="1">
    ="0" tab_id="0" mobile_row="0" mobile_zipped="1" row="0" section="0">
      
        ="Portland, OR"/>
        ="97217"/>
        =""/>
        =""/>
        ="2010-09-20"/>
        ="2010-09-20 23:46:50 +0000"/>
        ="US"/>
      </forecast_information>
      
        ="Cloudy"/>
        ="64"/>
        ="18"/>
        ="Humidity: 55%"/>
        ="/ig/images/weather/cloudy.gif"/>
        ="Wind: SW at 8 mph"/>
      </current_conditions>
      
        ="Mon"/>
        ="51"/>
        ="66"/>
        ="/ig/images/weather/partly_cloudy.gif"/>
        ="Partly Cloudy"/>
      </forecast_conditions>
      
        ="Tue"/>
        ="50"/>
        ="68"/>
        ="/ig/images/weather/partly_cloudy.gif"/>
        ="Partly Cloudy"/>
      </forecast_conditions>
      
        ="Wed"/>
        ="53"/>
        ="68"/>
        ="/ig/images/weather/sunny.gif"/>
        ="Sunny"/>
     </forecast_conditions>
    
      ="Thu"/>
      ="53"/>
      ="65"/>
      ="/ig/images/weather/rain.gif"/>
      ="Showers"/>
    </forecast_conditions>
  </weather>
</xml_api_reply>

All this should be pretty self explanatory. The two pieces to pay attention to here are current_conditions, and forecast_conditions. For our demo app, we’re simply going to display current temperature, conditions, a conditionsIcon, and today’s high and low temp. We’ll be able to pull all this information out of current_conditions and the first forecast_conditions (which is the forecast for today). In the interest of keeping everything organized, let’s build a class to hold our weather info.

//
//  ICB_WeatherConditions.h
//  LocalWeather
//
//  Created by Matt Tuzzolo on 9/28/10.
//  Copyright 2010 iCodeBlog. All rights reserved.
//
 
@interface ICB_WeatherConditions : NSObject {
    NSString *condition, *location;
    NSURL *conditionImageURL;
    NSInteger currentTemp,lowTemp,highTemp;
}
 
@property (nonatomic,retain) NSString *condition, *location;
@property (nonatomic,retain) NSURL *conditionImageURL;
@property (nonatomic) NSInteger currentTemp, lowTemp, highTemp;
 
- (ICB_WeatherConditions *)initWithQuery:(NSString *)query;
 
@end

In the .m we’re going to pull the data out of the XML and store it in our properties. There are several 3rd party Objective-C XML parsers. I’ve chosen to use Jonathan Wight’s TouchXML as it’s become somewhat of a standard for parsing XML on iOS. You can find it here. You’ll have to jump through a couple hoops to get TouchXML into your project. Here’s an excellent tutorial on installing TouchXML that will walk you through the whole process if you’ve never done it before.

//
//  ICB_WeatherConditions.m
//  LocalWeather
//
//  Created by Matt Tuzzolo on 9/28/10.
//  Copyright 2010 iCodeBlog. All rights reserved.
//
 
#import "ICB_WeatherConditions.h"
#import "TouchXML.h"
 
@implementation ICB_WeatherConditions
 
@synthesize currentTemp, condition, conditionImageURL, location, lowTemp, highTemp;
 
- (ICB_WeatherConditions *)initWithQuery:(NSString *)query
{
    if (self = [super init])
    {
        CXMLDocument *parser = [[[CXMLDocument alloc] initWithContentsOfURL:[NSURL URLWithString:[NSString stringWithFormat:@"http://www.google.com/ig/api?weather=%@", query]] options:0 error:nil] autorelease];
 
        condition         = [[[[[parser nodesForXPath:@"/xml_api_reply/weather/current_conditions/condition" error:nil] objectAtIndex:0] attributeForName:@"data"] stringValue] retain];
        location          = [[[[[parser nodesForXPath:@"/xml_api_reply/weather/forecast_information/city" error:nil] objectAtIndex:0] attributeForName:@"data"] stringValue] retain];
 
        currentTemp       = [[[[[parser nodesForXPath:@"/xml_api_reply/weather/current_conditions/temp_f" error:nil] objectAtIndex:0] attributeForName:@"data"] stringValue] integerValue];
        lowTemp           = [[[[[parser nodesForXPath:@"/xml_api_reply/weather/forecast_conditions/low" error:nil] objectAtIndex:0] attributeForName:@"data"] stringValue] integerValue];
        highTemp          = [[[[[parser nodesForXPath:@"/xml_api_reply/weather/forecast_conditions/high" error:nil] objectAtIndex:0] attributeForName:@"data"] stringValue] integerValue];
 
        conditionImageURL = [[NSURL URLWithString:[NSString stringWithFormat:@"http://www.google.com%@", [[[[parser nodesForXPath:@"/xml_api_reply/weather/current_conditions/icon" error:nil] objectAtIndex:0] attributeForName:@"data"] stringValue]]] retain];
    }
 
    return self;
}
 
- (void)dealloc {
    [conditionImageURL release];
    [condition release];
    [location release];
    [super dealloc];
}
 
@end

I’ve decided to write my own init method to handle making the request to our API. This will make for a clean implementation in our view controller.

Before we get to implementing ICB_WeatherConditions, I’ll touch briefly on location. Part 1/2 of this tutorial covered finding your user’s latitude and longitude with Core Location. Use MKReverseGeocoder to find city/state from coordinates. Start by adding both the MapKit and CoreLocation frameworks to your project.

MKReverseGeocoder works asynchronously to resolve location info; it has a delegate. In our example we set the delegate to the view controller (self). Be sure to add to your header as well. Since your view controller is now the delegate for the geocoder, make sure to implement the delegate methods for the MKReverseGeocoderDelegate protocol:

#pragma mark MKReverseGeocoder Delegate Methods
- (void)reverseGeocoder:(MKReverseGeocoder *)geocoder didFindPlacemark:(MKPlacemark *)placemark
{
    [geocoder release];
    [self performSelectorInBackground:@selector(showWeatherFor:) withObject:[placemark.addressDictionary objectForKey:@"ZIP"]];
}
 
- (void)reverseGeocoder:(MKReverseGeocoder *)geocoder didFailWithError:(NSError *)error
{
    NSLog(@"reverseGeocoder:%@ didFailWithError:%@", geocoder, error);
    [geocoder release];
}

Now we’re ready to implement ICB_WeatherConditions. I usually populate UILabels in viewDidLoad, but since we’re making API calls and downloading a remote image (the weather conditions icon), I decided to write a method to execute in the background. This lets us use synchronous requests (which a lot easier to deal with) to handle network requests without locking up the main thread. Once our network calls have finished, we call back to the main thread to update the UI accordingly.

// This will run in the background
- (void)showWeatherFor:(NSString *)query
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 
    ICB_WeatherConditions *weather = [[ICB_WeatherConditions alloc] initWithQuery:query];
 
    self.conditionsImage = [[UIImage imageWithData:[NSData dataWithContentsOfURL:weather.conditionImageURL]] retain];
 
    [self performSelectorOnMainThread:@selector(updateUI:) withObject:weather waitUntilDone:NO];
 
    [pool release];
}
 
// This happens in the main thread
- (void)updateUI:(ICB_WeatherConditions *)weather
{
    self.conditionsImageView.image = self.conditionsImage;
    [self.conditionsImage release];
 
    [self.currentTempLabel setText:[NSString stringWithFormat:@"%d", weather.currentTemp]];
    [self.highTempLabel setText:[NSString stringWithFormat:@"%d", weather.highTemp]];
    [self.lowTempLabel setText:[NSString stringWithFormat:@"%d", weather.lowTemp]];
    [self.conditionsLabel setText:weather.condition];
    [self.cityLabel setText:weather.location];
 
    [weather release];
}

Of course make sure your NIB is connected to your IBOutlets properly.

Now the final piece:

[self performSelectorInBackground:@selector(showWeatherFor:) withObject:@"97217"];

Build and Run:

And you’re done!

You can see the complete class below. I’ve also posted a demo project to github.

My name is Matt Tuzzolo (@matt_tuzzolo). I hope you found this post helpful.

//
//  LocalWeatherViewController.h
//  LocalWeather
//
//  Created by Matt Tuzzolo on 8/30/10.
//  Copyright iCodeBlog LLC 2010. All rights reserved.
//
 
#import 
#import "MapKit/MapKit.h"
 
@interface LocalWeatherViewController : UIViewController  {
    IBOutlet UILabel *currentTempLabel, *highTempLabel, *lowTempLabel, *conditionsLabel, *cityLabel;
    IBOutlet UIImageView *conditionsImageView;
    UIImage *conditionsImage;
}
 
@property (nonatomic,retain) IBOutlet UILabel *currentTempLabel, *highTempLabel, *lowTempLabel, *conditionsLabel, *cityLabel;
@property (nonatomic,retain) IBOutlet UIImageView *conditionsImageView;
@property (nonatomic,retain) UIImage *conditionsImage;
 
- (void)updateUI:(ICB_WeatherConditions *)weather;
 
@end

And the .m:

//
//  LocalWeatherViewController.m
//  LocalWeather
//
//  Created by Matt Tuzzolo on 8/30/10.
//  Copyright iCodeBlog LLC 2010. All rights reserved.
//
 
#import "LocalWeatherViewController.h"
#import "ICB_WeatherConditions.h"
#import "MapKit/MapKit.h"
 
@implementation LocalWeatherViewController
 
@synthesize currentTempLabel, highTempLabel, lowTempLabel, conditionsLabel, cityLabel;
@synthesize conditionsImageView;
@synthesize conditionsImage;
 
- (void)viewDidLoad {
    [super viewDidLoad];
 
    if (1) //you have coordinates but need a city
    {
        // Check out Part 1 of the tutorial to see how to find your Location with CoreLocation
        CLLocationCoordinate2D coord;
        coord.latitude = 45.574779;
        coord.longitude = -122.685366;
 
        // Geocode coordinate (normally we'd use location.coordinate here instead of coord).
        // This will get us something we can query Google's Weather API with
        MKReverseGeocoder *geocoder = [[MKReverseGeocoder alloc] initWithCoordinate:coord];
        geocoder.delegate = self;
        [geocoder start];
    }
    else // You already know your users zipcode, city, or otherwise.
    {
        // Do this in the background so we don't lock up the UI.
        [self performSelectorInBackground:@selector(showWeatherFor:) withObject:@"97217"];
    }
}
 
- (void)showWeatherFor:(NSString *)query
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 
    ICB_WeatherConditions *weather = [[ICB_WeatherConditions alloc] initWithQuery:query];
 
    [self.currentTempLabel setText:[NSString stringWithFormat:@"%d", weather.currentTemp]];
    [self.highTempLabel setText:[NSString stringWithFormat:@"%d", weather.highTemp]];
    [self.lowTempLabel setText:[NSString stringWithFormat:@"%d", weather.lowTemp]];
    [self.conditionsLabel setText:weather.condition];
    [self.cityLabel setText:weather.location];
 
    self.conditionsImageView.image = [UIImage imageWithData:[NSData dataWithContentsOfURL:weather.conditionImageURL]];
 
    [weather release];
 
    [pool release];
}
 
#pragma mark MKReverseGeocoder Delegate Methods
- (void)reverseGeocoder:(MKReverseGeocoder *)geocoder didFindPlacemark:(MKPlacemark *)placemark
{
    [geocoder release];
    [self performSelectorInBackground:@selector(showWeatherFor:) withObject:[placemark.addressDictionary objectForKey:@"ZIP"]];
}
 
- (void)reverseGeocoder:(MKReverseGeocoder *)geocoder didFailWithError:(NSError *)error
{
    NSLog(@"reverseGeocoder:%@ didFailWithError:%@", geocoder, error);
    [geocoder release];
}
 
- (void)didReceiveMemoryWarning {
     [super didReceiveMemoryWarning];
}
 
- (void)viewDidUnload {
	// Release any retained subviews of the main view.
	// e.g. self.myOutlet = nil;
}
 
- (void)dealloc {
    [super dealloc];
}
 
@end

Adding Local Weather Conditions To Your App (Part 1/2: Implementing CoreLocation)

Matt Tuzzolo — Fri, 03 Sep 2010 22:45:12 +0000

Knowing the latitude and longitude of your users can open up all kinds of possibilities in your apps. In an upcoming post, we’ll be discussing how you can use your user’s location to determine their local weather conditions and forecast. But for now, we’re going to focus on Part 1 of this two part tutorial: CoreLocation.

Apple’s done a great job of abstracting GPS, Cellular Triangulation, and Wifi Access Point location lookups into CoreLocation; making it extremely easy to determine the approximate location of your user regardless of their device and network connectivity. Additionally, Apple’s new iPhone Simulator finally supports CoreLocation as well. This significantly eases the process of testing your location code.

The first thing you’ll need to do is add the CoreLocation framework to your project. This is pretty straightforward. Command-Click on ‘Frameworks’ -> Add -> Existing Frameworks

Select ‘CoreLocation.framework’ and click ‘add’.

The class below implements the LocationManager delegate methods required to get the user’s location. You can just as easily implement the LocationManagerDelegate protocol in your AppDelegate or elsewhere in your App. Though I’ve found that having this class makes it super easy to drop in location support into new projects instead of having to cut/paste delegate methods (ugly). Anyway. Take a look:

//
//  LocationGetter.h
//  CoreLocationExample
//
//  Created by Matt on 9/3/10.
//  Copyright 2009 iCodeBlog. All rights reserved.
//
 
#import 
#import 
 
@protocol LocationGetterDelegate
@required
- (void) newPhysicalLocation:(CLLocation *)location;
@end
 
@interface LocationGetter : NSObject  {
    CLLocationManager *locationManager;
    id delegate;
}
 
- (void)startUpdates;
 
@property (nonatomic, retain) CLLocationManager *locationManager;
@property(nonatomic , retain) id delegate;
@end

Notice that we’re defining our own protocol with a method that takes the new CLLocation as a parameter. We’ll be implementing that delegate method in a minute. Now for the class

//  LocationGetter.m
//  CoreLocationExample
//
//  Created by Matt on 9/3/10.
//  Copyright 2009 iCodeBlog. All rights reserved.
//
 
#import "LocationGetter.h"
#import 
 
@implementation LocationGetter
 
@synthesize locationManager, delegate;
BOOL didUpdate = NO;
 
- (void)startUpdates
{
    NSLog(@"Starting Location Updates");
 
    if (locationManager == nil)
        locationManager = [[CLLocationManager alloc] init];
 
    locationManager.delegate = self;
 
    // locationManager.distanceFilter = 1000;  // update is triggered after device travels this far (meters)
 
    // Alternatively you can use kCLLocationAccuracyHundredMeters or kCLLocationAccuracyHundredMeters, though higher accuracy takes longer to resolve
    locationManager.desiredAccuracy = kCLLocationAccuracyKilometer;
    [locationManager startUpdatingLocation];
}
 
- (void)locationManager:(CLLocationManager *)manager didFailWithError:(NSError *)error
{
    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Error" message:@"Your location could not be determined." delegate:nil cancelButtonTitle:@"OK" otherButtonTitles: nil];
    [alert show];
    [alert release];
}
 
// Delegate method from the CLLocationManagerDelegate protocol.
- (void)locationManager:(CLLocationManager *)manage didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation *)oldLocation
{
    if (didUpdate)
        return;
 
    didUpdate = YES;
    // Disable future updates to save power.
    [locationManager stopUpdatingLocation];
 
    // let our delegate know we're done
    [delegate newPhysicalLocation:newLocation];
}
 
- (void)dealloc
{
    [locationManager release];
 
    [super dealloc];
}
 
@end

CoreLocation gives you a few options for the accuracy of the user’s location. The more accurate the measurement, typically the longer it takes LocationManager to call it’s delegate method didUpdateToLocation. It’s just something to keep in mind when deciding what level of accuracy to use.

Next we need to actually invoke this code and start getting location updates. I usually do this in my AppDelegate’s didFinishLaunchingWithOptions, though you could also do it in viewDidLoad somewhere if you didn’t need to know the user’s location on app startup.

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
 
    UIActivityIndicatorView *spinner = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge];
	spinner.center = CGPointMake(self.viewController.view.frame.size.width / 2, self.viewController.view.frame.size.height / 2);
    [spinner startAnimating];
 
    [viewController.view addSubview:spinner];
 
    // get our physical location
    LocationGetter *locationGetter = [[LocationGetter alloc] init];
    locationGetter.delegate = self;
    [locationGetter startUpdates];
 
    // Add the view controller's view to the window and display.
    [window addSubview:viewController.view];
    [window makeKeyAndVisible];
 
    return YES;
}

Notice that I’ve set locationGetter’s delegate to self. So in your .h, make sure to add LocationGetterDelegate to the interface.

//
//  CoreLocationExampleAppDelegate.h
//  CoreLocationExample
//
//  Created by Matt Tuzzolo on 9/3/10.
//  Copyright iCodeBlog 2010. All rights reserved.
//
 
#import 
#import "LocationGetter.h"
 
@class CoreLocationExampleViewController;
 
@interface CoreLocationExampleAppDelegate : NSObject  {
    UIWindow *window;
    CoreLocationExampleViewController *viewController;
    CLLocation *lastKnownLocation;
}
 
@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet CoreLocationExampleViewController *viewController;
@property (nonatomic, retain) CLLocation *lastKnownLocation;
 
@end

I’ve also added a CLLocation *lastKnownLocation that we’ll use in our delegate method (which comes next):

# pragma mark -
# pragma mark LocationGetter Delegate Methods
 
- (void)newPhysicalLocation:(CLLocation *)location {
 
    // Store for later use
    self.lastKnownLocation = location;
 
    // Remove spinner from view
    for (UIView *v in [self.viewController.view subviews])
    {
        if ([v class] == [UIActivityIndicatorView class])
        {
            [v removeFromSuperview];
            break;
        }
    }
 
    // Alert user
    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Location Found" message:[NSString stringWithFormat:@"Found physical location.  %f %f", self.lastKnownLocation.coordinate.latitude, self.lastKnownLocation.coordinate.longitude] delegate:nil cancelButtonTitle:@"OK" otherButtonTitles: nil];
    [alert show];
    [alert release];
 
    // ... continue with initialization of your app
}

This last piece takes care of storing the location, removing the spinner, and firing off an alert. If this was your code, you’d probably want to re-enable any UI elements that you’ve disabled and let the user start using your app.

Now build and run your app and you should see:

That’s it!

Here’s the Example Project for the post.

For those of you who don’t know me yet, my name is Matt Tuzzolo (@matt_tuzzolo). This is my first iCodeBlog post. I hope you enjoyed it.