¿Qué es mejor para las aplicaciones de iOS: guiones gráficos o desarrollo programático?

Guiones gráficos

No hay inconvenientes en el uso de Storyboards. Puede trabajar muy rápidamente y desarrollar una aplicación completa en aproximadamente un día.

Si necesita agregar un elemento, o hacer un cambio, es rápido hacerlo en la GUI.
Incluso puede crear pantallas y botones que funcionen, sin ningún código.

Si luego desea agregar algo de personalización a esos elementos, puede hacerlo mediante programación.

Construir una aplicación 100% programáticamente parece hacer las cosas de la manera difícil por el simple hecho de hacerlo.

En un proyecto reciente, el cliente quería un comportamiento de segmentación no estándar.
Usé guiones gráficos para diseñar la aplicación, usando segues estándar. Y cuando eso funcionaba, volví y los cambié programáticamente.

Editar:
Eric Harmon
ha señalado un inconveniente. El guión gráfico es un solo archivo. Lo que significa que en un entorno de equipo, es imposible para múltiples desarrolladores editar el contenido del guión gráfico simultáneamente.

Este es un problema legítimo. Una solución alternativa es convertir a un individuo en el jefe del guión gráfico. Pero eso no encajaría en todas las organizaciones.

En situaciones con equipos grandes y jerarquías de interfaz de usuario muy complejas, hay un caso para dividir la interfaz de usuario en NIB individuales o construir más contenido mediante programación.

Si bien el uso de guiones gráficos reduce la cantidad de codificación que hacemos, también plantea algunos desafíos al usar herramientas de control de versiones como GitHub, SVN, etc. Xcode considera el guión gráfico como un solo archivo, aunque hay múltiples controladores de vista presentes en él. Entonces, cuando varios desarrolladores trabajan en el mismo archivo de guión gráfico, habrá muchos conflictos de fusión que son difíciles de entender … Dado que el guión gráfico suele ser un archivo xml, resolver los conflictos se convierte en una tarea agitada. Este es el principal inconveniente de usar guiones gráficos (al menos para mí).
Sin embargo, si usted es un desarrollador individual, los guiones gráficos le harán la vida mucho más fácil …

Aparte de esto, hay un gran inconveniente para los guiones gráficos … Los guiones gráficos pueden ser muy útiles para aplicaciones más pequeñas con menos de 15 pantallas (aprox.) Pero se vuelve realmente difícil administrar más pantallas (30 + ??). Se vuelve realmente confuso cuando ves todas las pantallas.

depende de usted decidir … Feliz codificación … 🙂

Storyboard con menos cantidad de pantallas:

Storyboard con más cantidad de pantallas:

Yo diría que no hay una bala de plata. Cada uno de los enfoques tiene sus propios pros y contras.

Pros de Storyboards :

• Puede ayudar con la creación de prototipos
• Podría ser más rápido usar Storyboard que escribir código

Contras del guión gráfico :

• Poca reutilización
• La fusión de conflictos puede convertirse en dolor si varios desarrolladores están trabajando en el mismo guión gráfico
• Puede llevar mucho tiempo cargar enormes storyboards en Interface Builder

Código personalizado pros :

• A veces es solo la única opción
• Conflictos fáciles de fusionar
• Actuación
• Reusabilidad

Contras de código personalizado:

• Si recibe un nuevo proyecto donde toda la interfaz de usuario está hecha en código, se necesita mucho más tiempo para comprender cómo funcionan las cosas
• Es posible cometer un error en la arquitectura, especialmente cuando un proyecto evoluciona y se agregan características adicionales. Por lo tanto, podría ser necesaria una refactorización futura.

Podría parecer que el código personalizado tiene más ventajas, pero en la vida real, tener todos los valores entre pantallas es demasiado útil para ignorarlo. Sugeriría aprender ambos enfoques y usar guiones gráficos para la mayoría de las tareas y escribir código personalizado para diseños dinámicos o cualquier otra tarea cuando no se sienta cómodo con los guiones gráficos.

