This article is based on iPhone and iPad in Action, published on August, 2010. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code ‘java40beat’ and get 40% discount on eBooks and pBooks ]

Adding a map to an application

Introduction

Adding a map to any application is very similar to adding any other view. You can either do it through Interface Builder or programmatically. The choice is up to you depending on how you like to work with UI elements. We will show you both methods.

The view that displays a map is called MKMapView. This class contains quite a bit of functionality including how to display the map, annotations, and user location. We will first be discussing how to add an MKMapView through Interface Builder. Once we add the map to the view, we will connect it to an IBOutlet and set its delegate class.

Adding the map using Interface Builder

Before you start coding the MKMapView, you must first import MapKit.framework. This will provide you will all of the libraries needed to work with maps.

To add a map to your view, your must first create an MKMapView IBOutlet in the class that will be using the map. Listing 1 shows how to do this.

Listing 1 Declaring an IBOutlet for an MKMapView
[code]#import <UIKit/UIKit.h>
#import <MapKit/MapKit.h>
@interface SimpleMapViewController : UIViewController<MKMapViewDelegate> {
IBOutlet MKMapView * theMap;
}[/code]
@property (nonatomic, retain) IBOutlet MKMapView * theMap;
The first thing we want to point out is you must import the MapKit.h header file. This is included in MapKit.framework and is needed for all MapKit interaction. The second is, our class implements the MKMapViewDelegate interface. It will allow this class to become the delegate of the MKMapView and receive messages from it. In addition to making a property, you should also synthesize the map property in the .m file.

Now that the IBOutlet has been declared, you need to add the MKMapView to the view in the nib file. To do this open up the nib file associated with the class that contains your IBOutlet. Now, select MKMapView from the Library and drag it on to your view. Figure 1 shows what this object should look like.

Figure 1 Adding an MKMapView to your viewWhen you drag the map on to you view, you are able to move and resize it however you like. Now that it has been added, you must connect it to the IBOutlet. To do this, click on the File’s Owner object and open the Connections Inspector. Now, drag from the map outlet to the map view to make the connection.

The last thing that needs to be done is set the delegate of the MKMapView. To do this, right click on the map and drag to the File’s Owner object. It should pop up a bubble that reads, “delegate”. Click the word delegate to make the connection. Figure 2 shows what the Connection Inspector should look like after you have completed all of these steps.

Figure 2 Connection inspector for the MKMapView connectionsAs you can see, adding an MKMapView using Interface Building is about the same as adding UILabels, UITextFields, and other view elements. Now that you have seen how to add the map visually, we will show you how to add one programmatically.

Adding the map programmatically

As noted before, whether you add the map using Interface Builder or with code is up to you. It is completely dependent on your preferences and organization technique. Listing 2 demonstrates how to add an MKMapView to your view controller’s view using code.

Listing 2 Adding an MKMapView programmatically
[code]- (void)viewDidLoad {
[super viewDidLoad];
MKMapView * map = [[MKMapView alloc] initWithFrame:
CGRectMake(0, 0, 320, 480)];
Map.delegate = self;
[self.view addSubview:map];
}[/code]
This code is actually quite short. We create the map using a frame, set its delegate to our class, and add it to our class’ view. As with any other view, modifying the frame passed to the map will alter its size and position.

Controlling the map

By default, the map has gives the user a bit of control. Without any additional code, they have the ability to scroll all over the world by flicking the map. Also, the map comes with the ability to zoom in and out by using the pinch and pull gestures.

To navigate the map programmatically, you must specify a region. Doing this will allow you to move the map to a specified location. You will also have the ability to set the zoom level.

Let’s examine the region properties and methods for navigating the map. Table 1 discusses these properties and methods and their uses.

The code below shows you how to create an MKCoordinateRegion and move the map to display it on the screen. The method we created here fires when a user presses a button titled Apple. It will move the map from its current location to center on Apple’s headquarters in Cupertino.

Listing 3 moving the map to a given location
[code]- (IBAction) apple:(id) sender {
CLLocationCoordinate2D coords;
coords.latitude = 37.33188;
coords.longitude = -122.029497;
MKCoordinateSpan span = MKCoordinateSpanMake(0.002389, 0.005681);
MKCoordinateRegion region = MKCoordinateRegionMake(coords, span);
[theMap setRegion:region animated:YES];
}[/code]
The first thing we see here is a CLLocationCoordinate2D being created. This is simply a struct that holds two doubles for latitude and longitude. Next, we assign them to the coordinates of Apple using the WGS 84 reference frame.

