Cuándo usar Storyboard y cuándo usar XIB

Este grupo de especialistas luego de varios días de investigación y recopilación de de datos, han obtenido la respuesta, queremos que te sea útil para tu proyecto.

Solución:

Actualización 12/01/2016: Es 2016 y todavía prefiero diseñar mis UI en código y no en Storyboards. Dicho esto, los guiones gráficos han recorrido un largo camino. He eliminado todos los puntos de esta publicación que simplemente ya no se aplican en 2016.

Actualización 24/04/2015: Curiosamente, Apple ni siquiera usa Storyboards en su ResearchKit de código abierto recientemente, como ha notado Peter Steinberger (bajo el subtítulo “Interface Builder”).

Actualización 10/06/2014: Como era de esperar, Apple sigue mejorando Storyboards y Xcode. Algunos de los puntos que se aplicaron a iOS 7 y a continuación ya no se aplican a iOS 8 (y ahora están marcados como tales). Entonces, aunque los guiones gráficos todavía tienen fallas inherentes, reviso mi consejo de no use para usar selectivamente donde tenga sentido.

Incluso ahora que iOS 9 está disponible, recomendaría contra tener cuidado al decidir si usar Storyboards. Estas son mis razones:

• Los guiones gráficos fallan en tiempo de ejecución, no en tiempo de compilación: ¿Tiene un error tipográfico en un nombre de segue o lo conectó mal en su guión gráfico? Explotará en tiempo de ejecución. ¿Utiliza una subclase personalizada de UIViewController que ya no existe en su guión gráfico? Explotará en tiempo de ejecución. Si hace estas cosas en código, las detectará desde el principio, durante el tiempo de compilación. Actualizar: Mi nueva herramienta StoryboardLint principalmente resuelve este problema.

• Los guiones gráficos se vuelven confusos rápidamente: A medida que su proyecto crece, su guión gráfico se vuelve cada vez más difícil de navegar. Además, si varios controladores de vista tienen múltiples pasos a otros múltiples controladores de vista, su guión gráfico rápidamente comienza a verse como un plato de espaguetis y se encontrará acercándose y alejándose y desplazándose por todo el lugar para encontrar el controlador de vista que está buscando. para y para averiguar qué puntos de segue y dónde. Actualizar: Este problema se puede resolver principalmente dividiendo su Storyboard en múltiples Storyboards, como se describe en este artículo de Pilky y este artículo de Robert Brown.

• Los guiones gráficos hacen que trabajar en equipo sea más difícil: Debido a que generalmente solo tiene un archivo de guión gráfico enorme para su proyecto, tener varios desarrolladores que realizan cambios regularmente en ese archivo puede ser un dolor de cabeza: los cambios deben fusionarse y los conflictos deben resolverse. Cuando ocurre un conflicto, es difícil saber cómo resolverlo: Xcode genera el archivo XML del guión gráfico y no fue realmente diseñado con el objetivo en mente de que un humano tendría que leerlo, y mucho menos editarlo.

• Los guiones gráficos hacen que las revisiones de código sean difíciles o casi imposibles: Las revisiones de código de pares son una gran cosa para hacer en su equipo. Sin embargo, cuando realiza cambios en un guión gráfico, es casi imposible revisar estos cambios con un desarrollador diferente. Todo lo que puede extraer es una diferencia de un archivo XML enorme. Descifrar lo que realmente cambió y si esos cambios son correctos o si rompieron algo es realmente difícil.

• Los guiones gráficos dificultan la reutilización del código: En mis proyectos de iOS, normalmente creo una clase que contiene todos los colores, fuentes, márgenes e inserciones que utilizo en toda la aplicación para darle un aspecto y una sensación coherentes: es un cambio de una línea si tengo que ajustar alguno de esos valores para toda la aplicación. Si establece dichos valores en el guión gráfico, los duplicará y deberá encontrar cada ocurrencia cuando desee cambiarlos. Es muy probable que se pierda uno, porque no hay búsqueda y reemplazo en los guiones gráficos.

