NSWindowController clarification de la compréhension

Question

J'ai utilisé NSWindowController dans des projets à plusieurs reprises, et se sentir comme j'ai une (très)approximative de saisir les concepts de base de cette classe importante. Ce que je voudrais faire avec ce post est de clarifier ou corriger ma propre compréhension, et j'espère aider d'autres apprenants obtenir que la première étape dans la compréhension. C'est la d'un coup d'œil concepts, vue d'ensemble, et les meilleures pratiques que je trouve est le plus utile, et souvent défaut dans la documentation. Voici mon point de vue sur NSWindowController (les questions sont réparties en gras):

• Un NSWindowController (NSWC) sous-classe existe (conceptuellement) juste en dessous de chaque fenêtre de plume, agissant en tant que la colle entre les éléments de l'interface utilisateur et le modèle des objets qu'ils/contrôle de représenter. Fondamentalement, toutes les fenêtres de votre application doit avoir son propre NSWC sous-classe.
• Le Propriétaire du Fichier de la plume doit toujours être le NSWC sous-classe. Est-ce le cas même pour le MainMenu.xib application?
• Le NSWC window de la propriété doit toujours être reliée à la NSWindow dans InterfaceBuilder.
• Vous devez remplacer le "init" la méthode, à l'aide de [super initWithWindowNibName:], de sorte que lorsque vous vous référez à l' [mycontroller window] il va charger la plume. Faut-il aussi être le cas pour la NSWC pour le MainMenu.xib fenêtre, même si c'est ouvert au démarrage?
• Le NSWC ne devrait pas faire trop lourd de levage - il doit simplement transmettre des messages à des instances d'objets, et ces objets dans l'INTERFACE utilisateur.
• Il peut modifier l'INTERFACE utilisateur à l'aide d'une liaison ou d'agir en tant que délégué pour les tables etc., ou par activement à changer les éléments de l'INTERFACE utilisateur lorsqu'il observe un changement, ou une combinaison de tout ce qui précède (celui que vous utilisez semble être une question de goût, avec les avantages et les inconvénients de tous les côtés).
• Un NSWC peut créer des instances d'autres NSWCs lorsque nécessaire (par exemple, lors de l'ouverture d'une sous-fenêtre).

• Utiliser l' [mycontroller showWindow:nil] pour afficher la fenêtre associée à l'avant. Si vous voulez voir apparaître la fenêtre comme une feuille, utilisez quelque chose comme:

  NSWindowController* mycontroller = [[MyController alloc] init];
  [NSApp beginSheet: [mycontroller window]
     modalForWindow: [self window] 
      modalDelegate: self 
     didEndSelector: @selector(didEndMySheet:returnCode:contextInfo:)
        contextInfo: nil];
  

L' didEndSelector: devrait être une méthode de la NSWC de la fenêtre parent, et que vous pouvez accéder et de liberté", mycontroller " avec [sheet windowController]. - Pour fermer la fenêtre d'appel de l' performClose: méthode de NSWC de la fenêtre.

Quelques Questions:

