The iOS Development Platform

1 Contents

2 Abstract

3 Introduction

4 Main Part
4.1 The Learning Diary Application Development Project
4.2 Development Modules
4.2.1 iOS Device Family Hardware Specifications
4.2.2 Essential Design Patterns
4.2.3 The Objective-C Programming Language
4.2.4 The User Interface Toolkit
4.2.5 Data Storage
4.2.6 Networking
4.2.7 Security
4.2.8 Application Configuration
4.2.9 Mobile device specific functionality

5 Summary

6 Bibliography

7 Table of Figures

2 Abstract

The thesis serves as an entry point for developers that are new to the iOS application platform. It provides an introduction and an overview of the major APIs most commonly used in iOS applications including an introduction to the Objective-C programming language and the framework’s basic design patterns. In addition, the thesis is intended to be used as a programming reference, providing code snippets and usage examples for various common demands and issues within iOS application development. The paper is written in parallel to the development of an iPad application called the Learning Diary app which comprises a network module communicating via the XMPP protocol, a persistent database for storing learning data objects based on Apple’s Core Data framework and a modern user interface designed for mobile usage. The central aspects of mobile application development within the iOS environment are introduced using the example of the Learning Diary’s internal structure and software components.

3 Introduction

As the mobile application market is growing, developers need to extend their knowledge in working within mobile and embedded device environments. Since Apple introduced the iPhone in 2007 and their App Store market for distributing mobile applications in 2008, mobile applications have gained a lot of attention within the whole industry. The iOS system driving the iPhone and iPad devices is one of the 4 major mobile operating system environments on the market along with Windows mobile, Android and the Blackberry system. This paper provides a detailed overview of the main frameworks present in the iOS system and introduces them to developers new to mobile application environments. Readers should have experience in general application development and programming languages to extend their knowledge using the described design and programming techniques. The main part of this paper is dedicated to the development modules commonly used within modern applications and divides the software structure into distinct software modules. Each chapter explains a general approach on a specific module and adapts it to the iOS platform while providing implementation examples in form of code snippets and excerpts of the Learning Diary applications code base. Since there are many possible use cases and frameworks concerning the iOS library that would exceed the scope of this document, each chapter is designed to serve as a guide for the according software module and provides many references for further reading and deepening the knowledge on advanced topics.

4 Main Part

4.1 The Learning Diary Application Development Project

This paper is written in parallel to the development of an iOS application called the Learning Diary app. The chapters in the Development Module section of this paper use extracts of the application’s underlying software concepts and code base to provide examples for the general module demands and implementations appearing in iOS applications. The Learning Diary application is developed by the IMC AG as a contribution to the Mirror Project¹ co-funded by the European Commission. The Mirror Project targets the development of applications enabling users to apply and improve Reflective Learning processes. Within the project, Reflective Learning is defined as a “process of returning to experience in which the discrepancy between the learner’s current knowledge and what the learner observes about the experience leads to a change in the learner’s knowledge and behavior”². Learners are encouraged to run through multiple loops of learning and reflection phases to accomplish their learning goals.

As the name implies, the Learning Diary application aims at creating a digital diary application for learners. The Learning Diary app enables users to define main learning goals called Targets and attach sub-goals to them. These sub-goals are called Tasks within the Learning Diary app. Tasks can define actions and techniques to accomplish the desired learning goals while providing the ability to attach resource information in form of web references. These learning resources can be viewed and created in the Learning Diary’s resource web views. As users tend to hit on certain issues while gathering knowledge on a subject, the application enables users to capture these issues by creating and formulating Issue reports. When a user finds solutions concerning an issue, he can store and attach Solution objects to the Issue report to connect them to problem-solution pairs that can be merged to personal Best Practice manuals. In addition, the application provides Note creation features, a Recommendation database and a network platform called Reflection Spaces for exchanging gathered data with other learners. To enforce the model of reflective learning, the application enables users to attach Comments, Tags and Ratings to each of the learning objects above. Like this, users can manifest their thoughts on Targets, Tasks, Resources, Issues and Solutions while going through phases of reflection over their learning. The application encourages users to transform their thoughts while learning into the learning objects of the Learning Diary to collect data to form their own personal learning database including the ability to share their experiences with others. The first version of the finished application will be released exclusively for iPad devices. Future versions could add support for smaller devices (iPhone) or ports to other mobile operating systems (Android).