• Los guiones gráficos requieren cambios de contexto constantes: Me encuentro trabajando y navegando mucho más rápido en código que en guiones gráficos. Cuando su aplicación usa guiones gráficos, cambia constantemente su contexto: “Oh, quiero tocar esta celda de vista de tabla para cargar un controlador de vista diferente. Ahora tengo que abrir el guión gráfico, encontrar el controlador de vista correcto, crear una nueva secuencia al otro controlador de vista (que también tengo que encontrar), darle un nombre al segue, recordar ese nombre (no puedo usar constantes o variables en los guiones gráficos), volver al código y espero no escribir mal el nombre de ese paso para mi método prepareForSegue. ¡Cómo me gustaría poder escribir esas 3 líneas de código aquí mismo, donde estoy! ” No, no es divertido. Cambiar entre el código y el guión gráfico (y entre el teclado y el mouse) envejece rápidamente y lo ralentiza.

• Los guiones gráficos son difíciles de refactorizar: Cuando refactorice su código, debe asegurarse de que aún coincida con lo que espera su guión gráfico. Cuando mueva las cosas en su guión gráfico, solo descubrirá en tiempo de ejecución si todavía funciona con su código. Me parece que tengo que mantener dos mundos sincronizados. Se siente frágil y desalienta el cambio en mi humilde opinión.

• Los guiones gráficos son menos flexibles: ¡En código, básicamente puedes hacer lo que quieras! Con los guiones gráficos, está limitado a un subconjunto de lo que puede hacer en el código. Especialmente cuando desee hacer algunas cosas avanzadas con animaciones y transiciones, se encontrará “luchando contra el guión gráfico” para que funcione.

• Los guiones gráficos no le permiten cambiar el tipo de controladores de vista especiales: Quieres cambiar un UITableViewController en un UICollectionViewController? O en una llanura UIViewController? No es posible en un Storyboard. Debe eliminar el controlador de vista anterior y crear uno nuevo y volver a conectar todos los segues. Es mucho más fácil hacer un cambio de código de este tipo.

• Los guiones gráficos agregan dos responsabilidades adicionales a su proyecto: (1) La herramienta Storyboard Editor que genera el XML del storyboard y (2) el componente de tiempo de ejecución que analiza el XML y crea la interfaz de usuario y los objetos de controlador a partir de él. Ambas partes pueden tener errores que no se pueden corregir.

• Los guiones gráficos no le permiten agregar una subvista a una UIImageView: Quién sabe por qué.

• Los guiones gráficos no le permiten habilitar el diseño automático para vistas individuales (-Controlador): Al marcar / desmarcar la opción Diseño automático en un Storyboard, el cambio se aplica a TODOS los controladores en el Storyboard. (¡Gracias a Sava Mazăre por este punto!)

• Los guiones gráficos tienen un mayor riesgo de romper la compatibilidad con versiones anteriores: Xcode a veces cambia el formato de archivo de Storyboard y no garantiza de ninguna manera que podrá abrir los archivos de Storyboard que cree hoy dentro de unos años o incluso meses a partir de ahora. (Gracias a Thoughtadvances por este punto. Ver el comentario original)

• Los guiones gráficos pueden hacer que su código sea más complejo: Cuando crea sus controladores de vista en el código, puede crear init métodos, por ejemplo initWithCustomer:. De esa manera, puede hacer customer dentro de su controlador de vista inmutable y asegúrese de que este controlador de vista no se pueda crear sin un customer objeto. Esto no es posible cuando se utilizan guiones gráficos. Tendrás que esperar a que prepareForSegue:sender: método que se llamará y luego tendrá que configurar el customer propiedad en su controlador de vista, lo que significa que debe hacer que esta propiedad sea mutable y tendrá que permitir que el controlador de vista se cree sin un customer objeto. En mi experiencia, esto puede complicar enormemente su código y hace que sea más difícil razonar sobre el flujo de su aplicación. Actualización 9/9/16: Chris Dzombak escribió un gran artículo sobre este problema.

