¿Cómo organizas tus variables de layout de interfaz de usuario, objects, etc. en iOS?

Como la aplicación de iPad que estoy haciendo ha ido creciendo su tamaño, me resulta difícil hacer un seguimiento de los valores de layout de la interfaz de usuario. Aquí, estoy hablando de valores como el ancho de una tabla, los colors de background y la fuente de un título.

Me gustaría organizar todos los valores y objects relacionados con el layout de la IU de manera más eficiente.

¿Cómo organizas esto?

  • ¿#define valores en un file de encabezado?
  • ¿Los declara como variables globales o no?
  • ¿Pones tus valores una class estática?
  • ¿O no cree que organizar estos valores es bastante mejor?

Me gustaría escuchar tu consejo. Gracias 🙂

Sí, depende, por lo tanto, solo algunas reglas de oro …

Do you #define values in a header file? 

… en los casos en los que podría querer cambiar esto solo localmente, por ejemplo, para constantes, colors, alineamientos, imágenes de botones, … la razón principal por la que hago esto sin embargo es la documentation que permite al dar al local definir una explicación larga nombre

 Do you declare them as global variables or not? 

… todas mis aplicaciones tengo una class de MainDataManager, que contiene todas las variables que necesito de forma global, ya que para la parte de la interfaz de usuario a menudo tengo mi propio object usado globalmente. Esto es extremadamente útil, simplifica el código y probablemente sea una de las cosas más importantes que aprendí al principio. también podría ver aquí Uso de la variable de AppDelegate como una variable global: pregunta sobre la liberación / retención

 Do you put your values one static class? 

… las classs estáticas existen de forma conceptual. Las variables estáticas son bastante útiles cuando quieres darle a un método algún tipo de memory propia. Sin embargo, ninguno juega un papel importante en mi UI.

In general , me gusta usar IB para diseñar las pantallas, pero configuro todos los nombres de los botones, tags, texts en el código. ¿Por qué? Porque cuando tengo que localizar la aplicación para mantener múltiples files XIB (para cada idioma habrá un file XIB aislado para mantener) se convierte en una carga real, incluso si hay un solo cambio en el layout.

Todas las configuraciones de la constante global siempre se mantienen en GloblDefinitions.h mientras que al mismo time tengo en mi file .pch esta input #import "GlobalDefinitions.h"

Entonces, la combinación de una variable de delegado proporcionada globalmente + GlobalDefinitions.h para constantes es mi solución.

Es una buena pregunta. Al combinar el uso del generador de interfaces con ajustes de interfaz de usuario codificados manualmente y / o componentes personalizados, también tiene el problema de los valores duplicates entre IB y el código.

En algunas situaciones, para facilitar la lectura y facilitar el ajuste por parte de un tercero, es más fácil si los valores están codificados en el lugar, por lo que en casos triviales (por ejemplo, casos en que el valor no se repite en ningún otro lugar o es poco probable que cambie) una opción válida

En general, si las constantes son específicas del layout de un componente de interfaz de usuario particular, entonces parece lógico definirlas # en el file de encabezado para el componente de interfaz de usuario que las usa. Creo que ponerlas en un file global rompe el desacoplamiento que le gustaría tener entre los componentes de la interfaz de usuario, y también para la legibilidad, puede ser más fácil para otro desarrollador encontrarlos en el file de encabezado.

Por otro lado, si hay valores que se usan de manera consistente en varios componentes de UI dentro de la aplicación, estos se pueden definir en un file de inclusión global. De manera similar, si hay valores "base" que se utilizan para derivar otras longitudes, etc., que se usan comúnmente en múltiples componentes de interfaz de usuario, también se pueden almacenar en una inclusión global.

También, en la medida de lo posible, utilice los ajustes de flexibilidad de márgenes del administrador de layout y la configuration de flexibilidad ancho / alto para minimizar la necesidad de valores de código rígido. Y cuando sea relevante, obtenga valores de un valor base o de un sistema (por ejemplo, ancho de pantalla).

Al final del día, si el valor está ahí en el código que está delante de usted, a veces es mucho más fácil encontrar y modificar que cambiar un #define en otro file, por otro lado, si se repite el mismo valor en múltiples lugares y un #define no se usa, entonces puede ser muy confuso para otro codificador entrar y cambiar uno de estos valores repetidos solamente y tratar de comprender y examinar los efectos secundarios resultantes y en qué otros lugares se debe cambiar el valor.

Bueno, Ryan depende de ti. Puedes usar directivas de pre procesador … declarando en el file .pch.

o puede hacer que una class de object tome todas las constantes …

Espero que te ayude..

Gracias

Esto es lo que he aprendido de algunos de mis proyectos anteriores.

1] Convenciones de nomenclatura: use el prefijo apropiado y estandarizado. ex tblRecordLis, viewControlPanel, etc.

2] Mantener las constantes juntas: mantener todas las constantes en un solo lugar networkinguce el dolor de search el proyecto completo para encontrar / corregir / replace constantes y sus valores.

3] Agrupar Clases relevantes juntas según la utilidad y su funcionalidad.

4] Las constantes de la interfaz de usuario como el tamaño, las compensaciones, los valores del marco (que necesita para el código duro) se pueden mantener en constantes

algunos que he usado son

 #define MenuPopoverFrame CGSizeMake(278, 550); #define LandscapeContentSize @"{{0,0},{719,734}}" #define PortraitContentSize @"{{2,0},{765,980}}" 

5] Usando IB lo más posible ya que nos da más flexibilidad.

6] Los comentarios y la documentation apropiados demuestran ser un salvavidas cuando se trata de la debugging. Me resulta fácil declarar las keys como constantes, ya que usarlas en varios lugares también aumenta las posibilidades de error si se usan como tales. La key eq nombrada @ "método" se puede declarar mejor como

 #define kMethodKey @"method" 

Esto muy simple ahorra mi time al depurar cuando el tamaño del proyecto crece.

** Tomar pistas de las muestras de Apple también te brinda una gran ayuda para mantener tu código estandarizado.