Storyboard? :

• Para los menos inclinados técnicamente, los Storyboards pueden ser una excelente manera de contribuir al proyecto directamente, por ejemplo, ajustando los colores o las restricciones de diseño. Sin embargo, esto requiere una configuración de proyecto que funcione y algo de tiempo para aprender los conceptos básicos.
• La iteración es a menudo más rápida ya que puede obtener una vista previa de ciertos cambios sin construir el proyecto.
• Las fuentes personalizadas y los elementos de la interfaz de usuario se representan visualmente en Storyboards, lo que le da una idea mucho mejor de la apariencia final durante el diseño.
• Para las clases de tamaño, Interface Builder le ofrece una vista previa de diseño en vivo para los dispositivos que elija, incluida la multitarea de pantalla dividida de iPad.

¿Código? :

• Los guiones gráficos son más propensos a conflictos de versión debido a su compleja estructura XML. Esto hace que la fusión sea mucho más difícil que con el código.
• Es más fácil estructurar y reutilizar vistas en el código, manteniendo así su base de código seca.
• Toda la información está en un solo lugar. En Interface Builder, debe hacer clic en todos los inspectores para encontrar lo que está buscando.
• Los guiones gráficos introducen el acoplamiento entre su código y la interfaz de usuario, lo que puede provocar bloqueos, por ejemplo, cuando una salida o acción no está configurada correctamente. Estos problemas no son detectados por el compilador.

Use ambos:

Para sacar el máximo provecho, prefiero usar ambos. Use el guión gráfico cuando haya diseños de arreglos. Use el código cuando necesite diseños dinámicos.

Elige sabiamente 🙂

Storyboards + Stackview es mucho mejor que las restricciones creadas mediante programación.

Los guiones gráficos sin stackview probablemente no valen la pena.

De hecho, me sorprende que nadie haya mencionado esto. ¡Es una tangente importante!

Desde iOS9, donde Apple introdujo stackviews, la idea de usar guiones gráficos ha comenzado a cobrar impulso. ¿Por qué? Porque con las vistas de pila simplemente arrastra y suelta Y ya no necesita bailar con restricciones, sino que simplemente configura su diseño adaptativo con las propiedades de alignment y distribution de la vista de pila. Si tiene experiencia en diseño web, las vistas de pila son muy similares a las de flexbox. Le ahorra toda la molestia de alineación / div / margen.

Recomiendo encarecidamente a todos que vean el video de wwdc “Misterios del diseño automático, Parte 1”. Salta a 3:47.

Realmente muestra cuán simple es construir pilas de vistas complejas. Todavía es factible mediante programación, pero con los guiones gráficos se ven resultados inmediatos de distribuciones complejas con mucho menos tipeo. Hacer lo mismo en guiones gráficos con restricciones toma aproximadamente 5 veces más veces que con las vistas de pila

Un tutorial avanzado es: https://www.raizlabs.com/dev/201 …

Otra cosa que siento que muchos desarrolladores novatos no conocen y si hubieran sabido que harían un código menos complejo es conocer los casos de uso y las diferencias entre:

• readableContentGuide
• safeAreaLayoutGuide
• LayoutMarginsGuide
• Anclas

Una vez que domine estos, su uso de restricciones se vuelve muy limitado. Puede encontrar un buen ejemplo de sus diferencias en esta respuesta SO: en iOS, ¿cuáles son las diferencias entre márgenes, inserciones de borde, inserciones de contenido, rectificaciones de alineación, márgenes de diseño, anclajes …?

La naturaleza (simple) de las vistas de pila lo hace menos frágil en las actualizaciones de Swift / iOS y es fácilmente compatible y seguro para actualizaciones y migraciones. Las restricciones / marcos son un poco más extravagantes en ese sentido.

Lo que recomiendo a los desarrolladores novatos es hacer un poco de ambos, ya que ambos son útiles para el aprendizaje. Como el guión gráfico esconde muchos detalles buenos para saber y lastimaría a un desarrollador no saber sobre ellos, más tarde, una vez que esté trabajando en un equipo, el equipo le impondrá esa decisión.

