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?
Réponses:
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:
Vous devez éviter de mettre d'autres fonctionnalités dans AppDelegate car elles n'y appartiennent pas vraiment. Ces autres fonctionnalités comprennent:
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.
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.
@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.
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.
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.