¿Deberían o no usar los files nib?

Soy nuevo en el desarrollo de iOS. He leído algunos de los códigos fuente que encontré en línea y muchos de ellos no incluyen un solo file de nib. Toda la vista parece dibujarse manualmente desde el código.

¿Cuáles son los beneficios de tener / no tener un file nib? ¿Por qué eligieron crear todo, desde el código en lugar de algo que pueda visualizar como storyboard o files * .xib?

Hay nibs muy simples como el MainWindow.nib típico, que no tiene contenido localizado y se puede reproducir con una sola línea de código. En tales casos, el código es mucho más rápido que desarchivar la punta.

También hay layouts altamente dynamics que son imposibles de describir como una punta.

Debe elegir la forma más conveniente y eficiente en cada caso particular. Siempre habrá intercambios, solo elija sabiamente.

El mayor motivo por el que me gusta el código es que se diferencia bien en el control de origen. Los XIB son muy difíciles de diferenciar, fusionar, leer.

El código también es fácil de copyr / pegar fragments guardados. Con IB, siempre me olvido de alguna checkbox que me deja preguntándome por qué la magia no funciona. Mis notas tienen fragments de código.

Lo que IB realmente sobresale es el layout y la ayuda con las directrices de la interfaz humana (número de píxeles entre los controles, etc … con líneas definidas).

Entonces, mi preference personal es el layout en IB y todo lo demás en el código (incluyendo el objective, la acción, la adición de columnas, etc … etc …). Sin embargo, bajo escenarios dynamics, el IB se desmorona y termina con vistas personalizadas.

Aquí hay una publicación relacionada:

Interface Builder (XIB) o Code cuando se fusiona en un entorno de equipo?

Hay muchas razones sobre por qué debe usar nibs y por qué no. No hay una respuesta definitiva, y cada respuesta depende de lo que debe hacer.

Además de las ventajas obvias que ofrece Nibs (process de creación de interfaz de usuario rápido, minimiza el código de construcción de vista en files .m) ofrecen algo que no puedes encontrar de otra manera: solución de problemas de localización. Mientras localiza su aplicación en otros idiomas, tropezará con frases y cosas que requieren de 2-3 palabras para explicar mientras que en otro idioma toman solo una. Eso conduce seriamente a errores con vistas fuera de lugar dentro de un controller de vista cuando se usan diferentes localizaciones. Por lo tanto, puede tener 2-3 sub-nibs para cada nib en Xcode 4, y ubicar cada uno como prefiera, y colocar los botones y vistas en los lugares correctos, sin preocuparse de reubicar sus vistas dependiendo del idioma el usuario tiene Si tuviera que hacer todo esto usando el código, debería haber colocado 'if' en todas partes, y sin duda es una mala práctica de progtwigción y propenso a errores.

He creado algunos controlleres de vista que requerirían cientos de líneas para configurar las vistas si no utilizaba el creador de interfaces.

Sin embargo, los NIB nunca lograrán el performance de la creación de vistas de forma programática, ya que cada NIB es un descriptor de vista escrito en HTML / XML y antes de crear cualquier vista, un file debe leerse del disco y analizarse. Nibs también carece de las opciones de personalización que tiene el código simple (sombras sueltas, esquinas networkingondeadas y otra magia de cuarzo). Estas opciones de personalización no están disponibles porque hay muchas maneras de lograr el mismo resultado usando el código, ya sea hablando con la capa Core Animation de nivel superior, ya sea dirigiendo QuartCore y CGGraphics directamente y haciendo cosas pesadas allí, que ciertamente es más rápido y recomendado en la mayoría casos (las sombras con capas pueden ser extremadamente lentas). Entonces, Apple no quiere restringir el desarrollo a una forma específica de dibujar cosas.

Los NIB existen por una razón. Debe asegurarse de que en su request entienda los motivos por los que crea una NIB. Existen nibs para conectar el código a las salidas, facilitar la localización, acelerar el desarrollo y limpiar su código. Dentro de un proyecto, ciertamente debe usar Nibs, pero también debe evitar usarlos cuando el código simple también le proporcione los mismos resultados con un esfuerzo mínimo o similar.

Por último, pero no less importante, tenga en count la gestión de la memory. El uso de Nibs afectará la desasignación de objects asignados como IBOutlets. Si arena está seguro de que un IBOutlet que cree se desasignará cuando lo desee, no use una NIB. use un código simple en su lugar.

hay muchas razones para crear vistas en el código.

  • Los files de nib están cargados de perezosos y llevan en algún momento a una notable falta de reacción que a los usuarios no les gusta
  • no puedes configurar todo en IB y mucho. Las vistas necesitan algunos extras extravagantes.
  • a veces es más fácil simplemente escribir su vista que hacer clic y arrastrar todas las cosas necesarias juntas

Creo que la razón más importante es la falta de performance y características.

Estoy usando nib-files cuando solo quiero mostrar información fácil con simples botones y tags y para crear prototypes.

A nib file is a special type of resource file that you use to store the user interfaces of iOS and Mac apps. A nib file is an Interface Builder document. You use Interface Builder to design the visual parts of your app—such as windows and views—and sometimes to configure nonvisual objects, such as the controller objects that your app uses to manage its windows and views. In effect, as you edit an Interface Builder document, you create an object graph that is then archived when you save the file. When you load the file, the object graph is unarchived. 

El file nib (y, por lo tanto, el gráfico de objects) puede contener objects de marcador de position que se utilizan para referirse a objects que viven fuera del documento pero que pueden tener references a objects en el documento o a los que los objects en el documento pueden tener references. Un marcador de position especial es el propietario del file.

En time de ejecución, carga un file de nib con el método loadNibNamed: owner: o una variante del mismo. El propietario del file es un marcador de position en el file nib para el object que usted pasa como el parámetro propietario de ese método. Cualquier connection que establezca hacia y desde el propietario del file en el file nib en Interface Builder se restablecerá cuando cargue el file en time de ejecución.

iOS utiliza nibs como detalle de implementación que admite storyboards, el formatting de layout de la interfaz de usuario de iOS. Los storyboards le permiten diseñar y visualizar la interfaz de usuario completa de su aplicación en un solo canvas. Para los desarrolladores de iOS, el uso de storyboards es la forma recomendada de diseñar interfaces de usuario.

Comenzaría con xibs. Una vez que haya finalizado la interfaz de usuario, migre sus xibs al código. De esta manera obtienes lo mejor de ambos mundos. Los XIB pueden ser lentos, y he visto 400 KB XIBS (algo raro). Sin dudas, los XIB son crujientes …