Following the coordinates, we create a span using the MKCoordinateSpanMake method. An MKCoordinateSpan is a struct made of two doubles that represent a delta for latitude and longitude. The span represents the amount of area to view and is used when setting the zoom level. A larger number here tells the map to show a larger view area resulting in the map zooming out. Similarly, a smaller number tells the map to show less area and causes it to zoom in.

Once the coordinates and span have been initialized, we can create a region using the MKCoordinateRegionMake method. Finally, we set the region of the map to our newly created one and animate the transition. In addition to controlling the map’s location, you can also control how the user can interact with it. Table 2 details these properties.

As mentioned above, the mapType property allows you to display the map in three different ways. Most likely, you will want to make this configurable by the user, as preferences tend to vary about how the map should display. Figure 3 shows the difference between the map types.

Figure 3 mapTypes: (from left to right) MKMapTypeStandard, MKMapTypeSattelite, MKMapTypeHybridAs you can see, you have quite a bit of control over how the map looks. The standard map view looks very much like a road map that you would use for navigation. This is often the most useful of the map types.

The other two are quite similar. The only difference between them is the hybrid view contains the road names in addition to displaying the satellite photos.

This article is based on iPad in Practice, to be published on Summer 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code ‘java40beat’ and get 40% discount on eBooks and pBooks ]

Using an alert view as a task loader

Introduction

Some actions, like signing out of an account in an application, require a user to both confirm the action and to indicate the processing of the action. When you need to present this type of flow to a user, an interesting option is to present an alert with a confirm/cancel option and then to use the alert as a loader while the action is being processed.

Problem

Providing a loader during different types of operations can be a very valuable user interaction technique. One approach to doing so is by providing a loader as part of an alert view interaction.

Solution

Our app is going have one view with a button to fire the alert interaction. When the user taps the button, we display an alert that gives them the choice to sign out of the application. If they tap the action button, we display a loader and process the action. Once the action is completed, we display a second alert view that confirms the completion of the action.

Start by creating a new project. Call it AlertLoader and select a view-based project as the project type. Click on the AlerLoaderViewController.h header file as in listing 1 to start setting up the view controller.

Listing 1 AlertLoaderViewController.h header
[code]#import
@interface AlertLoaderViewController : UIViewController {
UIAlertView *alertView;
}
@property(nonatomic, retain) UIAlertView *alertView; #1
– (IBAction) signout; #2
– (void) runProcess; #2
– (void) showAlertLoader; #2
@end