All central learning objects mentioned above are represented by custom data classes within the application. The table below defines the data model implemented by the Learning Diary application.

illustration not visible in this excerpt

These main classes can be separated into 3 main categories: The Knowledge Database, the Task Tracking module and the Meta-Data objects. The illustration below shows these categories including their classes and relations.

illustration not visible in this excerpt

Figure 1 : Learning Diary Application data model

All application components are developed using Apple’s XCode³ development environment in version 4 including its Interface Designer, Code Creation and Core Data Management Tools. The application uses the iOS SDK version 5⁴ as basic framework for creating its class hierarchy and the Core Data Framework for data management and persistence (see below). The Meeting Space API is implemented using a custom XMPP client module, which will be made available as a separate project to enable developers to connect their iOS application with Mirror’s Meeting Spaces for exchanging learning data with other learners.

4.2 Development Modules

Applications have to perform many common tasks and operations. The iOS Framework provides developers with many tools in form of Sub-Frameworks and classes to accomplish these common tasks. Each software project targeting mobile application development has to analyze the given devices hardware specifications and operating system APIs. In addition, many existing software frameworks implement Design Patterns to form the desired behavior. This is especially true for the iOS framework’s design. There are several main application demands including Networking, User Interface Design, Data Storage, Security and many others. The Development Modules section is divided into parts to reflect this modularized software development approach.

4.2.1 iOS Device Family Hardware Specifications

At the time of this writing, Apple offers two devices running the iOS System: the iPad and the iPhone. Apple launched the iPhone in 2007 and renovated the cell phone market with their new device. Even if there have been touch screen devices before the iPhone, no company handled to combine usability and simplicity within their devices. In addition Apple was able to position their trademark on the market and transferred their successes from the iPod; a portable music player, to their new portable device. In 2010 Apple launched their iPad device by transferring the iOS system to a portable tablet computer. Both devices follow the same guidelines for User Interface Design and program flow which enables users to switch between devices without greater effort.

The current iPhone model is the iPhone 4S. It contains a 3.5 inch widescreen Multi-Touch display and an 8 megapixel camera. At the time of this writing, the latest iPad version is the iPad 3 providing a 9.7 inch widescreen Multi-Touch display and a 5 megapixel camera. Both devices are available in different versions reaching from 16 GB to 64 GB flash memory. The iPad is available as a Wi-fi-only and a Wi-fi plus cellular version.

Both devices are based on an ARM7 chip called A5 and contain a GPS-, a Bluetooth-, an Accelerometer- and a gyroscope sensor for device motion recognition providing users and developers with many possibilities to use and design iOS based applications. The current iOS system version is iOS 5 which will be followed by version 6 in autumn 2012. With each new iOS release, Apple provides a new version of their iOS SDK providing lots of additions and bugfixes enabling developers to extend their applications with new framework possibilities. Apple tried to reduce the number of buttons within their iOS device family and provides only 4 buttons on their devices for regulating on/off, volume and display lock functionalities. For a detailed list of device specifications please refer to Apple’s device specifications⁵.

4.2.2 Essential Design Patterns

Good software architecture has to incorporate many different design aspects like encapsulation, usability, extension and many more. In the process of past software projects many common issues and tasks have crystallized out. These experiences lead to basic and extended design patterns. A Design Pattern is a general solution to a frequently occurring design problem. Apple’s Cocoa Touch and Foundation Frameworks make extensive use of design patterns to establish basic coding tasks⁶. The following section explains the most frequently used design patterns in the iOS environment. For further information on Design Patterns refer to the Gang of Four’s standard reference⁷.

The Model-View-Controller Pattern

The Model View Controller Pattern⁸ belongs to the group of Architectural Design Patterns. Its main purpose is the separation of data model and logical components from graphical program components. As the name implies, the Pattern defines 3 major roles:

- Model : The model represents program logic and data components
- View : A View can be any component used to visualize data to the user
- Controller : The Controller acts as an intermediary between Model and View

