¿Cuántos desarrolladores de iOS no usan NIB, Storyboards y Restricciones?

Si ha estado evitando NSConstraints para crear diseños, es hora de zambullirse. La gran mayoría de los programadores de iOS están utilizando AutoLayout.

Es cierto que las restricciones son contra intuitivas cuando las usa por primera vez. Verá advertencias, errores, bloqueos. Tomará algún tiempo entender qué está pasando. Sin embargo, AutoLayout es potente, flexible. Con la amplia variedad de relaciones de aspecto que necesitamos admitir, AutoLayout es una herramienta esencial en su caja de herramientas.

Si prefiere escribir la interfaz de usuario en el código, le recomiendo PureLayout disponible como CocoaPod. Sin embargo, hay mucho que recomendar Storyboards. La capacidad de ver rápidamente diseños en todos los formularios del dispositivo usando la función de vista previa de Storyboard es increíble. La misma característica le permite ver cómo fluirán las cadenas localizadas simuladas en UILabels. Puede ajustar rápidamente las restricciones para que se comporten de manera diferente en un iPad frente a un iPhone6. Cosas muy poderosas.

Desde una perspectiva de reutilización del código, los Storyboards sirven como una línea muy clara de separación entre el código y las capas de presentación. Lo que hace y cómo se ve está completamente compartimentado. Sin embargo, ¡los conflictos de git-merge son intolerables con Storyboards! La mejor práctica es usar múltiples guiones gráficos para actividades discretas (incorporación, registro, inicio de sesión, tablero) para minimizar el grupo que pisa a los demás a medida que se desarrollan.

Hasta ahora nunca he conocido a un desarrollador de iOS que construya su IU completamente mediante programación.

En los primeros días de iOS, antes del diseño automático, solía diseñar muchos elementos de la interfaz de usuario y manejar el posicionamiento a través del código, ya que me pareció más flexible. En la actualidad, también hay muchos tamaños de pantalla para satisfacer y hacer que sea beneficioso no usar, XIB, Storyboards y Restricciones.

Uno de los principales propósitos de los guiones gráficos y las restricciones era permitir la separación del diseño de la interfaz de usuario y la codificación de back-end. En equipos más grandes, un diseñador de UI debería poder ingresar al proyecto y realizar cambios visuales sin tener que entender el código que lo respalda. Imagen si estaba trabajando en una aplicación de 50 pantallas y el cliente decidió que una vista (por ejemplo, llamemos a esta vista una barra de navegación personalizada) que estaba actualmente en la parte superior de cada pantalla debería estar en la parte inferior.

Con los guiones gráficos, simplemente movería la vista hacia abajo, restablecería la restricción de los elementos superior e inferior y configuraría las nuevas restricciones para la vista personalizada (el diseñador podría hacerlo por sí mismo).

Si estaba haciendo esto a través del código, ‘ usted ‘ tendría que hacer esto, ya que el diseñador puede no saber qué hacer. Tendría que volver a escribir todo su código de tamaño que se basaba en que esa vista personalizada se encontraba en la parte superior. No sabe dónde está esto visualmente, por lo que debe recordar cada fragmento de código que podría verse afectado en toda su aplicación y hacer algunas pruebas de regresión pesadas. Esto llevará mucho más tiempo y, en el mundo del desarrollo, el tiempo es dinero.

Sinceramente, recomendaría aprender a usar los creadores de UI que Apple ha creado, ya que acelerarán y simplificarán su proceso de desarrollo. Todavía puede hacer la interfaz de usuario base de código (y en algunos casos es la mejor manera) pero asegúrese de que haya una razón válida para ello.

Tiendo a crear y colocar vistas en el código también, para que no estés solo.

Los guiones gráficos son horribles en proyectos de varias personas porque dos personas no pueden trabajar en el mismo archivo al mismo tiempo. Es mejor de lo que solía ser ahora que puede tener múltiples guiones gráficos, pero aún no es excelente por otras razones, como la revisión de código y la modificación de cambios. Autolayout fue un desastre, pero lentamente Apple ha solucionado la mayoría de los problemas en Xcode que lo hicieron horrible desde el principio. Todavía no me gusta por otras razones, como la dificultad de animar vistas, modificar diseños existentes y depurar.

Si crea vistas en código, sugiero pasar a UIStackView de iOS 9. Es mucho más fácil y directo que el autolayout y funciona muy bien en código.

Apple se está moviendo a tamaños de pantalla no fijos, por lo que los guiones gráficos (ahora con clases de tamaños y referencias externas de guiones gráficos) con restricciones son el camino a seguir.

Interface Builder es una herramienta muy agradable ahora, los primeros esfuerzos de diseño automático en IB dejaron la herramienta inutilizable.

Puede codificar hermosas interfaces y UX simplemente animando restricciones … solo obtenga un buen tutorial, ¡estoy seguro de que nunca mirará hacia atrás!

La mayoría de los desarrolladores están utilizando Interface Builder ampliamente, desde prototipos rápidos y sucios hasta aplicaciones completas.

Hola,
Me alegra responder a su pregunta.

No tanto. La interfaz de la aplicación escrita mediante el uso de código no es extensible y usted dedica mucho más tiempo a escribirla. Además, este código es difícil de leer y editar.

Con guiones gráficos y restricciones, puede agregar cualquier elemento al controlador en el guión gráfico con solo arrastrar y soltar y diseñarlo en pocos clics del mouse.

Entonces, comience a usar guiones gráficos, restricciones, clases de tamaño

Atentamente,

rollncode.com

Una razón para NO usar plumillas / guiones gráficos es si está trabajando en un equipo de desarrolladores, todos trabajando en las mismas pantallas al mismo tiempo. Resolver conflictos sobre git es mucho más fácil con el código que con las descripciones XML ofuscadas de una IU.

Después de haber trabajado en más de 70 proyectos diferentes con iOS, todo lo que diré es que el cliente nunca lo sabrá. Si no está roto, no lo arregles. Una vez dicho esto, recomiendo encarecidamente utilizar un sitio web como raywenderliches y dominar el diseño automático porque le ahorrará un sinfín de tiempo.