In the previous chapter, we had a fair enough introduction of the Core Data framework and its components. We also learnt about the Data Model and its different terms including Entities, Properties, Attributes, Relationships, Inverse Relationships, and so on. We also explored the concepts of the Managed Object Model, Managed Object, and Managed Object Context. Finally, we saw the relationships among different components of Core Data API: Persistent Store, Persistent Store Coordinator, Fetch Request, and FetchedResultsController. Besides this, we also had a quick overview of the entire application that we will be building in this book from chapters 4 through 11.
As said in Chapter 1, Overview, for a better understanding of the Core Data, we need to have a good knowledge of two important concepts: How classes can adopt various protocols in Objective-C and knowledge of how information is displayed via Table View control. So, before we begin developing our application—Sales Record System for Departmental Store—we need to learn the first concept, which is about Protocols—what they are, how the methods are declared in a protocol, and the role of the delegate that conforms to the protocol. In other words, we can say that we're going to learn how a class receives tasks performed by another class via the Delegation Pattern.
You might be thinking, why it is necessary to understand the concept of protocol for developing our Core Data application. The answer is simple. While developing our application (which will begin from Chapter 5, Creating, Listing, and Deleting Names of Customers), we will realize that the main class of the application is the implementation file: RootViewController.m and its objects will adopt protocols, so that they can be used by other objects in a well-defined manner. That is, the main implementation file, RootViewController.m, will implement the methods of the protocols defined in other classes of the application.
This chapter will help you to better understand what we mean by the terms protocol, delegate, methods, and so on, through a running application.
Before we begin with the protocols, let's get a quick idea of the two patterns, Delegation pattern and Strategy pattern:
- The Delegation pattern is usually used to allow reuse of objects by allowing a helper object, or delegate, to assume the responsibility of customizing the behavior of the existing object without modifying its code. That is, a delegate is usually used to take some action at a defined hook. This is an alternative to customizing the behavior of a class via subclassing.
- In Strategy pattern, we have a few operations that will perform a calculation as per the strategy of the class that adopts the protocol. Regardless of how this is implemented, the implementation will only ever return a calculated value. The calculated values will not alter or customize the behavior of the object that is making use of the delegate.
Let's see how we can declare and enforce the behavior of delegate objects through protocols.
A protocol is not itself a class. Rather, it's an interface that declares methods. Only the methods are declared, that is, there is no body of the method defined in the protocol. The reason that format protocols are used for the delegation pattern is two fold:
- The protocol acts as a documentation of the delegate interface and it allows for the compiler to check adherence.
- At runtime you can interrogate an object in a single call to see if a protocol has been adopted rather than checking on a per method basis to see if an object will respond to a message.
The delegates are responsible for implementing the methods of the confirming protocol.
To work with a protocol, we need to:
- Define the protocol
- Create the delegate property
- Declare the protocol methods
A protocol is defined by using the @protocol compiler directive, combined with an @end directive. In between the two directives, we must declare the protocol method:
@protocol protocolname method declarations; @end
The delegate property is created in the class definition of the object that will utilize a delegate, not in the protocol nor in the class that adopts the protocol. A delegate property is created by defining an instance variable in the header file and synthesizing it in the implementation file. In the following example, we define an instance variable called delegate of type<protocolname>:
id <protocolname> delegate;
We also define the instance variable as a property with the attributes retain and nonatomic, used for generating the accessor and mutators:
@property (nonatomic, retain) id <protocolname> delegate;
The instance variable must be synthesized in the implementation file with the following command:
@synthesize delegate
Protocol methods are defined between the @protocol and @end directives. The methods can be of two types: optional and required.
The format of the defining methods in the protocol is:
@protocol protocolname -(void) method1: (data type) parameter1 secondparam: (data type) parameter2; @optional -(void) method2: (data type) parameter1 secondparam: (data type) parameter2; @end
Now the class that adopts to this protocol, that is, the class declared as a delegate of this protocol, must implement the protocol methods.