Je travaille dans une entreprise où nous avons plusieurs développeurs IOS et que nous utilisons Git pour travailler dans les mêmes projets ensemble. Nous n'utilisons jamais de storyboards ou de fichiers .xib dans notre processus de développement car il est presque impossible de les fusionner correctement.
Avec l'introduction de l'IOS7, j'ai pensé aux différences fondamentales entre des storyboards et codant tout l'interface utilisateur "the vieil", sans utiliser de constructeur d'interface.
Y a-t-il quelqu'un ici qui fait exactement ça? Et surtout, il y a quelque chose que vous pouvez faire dans des storyboards que vous ne pouvez pas faire en code dans xcode 5?
3 Réponses :
Je vais scinder votre question en deux: Nibs et storyboards.
En ce qui concerne les NIBS, les problèmes de contrôle des sources peuvent être douloureux mais gérables, principalement parce que vous avez généralement un fichier NIB par contrôleur d'affichage. Vous pouvez imaginer une situation dans laquelle vous avez deux développeurs travaillant sur deux sections différentes de votre application Powered NIB sans aucun problème de fusion. Les storyboards sont différents, car vous avez un seul fichier qui décrit le plus - sinon tout - de l'interface utilisateur de votre application. Il existe clairement un potentiel de problèmes de conflit beaucoup plus grand.
NIBS peut être extrêmement utile et gagner du temps, si utilisé correctement. Voici un exemple: l'application iPhoto sur iPad a une interface utilisateur très complexe. La grande majorité de cet interface utilisateur est aménagée de manière provisoire. Cependant, , l'application utilise également des pointes pour charger des éléments graphiques qui sont ensuite définis dans le code. C'est ainsi que fonctionne le panneau de brosse - toutes les brosses sont créées dans une nibr. Cela signifie que Apple ne doit pas avoir à avoir des dizaines d'images identiques / images d'image ALLOC / INIT Pièces de code. Toute la création peut se produire dans une NIB (cela a été discuté de manière détaillée dans une session de la WWDC 2012 sur l'interface utilisateur iPhoto - il vaut bien la peine de suivre).
SO NIBS - Parfois bien, peut vous faire gagner beaucoup de temps et, tandis que là sont les problèmes de fusion qu'ils peuvent dans de nombreux cas être facilement gérés et gérés.
Ensuite, nous arrivons à des storyboards. Les storyboards sont intéressants. D'une part, ils sont extrêmement utiles et utiles pour des applications simples et des développeurs nouvelles sur la plate-forme. Je viens de convertir un Toutefois, si vous travaillez sur un projet à grande échelle avec plusieurs développeurs, je ne suis pas convaincu que les storyboards sont aussi bénéfiques. Comme vous le dites, de gros problèmes avec les conflits de fusion et contrairement aux NIBS, il n'est pas facile de les résoudre puisque ce fichier de scénario unique contrôle tous de votre UI de votre application.
Voici ce que je suggère (et n'hésitez pas à m'ignorer!) - Si vous développez des applications et que vous effectuez votre mise en page / UI> entièrement dans le code, déterminez si les NIBS pourraient vous faire gagner du temps. Ils peuvent bien pas - ils ne sont pas pour tout le monde - mais cela vaut bien au moins la peine d'envisager. Vous pouvez être surpris de savoir combien de grandes applications utilisent réellement des NIBS (iPhoto, comme je l'ai mentionnée, mais également de nombreuses applications intégrées fournies par Apple, ainsi que de nombreuses applications tierces populaires par grandes équipes). Je ne voudrais probablement pas considérer les storyboards à moins que vous soyez un développeur unique travaillant sur une application avec une navigation assez simple. Cela ne va pas faire de storyboards de quelque manière que ce soit - j'adore les utiliser - c'est juste qu'ils ne conviennent pas vraiment à la collaboration.
Quelqu'un a posté ce commentaire en réponse à votre question - je voulais en discuter:
Il n'y a rien que vous puissiez faire dans Storyboard et ne peut pas faire en code. Objets, gestes reconnaissants, segues, voire contraintes - sont tous disponibles pour que vous construis par programme
Ceci est Techniquement vrai, mais en réalité, il y a des choses dans des storyboards / des pointes qui sont UinavigationController de NIBS à des storyboards et a trouvé des économies de temps significatives (en particulier des vues de table, car avec des storyboards, vous pouvez profiter des cellules prototypes).
N'oubliez pas que vous pouvez avoir plusieurs scénario comme vous pouvez avoir plusieurs points de poing.
"Il n'y a rien que vous puissiez faire dans le storyboard et ne peut pas faire en code", c'est comme dire "il n'y a rien que vous puissiez faire dans l'objectif-C et ne peut pas faire en assembleur". C'est vrai, mais il y a des différences de productivité.
Il est vrai que les contraintes de la vanille sont une sorte de douleur particulière qui devrait être évitée. Mais il y a des DSL qui aident un perdu , consultez Snapkit.
Les différences de productivité sont si mignonnes énormes que vous ne pouvez même pas la regarder comme la même catégorie de choses. Considérez par exemple que vous Ne nécessitez pas littéralement de Photoshop pour retoucher des images de PNG brutes de 80 Mo si vous êtes un photographe de mariage. Bien sûr que pas! Vous pouvez simplement l'ouvrir dans le texte Modifier et modifier les octets!
Vous devriez considérer ces problèmes dans votre déception:
Évidemment, travailler avec le concepteur UI Xcode est beaucoup plus rapide et facile à apprendre lors de la création de nouvelles applications à partir de zéro.
De manière programmatique, vous devrez définir dans le code chaque élément d'élément que vous voudrez définir.
Travailler avec Storyboard rendra le processus de développement beaucoup plus rapide.
Lorsque vous travaillez avec Storyboard, vous devrez lier les éléments UI au contrôleur avec des balles qui ajoute du code caché supplémentaire dans le fichier de scénarique. Les mêmes talons sont ajoutés lors de la création de segues entre contrôleur.
Cet addition Code caché fera rendre plus difficile de réutiliser les contrôleurs d'autres applications que vous construirez.
Si vous envisagez de faire une réutilisation de masse du code des contrôleurs, que la création des éléments de l'interface utilisateur sera plus approprié.
Les conflits résolvements sont une chose courante lorsque plusieurs développeurs valent des modifications apportées au dossier.
Création et modification des éléments d'interface utilisateur avec Storyboard Des modifications supplémentaires sont ajoutées au fichier de scénario qui rend parfois les conflits résoluds la sorte de délicatesse.
D'autre part, lors de la modification des éléments de l'interface utilisateur, seules les modifications que vous apporterez seront ajoutées le fichier de contrôleur.
Pour moi, le seul grand inconvénient de storyboards est le temps de chargement lent et le décalage habituel qui vient à la navigation du storyboard. Je ne parle pas d'applications de contrôleurs 2-5. Je parle de 10 ans et plus ...
Mes préférences personnelles sont des storyboards plus petits si je dois vraiment les utiliser (des cellules prototypes uitaires) ou simplement des xibs simples.
Le faire dans un code simple est juste une question de .... Avez-vous assez de temps sur vos mains? :) généralement, vous ne gagnerez pas beaucoup de cela de cette façon.
Vous ne pouvez rien faire dans Storyboard et ne peut pas faire en code. Les objets, les reconnaissants de geste, les segues, les contraintes même - sont tous disponibles pour que vous puissiez développer par programme.
@Nemesis concernant la Segue par exemple, ne sont-ils pas utilisés dans des storyboards? J'utilise principalement
[auto.navigationController pushviewController ...] ou justePresentViewControllerLes segues sont créés beaucoup plus facilement dans des storyboards (comme tout le reste), mais vous pouvez également les créer par programme. Personnellement, je n'ai jamais fait ça, mais le Documentation d'assurance-emploi dit que vous pouvez utiliser
InitwithIdentifier: Source: Destination: Pour créer une Segue.En fait, l'utilisation de storyboards générant simplement le même code sur l'arrière-plan. Donc, avec cette logique, chaque action et propriété de storyboard doivent avoir un code égal ..
@Nemesis: il y a des choses que vous ne pouvez pas faire sans storyboards. Les segues, par exemple, ne sont pas destinés à être créés par code (de la DOCS: «Vous ne créez pas directement des objets de Segue. Au lieu de cela, le Storyboard Runtime les crée lorsqu'il doit effectuer une SEGUE entre deux contrôleurs de vue.»). L'initialiseur est documenté au cas où vous auriez besoin de sous-classement. Une autre chose que vous ne pouvez faire que avec des storyboards et non avec du code ni de XIBS, autant que je sache, c'est des cellules de vue de la table statique.
Ne jamais éviter les storyboards. Utilisez toujours une approche de scénario dans 100% des situations. Tout ce qui est ridicule.