Personnellement je ne comprends pas pourquoi il y a tant de frein à l'utilisation des Storyboards. Ils ont peut être mal commencé mais aujourd'hui je les trouve indispensables, ne serait-ce que pour Auto-layout.
Personnellement je ne comprends pas pourquoi il y a tant de frein à l'utilisation des Storyboards.
- Ils posent toujours problème quand on travaille en groupe (va merger les modifs avec git pour voir) - Ils définissent la navigation dans l'application. Dans un sens, c'est pratique pour les débutants puisque ça donne une vision d'ensemble. Mais ça crée une interdépendance entre les view controllers, qui devient de plus en plus problématique quand l'appli grossit.
Ils ont peut être mal commencé mais aujourd'hui je les trouve indispensables, ne serait-ce que pour Auto-layout.
L'auto-layout fonctionne aussi dans les xib.
N'utiliser ni les Storyboards ni les xib, c'est du masochisme.
- Ils posent toujours problème quand on travaille en groupe (va merger les modifs avec git pour voir)
Effectivement, sur ce point nous sommes d'accord. Comme tous les fichiers générés par des logiciels, la gestion des versions pose problème.
- Ils définissent la navigation dans l'application. Dans un sens, c'est pratique pour les débutants puisque ça donne une vision d'ensemble. Mais ça crée une interdépendance entre les view controllers, qui devient de plus en plus problématique quand l'appli grossit.
L'interdépendance entre les contrôleurs serait présente dans tous les cas puisque si ce n'est pas le storyboard qui déclenche la transition, c'est le contrôleur de départ qui crée et prépare le contrôleur de destination.
Par contre je suis assez d'accord sur le problème des apps qui grossissent surtout quand le Storyboard devient trop gros et qu'il est lent à utiliser dans XCode.
L'auto-layout fonctionne aussi dans les xib.
N'utiliser ni les Storyboards ni les xib, c'est du masochisme.
Effectivement je n'ai pas fait la distinction entre les Storyboard et les xib mais je parlais justement d'utiliser l'un ou l'autre VS coder l'interface en Swift/ObjC.
Par contre je suis assez d'accord sur le problème des apps qui grossissent surtout quand le Storyboard devient trop gros et qu'il est lent à utiliser dans XCode.
J'utilise des References de Storyboard personnellement.
Cela permet de laisser mes collègues travailler sur une partie du Storyboard pendant que je travaille sur une autre. Cela ne règle pas tous les soucis évidemment, mais rien que niveau poids des Storyboards, c'est pas mal.
Après, c'est toujours délicat et propre au projet de définir ce qui fait partie d'une "branche" d'un SB, car sinon, on peut très vite arriver à des SB qui n'ont qu'un VC (en bref des XIB), avec des liens vers d'autres SB.
L'interdépendance entre les contrôleurs serait présente dans tous les cas puisque si ce n'est pas le storyboard qui déclenche la transition, c'est le contrôleur de départ qui crée et prépare le contrôleur de destination.
Pas forcément. Dans l'application que je développe actuellement, j'ai une classe AppRouter qui instancie les contrôleurs de base: Tabbar controller, navigations controllers, et leurs contrôleurs "racine". Un de ces contrôleur racine est un ProductsTableViewController qui présente une liste de Produits. Lors de l'appel de sa méthode tableViewDidSelectRowAtIndexPath, il prévient par délégation l'AppRouter qu'un Produit a été sélectionné. C'est alors l'AppRouter qui crée le ProductDetailsViewController et l'empile sur le navigation controller.
L'inconvénient de cette méthode est qu'il faut mettre en place la délégation. Pas bien compliqué en Swift. L'avantage principal est que le ProductsTableViewController ne gère plus la navigation. Et hop, une responsabilité de moins! Et on a une classe AppRouter qui a un rôle bien défini.
Juste pour préciser, je n'ai aucune haine envers les Storyboards. Seulement, ils règlent un problème que je n'ai jamais eu " gérer la navigation " d'une façon vraiment pas satisfaisante.
En pratique, je les utilise quand je crée une TableView statique. Dans ce cas, j'ai un storyboard contenant un seul contrôleur. Mais pour moi, c'est surtout parce qu'on ne peut pas le faire avec les xib.
Effectivement j'aime beaucoup cette idée de routeur!
Donc du coup ce que tu n'aimes pas dans les Storyboard ce sont les segue, car rien ne t'empêche d'utiliser les Storyboards sans les segue et utiliser des actions sur tes boutons pour appeler ton routeur.
Si on fait ça la différence entre les storyboards et les xib devient de plus en plus floue mais j'avais supposé (apparemment à tort) que les xib avaient été abandonné petit à petit par Apple et ne supportaient pas les dernières fonctionnalités.
On peut vraiment tout faire dans les xib ? (auto-layout, Size-classes de auto-layout, prototypes de cellules, tables statiques, SafeArea, etc.)
Donc du coup ce que tu n'aimes pas dans les Storyboard ce sont les segue, car rien ne t'empêche d'utiliser les Storyboards sans les segue et utiliser des actions sur tes boutons pour appeler ton routeur.
C'est vrai. Il me faudrait étudier la question.
On peut vraiment tout faire dans les xib ? (auto-layout, Size-classes de auto-layout, prototypes de cellules, tables statiques, SafeArea, etc.)
Pour le layout, il me semble que oui. Par contre, on ne peut pas y définir les tableviews statiques, c'est pourquoi j'indiquais utiliser les storyboards dans ce cas.
Comme l'a évoqué Céroce mon principal frein à l'utilisation d'xib reste le souci des merges lors de programmation en concurrence. Généralement je fixe mes enchaà®nements d'écran avec xib sur un storyboard et je construis mes IHM via Swift.
De ce fait :
- quand ton app commence à grossir, XCode ne passe pas des minutes entière à ouvrir le storyboard
- tu t'affranchis de faire des merges sur du code autogénéré illisible
- l'évolution de l'IHM (via l'historique Git) est bien plus lisible
- je n'utilise pas le caractère "!" pour la déclaration de mes composants dans mon controller, je passe par :
quel est l'intérêt des XIB actuellement par rapport à Storyboard ? (désolé mais je n'ai jamais réellement utilisé les XIB)
Ta question est très légitime. On a un seul xib par ViewController, et on fait l'instanciation du contrôleur soi-même. En fait, ça en fait plutôt moins que les Storyboards, d'où découlent certaines qualités: - pas besoin de donner des id à ses ViewControllers (donc d'oublier de les nommer) - un seul VC par xib => moins de problèmes quand on travaille en équipe, puisqu'il y a moins de chances que deux membres viennent modifier le même fichier. - on conserve entièrement la main sur la navigation
Pour les défauts de cette approche, vois plus haut.
Réponses
- Ils définissent la navigation dans l'application. Dans un sens, c'est pratique pour les débutants puisque ça donne une vision d'ensemble. Mais ça crée une interdépendance entre les view controllers, qui devient de plus en plus problématique quand l'appli grossit.
L'auto-layout fonctionne aussi dans les xib.
N'utiliser ni les Storyboards ni les xib, c'est du masochisme.
Effectivement, sur ce point nous sommes d'accord. Comme tous les fichiers générés par des logiciels, la gestion des versions pose problème.
L'interdépendance entre les contrôleurs serait présente dans tous les cas puisque si ce n'est pas le storyboard qui déclenche la transition, c'est le contrôleur de départ qui crée et prépare le contrôleur de destination.
Par contre je suis assez d'accord sur le problème des apps qui grossissent surtout quand le Storyboard devient trop gros et qu'il est lent à utiliser dans XCode.
Effectivement je n'ai pas fait la distinction entre les Storyboard et les xib mais je parlais justement d'utiliser l'un ou l'autre VS coder l'interface en Swift/ObjC.
J'utilise des References de Storyboard personnellement.
Cela permet de laisser mes collègues travailler sur une partie du Storyboard pendant que je travaille sur une autre. Cela ne règle pas tous les soucis évidemment, mais rien que niveau poids des Storyboards, c'est pas mal.
Après, c'est toujours délicat et propre au projet de définir ce qui fait partie d'une "branche" d'un SB, car sinon, on peut très vite arriver à des SB qui n'ont qu'un VC (en bref des XIB), avec des liens vers d'autres SB.
Dans l'application que je développe actuellement, j'ai une classe AppRouter qui instancie les contrôleurs de base: Tabbar controller, navigations controllers, et leurs contrôleurs "racine".
Un de ces contrôleur racine est un ProductsTableViewController qui présente une liste de Produits. Lors de l'appel de sa méthode tableViewDidSelectRowAtIndexPath, il prévient par délégation l'AppRouter qu'un Produit a été sélectionné. C'est alors l'AppRouter qui crée le ProductDetailsViewController et l'empile sur le navigation controller.
L'inconvénient de cette méthode est qu'il faut mettre en place la délégation. Pas bien compliqué en Swift.
L'avantage principal est que le ProductsTableViewController ne gère plus la navigation. Et hop, une responsabilité de moins! Et on a une classe AppRouter qui a un rôle bien défini.
Voir cet article: https://medium.com/swift-programming/mvc-rs-8780e73e9ff4. Ce fut une révélation pour moi quand Greg Lhotellier en a fait la démonstration à FrenchKit l'an dernier.
Et aussi pas mal de billets de Soroush Khanlou à ce sujet: http://khanlou.com
En pratique, je les utilise quand je crée une TableView statique. Dans ce cas, j'ai un storyboard contenant un seul contrôleur. Mais pour moi, c'est surtout parce qu'on ne peut pas le faire avec les xib.
Effectivement j'aime beaucoup cette idée de routeur!
Donc du coup ce que tu n'aimes pas dans les Storyboard ce sont les segue, car rien ne t'empêche d'utiliser les Storyboards sans les segue et utiliser des actions sur tes boutons pour appeler ton routeur.
Si on fait ça la différence entre les storyboards et les xib devient de plus en plus floue mais j'avais supposé (apparemment à tort) que les xib avaient été abandonné petit à petit par Apple et ne supportaient pas les dernières fonctionnalités.
On peut vraiment tout faire dans les xib ? (auto-layout, Size-classes de auto-layout, prototypes de cellules, tables statiques, SafeArea, etc.)
Pour le layout, il me semble que oui.
Par contre, on ne peut pas y définir les tableviews statiques, c'est pourquoi j'indiquais utiliser les storyboards dans ce cas.
Perso j'ai une programmation de type hybride.
Comme l'a évoqué Céroce mon principal frein à l'utilisation d'xib reste le souci des merges lors de programmation en concurrence. Généralement je fixe mes enchaà®nements d'écran avec xib sur un storyboard et je construis mes IHM via Swift.
De ce fait :
- quand ton app commence à grossir, XCode ne passe pas des minutes entière à ouvrir le storyboard
- tu t'affranchis de faire des merges sur du code autogénéré illisible
- l'évolution de l'IHM (via l'historique Git) est bien plus lisible
- je n'utilise pas le caractère "!" pour la déclaration de mes composants dans mon controller, je passe par :
Je profite du sujet pour poser une question :
quel est l'intérêt des XIB actuellement par rapport à Storyboard ? (désolé mais je n'ai jamais réellement utilisé les XIB)
xib = Xcode Interface Builder
C'est ce qui te permet de designer tes IHMs dans ton storyboard.
On a un seul xib par ViewController, et on fait l'instanciation du contrôleur soi-même. En fait, ça en fait plutôt moins que les Storyboards, d'où découlent certaines qualités:
- pas besoin de donner des id à ses ViewControllers (donc d'oublier de les nommer)
- un seul VC par xib => moins de problèmes quand on travaille en équipe, puisqu'il y a moins de chances que deux membres viennent modifier le même fichier.
- on conserve entièrement la main sur la navigation
Pour les défauts de cette approche, vois plus haut.
Oooops, j'avais mal lu la question. ::)