• Si le NSWC de la MainMenu fenêtre également être l'application délégué, ou devrait-il être une classe différente?
• Dans la même veine, la NSWC gérer les fichiers (glisser/déposer et d'ouverture), ou doit-il être transmis au délégué d'application, ou est-ce juste une question de goût?

S'il vous plaît corrigez-moi si tout cela est une mauvaise pratique, ou est tout simplement faux. Je suis à la recherche de clarifier ma compréhension de NSWindowController, de sorte que tous les ajouts (sous la forme de bonnes pratiques, des expériences, des pièges) serait très appréciée.

Merci, Laurie

Answer 1

Ce sont les contrôleurs de fait pour?

Fenêtre contrôleurs sont des outils permettant de charger une fenêtre à partir d'une PLUME de fichier et de la gestion de la mémoire, des ressources allouées à la PLUME. Avant, là où est - NSWindowControllers un essentiellement dû écrire le même code pour chaque fenêtre ou d'inventer une nouvelle fenêtre contrôleur de classe.

Bien sûr, ils sont aussi les contrôleurs du Modèle/Vue/Contrôleur de sens, de sorte qu'ils sont au bon endroit pour connecter les points de vue à partir de la fenêtre pour les objets de modèle. Pour ce faire, ils ont souvent besoin d'agir en tant que délégué ou de la source de données pour un objet de vue. Si vous avez cette partie parfaitement droit.

Aussi la fenêtre de contrôleurs sont un outil pour la réutilisation du code. Il est facile de tomber de la fenêtre contrôleur de classe et c'est XIB/PLUME dans un autre projet et l'utiliser.

Alors oui, chaque fenêtre à partir d'une PLUME doit être possédé par une fenêtre contrôleur, à une exception près. En fait, c'est juste une recommandation pour le bon code, rien n'impose d'elle.

WindowControllers et MainMenu.xib

MainMenu.xib est autre chose, là, vous ne pouvez pas utiliser une fenêtre contrôleur. Cette PLUME est chargé par NSApplication donc ce doit être ça "Fichiers de propriétaire". Il n'existe aucun moyen pour obtenir une fenêtre contrôleur entre l' NSApplication et la PLUME. Il n'est pas nécessaire d'utiliser une fenêtre contrôleur de gestion de la mémoire, puisque l'objet de l'application de vie pour l'ensemble de l'exécution du programme, afin de ne pas avoir à le nettoyer de ses ressources de la PLUME quand il fait libéré.

Si vous avez vraiment besoin d'une fenêtre contrôleur pour votre fenêtre principale, vous ne pouvez pas mettre cela dans l' MainMenu.xib.

J'espère que cette aide. Il n'y a probablement beaucoup plus à dire sur la fenêtre de contrôleurs de trop

Answer 2

Est-ce le cas même pour le MainMenu.xib application?

Non, le MainMenu plume est détenue par NSApplication (c'est qui le charge).

Faut-il aussi être le cas pour la NSWC pour le MainMenu.xib fenêtre, même si c'est ouvert au démarrage?

Non, NSApplication charge les principaux plume basé sur vos applications du fichier "NSMainNibFile de la propriété". (Il arrive juste à être pré-réglé sur "MainMenu" dans le modèle des projets Xcode.) Si vous voulez changer son nom, puis le changer là-bas (et renommer votre fichier nib). (BTW: Cette propriété peut également être modifié dans la cible "Résumé" afficher dans Xcode 4.)

Si le NSWC de la MainMenu fenêtre également être l'application délégué, ou devrait-il être une classe différente?

Le propriétaire de la NSMainNibFile plume est l'instance de NSApplication qui le charge et par l'association tout délégué de cette instance. Aucune de ces sont NSWC sous-classes.

Dans la même veine, la NSWC gérer les fichiers (glisser/déposer et d'ouverture), ou doit-il être transmis au délégué d'application, ou est-ce juste une question de goût?

Il n'y a pas de "main NSWC" (app/app-délégué est le contrôleur de la NSMainNibFile).

Tous les drag-n-drop, les opérations sont gérées par NSWindow ou NSView sous-classes. J'ai l'habitude d'utiliser une NSWindow ou NSView sous-classe qui vient de passer tous les drag-n-drop méthodes thru pour le délégué. Par exemple:

- (unsigned int) draggingEntered:sender
{
    return [[self delegate] draggingEntered:sender];
}

De cette façon, je peux garder toutes mes fenêtre/afficher le code dans leurs respectifs contrôleur (tel que déterminé par leur plume propriétaire). Et parce que la fenêtre/afficher le code spécifique dans le contrôleur (pas le NSWindow/NSView sous-classe) de différents types de NSWindows/NSViews pouvons tous utiliser le même drag-n-drop sous-classes.