Storyboards vs hacerlo en código

Estoy trabajando en una empresa en la que tenemos varios desarrolladores de iOS y usamos GIT para trabajar juntos en los mismos proyectos. Nunca utilizamos storyboards o files .xib en nuestro process de desarrollo, ya que es casi imposible combinarlos correctamente.

Con la introducción del iOS7, pensé en las diferencias fundamentales entre Storyboards y codificando toda la interfaz de usuario "a la antigua usanza", sin el uso de Interface Builder.

¿Hay alguien aquí que haga eso? Y lo más importante, ¿hay algo que puedas hacer en Storyboards que no puedas hacer en el código en XCode 5?

Voy a dividir su pregunta en dos: NIB y storyboards.

En lo que respecta a los NIB, los problemas de control de fuente pueden ser dolorosos pero manejables, principalmente porque normalmente obtienes un file NIB por controller de vista. Podría imaginar una situación en la que tiene dos desarrolladores trabajando en dos secciones diferentes de su aplicación con alimentación NIB sin problemas de fusión. Los guiones charts son diferentes, ya que tiene un solo file que describe la mayoría, si no la totalidad, de la interfaz de usuario de su aplicación. Es evidente que hay un potencial mucho mayor para los problemas de conflicto allí.

Los NIB pueden ser extremadamente útiles y ahorrar time, si se usan correctamente. Aquí hay un ejemplo: la aplicación iPhoto en iPad tiene una interfaz de usuario muy compleja. La gran mayoría de esa interfaz está progtwigda. Sin embargo , la aplicación también utiliza NIB para cargar elementos charts que luego se presentan en el código. Así funciona el panel de pinceles: todos los pinceles se crean en una NIB. Esto significa que Apple no tiene que tener docenas de imágenes / imágenes idénticas asignar / init piezas de código. Toda la creación puede suceder en un NIB (esto fue discutido con cierto detalle en una session de WWDC 2012 en la interfaz de usuario de iPhoto; merece la pena rastrearlo).

Por lo tanto, los NIB, a veces buenos, pueden ahorrarle mucho time y, aunque existen problemas de fusión, en muchos casos pueden manejarse y manejarse fácilmente.

Luego llegamos a los storyboards. Los storyboards son interesantes. Por un lado, son extremadamente útiles y útiles para las aplicaciones sencillas y los desarrolladores nuevos en la plataforma. Acabo de convertir una aplicación basada en UINavigationController de NIB a storyboards y he encontrado algunos ahorros significativos en el time (particularmente en torno a las vistas de tabla, ya que con storyboards puedes aprovechar celdas prototipo).

Sin embargo, si está trabajando en un proyecto a gran escala con varios desarrolladores, no estoy convencido de que los storyboards sean tan beneficiosos. Existen, como tú dices, grandes problemas con los conflictos de mezcla, ya diferencia de los NIB, no es fácil resolverlos ya que ese único file de storyboard controla toda la interfaz de usuario de la aplicación.

Esto es lo que sugeriría (¡y siéntase libre de ignorarme!): Si actualmente está desarrollando aplicaciones y haciendo su layout / interfaz de usuario por completo en código, considere si los NIB pueden ahorrarle time. Puede que no, no son para todos, pero al less vale la pena considerarlos. Puede que se sorprenda de cuántas aplicaciones grandes realmente usan NIB (iPhoto, como mencioné, pero también muchas aplicaciones integradas proporcionadas por Apple, así como muchas aplicaciones populares de terceros por equipos grandes). Probablemente no consideraría storyboards a less que fueras un único desarrollador trabajando en una aplicación con navigation bastante sencilla. Eso no significa hacer abajo los storyboards de ninguna manera, me encanta usarlos, simplemente no son adecuados para la queueboración.

Alguien envió este comentario en respuesta a su pregunta. Quería discutirlo:

No hay nada que puedas hacer en el guión gráfico y no puedes hacer en el código. Los objects, reconocedores de gestos, segues, incluso restricciones, están disponibles para que usted compile mediante progtwigción

Esto es técnicamente cierto, pero en realidad hay cosas en los storyboards / NIB que son mucho más fáciles que el código. Un buen ejemplo de esto es el layout automático. Si bien es cierto que puede manejar su layout automático en su código completamente, la dura realidad es que la representación automática de layout ASCII es mucho más difícil de usar que la representación visual que obtiene en IB. Esto es especialmente cierto en XCode 5, donde hay mejoras masivas en el layout automático en IB (no puedo detallarlo demasiado, ya que todavía está bajo NDA, pero Apple habla públicamente un poco sobre los cambios aquí ).

Para mí, el único gran inconveniente de los guiones charts es el lento time de carga y el rezago habitual que se produce al navegar por el guión gráfico. No estoy hablando de 2-5 ver aplicaciones de controlleres. Estoy hablando de 10 y más …

Mis preferences personales son los storyboards más pequeños si realmente tengo que usarlos (células prototipo UITableView) o simplemente xibs.

Hacerlo en un código simple es solo cuestión de … ¿tienes suficiente time en tus manos? 🙂 Por lo general, no ganas mucho de hacerlo de esta manera.

Debe considerar estos problemas en su elección:

Tiempo de desarrollo –

Obviamente, trabajar con el diseñador de UI xcode es mucho más rápido y fácil de aprender cuando se crean nuevas aplicaciones desde cero. De forma programática, deberá definir en código todas y cada una de las properties del elemento que desee establecer. Trabajar con storyboard hará que el process de desarrollo sea mucho más rápido.

Reutilización del código

Cuando trabaje con storyboard, deberá vincular los elementos de la interfaz de usuario al controller con viñetas que agreguen código oculto adicional en el file del guión gráfico. Los mismos talones se agregan al crear segues entre el controller. Este código oculto adicional hará que sea más difícil reutilizar los controlleres en otras aplicaciones que buildás. Si planea hacer una reutilización masiva de su código de control, será más conveniente crear los elementos de la interfaz de usuario mediante progtwigción.

Integración del código fuente:

La resolución de conflictos es algo común cuando varios desarrolladores confirman cambios en el file. La creación y el cambio de elementos de interfaz de usuario con storyboard se agregan cambios adicionales al file de storyboard que a veces hace que los conflictos resuelvan un poco complicado. Por otro lado, cuando cambie los elementos de la interfaz de progtwigción de forma programática, solo los cambios que realice se agregarán al file del controller.