7
votes

Utilisation de plusieurs fichiers NIB avec un contrôleur d'affichage unique?

fond strong>

J'utilise l'interface Builder pour créer l'interface utilisateur pour une application sur laquelle je travaille. L'application dispose d'un seul écran qui affiche une série de boutons. En cliquant sur une touche Affiche une vue associée qui superpose les boutons. En cliquant sur un autre bouton masque la vue précédente de la superposition et en affiche un autre. P>

Trop, faites la gestion de l'interface utilisateur plus facile dans IB, j'ai décidé de créer plusieurs fichiers NIB pour chaque sous-vue pour apparaître en cliquant sur le bouton correspondant. . Je charge ensuite le fichier NIB de Sous View dans la méthode VIEWDIDLOAD CODE> VIEW CONTRÔLELTER CODE> à l'aide de la classe UINIB CODE> CLASSE. P>

L'idée derrière ceci était d'éviter d'avoir Plusieurs vues empilées les unes sur les autres dans un seul fichier NIB car cela serait difficile à manipuler dans IB. J'aurais pu créer toutes les vues du code, mais cela nécessiterait beaucoup de codage fastidieux car les dispositions de chaque sous-vue sont assez complexes (avec plusieurs vues d'enfants). P>

exemple de code charger une sous-vue de Fichier NIB. P>

- (void)viewDidLoad
{
    UINib *aSubViewNib = [UINib nibWithNibName:@"aSubView" bundle:nil];
    NSArray *bundleObjects = [aSubViewNib instantiateWithOwner:self options:nil];

    // get root view from bundle array
    UIView *aSubView = [bundleObjects objectAtIndex:0];
    [self.view addSubview:aSubView];
...


 est mon approche mauvaise ou inhabituelle?  LI>
 Y a-t-il des problèmes potentiels pour le faire de cette façon?  LI>
 Qu'est-ce que d'autres personnes ont fait quand ils ont besoin d'une interface dynamique et
toujours envie de tout garder dans l'interface Builder?  Li>
 ul>   notes  strong>  p> 
 Avant que quiconque demande pourquoi je ne faisais pas simplement afficher les sous-vues sur un nouvel écran et utilisez-moi la barre de navigation, laissez-moi dire que je Avoir de très bonnes raisons et que je comprends les directives de l'interface utilisateur iOS. Le cas d'utilisation ci-dessus n'est pas exactement mon cas d'utilisation, mais c'est celui qui décrit clairement le problème sans se boucher dans mon application de développement.  P> 
 Je sais que j'aurais pu écrire tous les sous-vues comme code mais chaque sous La vue a une mise en page complexe d'une vue sur les enfants et ce serait beaucoup de code et de jouer pour essayer de les amorer à l'air bien.  p> 
  merci d'avance.  strong>  p>

ios interface-builder nib uiview ios4

0 commentaires

3 Réponses :

0
votes

Chaque vue doit avoir un UIViewController correspondant. En utilisant une vue de vue pour "contrôler" plus d'une vue enfreint le paradigme MVC. "Contrôler" plusieurs "vues" d'un contrôleur rendront beaucoup plus difficile à changer une chose sans casser autre chose. Les choix que vous faites sur la manière de présenter le contenu à l'utilisateur final seront différents pour chaque individu. Donc, si vous dites qu'une carte de navigation ne fonctionnera pas dans votre cas, une vue modale est peut-être la réponse ou, vous pourriez simplement instancier votre UIViewControls personnalisée et les ajouter à votre vue ([AddSubView:]), si c'est la route que vous voulez, Mais comme je l'ai dit, il serait bénéfique pour vous de créer un "contrôleur" pour chaque objet d'affichage avec le XIB correspondant. Si vous avez besoin d'informations renvoyées, utilisez un délégué ou utilisez des notifications pour renvoyer le message à la vue parent. J'ai appris la difficulté à ne pas suivre le paradigme MVC, vous rendra la vie misérable. Essayez de garder votre code aussi découplé que possible. Et lisez sur le modèle de conception MVC, vous ne le regretterez pas.

3 commentaires

Toutes les sous-vues sont liées à l'écran unique et donc un contrôleur d'affichage unique. J'aurais pu facilement ajouter toutes les sous-vues dans le même fichier NIB, mais comme je l'ai dit que cela devint désordonné et difficile à mettre en page comme des vues se chevauchent. Mon idée était de rompre certaines des vues dans des fichiers NIB distincts, puis de les charger dans la vue principale à l'aide de la méthode ViewDiddIdload de l'affichage.

Chaque vue doit avoir un UIViewController correspondant. En utilisant une vue de vue pour "contrôler" plus d'une vue enfreint le paradigme MVC. Si cela était vrai, comment fonctionne Universal View Controller?, il a 2 points de nibrage.

Je pensais presque la même chose @hubert. Il semble y avoir des problèmes associés à cela. Si la décision est effectuée au moment de l'exécution et sur un bouton, cela signifie-t-il que le XIB sera chargé en arrière-plan, les infecte tous, et on sera sélectionné? En outre, Autolayout aurait pu résoudre le problème facilement.

1
votes

Il n'y a pas nécessairement une relation de 1 à 1 entre les contrôleurs d'affichage et les vues. La plupart des vues contiennent de nombreux sous-espions, qui sont des vues elles-mêmes, donc cela n'a littéralement pas de sens.

Cependant, en fonction de la complexité des vues (y compris de leur contenu), vous pouvez souhaiter des contrôleurs de vue séparés ... ou non.

Par exemple, si vous avez deux SBUVIEWS qui sont chaque tableViews, vous pouvez avoir un contrôleur d'affichage pour chaque TableView. En effet, chaque TableView examine les mêmes méthodes de délégation, et s'ils se trouvent dans la même liste de visualisation, les méthodes déléguées doivent alors faire la différence entre les visites de la table. Les méthodes déléguées ont des signatures qui permettent cela, mais dans mon expérience, il peut vraiment faire une conception de code désordonnée difficile à suivre et difficile à gérer.

D'autre part, vous pouvez avoir deux tables gérées par le même mode de vue, où une table est remplie de données significatives et que l'autre est simplement un support de lieu (comme lorsque la source de données est vide). On pourrait être visible tant que l'autre n'est pas. Pourquoi vous rendre la vie compliquée en créant deux contrôleurs d'affichage lorsque les deux sont entraînés par la même source de données (le modèle)?

Dans mon esprit, cela revient à quel point il est difficile de suivre et de gérer le code. Si la complexité de l'utilisation d'un contrôleur d'affichage unique devient bourdonnée, envisagez d'utiliser plus de contrôleurs de vue.

mise à jour

Au fait, j'ai un exemple que je travaille actuellement avec cela peut illustrer une situation similaire. Dans InAppSettingskit, que beaucoup de développeurs utilisent, il existe plusieurs fichiers XIB pour des morceaux de la vue principale. Vous pouvez consulter la structure ici sur Github . Il y a un point de vue principal et plusieurs fichiers XIB. (Il y a aussi ce que j'appellerais un contrôleur d'affichage "assistant" et un contrôleur d'affichage du compositeur de courrier électronique.) Dans cet exemple, les fichiers XIB peuvent être utilisés à plusieurs reprises pour spécifier la disposition des cellules de la vue de table. Il n'y a pas de contrôleur d'affichage pour chaque fichier XIB, cependant. (La documentation pour InAppSettingskit est rare, de sorte que ces choses peuvent ne pas être évidentes simplement en y regardant rapidement.)

4 commentaires

Donc, pour mon cas d'utilisation où la seule raison pour laquelle j'ai divisé les vues dans des fichiers de NIB distinctes consistait à faciliter la gestion de ces points de vue de l'IB, pensez-vous que mon approche est prudente à utiliser ou de casser les directives d'Apple?

Il n'y a pas de règle ou de directive concernant ce que vous faites. Vous allez bien à cet égard.

J'ai ajouté un exemple de composant logiciel réel que de nombreux développeurs utilisent. Voir ma réponse ci-dessus pour plus de détails.

Merci Jim. Je voulais juste m'assurer que je ne faisais pas quelque chose de fou.

0
votes

En fait, il est possible de faire cela.

Ouvrez votre fichier .xib, sélectionnez le propriétaire du fichier (dans l'espace réservé) -> "Inspecteur d'identité" (utilitaires) -> Modifier le nom de la classe à votre contrôleur de classeName -> Appuyez sur Control et faites glisser le propriétaire du fichier pour afficher l'objet, sélectionnez " "Dans la boîte de dialogue. Maintenant, vous pouvez personnaliser votre vue.

P.s. Vous pouvez utiliser les mêmes points de vente que le premier XIB, vous n'avez besoin que de les faire glisser sur le nouveau XIB (+ Contrôle de contrôle).

Voici un tutoriel expliqué: http://irawd.wordpress.com/2013/09/05/how-to-link-a-xib-file-a-a-class-and- Utilisez-2-XIB-Files-for-iPhone4-and iPhone5 /

2 commentaires

Publier des liens en tant que pourraient être bons mais des liens ont tendance à se perdre ... veuillez poster les éléments critiques de votre réponse dans le corps de réponse.

@Nirmh édité. merci pour les commentaires, c'est ma première réponse sur tellement