• Es McDonald’s: Para decirlo con las palabras de Steve Jobs sobre Microsoft: ¡Es McDonald’s (video)!

Estas son mis razones por las que realmente no me gusta trabajar con guiones gráficos. Algunas de estas razones también se aplican a los XIB. En los proyectos basados ​​en guiones gráficos en los que he trabajado, me han costado mucho más tiempo del que han ahorrado y han hecho las cosas más complicadas en lugar de más fáciles.

Cuando creo mi interfaz de usuario y el flujo de la aplicación en código, tengo mucho más control de lo que está sucediendo, es más fácil de depurar, es más fácil detectar errores desde el principio, es más fácil explicar mis cambios a otros desarrolladores y es más fácil de admitir iPhone y iPad.

Sin embargo, estoy de acuerdo en que diseñar toda tu interfaz de usuario en el código podría no ser una solución única para todos los proyectos. Si la interfaz de usuario de su iPad difiere mucho de la interfaz de usuario de su iPhone en ciertos lugares, podría tener sentido crear un XIB solo para esas áreas.

Apple podría solucionar muchos de los problemas descritos anteriormente y espero que eso sea lo que hagan.

Solo mis dos centavos.

Actualizar: En Xcode 5, Apple eliminó la opción de crear un proyecto sin Storyboard. Escribí un pequeño script que transfiere las plantillas de Xcode 4 (con la opción de exclusión voluntaria de Storyboard) a Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

He usado XIB extensamente y completé dos proyectos usando Storyboards. Mis aprendizajes son:

• Los guiones gráficos son buenos para aplicaciones con un número pequeño o mediano de pantallas y una navegación relativamente sencilla entre vistas.
• Si tiene muchas vistas y mucha navegación cruzada entre ellas, la vista Storyboard se vuelve confusa y requiere demasiado trabajo para mantenerla limpia.
• Para un proyecto grande con varios desarrolladores, no usaría Storyboards porque tiene un solo archivo para su interfaz de usuario y no puede trabajar fácilmente en paralelo.
• Podría valer la pena que las aplicaciones grandes se dividan en varios archivos de guión gráfico, pero no lo he intentado. Esta respuesta muestra cómo hacer segues entre guiones gráficos.
• Todavía necesita XIB: en mis dos proyectos de Storyboard tuve que usar XIB para celdas de tabla personalizadas.

Creo que los guiones gráficos son un paso en la dirección correcta para la implementación de la interfaz de usuario y espero que Apple los extienda en futuras versiones de iOS. Sin embargo, necesitan resolver el problema del “archivo único”; de lo contrario, no serán atractivos para proyectos más grandes.

Si inicio una aplicación de tamaño pequeño y puedo permitirme la compatibilidad solo con iOS5, usaría Storyboards. Para todos los demás casos, me quedo con XIB.

Los guiones gráficos se crearon para ayudar a los desarrolladores a visualizar su aplicación y el flujo de la aplicación. Es muy parecido a tener un montón de xib pero en un solo archivo.

Hay una pregunta similar a esta ubicada ¿Cuál es la diferencia entre un archivo .xib y un .storyboard ?.

También puede crear transiciones personalizadas a través de código que cambiará dinámicamente si es necesario, al igual que puede hacerlo con .xibs.

PROS:

• Puede simular el flujo de una aplicación sin escribir mucho código, si es que lo hay.
• Es mucho más fácil ver sus transiciones entre pantallas y el flujo de su aplicación.
• También puede usar .xibs si es necesario con guiones gráficos.

CONTRAS:

• Solo funciona con iOS 5+. No funciona con iOS4.
• Puede abarrotarse fácilmente si tiene una aplicación con mucha visualización.

Realmente no hay un correcto / incorrecto cuándo usar uno u otro, es solo una cuestión de preferencia y qué versiones de iOS desea usar.

Comentarios y valoraciones

Si posees alguna suspicacia y disposición de acrecentar nuestro sección eres capaz de añadir una glosa y con placer lo observaremos.

---

---

Utiliza Nuestro Buscador