¿Cuáles son los beneficios de usar Storyboards en lugar de archivos xib en la progtwigción de iOS?

¿Cuáles son las principales diferencias entre usar Storyboards y archivos xib?

Específicamente, ¿cuáles son las ventajas o desventajas de usar un Storyboard?

Desafortunadamente, a pesar de investigar un poco, todo lo que he podido encontrar en Storyboards son simples tutoriales que te muestran cómo configurar un Storyboard, en lugar de información concreta que explica qué son.

Un Storyboard es:

  • Un contenedor para todas sus escenas (controladores de vista, controladores de navegación, controladores TabBar, etc.)
  • Un administrador de conexiones y transiciones entre estas escenas (estos se llaman Segues)
  • Una buena forma de administrar cómo los diferentes controladores hablan entre sí
  • Los guiones gráficos le dan una visión completa del flujo de su aplicación que nunca puede obtener de los archivos individuales de punta flotantes.
  • Un reductor de todo el “desorden” que ocurre cuando tienes varios controladores, cada uno con su propio archivo de punta.

He estado usando Storyboards por un tiempo y el ÚNICO inconveniente es que no puedes apuntar a iOS 4 o inferior. Los guiones gráficos solo funcionan en dispositivos con iOS 5 o superior. Aparte de eso, los beneficios son muchos y las desventajas son IMO inexistente.

El mejor tutorial que he visto es el de Ray Wenderlich

Además, si eres miembro del progtwig Apple Developer, echa un vistazo a la sesión WWDC del año pasado en Storyboards (iTunesU), es increíble.

Otra excelente (también en iTunesU) es el último curso de Progtwigción de Aplicaciones de Stanford para iOS.

No solo hay lados pro de Storyboarding, sino también porque solicitaste tu opinión:

  • no es fácil trabajar con SB en un equipo, ya que solo un participante puede trabajar en el SB de una vez (porque es un archivo).

-Lo siguiente no es cierto: si necesita hacer cosas que SB no ofrece, no es muy fácil mezclar SB con vistas creadas programáticas (bueno, es posible)

La regla de oro parece ser: cuanto más complejo esperas que sea tu proyecto, más te vale no ir por SB.

EDIT: – otra desventaja de SB: trabajar con todos los errores molestos de XCode con respecto a SB. Por ejemplo, tener que lavar frecuentemente la carpeta DerivedData debido a varias incoherencias. A veces, los archivos del guión gráfico o el enlace se corrompen. Entonces puedes tener la alegría de buscar el problema. Echa un vistazo a este hilo para entender la idea

EDIT 2 (marzo de 2013): mientras tanto Storyboards y Xcode funcionan mucho mejor, y la documentación y las mejores prácticas están muy extendidas. Creo que se puede recomendar trabajar con guiones gráficos para la mayoría de los proyectos, incluso si todavía hay fallas.

EDIT 3 (septiembre de 2013): ahora con el nuevo formato Xcode 5, trabajar en equipos con SB podría ser aún mejor, ya que parece ser posible fusionar el código SB mucho más fácilmente ahora.

Otro EDIT: bueno, si tienes una hora de tiempo, siéntate, relájate y escucha a estos tipos discutiendo este tema (Ray Wenderlich & Co)

Editar 2016.1: después de mucho tiempo como defensor del guión gráfico, tuve tantos problemas en los últimos meses que decidí abandonar Storyboards en la medida de lo posible. La razón de esto es que Apple agrega características como estúpidas, pero no se preocupa por los errores y fallas. El rendimiento que tiene muchas restricciones de diseño automático es realmente malo (mientras que el tiempo de diseño) y la propensión a los errores se ha vuelto enorme. Ejemplo: Storyboards incluso menos complejos tienden a entrar en un ‘modo sucio’ justo después de abrir un proyecto en Xcode (ver estado de git). Consejo: como principiante, te encantará Storyboards, ya que puedes crear prototipos rápidamente y hacer que las cosas funcionen sin mucho código. Al ingresar un estado intermedio, agregará más código GUI a su proyecto. Ahora empiezas a ir y venir entre el código y SB, y las cosas empiezan a empeorar. Tarde o temprano tenderás a hacer la mayoría de las cosas de la GUI en el código, porque el resultado es más predecible que tener varias fonts.

