Learn Objective-C on the Mac - Mark Dalrymple [17]
The AppKit Framework
Look at your Mac’s screen. Pretty much everything you see there is the domain of AppKit, which is an abbreviation of “application kit.” This framework contains all the objects used to create or manage a user interface. There are objects that create buttons, windows, text fields, tab bars, and more. Any user interface element that you’ve seen in more than one application is probably part of the AppKit framework. All that cool stuff you got for free last chapter? Yep, all AppKit.
The Cocoa Way: Model-View-Controller
Before diving in and seeing how we use these frameworks, we need to discuss a very important bit of theory. The designers of Cocoa were guided by a concept called Model-View-Controller (MVC), which is a very logical way of dividing the code that makes up a GUI application. These days, almost all object-oriented application frameworks pay a certain amount of homage to MVC, but there are few that are as true to the MVC model as Cocoa, or that have been using it as long.
The MVC model divides up all functionality into three distinct categories:■ Model: The classes that hold your application’s data.
■ View: Made up of the windows, controls, and other elements that the user can see and interact with.
■ Controller: Binds the model and view together and contains the application logic that determines how to handle the user’s inputs.
The goal of MVC is to make the objects that implement these three types of code as distinct from one another as possible. Any object you write should be readily identifiable as belonging to one of the three categories, with little or no functionality within it that could be classified within either of the other two. An object that implements a button, for example, shouldn’t contain code to process data when that button is clicked; and code that implements a bank account shouldn’t contain code to draw a table to display its transactions.
MVC helps ensure maximum reusability. A class that implements a generic button can be used in any application. A class that implements a button that does some particular calculation when it is clicked can only be used in the application for which it was originally written.
When you write Cocoa applications, you will primarily create your view components using Interface Builder, although you will sometimes also modify your interface from code, or you might subclass existing view and control classes to create new ones.
Your model will be created using something called Core Data or crafting Objective-C classes to hold your application’s data. We won’t be creating any model objects in this chapter’s application, because we’re not going to store any data; but we will introduce very simple model objects starting next chapter, and move on to full-fledged model objects when we start using Core Data in Chapter 7.
Your controller component will typically be comprised of classes that you create and that are specific to your application. Controllers can be completely custom classes (NSObject subclasses), which was the traditional way of doing things in Cocoa. A few years ago, Apple began to introduce generic controller classes into the AppKit framework that handle certain basic tasks for you, such as handling an array of objects to be displayed in a list.
As we get deeper into Cocoa, you will quickly start to see how the classes of the AppKit framework follow the principles of MVC. If you keep this concept in the back of your head as you develop, you will create cleaner, more easily maintained code.
Outlets, Actions, and Controllers
Obviously, a user interface isn’t much use if you can’t get data in and out of it or change its appearance from code. In Cocoa, we use things called actions and outlets to interact with the user interfaces we design in Interface Builder.