Ответ 1
Что такое делегирование?
Прежде всего, вы должны знать, что "Шаблон делегирования" не является исключением для iOS мира:
В разработке программного обеспечения шаблон делегирования является шаблоном проектирования в объектно-ориентированное программирование, позволяющее достичь композиции объекта такое же повторное использование кода как наследование.
Но работа с делегацией в мире iOS настолько распространена, я предполагаю, что вы можете увидеть многие классы, предоставляющие делегацию/источник данных для предоставления возможности предоставлять свойства или поведения для используемого экземпляра. Это один из основных механизмов взаимодействия объектов друг с другом в CocoaTouch.
Альтернативы:
Однако делегирование - это не единственный способ позволить объектам общаться друг с другом в iOS, вы можете знать, что есть:
- NotificationCenter.
- KVO (наблюдение за ключевыми значениями).
- Обработчики завершения/Обратные вызовы (с использованием закрытий).
- Целевое действие.
Примечание: если вы заинтересованы в сравнении между ними, вы можете проверить следующие статьи:
- Шаблоны связи.
- Когда использовать делегирование, уведомление или наблюдение в iOS.
- Делегаты против наблюдателей.
Когда использовать делегацию?
Итак, возникает вопрос: "Так почему я должен использовать делегирование вместо этих параметров?"
Я постараюсь сделать это простым; Я бы предложил использовать делегацию, если у вас есть один к одному между двумя объектами. Чтобы сделать его более ясным, цель немного рассказать об NotificationCenter заключается в том, чтобы попытаться понять, когда используются делегации:
NotificationCenter представляет отношение от одного до большого; Просто он работает как: публикация (уведомление) уведомления о конкретном событии и наблюдение (уведомление) об этом уведомлении - его можно наблюдать где-либо еще; Логически, это то, от чего зависит одно отношение. Это представление Шаблон наблюдателя.
Как применить делегирование?
В целях упрощения я бы упомянул его как шаги:
-
Знание требований: Каждый делегат имеет свои собственные правила, перечисленные в протоколе делегата, который представляет собой набор сигнатур методов, которые вы должны реализовать для соответствия этой делеции.
/li > -
Соответствие для делегирования: просто позволяет вашему классу быть делегатом, пометив его. Например:
class ViewController: UIViewController, UITableViewDelegate {}. -
Соединение объекта-делегата: Маркировка вашего класса как делегата недостаточна, вам нужно убедиться, что объект, который вы хотите подтвердить своим классом, дать требуемую работу к вашему классу.
-
Реализация требований: Наконец, ваш класс должен реализовать все необходимые методы, перечисленные в протоколе делегата.
Для примера
Это звучит немного странно? Как насчет реального мира?
Рассмотрим следующий сценарий:
Представьте, что вы создаете приложение, связанное с воспроизведением аудио. Некоторые из viewControllers должны иметь вид аудиоплеер. В простейшем случае мы предполагаем, что у него должна быть кнопка воспроизведения/паузы и еще одна кнопка, чтобы, скажем, показ списка воспроизведения, независимо от того, как это может выглядеть.
До сих пор так хорошо, что просмотр аудиоплеера имеет выделенный файл UIView и .xib; он должен быть добавлен как подчиненный в любой требуемый viewController.
Теперь, как вы можете добавить функциональность для обеих кнопок для каждого viewController? Вы можете подумать: "Просто, я добавлю IBAction в класс представления и что он", сначала посмотрите, это может звучать нормально, но, переосмыслив немного, вы поймете, что это не применимо если вы пытаетесь обработать событие нажатия кнопки на уровне контроллера; Чтобы было ясно, что, если каждый viewController реализовал различные функции при нажатии кнопок в представлении аудиоплеера? Например: нажатие списка воспроизведения в "A" viewController отобразит tableView, но нажатие на него в режиме просмотра "B" отобразит сборщик.
Хорошо, давайте применим делегирование к этой проблеме:
Комментарии "#" представляют собой шаги "Как применить делегирование?". раздел.суб >
Просмотр аудиоплеера:
// # 1: here is the protocol for creating the delegation
protocol AudioPlayerDelegate: class {
func playPauseDidTap()
func playlistDidTap()
}
class AudioPlayerView: UIView {
//MARK:- IBOutlets
@IBOutlet weak private var btnPlayPause: UIButton!
@IBOutlet weak private var btnPlaylist: UIButton!
// MARK:- Delegate
weak var delegate: AudioPlayerDelegate?
// IBActions
@IBAction private func playPauseTapped(_ sender: AnyObject) {
delegate?.playPauseDidTap()
}
@IBAction private func playlistTapped(_ sender: AnyObject) {
delegate?.playlistDidTap()
}
}
Контроллер просмотра:
class ViewController: UIViewController {
var audioPlayer: AudioPlayerView?
// MARK:- Life Cycle
override func viewDidLoad() {
super.viewDidLoad()
audioPlayer = AudioPlayerView()
// # 3: the "AudioPlayerView" instance delegate will implemented by my class "ViewController"
audioPlayer?.delegate = self
}
}
// # 2: "ViewController" will implement "AudioPlayerDelegate":
extension ViewController: AudioPlayerDelegate {
// # 4: "ViewController" implements "AudioPlayerDelegate" requirments:
func playPauseDidTap() {
print("play/pause tapped!!")
}
func playlistDidTap() {
// note that is should do a different behavior in each viewController...
print("list tapped!!")
}
}
Быстрый совет:
Как один из самых популярных примеров использования делегирования - Передача данных назад между диспетчерами просмотра.
