ios5 standards xib uistoryboard

ios5 - ¿Cuál es la mejor práctica al usar UIStoryboards?



standards xib (2)

Encontré que este article mencionaba muchos problemas al usar StoryBoard, una cosa que el autor planteó es el uso de una gran cantidad de archivos de plumillas en un StoryBoard, que acordé que no debería hacer eso, pero hubo otros temas como:

Mi controlador de vista raíz se ha convertido en un controlador de vista de origen para muchos segmentos y, por lo tanto, su preparación para el evento: se ha convertido en un método estúpidamente grande con una gran cantidad de declaraciones "if (segue.identifier isEqualToString: @" ... ")” en una fila

y

Es posible asignar un identificador a los controladores de vista en un guión gráfico. Desafortunadamente, esta propiedad de identificador no está expuesta en la clase UIViewController. Esto hace que sea muy difícil realizar una introspección segura de la jerarquía del controlador de vista en tiempo de ejecución. Sería realmente bueno si el identificador estuviera expuesto para los controladores de vista, así como para los segmentos.

y ... más otros problemas, pensé que tiene sentido, y me preocupa si debo o no usar StoryBoard por ahora.

Habiendo usado los guiones gráficos por un tiempo, ahora los he encontrado extremadamente útiles, sin embargo, tienen algunas limitaciones o al menos formas poco naturales de hacer las cosas. Si bien parece que debe usarse un solo guión gráfico para su aplicación, cuando llega a incluso una aplicación de tamaño moderado, esto presenta varios problemas.

  1. Trabajar en equipo se hace más difícil ya que los conflictos en los Guiones gráficos pueden ser problemáticos de resolver (cualquier sugerencia con esto también sería bienvenida)
  2. El guión gráfico en sí puede volverse bastante desordenado e inmanejable.

Entonces mi pregunta es ¿cuáles son las mejores prácticas de uso?

He considerado utilizar un enfoque híbrido con tareas lógicas que se dividen en guiones gráficos separados, sin embargo, esto hace que el flujo de UX se divida entre el código y el guión gráfico. Para mí, esta es la mejor manera de crear acciones reutilizables, como acciones de inicio de sesión, etc.

¿También debería considerar un lugar para Xibs? Este artículo tiene una buena visión general de muchos de los problemas y propone que para las escenas que solo tienen una pantalla, se deben usar xibs en este caso. Una vez más, esto me parece inusual con el soporte de Apple para la creación de instancias de escenas desconectadas de un guión gráfico, lo que sugeriría que los xibs no tendrán un lugar en el futuro, pero podría estar equivocado.


Tienes razón, dividir los guiones gráficos es la mejor manera de hacerlo. La descomposición hace más que solo hacer que las partes de la interfaz de usuario sean más reutilizables. También hace que el uso de guiones gráficos en un equipo sea más manejable.

Últimamente, muchos de mis guiones gráficos han contenido cuatro o menos escenas. Es bastante fácil para una persona construir y mantener únicamente uno o más de dichos módulos de UI. Esta práctica reduce o elimina los conflictos de fusión.

En el caso de que necesite cambiar algo en un guión gráfico de otra persona, primero le pregunto al propietario si tiene algún cambio local. Si es así, a veces el propietario me agrega los cambios. La descomposición aún requiere algo de coordinación, pero es sustancialmente menos que un guión gráfico de aplicación completa. Desde que empecé esta práctica, no he tenido ninguna dificultad de fusión.

En cuanto a los XIB, creo que no escribí lo suficiente sobre ellos en mi artículo. Todavía son muy útiles. Pueden ser agradables para los controladores de vista única. Sin embargo, aquí no es donde realmente brillan. Los XIB tienen una ventaja que los guiones gráficos nunca pueden tener. La unidad más básica de un XIB es una UIView, mientras que la unidad básica de un guión gráfico es un UIViewController. Dado que los XIB pueden contener colecciones de UIViews, son excelentes para crear controles personalizados visualmente. En un XIB, puedo construir visualmente un dial giratorio o un widget de GPS. Luego puedo colocar estos controles y widgets en guiones gráficos u otros XIB. Estos XIB se ven más a menudo en las aplicaciones de iPad, ya que tienen pantallas más grandes capaces de albergar muchos controles y widgets. No sería natural construir un UISwitch dentro de un UIViewController en un guión gráfico.

Ahora las mejores noticias. Es posible conectar guiones gráficos dentro de Interface Builder y sin escribir ningún código. Estaba planeando lanzar esta técnica después de WWDC, ya que Apple podría lanzar una funcionalidad similar en iOS 6. Sin embargo, ya que me lo pediste, decidí lanzarla ahora. En lugar de duplicar mis explicaciones sobre cómo funciona RBStoryboardLink, puedes encontrar más detalles en mi blog y en GitHub . Esto hará que sus experiencias con UIStoryboard sean mucho más agradables.