Controller objects observe the Model and one or multiple View objects. When users interact with the View component, the Controller is notified by events and performs according actions on the Model component. When the Model component changes its data, the Controller is notified and adjusts the View Component accordingly. The Controller doesn’t have to know about the implementation details of the View and Model Components. All interactions are following a well defined interface between the 3 components. The View contains no reference to the Model and vice versa; they are only connected via the Controller Component. This design approach improves capsulation and reusability of the Model and View Components and leads to better defined interfaces in general. Model and View Components can be used in different environments without changing their code base. This fact leads to an improved reusability of existing classes. There are different approaches to accomplish a Model View Controller behavior within applications depending on implementation demands and programming languages. The diagram below shows one possible structure of the MVC Pattern.

illustration not visible in this excerpt

Figure 2 : Model-View-Controller Diagram

Example: MVC in iOS

The MVC Pattern is used intensively throughout the whole User Interface Library within iOS and the whole view management within iOS applications is based on the MVC pattern. Views

can be designed using the Interface Designer and are connected to the program logic and data model by using ViewController objects. For instance, the UITableViewController connects UITableView objects with the Data model, frequently represented by arrays of data objects. Table Views present tables to the user which can be reordered and manipulated by touch- interaction. These manipulations are sent to the corresponding Table View Controller, which implements methods to perform the according manipulations to the referenced array of data objects. When changes are made to the View, only the View Controller has to adopt to eventual interface changes. The Model needs no code changes. Views and Models can be replaced, provided the new objects provide the same interface to the View Controller. The illustration below shows these relations.

illustration not visible in this excerpt

Figure 3 : MVC in iOS Table Views

The Command Pattern

In some cases, developers need to capsulate command execution into separate objects, e.g. to execute a function call at a later time. The Command Pattern⁹ enables software designers to accomplish this task by encapsulating all necessary information needed for a method call into a separate object called a Command. The Command object stores a reference to the targeted object containing the desired function, the function signature and all necessary arguments to execute the function on demand. Its interface provides an execute method which can be used by other objects called Invokers to fire function execution. The Command Pattern belong to the group of Behavioral Patterns and comprises 5 major roles:

- The Command Interface : provides an interface for firing method execution on demand
- The Concrete Command : is a concrete implementation of the Command Interface pointing to a receiver object and initialized with all necessary parameters The Invoker : fires the Concrete Command’s execute method on demand or in scheduled intervals
- The Receiver : contains the actual method implementation invoked by the Concrete Command
- The Client : creates and initializes the Concrete Command

illustration not visible in this excerpt

Figure 4 : Command Pattern Diagram

Capsulation of commands has many use cases in modern applications. For example, if an application needs to keep track of user actions to provide undo-redo functionality, Command objects can be held in stacks. These stacks can then be used to reconstruct the exact behavior of users. In addition, the pattern is applicable for network and parallel processing tasks or for creating execution queues to be executed in a given order or sorted by their priority. Many graphical Wizards in applications use Commands to collect the needed data for later execution.

Example: Command Pattern in iOS

In iOS, the Command Pattern is most frequently used within the User Interface toolkit and its different control objects. The UIControl¹⁰ class is the parent class of all touchable control objects within the toolkit. These controls can be created and customized using XCode’s interface designer. The designer allows developers to connect user events, like touching or sliding a control, with class objects without writing any code. Even if the designer allows automatic method connection, all controls can be connected to an object’s methods at runtime in executed code. The control contains a list of referenced events, their assigned target objects and functions. When the user interacts with a control, it invokes the execution of the assigned method on the assigned target object. The Objective-C programming language supports the Command Pattern by providing so called Selectors to address methods (see below). The illustration below shows the Command Pattern integrated into the UIControl class provided by the UIKit framework.

illustration not visible in this excerpt

Figure 5 : Commands within iOS UIControl objects

The Delegation Pattern

Modern applications lead to complex structures of classes and their inheritance hierarchies. Delegation is a possibility to encapsulate functionality into separated components which can be attached to existing classes. This task is accomplished by externalizing method functionality into Delegate objects which can be called by a Delegators class method. The Pattern comprises the following roles:

- The Delegator : references and redirects function calls to the Delegate object
- The Delegate : implements and performs the actual method processing
- The Delegate Interface : provides a common interface to Delegate objects and defines the methods accessible to the Delegator object

