À quoi sert AppDelegate et comment savoir quand l'utiliser?

146

Je commence tout juste à travailler sur les applications iPhone. Comment savoir quand je dois placer des éléments dans AppDelegate par rapport à une classe personnalisée? Existe-t-il une règle ou un type d'analogie avec un autre langage de programmation comme Python ou PHP qui utilise un modèle similaire à AppDelegate?

resopollution
la source

Réponses:

255

J'évite normalement l'approche de conception qu'implique l'utilisation par Andrew du terme «cœur de votre application». Ce que je veux dire par là, c'est que je pense que vous devriez éviter de regrouper trop de choses dans un emplacement central - une bonne conception de programme implique normalement de séparer les fonctionnalités par «domaine de préoccupation».

Un objet délégué est un objet qui est notifié lorsque l'objet auquel il est connecté atteint certains événements ou états. Dans ce cas, le délégué d'application est un objet qui reçoit des notifications lorsque l'objet UIApplication atteint certains états. À bien des égards, il s'agit d'un modèle d'observateur un-à-un spécialisé.

Cela signifie que la "zone de préoccupation" pour AppDelegate gère les états UIApplication spéciaux. Les plus importants sont:

  • applicationDidFinishLaunching: - bon pour gérer la configuration et la construction au démarrage
  • applicationWillTerminate: - bon pour le nettoyage à la fin

Vous devez éviter de mettre d'autres fonctionnalités dans AppDelegate car elles n'y appartiennent pas vraiment. Ces autres fonctionnalités comprennent:

  • Données de document - vous devez avoir un singleton de gestionnaire de documents (pour plusieurs applications de document) ou un singleton de document (pour les applications de document unique)
  • Contrôleurs de bouton / table / vue, méthodes de délégué de vue ou autre gestion de vue (sauf pour la construction de la vue de niveau supérieur dans applicationDidFinishLaunching :) - ce travail doit être effectué dans les classes de contrôleur de vue respectives.

Beaucoup de gens mettent ces éléments dans leur AppDelegate parce qu'ils sont paresseux ou pensent que AppDelegate contrôle l'ensemble du programme. Vous devriez éviter de centraliser dans votre AppDelegate car cela brouille les domaines de préoccupation dans l'application et ne s'adapte pas.

Matt Gallagher
la source
8
+1 C'est une excellente réponse. Je regardais un exemple de code dans lequel des sous-vues appelaient appDelegate pour demander à un contrôleur de vue de basculer vers une sous-vue différente, et cela ressemblait à une odeur de code. C'est bon de savoir que mon nez fonctionne toujours.
Alan
2
parfois, nous voyons quelque chose comme ça dans les tutoriels en ligne: AppDelegate * del = [AppDelegate sharedAppDelegate]; (voir developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/… ) qu'est-ce que cela signifie? Je peux voir des exemples d'utilisation mais je ne comprends pas vraiment la théorie derrière cela (voir cet exemple: developer.apple.com/library/ios/#samplecode/… )
abbood
27

Votre délégué d'application est le cœur de votre application. C'est en fait votre "contrôleur de programme".

Le délégué d'application est la classe qui reçoit les messages au niveau de l'application, y compris le message applicationDidFinishLaunching le plus couramment utilisé pour lancer la création d'autres vues.

Bien que ce ne soit pas exactement similaire, vous pouvez le considérer comme la routine "main ()" de votre programme Cocoa.

Andrew Grant
la source
Je vous donne +1 car avoir tous vos contrôleurs d'interface utilisateur dans AppDelegate est moins compliqué que de créer toutes ces classes personnalisées pour cela.
rwols
3
@rwols soyez prudent, séparer vos préoccupations aide à un code plus propre et le débogage est moins compliqué, vous devriez prendre le temps de créer ces classes personnalisées et de ne pas mettre tous vos observateurs dans un seul fichier.
wheeliez
2

@Shivam, merci.

D'après ce que je comprends appDelegate, c'est proche de ce qu'est un ApplicationAndroid. Le viewDidLoad, viewDidDisappearest comparable à ce que le cycle de vie d'Android. Chaque application a un cycle de vie, du lancement aux interruptions d'appels entrants, en passant par l'affichage des notifications. Si vous avez besoin de votre code pour faire quelque chose de spécial lorsque ces systemévénements se produisent, vous devez écrire du code pour les méthodes.

Dans Android que nous utilisons onPause, onDestroy, onCreatecallback un peu des méthodes pour gérer ces événements système.

Siddharth
la source
Les onPause, onCreateet les onDestroyméthodes d'Android sont similaires à viewDidDisappear, les viewDidLoadméthodes du cycle de vie d'un iOS View Controller. Si vous devez comparer, je dirais que la Applicationclasse d'Android serait plus proche de celle AppDelegated'iOS.
Shivam Bhalla
Merci, si vous pouvez améliorer ma réponse, faites-le. Je supprimerai ma réponse après avoir lu la vôtre.
Siddharth
1

J'espère que cela aidera un peu plus ...

Les programmeurs novices dans ce langage ont toujours la même question: le programme part-il d'une méthode principale? Oui, vous avez raison dans ce cas; Les applications IOS partent également d'une méthode principale.
Votre classe principale appelle la fonction ci-dessous:

 UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); 

UIApplicationMain lance la boucle d'exécution Cocoa Touch et l'infrastructure d'application qui crée un UIApplicationobjet. Notre application a besoin de contenu, donc objective-c utilise un délégué pour gérer cela. C'est pourquoi nous l'appelons AppDelegate (agir en tant que délégué de UIApplication). Nous implémentons certaines des méthodes facultatives de ce délégué et il se comporte en conséquence.

Anurag Bhakuni
la source
s'il vous plaît, quelqu'un peut-il me faire comprendre ce qui ne va pas dans la réponse ci-dessus
Anurag Bhakuni
2
Cela semble confus parce que a) vous n'utilisez pas la bonne ponctuation / orthographe / grammaire, b) c'est hors sujet car cela ne répond pas vraiment à la question posée par l'affiche originale.
Kay