Recap of Storyboards, MapKit and Navigation Demo

Updated Oct 4 2013: This tutorial is compatible with XCode 5 AND XCode 4!

We’re taking a practical approach to learning iOS programming. This means lots of hands on work and practice!
In order to benefit the most from these lessons, you should open XCode and try to follow along.

This is part 9 of the lesson plan. Click here for the entire Learning Plan.

Multi-View App Flow

In the previous tutorial, we introduced Storyboards and you saw how easily we could hook up two views and navigate between them.

The app flow looked like this:

XCode Storyboard Demo App Flow

Do you remember when you selected the first ViewController and selected a menu option called “Embed In Navigation Controller”?

What that effectively does, is create a UINavigationController and then sets that first ViewController as a child of the Navigation Controller so that the Navigation Controller can manage it.

Then instead of the AppDelegate having a reference to the single ViewController, it sets the AppDelegate to hold a reference to the Navigation Controller.

That’s how you end up with the app flow in the diagram above.

What’s a Navigation Controller?

So what is a navigation view controller? It’s a special UIViewController that manages other viewcontrollers (Apple Doc here).

It has a property called “viewControllers” which acts like a bucket for ViewControllers that you can add to or remove from.

The Navigation Controller also provides methods to transition between any of the ViewControllers in the “bucket”.

Navigation Controller’s ViewController Stack

The “bucket” actually behaves more like a stack of papers. When ViewControllers are added to the stack, they are at the top of the stack.

In order to get to the ViewControllers below, you have to remove the ones above it.

Also, the ViewController at the top of the stack is the ViewController that is visible.

What’s a “push” Transition?

Remember when you hooked up the button in the first ViewController to transition to the second ViewController? We chose the option “push” for that transition.

What’s happening is the following:

Initially you only have the first ViewController in the stack so it’s visible to the user

XCode Storyboard Navigation Controller ViewControllers Stack Diagram with 1 ViewController

Then when the user clicks the button, the second ViewController gets added to the top of the stack so now the second ViewController is what the user sees.

XCode Storyboard Navigation Controller ViewControllers Stack Diagram with 2 ViewControllers

Then when the user hits the “back” button, the top ViewController gets removed, and the user once again is looking at the first ViewController

XCode Storyboard Navigation Controller ViewControllers Stack Diagram When Navigating Back

Modal transition

Another option is to present the second ViewController as a modal of the first ViewController.

You see, ViewControllers have an ability to present another ViewController as a modal and it looks like this:

XCode Storyboard Navigation Controller ViewControllers Stack Diagram With Modal View Controller

In this case, the first ViewController has a reference to the second ViewController and it controls whether the second ViewController is displayed or not.

In the “push” case, the navigation controller has a reference to both ViewControllers so it’s the “parent” of both of them.

You can read more about how to use Modal ViewControllers in the Apple Documentation, Presenting View Controllers from Other View Controllers.

Adding frameworks

When we were working with the Map, we needed to add some additional frameworks for the map functionality.

The reason for this is because most of the time, apps don’t need access to the full feature set so by default, your XCode project only includes some basic frameworks that are common to all apps. By only including what you need, you save space and memory so that your app is as lean and fast as possible.

In the future, most likely you’ll need to add frameworks again for functionality such as social, mailing etc.

Subclassing and Overriding Methods

In Object Oriented Programming (which is the form of programming you’re learning now), there’s a concept of class inheritance.

This means that when we create a class, we can make it a “Subclass” of another class.

For example, let’s say we have a class called Car which contains a method called “Drive” and a property “TransmissionType”.

All cars have a transmission type. Furthermore, all cars should be able to be driven.

Now what if we wanted to create another class called “BMWCar”?

We could create it as a standalone class and then declare a “Drive” method inside of it and a “TransmissionType” property.

But instead of that, we could make the class, BMWCar, a subclass of the Car class.
In this arrangement, the Car class is the parent and BMWCar class is the child.

This allows the BMWCar class to “inherit” all the properties and methods of Car so you don’t have to rewrite it. When another object calls the “Drive” method of a BMWCar object, it’ll be calling the “Drive” method defined in the parent Car class.

Likewise, BMWCar has the “TransmissionType” property simply by subclassing Car.

Objective-C Subclassing Diagram

In the header file, BMWCar.h, you’ll notice that the colon followed by the parent class.

This is how you specify if the class is a subclass of another. The class on the right side of the colon is the class that this one is subclassing.

Overriding Methods

Overriding methods is a way for a subclass to specify it’s own unique implementation of a method in it’s parent class.

In the Car example above, the Car class has a Drive method that the BMWCar class inherits. That means that if you create a BMWCar object, you can call the Drive method on it even though the BMWCar class doesn’t explicitly define a Drive method.

When you call the Drive method on a BMWCar object, it’ll run the parent class’s implementation of the method. In other words, when you call the Drive method on a BMWCar object, it’ll run the code defined in the Drive method of the Car class.

Now what if you wanted to do something different in BMWCar’s Drive method? You could override the Drive method by re-defining the implementation of the Drive method in BMWCar.m, the implementation file. (No need to redeclare the method in BMWCar’s header file)

In the previous tutorial, you’ll notice that we typed out a “viewDidAppear” method and you’ll also notice in ViewController.h that ViewController is a subclass of UIViewController.

Little did you know, you were actually overriding the “viewDidAppear” method of the parent class, UIViewController!

The parent class, UIViewController, has a couple of methods like “viewDidLoad”, “viewWillAppear” etc. but by default, they’re empty implementations.

When you redefine the implementation of them in your own ViewController.m file, you’re overriding the method and providing your own custom code.

ViewController Lifecycle

Speaking of viewDidLoad and viewDidAppear, we’ve been using them but we haven’t talked about ViewController lifecycle.

Here are some methods you can override and when they’re called:

viewDidLoad – This method is called when you create the class and after it loads the XIB file. Ideally, you put code in here that is needed for setup of the view controller.

viewWillAppear – This method is called right before the view appears and is good putting code that needs to hide/show UIElements or any other code that needs to happen every time the view transitions from being not visible to being displayed. Remember that if your app has multiple views, the code in this method may be called multiple times (each time you switch to this view controller from another one). At this point, the view is not visible to the user yet.

viewDidAppear – This is called right after the view appears. At this point, the view is visible to the user and you can start any animations or other code that needs to execute after the user sees the view.

viewWillDisappear and viewDidDisappear – These two methods are the opposite of the Will/DidAppear methods and these methods can be used for resetting state or doing animations as the user leaves the view.

viewDidUnload – The opposite of viewDidLoad and is used for any sort of cleanup tasks as the user leaves the

What’s Next?

You might not have fully understood all of it yet, but you will as we practice more and naturally, you’ll have more and more questions as you begin to grasp iOS development.

I have a premium video course offering where I provide this personal mentorship and you’ll go deeper into the concepts that you’ve been introduced to in this short introductory series.

I’m getting really positive feedback from current members and many have successfully begun to build their own apps!

Click here get the details!

Frequently Asked Questions

If you have a question related to this tutorial or need me to clarify something, please ask in the comments below and I’ll update this FAQ section for everyone’s benefit.