J'ai essayé d'apprendre comment fonctionne la délégation avec les protocoles. J'ai tout compris, mais je ne peux pas penser au moment d'utiliser la délégation autre que lors de l'utilisation des vues de table et éventuellement des vues de défilement.
En général, quand la délégation est-elle utilisée?
Tout d'abord, vous devez savoir que Modèle de délégation n'est pas exclusif au monde iOS:
En génie logiciel, le modèle de délégation est un modèle de conception en programmation orientée objet qui permet à la composition d'objet d'obtenir la même réutilisation de code que l'héritage.
Mais travailler avec délégation dans le monde iOS est si courant, je suppose que vous pouvez voir de nombreuses classes qui fournissent une délégation/source de données pour donner la possibilité de fournir des propriétés ou des comportements pour l'instance utilisée. C'est l'un des principaux mécanismes de communication entre les objets dans CocoaTouch.
Cependant, la délégation est pas la seule façon de permettre aux objets de se parler dans iOS, vous voudrez peut-être savoir qu'il existe:
Remarque: au cas où vous souhaiteriez les comparer, vous voudrez peut-être vérifier le articles suivants:
Donc, la question est: "Alors pourquoi devrais-je utiliser la délégation au lieu de ces options?"
Je vais essayer de faire simple; Je suggérerais l'utilisation de la délégation lorsque vous avez un à un relation entre deux objets. Pour être plus clair, le but de parler un peu du NotificationCenter est d'essayer de donner un sens lorsque des délégations sont utilisées:
NotificationCenter représente un à plusieurs relation; Simplement, cela fonctionne comme: poster (notifier) une notification sur un événement spécifique et observer (être averti) cette notification - elle pourrait être observée = n'importe où else; Logiquement, c'est ce que signifie une relation un à plusieurs. C'est une représentation du Observer Pattern .
Dans un souci de simplification, je le mentionnerais comme étapes:
Connaître les exigences: Chaque délégué a ses propres règles , répertoriées dans le protocole délégué qui est un ensemble de signatures de méthode que vous devez implémenter pour conformer cette délégation.
Conforme pour la délégation: c'est simplement laisser votre classe être un délégué, en la marquant. Par exemple: class ViewController: UIViewController, UITableViewDelegate {}
.
Connexion de l'objet délégué: Marquer votre classe comme délégué est pas suffisant, vous devez vous assurer que le objet que vous souhaitez voir confirmé par votre classe pour donner le travail requis à votre classe.
Implémentation des exigences: Enfin, votre classe doit implémenter toutes les méthodes requises répertoriées dans le protocole délégué.
Cela vous semble un peu déroutant? Et un exemple concret?
Considérez le scénario suivant:
Imaginez que vous construisez une application liée à la lecture d'audios. Certains des viewControllers devraient avoir une vue d'un lecteur audio. Dans le cas le plus simple, nous supposons qu'il devrait avoir un bouton de lecture/pause et un autre bouton pour, disons, afficher une liste de lecture d'une manière ou d'une autre, quelle que soit son apparence.
Jusqu'ici tout va bien, la vue du lecteur audio a sa classe UIView
et son fichier .xib
Séparés; il doit être ajouté en tant que sous-vue dans n'importe quel viewController souhaité.
Maintenant, comment pouvez-vous ajouter des fonctionnalités aux deux boutons de chaque viewController? Vous pourriez penser: "Simplement, je vais ajouter un IBAction
dans la classe view et c'est tout", à première vue, cela peut sembler correct, mais après avoir repensé un peu, vous vous rendrez compte que cela ne s'applique pas si vous essayez de gérer l'événement de toucher le bouton au niveau de la couche contrôleur; Pour que ce soit clair, que se passe-t-il si chaque viewController implémente des fonctionnalités différentes lors de l'appui sur les boutons dans la vue du lecteur audio? Par exemple: en appuyant sur la liste de lecture dans "A" viewController affichera une tableView, mais en le touchant dans "B" viewController affichera un sélecteur.
Eh bien, appliquons Délégation à ce problème:
Le commentaire "#" représente les étapes de "Comment appliquer la délégation?" section.
Vue du lecteur audio:
// # 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()
}
}
Afficher le contrôleur:
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!!")
}
}
Astuce rapide:
Comme l'un des plus exemples populaires d'utilisation de la délégation est Passing Data Back entre les contrôleurs de vue.
La délégation est utilisée lorsque vous souhaitez transmettre des informations ou l'état de l'objet A à un autre objet B. Habituellement, l'objet B est l'objet qui a créé l'objet A.
Je vais énumérer certaines situations où vous utiliseriez la délégation.
Oui tu as raison. les vues de table et les vues de défilement utilisent des délégués car ils veulent dire à quiconque est intéressé (généralement votre contrôleur de vue) que "quelqu'un a sélectionné une ligne!" ou "quelqu'un a fait défiler la vue de défilement!". Non seulement les vues de défilement et les vues de table utilisent des délégués, UITextField
et UIDatePicker
et beaucoup d'autres vues utilisent aussi des délégués!
Les contrôleurs de vue ont également des délégués. Par exemple, UIImagePickerController
. La raison en est à peu près la même que ci-dessus - parce que le UIImagePickerController
veut vous dire des messages comme "une image a été sélectionnée!". Un autre exemple serait UIPopoverControllerDelegate
. Ce délégué vous dit des choses comme "le popover a été rejeté!"
Les autres classes qui utilisent des délégués incluent CLLocationManager
. Ce délégué vous dit des choses comme "l'emplacement de l'utilisateur a été détecté" ou "n'a pas réussi à détecter l'emplacement de l'utilisateur".
Vous pouvez utiliser la délégation dans votre code lorsqu'un certain contrôleur de vue à vous souhaite envoyer des messages à d'autres contrôleurs de vue. S'il s'agit d'un contrôleur d'affichage des paramètres, il peut envoyer des messages tels que "le paramètre de taille de police a été modifié!" et le contrôleur de vue qui se soucie du changement de paramètre de taille de police connaîtra et changera la taille de police d'une étiquette ou quelque chose.
La délégation dans le monde IOS et principalement dans MVC (Model View Controller) est un moyen pour la vue de parler au contrôleur et elle est appelée "communication aveugle" et la délégation signifie donner le "bâton de tête" à un autre objet (peu importe qui prend le relais mais généralement le contrôleur) pour contrôler les composants que la vue ne peut pas contrôler seule (rappelez-vous que ce n'est qu'une vue) ou ne possède pas pour le rendre plus simple. ..
le contrôleur peut parler à une vue mais la vue ne peut pas parler au contrôleur sans délégation