Resumen

Los archivos Nibs / .xib y Storyboards son archivos de Interface Builder que se utilizan para crear visualmente la interfaz de usuario para las aplicaciones iOS y Mac en Xcode (usaré la terminología iOS para las clases ya que esta pregunta está etiquetada como iOS pero también se aplica a la progtwigción de Mac) .

Diferencias

Los nibs están destinados a ser utilizados con un solo UIView . También se pueden conectar a una subclase UIViewController configurando la clase de Propietario de archivo en cualquier subclase de UIViewController y conectando la salida de visualización (arrastre para conectarse usando Connections Inspector en el panel derecho de Xcode).

Los UIViewController están destinados a contener la interfaz de usuario para 1 o más UIViewController . Puede construir su interfaz de usuario completa en un solo guión gráfico o separarlo en partes más pequeñas.

Ventajas

Los guiones gráficos siempre se deben usar a favor de archivos .xib / Nibs (para controladores de vista). Los guiones gráficos tienen más características y están desarrollados activamente por Apple.

Todos los argumentos a favor de Nibs se basan en el hecho de que se usaron individualmente, mientras que los guiones gráficos contienen muchas escenas. Puede usar un solo guión gráfico para cada UIViewController con la mayor facilidad posible con Nibs (consulte ejemplos de códigos a continuación). Sigue leyendo para obtener una explicación detallada y ejemplos de código.

Detallado

¿Por qué son Storboards superiores a Nibs?

La respuesta básicamente se reduce a que Apple alienta el uso de Guiones gráficos y pone más esfuerzo de desarrollo en ellos.

  1. Los guiones gráficos tienen una función de zoom que carece de Nibs. En serio, no se puede hacer zoom en Nibs, lo que apesta cuando se diseñan pantallas más grandes en una laptop pequeña.
  2. Nibs faltan funcionalidades clave como:
    • Celdas prototipo y dinámicas para UITableView ( más información )
    • La propiedad de la guía de diseño superior (ver comentario)
    • Probablemente haya más, edite o comente si tiene algo que agregar a esta lista
  3. No necesita meterse con la configuración de la clase de Propietario de archivos.

El argumento básico contra los guiones gráficos es que tener todos los controladores de vista en un lugar conduce a conflictos de fusión, un Xcode lento, tiempos de construcción lentos y un dolor general en el trasero para mantener. Por lo tanto, el consejo general es usar un Nib para cada UIViewController .

Pero … Puedes crear un guión gráfico para cada UIViewController . Una práctica común (al menos para mí) es ocultar toda la inicialización de UIViewController en un método de clase (ya que ninguna otra clase necesita saber el nombre del archivo donde se encuentra el Nib / Storyboard del controlador). Comparemos los fragmentos de código relacionados que uno podría usar para crear dicho método. Una sola línea de código es la diferencia completa entre los dos.

C objective

Storyboard

 + (ViewController *)create { UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil]; return [storyboard instantiateInitialViewController]; } 

Punta

 + (ViewController *)create { return [super initWithNibName:@"ViewController" bundle:nil]; } 

Uso

 - (void)showMyViewController { ViewController *vc = [ViewController create]; [self presentViewController:vc animated:YES completion:nil]; } 

Rápido

Storyboard

 static func create() -> ViewController { let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle()) return storyboard.instantiateInitialViewController() as! ViewController } 

Punta

 static func create() -> ViewController { return ViewController(nibName: "ViewController", bundle: nil) } 

Uso

 func showMyViewController() { let vc = ViewController.create() self.presentViewController(vc, animated: true, completion: nil) } 

Argumentos

Voy a abordar todos los argumentos habituales para Nibs; como mencioné anteriormente, hay mayoritariamente a favor de archivos individuales, no como argumento para Nibs sobre Storyboards

  1. Equipos y fusión

