Navigation Controllers and Movie Multiplexes

Each page of an iOS application (sometimes referred to as a scene) is managed by a view controller. The purpose of the view controller is to coordinate between the view and model, in line with the Model-View-Controller (MVC) architecture used in iOS apps.

The various view controllers in the app are managed by a navigation controller, which stores them in an array. The navigation controller pushes view controllers onto the stack as needed. Initially, the root view controller will be at the top of the navigation stack. Each user action within the current view controller pushes a new view controller onto the stack. Going back from one screen to the previous one pops the current view controller off the stack, revealing the previous view controller that is now at the top of the stack.

At least, this is my current understanding of the relationship between the navigation controller and the various view controllers. I’ll add to this as my understanding evolves.

Perhaps we could think of this as being a little like a multiplex movie theatre with a single box office. Each room within the multiplex has its own projectionist (view controller). The user accesses the application through via the box office and is directed to the correct room (app page). Imagine a person with a special ticket that is good for any of the movies that are showing. All they have to do is return to the box office (navigation controller) and get directed to the correct room.

The analogy is not perfect because it does not quite capture the idea of the stack. But it illustrates the way the navigation controller controls which view the user sees, and the autonomy of each view to manage its own affairs.

Adding a New Image Button to an iOS Program

In iOS, a button can be represented by an image. Here’s how to add a new image to your Xcode project.

1. In images.xcassets, add a new image set (right-click and choose New Image Set).
2. Drag your images to the image set. Consider having different sizes for different purposes (retina screens vs older screens, and so forth).
3. In Attribute Manager, view the object library and drug a button to the storyboard.
4. Set the desired image to be the new graphic for the button (you must have the Assistant Editor selected and click on the Attributes Inspector in order to do this).
5. On the storyboard, Ctrl-drag to create an action for the new button.
6. Put code in the button’s new action.

Model - View - Controller (MVC)

iOS programs are functionally divided into three parts: model, view and controller. The model takes care of business logic. In a game, it would be keeping score, remembering moves and detecting invalid moves. In a text editor, it would store the file content (before saving it to disk), remember user changes if implementing an undo function, and carry out search and replace tasks.

The view implements the user interface. It provides the buttons on which the user clicks and any other controls with which the user interacts with the application.

The controller is responsible for dispatching messages between the view and the controller. It makes user interface objects appear and disappear, or change their appearance, and informs the model when the user has performed a UI action such as clicking on a button. Conversely, it informs the view when changes in the data managed by the model mean that the UI must be updated.

MVC architecture dates back to the mid-1970s when it was used in Smalltalk, an early object-oriented programming environment. Microsoft also uses MVC architecture in Windows programming, but has moved away from MVC terminology in recent technical papers. In fact, MVC architecture lends itself well to any message-driven programming environment. By “message-driven”, I mean an environment where a central dispatcher (controller) manages system messages that are triggered by user interface (view) actions such as mouse clicks, and where various snippets of business logic code (in the model) are executed in response.

Functionally separating code in this way makes code easier to read because user interface code and business logic are kept separate. In the 1980s and early 1990s it facilitated client-server architectures where the business logic ran on a different machine than the user interface. This is also the architecture of the web, where thin, browser-based clients implement the view, powerful web servers handle the model (often coordinating with other server-side resources such as database servers), and HTTP, the protocol of the web itself, serves as the controller.

I wasn’t planning to start a software development blog. But I’m currently dipping a toe in the water of iOS development by taking a Udacity course and have set this blog up as one of my class assignments. I’ll be using it to post my thoughts on iOS, and to make notes on things I want to remember. If it helps others to learn iOS programming, so much the better.

I’ve been writing code professionally for a long time, using C and C++, and later with PHP and Python. I’ve made three or four false starts in iOS programming. With the transition from Objective C to Swift, perhaps I’ve managed to skip an entire language. Or maybe I’ll need to learn Objective C later.

Anyway, here goes. Bracing myself for the shock of XCode and a backstage view of iOS, I’m about to dip my toe in the water.