¿Por qué no utilizar archivos XIB?

Question

¿Hay alguna buena razón por la que no deba usar archivos XIB/NIB con una interfaz de usuario altamente personalizada y amplias animaciones y necesidades de memoria muy bajas?

Como principiante comencé con XIB. Entonces descubrí que no podía hacer casi todo en ellos. Comenzó a ser muy difícil personalizar las cosas de la forma en que yo quería que fueran. Así que al final, arrojé todos mis XIBs y lo hice todo programáticamente.

Así que cuando alguien me pregunta si XIB es bueno, generalmente digo: Sí, si quieres crear interfaces aburridas y aburridas y no te importa demasiado el rendimiento, adelante. Pero, ¿qué otra cosa podría ser una razón para no usar XIB?

¿Soy el único desarrollador de iPhone que prefiere hacer todo de forma programática por este motivo?

Answer 1

Creo que Interface Builder es uno de los mayores activos del desarrollo de software de Mac (y, por extensión, iPhone). Las GUI son visuales; ¿Por qué no crearlos utilizando una interfaz visual? IB es lo suficientemente flexible como para que pueda diseñar una interfaz utilizando sus componentes "genéricos" y luego subclasificarlos cuando sea necesario. Claro, si tiene una interfaz única, tendrá que subclasificar una clase de vista y realizar un dibujo personalizado, pero también puede diseñar su interfaz en IB y luego usar fácilmente el inspector para cambiar la clase a su subclase personalizada.

Answer 2

Honestamente, creo que es un espectro de conveniencia. Si te sientes cómodo escribiendo todo en código, entonces hazlo. Si diseñas bien tu proyecto, debería ser aproximadamente la misma cantidad de trabajo creando ventanas nuevas, etc. Pero sé que mucha gente no está tan cómoda con el mundo de la GUI, por lo que las nib/xibs funcionan bien allí.

Honestamente, me encuentro utilizando los XIB como base con bastante frecuencia y editándolos con código para obtener el aspecto específico que quiero. Preferencia personal.

Para una estafa específica en ese punto, las vistas pueden ser difíciles de configurar después de cargarlas desde un xib. Cuando tiene configuraciones conflictivas entre IB y el código que pueden ser desagradables para solucionar problemas.

Aquí hay una pregunta para la lista. ¿Cuál es el rendimiento alcanzado al usar un xib? Pensé que eran una ventaja porque no se cargan en la memoria hasta que los necesites. Dicho eso, el tiempo de carga es más largo, lo que ralentizará tu programa. ¿Pensamientos?

Answer 3

Una cosa que encontré mejor sobre el código es para las conexiones de eventos en los controles, cuando busca usos de un método (mensaje) los encuentra si están codificados y no los encuentra si se establecieron en IB .

Por otro lado, colocar objetos en una vista es mucho más fácil en IB, donde puede ver su tamaño y posición. Cuando haces eso en el código, tienes que adivinar el tamaño y la configuración de origen y luego ejecutarlo y hacer ajustes, luego ejecutarlo nuevamente para ver cómo se ve.

Answer 4

Ahorro muchísimo tiempo al tratar con UIControllers (UITabBarControllers, UINavigationControllers, etc.) en la fase de arranque donde todo el material de navegación está conectado.

Acabo de construir X viewControllers con un XIB de acompañamiento, incluyo todo lo necesario en IB, etiquetas, imágenes, etc. Esto significa que para casi cualquier tipo de aplicación puede tener una prueba de concepto en pocas horas. Esto es suficiente para justificar pasar un tiempo aprendiendo los pormenores de IB. Especialmente en el iPhone, donde puedes tener un montón de buenas ideas de UI, pero todas fallan cuando se mueven del Simulador a un dispositivo real.

Lo mejor, en mi opinión, es equilibrarlo, si te encuentras usando mucho tiempo haciendo "cambiar el marco 3 px -> compilar -> ahh .. necesita dos píxeles más -> cambiar 2 px - compilar -> ahh ... 1 px más "para algo que se podría hacer en IB, empezarás a perder el tiempo seriamente.

Empiezo como se muestra arriba, pero luego a menudo lanzo los XIB para cosas personalizadas. El truco es no gastar horas en implementar versiones de cosas personalizadas en el código una y otra vez, pero descubra cómo debe ser y haga las cosas personalizadas una vez :)

Answer 5

Cuando su aplicación tiene algún tipo de vistas "estándar" , ve con el XIB. Si necesita una personalización real, dependiendo del contenido externo (XML ...) hágalo programáticamente.

Empecé a usar XIB y ahora es todo código, me siento más cómodo de esta manera. Tenía problemas reales con los XIB, y ahora escribir todas las interfaces en código realmente me ahorra tiempo.

Answer 6

El contenido XML de un archivo nib es muy complicado. Esto hace que sea extremadamente difícil revisar los cambios o corregir los conflictos de combinación con un sistema de control de versiones como Git.

Interface Builder es una buena idea, pero Bret Victor, en su charla "Inventing on Principle" y su ensayo "Learnable Programming," implícitamente desafía a Apple para construir un IDE aún mejor.

Una idea, basada en el principio de Bret Victor: ¿Qué pasaría si pudiera seleccionar una "Herramienta Mover" en la aplicación iOS Simulator que me permite mover un botón en mi aplicación y luego cambiar el código en el archivo de implementación (.m) ? Esto sería mucho mejor.