Delegation is an alternative to inheritance and can simulate multiple inheritance without programming language support. This approach reduces the coupling of methods to classes. In addition, class behavior can be varied during runtime by replacing Delegate objects which just have to implement the same Delegate Interface. Even multiple delegates are possible, enabling further method capsulation or multiple processing started by a Delegator’s function call. The pattern counts to the group of Structural Design Patterns. The diagram below presents the connections between the major roles.

illustration not visible in this excerpt

Figure 6 : Delegation Pattern Diagram

Example: Delegation in iOS

Delegation is one of the central design patterns within the whole Foundation Library. Apple provides many different Delegate Interfaces which can be implemented in custom classes to catch system or interface events and execute custom code on demand. For example, the central access point for each iOS application is called the ApplicationDelegate¹¹. It provides an interface for application state changes (see below), remote notifications and operating system events. These access points can be overridden by custom sub-classes to implement custom behavior for each application.

In addition, Delegation is the central pattern for handling user interface events and passing data between views¹². Table Views are represented by the UITableView class which references a custom Delegate implementing the UITableViewDelegate protocol. The Protocol comprises interface methods for handling user interface events occurring in the Table View. Table Views contain a reference to their Delegate object. When users interact with the view, events are sent to the Delegate object which can react accordingly. For example, if a user selects a row within the Table View, the view calls its Delegate’s tableView:didSelectRowAtIndexPath: method which can be used to create and display a new view. In this way, developers can customize many application behaviors without knowing about the implementation details of framework classes. The Delegate Interfaces are well defined and developers just have to react to according events on demand. The illustration below shows the implementation details of the Delegate Pattern within UITableViews.

illustration not visible in this excerpt

Figure 7 : Delegation within iOS Table Views

The Composite Pattern

The Composite Pattern defines a solution for arranging data into tree structures¹³. It counts to the group of Structural Design Patterns. The Pattern structures program components into groups providing a uniform interface for execution of their main methods. Using this technique, each component’s execution can be triggered, without knowing about the count of objects, or internal structure of a given component tree. Each Component knows how to execute its task and conforms to a well defined interface. The Composite Pattern comprises 3 roles:

- The Component : provides a central interface to all roles. It defines an execution method declaration that has to be implemented by each sub-class
- The Leaf : represents a leaf in the tree structure. Leaves can’t hold any child objects
- The Composite : represents a node in the tree structure. It can contain multiple children deriving from the Component Interface and provides methods for managing child objects.

Using a Composite Pattern implementation, complex trees of objects and primitive objects can be treated uniformly. Composite objects can contain any number of Leafs and Components. In many cases Composite objects implement their execution function by delegating function calls to their children. Many applications have to organize objects into part-whole hierarchies. For example, a CAD software for constructing complex engines could implement the Composite Pattern for managing the internal structure of an engine consisting of many different modules, all represented by custom classes. In this scenario, each module class would implement the Component’s execute function. Modules that can’t be sub-divided become Leaf objects while modules that consist of multiple sub-modules are implemented as Composites. Another example is the management of file systems in operating systems. Single files can be implemented as Leaf objects, while directories are Composites.

[...]

¹ Mirror Project Homepage (Mirror Project)

² Mirror Project : FAQ (Mirror Project)

³ Cf. XCode 4 User Guide (Apple Inc., 2012)

⁴ Cf. iOS Dev Center (Apple Inc., 2012)

⁵ Cf. iPad Technical Specifications (Apple Inc., 2012)

⁶ Cf. Definition : Design Pattern (Rouse, 2007)

⁷ Cf. Design Patterns: Elements of Reusable Object-Oriented Software (Erich Gamma, 1994)

⁸ Cf. Cocoa Core Competencies : Model-View-Controller (Apple Inc., 2012)

⁹ Cf. Command Pattern (Wikipedia.com, 2012)

¹⁰ Cf. UIControl Class Reference (Apple Inc., 2011)

¹¹ Cf. UIApplicationDelegate Protocol Reference (Apple Inc., 2011)

¹² Cf. Cocoa Core Competencies : Delegation (Apple Inc., 2012)

¹³ Composite Design Pattern (Sourcemaking.com)