View source for The iOS 8 Application and Development Architecture

<table border="0" cellspacing="0" width="100%">
<tr>
<td width="20%">[[Working with Array and Dictionary Collections in Swift|Previous]]<td align="center">[[iOS 8 App Development Essentials|Table of Contents]]<td width="20%" align="right">[[Creating an Interactive iOS 8 App (Swift)|Next]]</td>
<tr>
<td width="20%">Working with Array and Dictionary Collections in Swift<td align="center"><td width="20%" align="right">Creating an Interactive iOS 8 App (Swift)</td>
</table>
<hr>


<google>BUY_IOS8</google>


So far we have covered a considerable amount of ground intended to provide a sound foundation of knowledge on which to begin building iOS 8 based apps. Before plunging into more complex apps, however, it is vital that you have a basic understanding of some key methodologies associated with the overall architecture of iOS applications.

These methodologies, also referred to as design patterns, clearly define how your applications should be designed and implemented in terms of code structure. The patterns we will explore in this chapter are Model View Controller (MVC), Subclassing, Delegation and Target-Action.

It is also useful to gain an understanding of how iOS 8 itself is structured in terms of operating system layers.

If you are new to these concepts this can seem a little confusing to begin with. Much of this will become clearer, however, once we start working on some examples in subsequent chapters.

== An Overview of the iOS 8 Operating System Architecture ==

iOS consists of a number of different software layers, each of which provides programming frameworks for the development of applications that run on top of the underlying hardware.

These operating system layers can be presented diagrammatically as illustrated in Figure 15-1:
 

[[Image:iOS8Architecture.png|The iOS 8 architecture]]

Figure 15-1


Some diagrams designed to graphically depict the iOS software stack show an additional box positioned above the Cocoa Touch layer to indicate the applications running on the device. In the above diagram we have not done so since this would suggest that the only interface available to the app is Cocoa Touch. In practice, an app can directly call down to any of the layers of the stack to perform tasks on the physical device. 

That said, however, each operating system layer provides an increasing level of abstraction away from the complexity of working with the hardware. As an iOS developer you should, therefore, always look for solutions to your programming goals in the frameworks located in the higher level iOS layers before resorting to writing code that reaches down to the lower level layers. In general, the higher level of layer you program to, the less effort and fewer lines of code you will have to write to achieve your objective. And as any veteran programmer will tell you, the less code you have to write the less opportunity you have to introduce bugs.

== Model View Controller (MVC) ==

In the days before object-oriented programming (and even for a time after object-oriented programming became popular) there was a tendency to develop applications where the code for the user interface was tied tightly to the code containing the application logic and data handling. This coupling made application code difficult to maintain and locked the application to a single user interface. If, for example, an application written for Microsoft Windows needed to be migrated to Mac OS, all the code written specifically for the Windows UI toolkits had to be ripped out from amongst the data and logic code and replaced with the Mac OS equivalent. If the application then needed to be turned into a web based solution, the process would have to be repeated again. Attempts to achieve this feat were usually found to be prohibitively expensive and ultimately ended up with the applications being completely re-written each time a new platform needed to be targeted.

The goal of the MVC design pattern is to divorce the logic and data handling code of an application from the presentation code. In this concept, the Model encapsulates the data for the application, the View presents and manages the user interface and the Controller provides the basic logic for the application and acts as the go-between, providing instructions to the Model based on user interactions with the View and updating the View to reflect responses from the Model. The true value of this approach is that the Model knows absolutely nothing about the presentation of the application. It just knows how to store and handle data and perform certain tasks when called upon by the Controller. Similarly, the View knows nothing about the data and logic model of the application.

Within the context of an object-oriented programming environment such as the iOS 8 SDK and Swift, the Model, View and Controller components are objects. It is also worth pointing out that applications are not restricted to a single model, view and controller. In fact, an app can consist of multiple view objects, controller objects and model objects.

The way that a view controller object interacts with a Model is through the methods and properties exposed by that model object. This, in fact, is no different from the way one object interacts with another in any object-oriented programming environment. 