Argumento: Tener un guión gráfico con muchos controles de vista causará conflictos de fusión si está trabajando en un equipo con varias personas haciendo cambios.

Respuesta: Un solo guión gráfico no causa más conflictos de fusión que un solo plumín

  1. Complejidad

Argumento: las aplicaciones muy complejas tienen muchas escenas en el guión gráfico que conducen a un guión gráfico gigante que tarda una eternidad en cargar y apenas es comprensible debido a su tamaño.

Respuesta: Este es un gran punto, pero puede dividir fácilmente Storyboards en partes más pequeñas. Las referencias a guiones gráficos parecen una excelente función que se puede usar para vincular Storyboards juntos, pero solo están disponibles en Xcode 7 / iOS 9+. Además, todavía no es una razón para elegir Nibs individuales en Storyboards.

  1. Reutilizabilidad

Argumento: la creación de un Nib para cada subclase UIViewController permite reutilizar el código para que no tenga que configurar todas sus restricciones y salidas para cada escena en su guión gráfico.

Respuesta: Nuevamente, no es una razón para elegir Nibs individuales en Storyboards individuales.

Hubo una buena presentación sobre Storyboard en la reunión de LiDG hace un par de meses.

Personalmente, diría que es la manera de ir con una nueva aplicación. Hay algunas lagunas, especialmente para aplicaciones muy complejas, pero el profesional es mayor que las desventajas.

Algunos más beneficios de los guiones gráficos:

  • Los guiones gráficos tienen un mejor soporte para las vistas de tabla. Es decir que puede usar celdas “dinámicas” y “prototipo”.
  • Es más fácil crear instancias de los controladores de vista usando storyboards. Puede hacer cosas como: [se lf.storyboard instantiateViewControllerWithIdentifer:]
  • Los guiones gráficos son compatibles con los contenedores del controlador de vista, por lo que puede tener los controles de vista secundarios expuestos gráficamente.

Los inconvenientes son:

  • Los guiones gráficos se procesan con lentitud en XCode cuando contienen muchos controladores de visualización

  • Autolayout no se puede habilitar para un controlador de vista en el guión gráfico.

Tenga cuidado, si utiliza Storyboards su aplicación no es compatible con versiones anteriores de las instalaciones del sistema operativo más antiguas.

Un guión gráfico es básicamente un dispositivo para facilitar su trabajo como desarrollador. Se cumple en una serie de archivos semilla, por lo que el rendimiento es bastante equivalente, pero es genial como desarrollador poder ver una descripción general rápida de todo el flujo de la aplicación.

Estoy empezando la transición al uso de guiones gráficos en nuevos proyectos, siempre que pueda convencer al cliente de que acepte iOS 5 como una versión mínima. Esto es puramente porque prefiero hacerlo de esta manera, y me lleva menos tiempo realizar las mismas tareas.

Su actitud hacia el diseño automático también puede afectar si desea usar Storyboards. El uso de xibs puede habilitar o deshabilitar el diseño automático por .xib, lo que permite una mezcla dentro de su aplicación, mientras que Storyboards aplica su elección a TODAS las vistas que contienen.

Ves el outlook general en un segundo. Tener muchos archivos NIB, bueno, no se ve el outlook completo. Más fácil de mantener sus progtwigs. Más fácil de entender otros progtwigs … entre otros.

Ventajas:

1) Es muy bueno para diseñar interfaces

2) Puede usar Segmentos de Storyboard para identificar las relaciones de navegación / moda de manera genial.

3) Si su aplicación es compatible con varios dispositivos, es una buena forma de organizar diferentes vistas.

4) Prototipos es otra ventaja añadida.

5) Prototipo UITableViewCell puede ahorrar tiempo y también reduce la cantidad del código.

6) puedes ver todas las pantallas de la aplicación en un solo lugar usando StoryBoard.

7) Puedes ver fácilmente la relación entre ellos

