¿Cuáles son las mejores prácticas y directrices de la organización de la solución Xcode?

Question

¿Hay mejores prácticas de cómo organizar la solución de uno en Xcode

Esto es mío en el momento de la raíz:

• una carpeta para cada marco tercera parte, por ejemplo, KissXML
• Una carpeta para mi unidad de prueba
• Una carpeta para los marcos de trabajo, productos y recursos
• Una carpeta para MiApl que tiene subcarpetas para el modelo, vista, controlador, base de datos, ficheros de soporte y de dominio.

Answer 1

mina es:

Main application 
    Model 
    Singletons 
    Helper+managers 
    Controllers // I keep nibs with their respective class files 
    View 
    Resources 
     images 
     plists 
     // ... groups from other types of resources if needed 
    Supporting files 
Unit tests 
Frameworks 

Para el código reutilizable en iOS que utilizan las bibliotecas estáticas y agregar estos como proyectos separados en el espacio de trabajo de Xcode. Incluso para el código de un tercero, si no hay un objetivo de biblioteca estática, creo uno. De esa forma, trato el código de terceros de la misma manera que trato mi propio código de biblioteca. Además, entonces no tengo que preocuparme por las versiones de código de terceros.

He encontrado que es importante que Xcode refleje la organización del código del sistema, al menos hasta cierto nivel. Adopté esta práctica después de leer this blog post. Sin embargo, no hago esto debajo de los niveles que he enumerado arriba. Esto ayuda cuando compartes código en github, por ejemplo. En lugar de hacer que los descargadores o los contribuyentes tengan que explorar toda su fuente volcada en un solo directorio, está organizada en categorías funcionales. He visto algunos proyectos en los que la organización de Xcode está bien, pero todos los archivos de origen del sistema de archivos se vuelcan en un solo directorio.

Answer 2

Aunque ningún método en particular puede estar desprovista de inconvenientes, aquí es lo que usamos

1. carpeta para el núcleo de la aplicación o modelo. Esto incluye las subcarpetas para las bibliotecas de terceros utilizadas y las carpetas para las clases de modelo especializado . Por ejemplo, habría una carpeta para el manejo del servicio web.

2. Carpeta para un módulo importante que incluiría subcarpetas para cada pantalla que contiene los archivos de clase, puntas y recursos (esto puede incluir más sub-carpetas de acuerdo a la necesidad).

3. carpeta para el segundo módulo mayor y así sucesivamente ..

Este modelo nos sirve un propósito importante. Nuestro núcleo de aplicaciones contiene cosas como el registro, el cifrado/descifrado de datos, etc. Por lo tanto, es muy poco probable que se modifique para muchas aplicaciones que desarrollamos. Del mismo modo, habría algunas aplicaciones que necesitarían la funcionalidad del módulo principal uno y agregar algunas otras cosas. Por lo tanto, estos tres grupos de carpetas se mantienen como repositorios separados en la subversión.

Ahora cuando comenzamos un nuevo proyecto, creamos un nuevo repositorio para el proyecto y lo vinculamos con el repositorio central de la aplicación y otros repositorios de módulos principales según la necesidad. Por lo tanto, cualquier cambio realizado en el núcleo de la aplicación por parte de un equipo de proyecto se refleja también en otros proyectos. Lo mismo con otros módulos principales. Esto también nos ayuda a lograr una modularidad completa.

Por supuesto que habría desventajas en este esquema, pero este esquema nos ha venido bien desde hace muchos años :)