How To Make iPhone Apps – MVC, One Pattern To Rule Them All

Welcome to part 3 of my series on How To Make iPhone Apps with no programming experience – where we’ll turn even the non-programmer into an iOS developer! Here’s the article index for the entire series in case you missed it.

Today, we introduce the model view controller architecture pattern that all iOS apps are based off of! By the end of this tutorial, you’ll be armed with the practical knowledge of Objective-C from the previous 2 parts of this series and you’ll understand the concepts of architecting iPhone apps with MVC.

1. MVC – Introduction

As implied with the name, the MVC software design pattern refers to three separate roles: the model, the view and the controller.

The idea is that the objects in your application will take on these roles and work together to create and manage the user interface. Not all objects will assume one of these 3 roles; For example you might have a class that contains a bunch of helper methods however, the model, view and controller roles are the central actors to making your app function.

The Model

The model represents the data in your application. It’s responsible for sorting, validating and organizing your data.

The View

The view is the user interface or what the user sees and interacts with.

You can create views programmatically through code using Apple classes such as UIView or you can create a XIB file to represent the view and visually layout your elements through Interface Builder.

The Controller

The controller manages the communication between the view and the model. It takes the data from the model and communicates it to the view for display.

In the same vein, the controller also takes the changed data (due to user interaction or something else) and communicates it back to the model.

The Model And View Never Talk To Each Other
They shouldn’t even know about each other in the ideal case.

The beauty of this modular architecture is that the separation of roles allow us to make modifications easily with less bugs.

For example, if in the future, you need to make a change to the way the data is fetched or organized, all you need to do is switch out the model. As long as you keep the interface of the model the same (the header file), then the views and controllers will be none the wiser.

Here’s a diagram illustrating what we’ve talked about:

2. The Lifecycle Of ViewControllers

When the user sees a screen of your application, there’s a process of steps that happens. First a UIViewController gets loaded into memory, then it sets up the UIView and the view gets presented to the user. When the user moves on from that view, the UIView gets torn down and the UIViewController gets unloaded from memory.

In the UIViewController class, there are specific methods that you can override to perform tasks during each of those events.

@interface BaseViewController : UIViewController

- (void)resetView;

@end

@implementation BaseViewController

- (void)resetView
{
    // Some code to reset the view
}

@end

#import "BaseViewController.h"

// Notice this class is a subclass of BaseViewController (parent)
@interface HomeViewController : BaseViewController

@end

@implementation HomeViewController

- (void)resetView
{
    // This will call the resetView method in the parent
    [super resetView];
    
    // Some additional code
}

@end

Back To The Lifecycle Of ViewControllers
So we were talking about how there are events at certain points in the lifecycle of viewcontrollers that you can override and execute code in.

Here they are:

ViewDidLoad

- (void)viewDidLoad
{
    [super viewDidLoad];
    // Do any additional setup after loading the view.
}

This method occurs after the view has been allocated and loaded into memory. Typically you’ll want to do any initialization of the views in this method such as setting properties of the view, calling methods of the view and generally getting it ready to be displayed to the user.

ViewWillAppear

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
}

As the name implies, the view is about to be rendered to the user.

You don’t want to execute any heavy code in here or else the user will notice a lag before the view shows up.

ViewDidAppear

- (void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];
}

At this point, the view has just been displayed to the user.

Here you may want to show additional views, animate other things in etc.

ViewWillDisappear

- (void)viewWillDisappear:(BOOL)animated
{
    [super viewWillDisappear:animated];
}

The view is about to be removed from the screen.

For example, you may want to use this opportunity to save certain values or user input.

ViewDidDisappear

- (void)viewDidDisappear:(BOOL)animated
{
    [super viewDidDisappear:animated];
}

After the view has disappeared from display.

For example, you may use this opportunity to display the next view.

You might not have the need to run code in all of these overridden methods, but the opportunity exists and you can do so in the right situation.

Let’s Summarize

This was a short post but nonetheless really important!

Now you understand:
-What MVC means!
-What the different roles of MVC are responsible for!
-How models, views and controllers interact with each other!
-The UIViewController life-cycle!

What’s Next?

This concludes the iOS app development tutorial. In the next part, we’ll get started with XCode and introduce you to the environment that you’ll be spending a lot of time in.

Go To Part 4