This is the second installment in the multi-part series covering the various design patterns used in iOS. A good read for anyone getting started with iOS development. This second part covers a design pattern known as Delegation.
The delegation pattern means exactly what its name implies, in that it delegates control. It is simple yet powerful.
Take the example of a simple app that contains some images within a scrollable view. The images are laid out horizontally and dragging the view horizontally makes it possible to paginate between the images. The images are downloaded from the internet, hence scrolling should automatically trigger the image download.
Therefore, the two main components for this app are the image downloads and the scrollable view. Once the view has been scrolled the application needs acknowledgement of this event and subsequently trigger an image download. In most cases what matters most is where the scrolling has halted, however, in some cases it is also important to know when the scrolling began and the velocity of the scroll. The iOS framework has a class called
UIScrollView but this is a generic class without any knowledge of the fact that there are images that need to be downloaded upon scroll. This would be an application specific task and it is impossible for the
UIScrollView to perform any such tasks.
So how does the
UIScrollView notify the application of scrolling events? It uses a delegate class called
UIScrollViewDelegate which defines all the scrolling events available. The application can then implement this delegate and intercept those scrolling events.
In the example above, the application creates and displays an instance of the scroll view which then contains a reference to the delegate. The delegate is a property of the
UIScrollView which tells the view that another class will contain an implementation of the methods defined in
UIScrollViewDelegate. Therefore, when scrolling occurs it refers to its delegate and accordingly calls the methods. Another way to look at it would be a method callback.
The delegating class (such as
UIScrollView in the above example) contains a property, usually named delegate and it declares one or more methods that constitute a formal or informal protocol.
A formal protocol (such as
UIScrollViewDelegate in the above example) declares all the methods that can be implemented by a class. It can also mark methods as required or optional.
The informal protocol declares methods on a category of NSObject. A category is a feature that enables you to add methods to a class without subclassing it. However, Apple is phasing out this approach.
The mechanism of delegation gives objects a chance to coordinate their appearance and state with changes occurring elsewhere in an application usually brought about by user actions. More importantly, delegation makes it possible for one object to alter the behavior of another object without the need to inherit from it. The delegate is almost always one of your custom objects, and by definition it incorporates application-specific logic that the generic and delegating object cannot possibly know itself.
The delegate methods follow a standard naming convention. Starting with the name of the UIKit object doing the delegating which is followed by an auxiliary verb (such as: will, should, did or has) describing the status of the reported event. Let’s look at some of the methods within the
The data source is just like the delegate except it has a different purpose. Instead of delegating control of the user interface it delegates control of data. For example, a table view has a data source which provides information on which rows to display with what data. Data sources are responsible for the memory management of their data objects.
Check out the other posts in this series:
iOS Design Patterns: Target-action (Part 1)
If you are interested in learning more do check out the iOS development course.