In terms of the view controller’s interactions with the view, however, things get a little more complicated. In practice, this is achieved using the Target-Action pattern, together with Outlets and Actions.
<google>BUY_IOS8</google>
== The Target-Action pattern, IBOutlets and IBActions ==

When you create an iOS 8 app you will typically design the user interface (the view) using the Interface Builder tool and write the view controller and model code in Swift using the Xcode code editor. The previous section looked briefly at how the view controller interacts with the model. In this section we will look at how the view created in Interface Builder and our view controller code interact with each other.

When a user interacts with objects in the view, for example touching and releasing a button control, an event is triggered (in this case the event is called a Touch Up Inside event). The purpose of the Target-Action pattern is to allow you to specify what happens when such events are triggered. In other words, this is how you connect the objects in the user interface you have designed in the Interface Builder tool to the back end Swift code you have written in the Xcode environment. Specifically, this allows you to define which method of which controller object gets called when a user interacts in a certain way with a view object.

The process of wiring up a view object to call a specific method on a view controller object is achieved using something called an Action. An action is a method defined within a view controller object that is designed to be called when an event is triggered in a view object. This allows us to connect a view object created within Interface Builder to the code that we have written in the view controller class. This is one of the ways that we bridge the separation between the View and the Controller in our MVC design pattern. As we will see in Creating an Interactive iOS 8 App, action methods are declared using the IBAction keyword.

The opposite of an Action is the Outlet. As previously described, an Action allows a view object to call a method on a controller object. An Outlet, on the other hand, allows a view controller object method to directly access the properties of a view object. A view controller might, for example, need to set the text on a UILabel object. In order to do so an Outlet must first have been defined using the IBOutlet keyword. In programming terms, an IBOutlet is simply an instance variable that references the view object to which access is required.

== Subclassing ==

Subclassing is an important feature of any object-oriented programming environment and the iOS SDK is no exception to this rule. Subclassing allows us to create a new class by deriving from an existing class and then extending the functionality. In so doing we get all the functionality of the parent class combined with the ability to extend the new class with additional methods and properties. 
Subclassing is typically used where a pre-existing class does most, but not all, of what you need. By subclassing we get all that existing functionality without having to duplicate it and simply add on the functionality that was missing.

We will see an example of subclassing in the context of iOS 8 development when we start to work with view controllers. The UIKit Framework contains a class called the UIViewController. This is a generic view controller from which we will create a subclass so that we can add our own methods and properties.

== Delegation ==

Delegation allows an object to pass the responsibility for performing one or more tasks on to another object. This allows the behavior of an object to be modified without having to go through the process of subclassing it.

A prime example of delegation can be seen in the case of the UIApplication class. The UIApplication class, of which every iOS application must have one (and only one) instance, is responsible for the control and operation of the application within the iOS environment. Much of what the UIApplication object does happens in the background. There are, however, instances where it gives us the opportunity to include our own functionality into the mix. UIApplication allows us to do this by delegating some methods to us. As an example, UIApplication delegates the didFinishLaunchingWithOptions method to us so that we can write code to perform specific tasks when the app first loads (for example taking the user back to the point they were at when they last exited). If you still have a copy of the Hello World project created earlier in this book you will see the template for this method in the AppDelegate.swift file.

== Summary ==

In this chapter we have provided an overview of a number of design patterns and discussed the importance of these patterns in terms of structuring iOS 8 applications. Whilst these patterns may seem unclear to some, the relevance and implementation of such concepts will become clearer as we progress through the examples included in subsequent chapters of this book.


<google>BUY_IOS8</google>


<table border="0" cellspacing="0" width="100%">
<tr>
<td width="20%">[[Working with Array and Dictionary Collections in Swift|Previous]]<td align="center">[[iOS 8 App Development Essentials|Table of Contents]]<td width="20%" align="right">[[Creating an Interactive iOS 8 App (Swift)|Next]]</td>
<tr>
<td width="20%">Working with Array and Dictionary Collections in Swift<td align="center"><td width="20%" align="right">Creating an Interactive iOS 8 App (Swift)</td>
</table>