Building Views with UIKit

The UIKit framework provides the building blocks of touch-based applications for iOS. That means it’s responsible both for the concept of what an app is and how it interacts with the rest of the system, as well as for providing a suite of user interface views. Every user interface control we add to the app comes from UIKit, as well as the systems for sending user interface events to our code, how we draw things, fonts, colors, gestures, and so forth.

UIKit’s UIApplication class is the point of contact between our code and the rest of the system. By accessing its sharedApplication method, we can open other apps by URL, receive remote events from Apple’s Push Notification service, and set a number for our app icon’s badge. But a lot of apps don’t do any of these things, so we don’t often use UIApplication directly. Instead, the Xcode template sets up a UIApplicationDelegate class for us to customize; this class gets callbacks when common events occur, like the app being started up or opened via a URL from another app, or when it’s sent to the background by the user tapping the home button.

The delegate pattern is frequently used in the iOS SDK, often as an alternative to subclassing. The idea is that for certain responsibilities, usually the custom behaviors specific to an app, an object can delegate its behaviors to another object. In this case, the UIApplication class handles the activities that are common to all applications, but for cases where different apps will want to do different things, it makes callbacks to our AppDelegate. Delegates don’t need to be their own classes like this: they are often classes with other purposes that just implement one or two methods (usually collected as a protocol) in order to serve as a delegate.

As for the app delegate itself, we’ll be revisiting it in a later chapter, when we look into what apps can do in iOS 9 even when they’re not running.

Many of the UIKit classes are views, which are the onscreen touch objects in our user interface. We’ve been using these in our Twitter example: our UI has a single view that fills the screen and has two subviews: the label and the button. Many other view classes are available, like switches, tables, and sliders. We saw many of these views as icons in the IB library pane (shown in the figure), and each is backed up by a subclass of UIView.

The top-level UIView defines the common functionality of all views. All views have visual properties, such as a backgroundColor, an alpha variable, and hidden and opaque flags. As we’ve already seen, a view can contain other views; these are accessible via a subviews property and can be added with convenience methods like insertSubview(). A child view can access whatever view it’s a subview of via the superview property. Subviews are layered on top of one another by drawing them in the order of the subviews array, with the view at index 0 at the bottom, then index 1 on top of it, and so on. For visual styling needs, UIView also has a tintColor property that applies to all subviews, which makes it easier to apply custom theming to all the UI components on the screen.

Views also have frame and bounds properties that indicate their size and location. Each of these properties is a CGRect, a structure that defines an x-y origin (of type CGPoint, a struct inherited from the Core Graphics framework) and a width-by-height size (of type CGSize, another structure). The CGRect definition looks like this:

The difference between a view’s bounds and its frame is that the bounds values are in the view’s own coordinate system, while the frame is in its superview’s coordinate system. So a subview’s frame’s origin is its top-left corner, relative to its parent’s top-left corner at (0,0). Setting either property changes the other as needed, and these interact with two related visual properties, transform and center.

Along with views, UIKit provides the UIViewController class, which is meant as the place where we put the logic for our user interfaces. The view controller also has a number of life-cycle callbacks, telling it when its view is loaded from the storyboard and when the view will appear or disappear as a result of navigating to different parts of the app. We will look more at this relationship in a later chapter.

Finally, UIKit provides classes for objects that are commonly needed by user interfaces, such as UIFont and UIImage. Taken together, the UIKit classes provide an extensive and extensible user interface toolkit.