2010-03-08 7 views
3

J'ai un UIViewController qui charge plusieurs sous-vues à des moments différents en fonction de l'interaction de l'utilisateur. J'ai initialement construit toutes ces sous-vues en code, sans fichiers nib. Maintenant, je passe à des fichiers nib avec des sous-classes UIView personnalisées.Comment utiliser un contrôleur générique (NSObject) avec des sous-vues d'un UIViewController?

Certaines de ces sous-vues affichent des données statiques et j'utilise loadNibNamed: owner: options: pour les charger dans le contrôleur de vue. D'autres contiennent des contrôles auxquels j'ai besoin d'accéder. Je comprends (en quelque sorte) les raisons pour lesquelles Apple dit d'utiliser un contrôleur de vue par écran de contenu, en utilisant des objets contrôleur génériques (NSObjects) pour gérer les sous-sections d'un écran. J'ai donc besoin d'un contrôleur de vue, d'un contrôleur générique, d'une classe de vue et d'une plume. Comment puis-je mettre tout cela ensemble?

Mes hypothèses de travail et les questions suivantes:

  • j'associer la classe de vue avec la pointe dans le menu déroulant « identité de classe » dans IB.
  • Le contrôleur de vue coordonnera les interactions globales de l'écran. Lorsque nécessaire, il va créer une instance du contrôleur générique.
  • Le contrôleur générique charge-t-il la plume ? Comment?
  • Est-ce que je définis les points de vente et les actions dans cette classe de vue ou doivent-ils être dans le contrôleur générique?
  • Comment transmettre des messages entre le contrôleur de vue et le contrôleur générique ?

Si quelqu'un peut me pointer vers un exemple de code en utilisant un contrôleur de cette façon, cela m'aidera à comprendre. Aucun des livres ou des messages de stackoverflow que j'ai lus n'ont encore atteint leur but.

+1

Remarque: Si vous souhaitez diviser un seul écran en plusieurs zones et gérer chacune séparément, utilisez des objets de contrôleur génériques (objets personnalisés descendant de NSObject) au lieu de voir les objets de contrôleur pour gérer chaque sous-section de l'écran. Utilisez ensuite un objet contrôleur de vue unique pour gérer les objets de contrôleur génériques. Le contrôleur de vue coordonne les interactions globales de l'écran mais transmet les messages selon les besoins aux objets de contrôleur génériques qu'il gère. – wanderlust

Répondre

3

D'accord, je pense que j'ai tout compris:

  1. Extend NSObject pour rendre votre CustomController
  2. Définissez vos points & actons dans CustomController.h, y compris une référence à la UIView dans votre nib
  3. Définir le propriétaire du fichier de votre plume sur CustomController
  4. Relier toutes vos prises & comme d'habitude, y compris la sortie UIView
  5. Dans votre init CustomController.m, chargez la pointe

- (id)init { 
    self = [super init]; 
    if (self != nil) 
     [self loadNib]; 

    return self; 
} 

- (BOOL)loadNib { 
    NSArray *topLevelObjs = nil; 
    topLevelObjs = [[NSBundle mainBundle] loadNibNamed:@"CustomView" owner:self options:nil]; 

    if (topLevelObjs == nil) { 
     NSLog(@"Error! Could not load nib file.\n"); 
     return NO; 
    } 
    return YES; 
} 

Le nouveau contrôleur basé NSObject fonctionne très bien comme un contrôleur de vue.

+0

Malheureusement, cette solution n'ajoute pas CustomController à la chaîne du répondeur. – titaniumdecoy

+0

Selon les fichiers d'aide d'Apple, je ne pense pas que vous devriez faire cela. Au lieu de cela, ils prescrivent que le ViewController contenant tous les contrôleurs génériques gère les réponses. Je suis en train de le faire moi-même, donc si je me trompe, j'aimerais l'entendre :) – SpacyRicochet

1

On dirait que ce que vous voulez est ce que j'ai inventé "widgets UIView réutilisables" - des widgets réutilisables qui font quelque chose/présentent un affichage que vous pouvez intégrer dans vos écrans d'applications où et combien de fois vous voulez - vous pouvez les créer purement en code ou les instancier en plaçant leur cadre dans un autre fichier xib (mais vous ne pouvez pas modifier les paramètres internes des widgets dans le fichier xib, ce qui nécessiterait un plugin IB).

Ceci est une organisation que je n'ai jamais vu discuté nulle part. Une partie de ma frustration au début de la programmation iOS est de vouloir quelque chose comme ça, mais ne voyant aucun moyen de l'exprimer dans un exemple.

Voir ma réponse à cette question pour voir comment il peut être structuré:

UIView and initWithFrame and a NIB file. How can i get the NIB file loaded?

Je recommande de placer toutes les manipulations widget interne des événements directs/bas niveau dans la sous-classe widget UIView et implememnt un protocole délégué pour une interaction de niveau supérieur avec le client du widget (par exemple, "loginRequested: userName: passWord" au lieu d'accéder manuellement au bouton et aux champs de texte internes au widget). Le fichier xib (facultatif mais recommandé) du widget a un propriétaire du widget, et le code d'initialisation du widget est chargé de charger le fichier xib. Le client du widget instancie simplement le widget et implémente les fonctions de délégué du widget sans problème.