8) si está trabajando con el código de alguien, puede obtener una mejor comprensión del flujo de la aplicación.

9) Puede configurar la interfaz de usuario para iPhone 4 y iPhone 5 aplicando el factor de forma Retina del guión gráfico, sin ejecutar la aplicación una y otra vez.

10) Los clientes pueden ver el prototipo de la aplicación antes de comenzar a desarrollarla, aquí el guión gráfico te ayuda mucho.

Desventajas:

1) Solo está disponible en iOS 5+

2) StoryBoardSegues son un poco rígidos y puedes utilizar preparació para varias veces.

4) Al igual que IB, no es muy amigable con otros motores de pantalla y juegos de herramientas.

4) Hace que sea difícil compartir diseños para una sola vista o conjunto de vistas: debe enviar todo o nada.

5) Para el guión gráfico necesitarás una pantalla grande especialmente en el caso de iPad.

6) Dificultad al copiar vistas desde otras aplicaciones al guión gráfico.

7) Problemas en el guión gráfico cuando varios desarrolladores trabajan en el mismo proyecto usando el repository de git

copiado de algún recurso

Los guiones gráficos tienen muchos más problemas que beneficios. Aquí hay una lista de sus problemas, copiados de iraycd :

  • Los guiones gráficos fallan en tiempo de ejecución, no en tiempo de comstackción : ¿tiene un error tipográfico en un nombre de transición o lo conectó mal en su guión gráfico? Estallará en el tiempo de ejecución. ¿Usas una subclase UIViewController personalizada que ya no existe en tu guión gráfico? Estallará en el tiempo de ejecución. Si hace tales cosas en el código, las detectará desde el principio, durante el tiempo de comstackción. Actualización : 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 los controladores de múltiples vistas tienen múltiples segues para varios otros controladores de vista, su guión gráfico comienza a parecerse rápidamente a un plato de espagueti 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 descubrir qué puntos segue dónde. Actualización : Este problema se puede resolver principalmente dividiendo su Guión gráfico en varios Guiones gráficos , como se describe en este artículo de Pilky y en este artículo de Robert Brown .

  • Los guiones gráficos hacen que trabajar en equipo sea más difícil : como generalmente solo tienes un gran archivo de guión gráfico para tu proyecto, tener varios desarrolladores haciendo cambios regularmente en ese archivo puede ser un dolor de cabeza: los cambios deben fusionarse y los conflictos deben resolverse. Cuando se produce un conflicto, es difícil decir cómo resolverlo: Xcode genera el archivo XML del guión gráfico y no fue diseñado con el objective en mente de que un humano tenga que leer, y mucho menos editarlo.

  • Los guiones gráficos hacen que las revisiones de los códigos sean difíciles o casi imposibles : las revisiones de los códigos de pares son una excelente opción para 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 enorme archivo XML. 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 con iOS, suelo crear una clase que contenga todos los colores, fonts, márgenes e inserciones que uso en toda la aplicación para darle un aspecto coherente: es un cambio de una sola línea si tengo que ajustar cualquiera de esos valores para toda la aplicación. Si establece dichos valores en el guión gráfico, los duplica y tendrá que buscar cada aparición cuando quiera cambiarlos. Hay muchas posibilidades de que pierda uno, porque no hay búsqueda y reemplazo en los guiones gráficos.

  • Los guiones gráficos hacen que hagas todo dos veces : ¿estás creando una aplicación universal que se ejecute tanto en iPad como en iPhone? Cuando utiliza storyboards, generalmente tendrá un guión gráfico para la versión de iPad y otro para la versión de iPhone. Mantener ambos sincronizados requiere que hagas todos los cambios en la interfaz de usuario o en el flujo de trabajo de la aplicación en dos lugares. Hurra. Actualización : en iOS 8 y Xcode 6, puede usar un Storyboard único para iPhone y iPad.

  • Los guiones gráficos requieren interruptores de contexto constantes : me encuentro trabajando y navegando mucho más rápido en el código que en los guiones gráficos. Cuando su aplicación usa guiones gráficos, cambia constantemente su contexto: “Oh, quiero un toque en 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 un nuevo segue al otro controlador de vista (que también tengo que encontrar), déle un nombre a la transición, recuerde ese nombre (no puedo usar constantes o variables en los guiones gráficos), vuelva al código y espero no escribir mal el nombre de que segue para mi método prepareForSegue. ¡Cómo me gustaría poder escribir esas 3 líneas de código justo donde estoy! No, no es divertido. Alternar entre el código y el guión gráfico (y entre el teclado y el mouse) envejece rápidamente y te ralentiza.

  • Los guiones gráficos son difíciles de refactorizar : cuando refactorices tu código, debes asegurarte de que siga coincidiendo con lo que espera tu guión gráfico. Cuando mueve las cosas en su guión gráfico, solo lo descubrirá en tiempo de ejecución si todavía funciona con su código. Me siento como si tuviera que mantener dos mundos sincronizados. Se siente quebradizo y desalienta el cambio en mi humilde opinión.

  • Los guiones gráficos no se pueden buscar : una búsqueda en todo el proyecto en Xcode no es realmente una búsqueda de todo el proyecto cuando se utilizan guiones gráficos. No están incluidos en la búsqueda. Por lo tanto, cuando elimine una clase personalizada de su código o la cambie de nombre, tendrá que pasar manualmente por el guión gráfico o mirar su XML sin procesar para asegurarse de que esté a la par con los cambios en su código. No señor, no me gusta. Actualización : los guiones gráficos se pueden buscar en Xcode 6.

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

  • Los UITableViewController UICollectionViewController no le permiten cambiar el tipo de controles de vista especiales : ¿Desea cambiar un UITableViewController en un UICollectionViewController ? ¿O en un UIViewController simple? No es posible en un Storyboard. Tienes que eliminar el viejo controlador de vista y crear uno nuevo y volver a conectar todos los segmentos. Es mucho más fácil hacer un cambio de código.

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

  • Los UIImageView no le permiten agregar una subvista a UIImageView : quién sabe por qué.

  • Los guiones gráficos no le permiten habilitar el diseño automático para vista individual (-Controlador) s : Al marcar / desmarcar la opción Diseño automático en un guión gráfico, el cambio se aplica a TODOS los controladores en el guión gráfico. (¡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 del archivo Storyboard y no garantiza en modo alguno que pueda abrir archivos Storyboard que cree hoy dentro de unos años o incluso meses a partir de ahora. (Gracias a thoughtadvances para este punto. Vea el comentario original )

  • Es McDonald’s : decirlo en palabras de Steve Jobs sobre Microsoft: ¡es McDonald’s (video) !

Antes de iOS 7, Storyboards era algo ordenado pero no imprescindible. Introdujeron tantos problemas como resolvieron. iOS 7 inclinó la balanza hacia Storyboards.

Con iOS 8 y 9 ya no es una pregunta: ¡usa storyboards!

La desventaja principal del guión gráfico es que dependes por completo de XCode, y es posible que termines pasando horas haciendo girar tus ruedas en los errores de XCode. Pero XCode ha mejorado mucho, y las ventajas con Storyboards son ahora demasiado numerosas como para ignorarlas. Prototipos de células de vista de tabla, clases de tamaño, soporte de diseño automático, etc.

Algunos consejos:

  • Piensa en cada Guión gráfico como un contenedor para controladores de vista que pertenecen juntos. No lo piense como un gran diseño de su aplicación completa.
  • Es posible que necesite más de un guión gráfico
  • Los segmentos realmente solo son útiles para los casos de uso más triviales; son geniales para eso. Pero en una aplicación del mundo real, muchas transiciones ocurrirán dentro del código. Y eso está bien.
  • Escriba una categoría para crear instancias programáticas de los controladores de vista del guión gráfico, de modo que todo lo que tiene que hacer es dejar vc = SomeViewController.create (), donde el método maneja todos los detalles (extraiga el guión, retire el controlador de vista del guión, etc. )