Difference between revisions of "An Overview of the iPad iOS 5 Application Development Architecture"
m (Text replacement - "<google>ADSDAQBOX_FLOW</google>" to "<htmlet>adsdaqbox_flow</htmlet>") |
m (Text replacement - "<google>BUY_IOS5_IPAD</google>" to "<htmlet>ios9_upgrade</htmlet>") |
||
| Line 8: | Line 8: | ||
| − | < | + | <htmlet>ios9_upgrade</htmlet> |
| Line 55: | Line 55: | ||
| − | < | + | <htmlet>ios9_upgrade</htmlet> |
Revision as of 20:45, 1 February 2016
| Previous | Table of Contents | Next |
| The Basics of Object Oriented Programming in Objective-C (iOS 5) | Creating an Interactive iOS 5 iPad App |
Learn SwiftUI and take your iOS Development to the Next Level
|
So far we have covered a considerable amount of ground intended to provide a sound foundation of knowledge on which to begin building iPad iOS 5 based apps. Before plunging into writing your first app, however, it is vital that you have a basic understanding of some key methodologies associated with the overall architecture of an iOS application.
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.
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.
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 5 SDK and Objective-C, 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.
The Target-Action pattern, IBOutlets and IBActions
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 a nib file using 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 5 iPad 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 5 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 iPad 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 applicationDidFinishLaunchingWithOptions: 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 HelloWorldAppDelegate.m 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 5 applications to run on the iPad. 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.
Learn SwiftUI and take your iOS Development to the Next Level
|
| Previous | Table of Contents | Next |
| The Basics of Object Oriented Programming in Objective-C (iOS 5) | Creating an Interactive iOS 5 iPad App |