Depende del desarrollador o enfoque de desarrollo.

No soy un gran admirador de los guiones gráficos o los archivos de plumín, ya que he descubierto que son contraproducentes (para mí) y prefiero tener un control granular sobre mi interfaz de usuario; Además, si va a escribir una subclase para modificar el diseño / elementos de un guión gráfico, etc., también podría hacer un esfuerzo adicional y hacerlo todo.

No he comparado ni investigado, pero supongo que no hay mejoras masivas en la representación por código versus guión gráfico, ya que el código está compilado (incluidos los guiones gráficos, que de todos modos son representaciones gráficas de código).

El enfoque programático … ¿por qué? Principalmente para la escalabilidad, el uso de guiones gráficos puede generar conflictos de fusión si hay dos o más desarrolladores trabajando en él. Eso es todo. Personalmente, no veo otra gran ventaja más que eso.

Existen algunos desafíos al usar el enfoque programático, necesitará saber cómo usar NSLayoutConstraints, VFL … pero una vez que los conozca, es bastante simple. No podrá obtener una vista previa en el generador de interfaces, por lo que necesitará saber cómo usar las restricciones, en el dorso de su mano.

Yo diría que use XIB. Habrá conflictos de fusión, pero no tanto como los guiones gráficos, ya que puede dividir los controladores de vista entre sus desarrolladores y cada desarrollador puede trabajar en XIB individuales.

Si yo fuera tú, iría por los XIB.

Los guiones gráficos simplemente se burlan, crean prototipos y fluyen, pero el verdadero desafío es el flujo de datos. Storyboard no puede manejar los flujos de datos muy bien, debe usar prepareForSegue para pasar datos.

  if ([identificador [correo electrónico protegido] "segue_name_1"]) {
         MyViewController * vc = (MyViewController *) [segue destinationViewController];
         [vc setData: myData];
     } else if ([identificador [correo electrónico protegido] "segue_name_2"]) {
         ...
     } más si ...

Esto es muy innecesario y detallado.

Prefiero programático porque es un poco más simple, especialmente cuando trabajas con dos o más desarrolladores. Como desarrollador único, realmente no importa. Pero si está trabajando en una startup o en varios equipos, los guiones gráficos no funcionarán muy bien. La respuesta a esta pregunta depende del desarrollador. Si el desarrollador trabaja solo, los guiones gráficos pueden ser mejores. Pero si también están trabajando con otros desarrolladores, entonces programáticamente sería mejor. Pero prefiero trabajar también sin guiones gráficos, ya que hace que sea más fácil de entender si entiendes bien las API de Swift e iOS.

Como Glyn Williams ya mencionó este problema, recientemente rara vez uso storyboard porque es un archivo gigante que mantiene todas las vistas y cuando tenemos muchas de ellas, lleva mucho tiempo cargar y compilar, por lo que generalmente uso archivos XIB. Todavía utilizamos la GUI para crear vistas, por lo que no se realiza mediante programación.

Storyboard también tiene un problema de reutilización. Por ejemplo, si tengo una celda de vista de tabla que se usa en diferentes controladores de vista, debería copiarla en ambos, pero creo un solo archivo XIB para la celda, puedo reutilizarlo en todas partes.

Además de eso, cuando trabajamos en un equipo, a menudo tenemos que fusionar conflictos con git o los desarrolladores editan el guión gráfico.

No hagas todo programáticamente.
Si tienes más pantallas, crea múltiples guiones gráficos.
Si tiene una historia con muchas pantallas, llevaría tiempo cargar el guión gráfico y el desarrollo se vuelve realmente lento en mac de baja configuración.

Storyboards. Toda la razón por la que existen es porque hacen que el desarrollo sea más fácil y rápido.

Yo mismo estaré en desacuerdo con quien haya dicho que habrá problemas importantes. Hasta ahora no tenemos ninguno usando guiones gráficos durante varios años.