#1 UIAlertView property
#2 Function and action declarations[/code]
In the header file, we define a single property (#1), which is a UIAlertView. This is the alert view we’ll be using to control our interaction and to display the loader. We also declare three functions (#2) on IBAction, which will be attached to our button to start the interaction. The other two we’ll review in the implementation of the controller. Edit your header file to implement the property and function declarations.

Now double-click on the AlertLoaderViewController.xib to modify the UI in the interface builder. Your view will be pretty much empty; all you need to do is drag a single UIButton on the view and give it the title Sign Out. Now, connect the button to the IBAction signout on the controller as shown in figure 1.

The core of the solution is in the implementation of the controller where we implement the alert interactions. Let’s take a look at that next in listing 2.

Listing 2 AlertLoaderViewController.m implementation
[code]#import "AlertLoaderViewController.h"
#define START_RUNNING_INDEX 1
#define PROCESS_LOADING_TAG 200
#define PROCESS_LABEL_TAG 201
@implementation AlertLoaderViewController
@synthesize alertView;
#pragma mark –
#pragma mark AlertView Delegate methods
(void)alertView:(UIAlertView *)alertView #1
clickedButtonAtIndex:(NSInteger)buttonIndex { #1
if(START_RUNNING_INDEX == buttonIndex) #1
[self runProcess]; #1
}
#pragma mark –
#pragma mark Sync now
– (IBAction) signout { #2
NSLog(@"sync now"); #2
self.alertView = [[[UIAlertView alloc] #2
initWithTitle:@"Sign Out" #2
message:@"Sign Out" #2
delegate:self #2
cancelButtonTitle:@"Cancel" #2
otherButtonTitles:@"Confirm", nil] autorelease]; #2
UIActivityIndicatorView *loading = #2
[[UIActivityIndicatorView alloc] #2
initWithActivityIndicatorStyle: #2
UIActivityIndicatorViewStyleWhiteLarge]; #2
loading.frame = CGRectMake(122.0, 40.0, #2
loading.frame.size.width, #2
loading.frame.size.width); #2
loading.tag = PROCESS_LOADING_TAG; #2
[loading stopAnimating]; #2
[alertView addSubview:loading]; #2
[loading release]; #2
[alertView show]; #2
} #2
– (void) showAlertLoader { #3
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; #3
[(UIActivityIndicatorView *) #3
[self.alertView viewWithTag:PROCESS_LOADING_TAG] #3
startAnimating]; #3
[(UILabel *)[self.alertView viewWithTag:PROCESS_LABEL_TAG] #3
setHidden:NO]; #3
self.alertView.title = @"Processing…"; #3
self.alertView.message = @""; #3
[pool release]; #3
} #3
#pragma mark –
– (void) runProcess { #4
[NSThread detachNewThreadSelector:@selector(showAlertLoader) #4
toTarget:self #4
withObject:nil]; #4
[NSThread sleepForTimeInterval:10]; #4
UIAlertView *alert = [[[UIAlertView alloc] #4
initWithTitle:@"Completed" #4
message:@"Sign out completed" #4
delegate:nil #4
cancelButtonTitle:@"OK" #4
otherButtonTitles:nil] autorelease]; #4
[alert show]; #4
} #4
– (BOOL)shouldAutorotateToInterfaceOrientation:
(UIInterfaceOrientation)interfaceOrientation {
return YES;
}
– (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning];
}
– (void)dealloc {
[alertView release];
[super dealloc];
}
@end
#1 Alert view delegate function
#2 Display alert and init loader
#3 Display the loader
#4 runProcess our fake worker function[/code]
The AlertLoaderViewController first implements the UIAlertView delegate protocol at #1 by implementing alertView:clickedButtonAtIndex: function, which is called when an alert view button is tapped. In this case, we have a constant START_RUNNING_INDEX, which is used to match the action button index for our main alert view.

At #2, we implement the signout IBAction, which is responsible for displaying the choice alert view to our user. When we create the alert view we also create a UIActivityIndicatorView, which will be our loader, set its frame, and add it as a subview to the alert view. You’ll notice that we call stopAnimating on the activity indicator. The default behavior of the activity indicator is to hide itself when it is not animation. So, we call stopAnimating when we add it and then later call startAnimating to display it. When signout is called, we get the alert view pictured in figure 2.

The showAlertLoader (#3) and runProcess (#4) functions work together. runProcess is actually what is called by our alert view delegate function when the user taps Confirm in the Sign Out alert. The runProcess function first fires off a call to showAlertLoader in the background using detachNewThreadSelector:toTarget:withObject:, which modifies the displayed loader to show our activity indicator, as depicted in figure 3.

Finally, in #4, after the loader has been displayed, we do our fake work. In this case, we just call sleepForTimeInterval: to pause the thread for 10 seconds as a simulation of doing some other work. Once the sleep completes, we create and show a new alert view to inform the user that the process has completed.

Discussion

Looking at this technique, we can see that it’s fairly simple; all it really does is add a subview to an alert view as a means of smoothing out some user interaction flow. It’s worth noting that this isn’t something to take too lightly. Adding a subview to a system view is accepted by Apple and I’ve used this approach in a few different applications in cases where it made sense. However, you need to be aware that trying to use private properties or views of a system view is a different story. I’ve heard it directly from Apple engineers that they not only frown upon trying to access and manipulate private components but that they are going to be checking for this and rejecting apps based on it. This particular technique doesn’t try to use or change the original UIAlertView other than clearing the text of the detail label, but going any farther may be walking a fine line with the app review team.

As shown in figure 4, after our loader has completed we show a confirmation loader, this is an optional extra piece of information you can show the user.

Summary

Alerts are a simple view, which was carried over from the iPhone SDK they give you a way to notify users of changes in state. You should try to use Alerts only in cases where it is really necessary to notify the user of a change that will impact their use of the application. Alerts views are extremely simple but can be very effective so it is a good idea to be familiar with how to use them.

We showed you how to set up one view with a button to fire the alert interaction so that, when the user taps the button, we display an alert that gives them the choice to sign out of the application. Tapping on the action button displayed a loader and processed the action at the same time. Once the action was completed, we displayed a second alert view that confirmed the completion of the action.