Espacio de trabajo de Xcode contra proyectos anidados
project code-organization (2)
No entiendo el uso de un espacio de trabajo de Xcode para organizar proyectos con dependencias entre ellos. Por ejemplo, veo que muchos desarrolladores crean estructuras de espacios de trabajo que se ven así:
Workspace |-- App |-- A Common Library |-- Another Common Library
¿Qué beneficio proporciona esto? Si alguien abre directamente el proyecto "Aplicación", ¿no podrán ellos realmente crear la aplicación? Tendrían que darse cuenta de que existe un espacio de trabajo con las dependencias necesarias.
Me parece que el mejor enfoque es utilizar proyectos anidados como este:
App |-- Libraries | |-- A Common Library | |-- Another Common Library
Entonces no existe ningún proyecto que no pueda ser construido. También parece estar más en línea con la idea de Git de los submódulos.
El único uso que veo para un espacio de trabajo es agrupar proyectos comunes sin dependencias entre ellos. Me gustaría escuchar las opiniones de otras personas sobre esto porque me puede estar perdiendo algo.
Agregamos proyectos anidados en los Frameworks del proyecto principal, para poder "incluirlos" en el producto .framework.
Main
|-- Main
|-- MainTests
|-- Frameworks
| |-- CommonLibrary.xcodeproj
| |-- AnotherCommonLibrary.xcodeproj
| |-- UIKit.framework
| |-- Foundation.framework
| |-- CoreFoundation.framework
|-- Products
Vea este gran tutorial de Jeff Verkoeyen para agregar marcos universales a un proyecto. No es fácil, al principio, pero sigue trabajando en eso y lo entenderás.
Utilizo espacios de trabajo cuando quiero combinar proyectos al mismo tiempo que mantengo la independencia del proyecto.
Un ejemplo donde uso espacios de trabajo es una serie de proyectos tutoriales que progresan de muy simple a más complejo. Cada proyecto puede funcionar como un proyecto independiente, pero agruparlos en un espacio de trabajo ayuda a mi organización en el proyecto en general.
En otra instancia, tengo una aplicación desarrollada para un cliente. La aplicación funciona como una aplicación independiente y un módulo en el proyecto general. El proyecto independiente puede construir la aplicación independiente. La otra aplicación usa un espacio de trabajo que incluye dos proyectos. La versión de módulo de la aplicación se crea a partir de un esquema especial, y esta aplicación combinada no se crea sin utilizar el espacio de trabajo.
Un giro con las dos situaciones anteriores es donde se almacena la carpeta de compilación. Tengo que cambiar la preferencia de Xcode para colocar los productos de compilación en carpetas únicas para el grupo de proyectos de tutoriales, usar una carpeta de compilación común para el módulo dentro de la configuración de la otra aplicación.
En otras circunstancias, tengo muchos proyectos con proyectos integrados. En estas situaciones, los proyectos de la biblioteca son estables. No intento un mayor desarrollo de los proyectos de la biblioteca, por lo que son solo otro recurso para el proyecto. Me resulta más fácil trabajar donde la organización de mi sistema de archivos de los recursos del proyecto refleja algo la organización de mi proyecto Xcode. Entonces, estos proyectos de biblioteca se copian en la jerarquía de archivos del proyecto principal. Tendría sentido usar espacios de trabajo si estuviera desarrollando las bibliotecas y utilizándolas en múltiples proyectos. Por conveniencia, frecuentemente no me molesto.
A veces incluso combino espacios de trabajo con proyectos que contienen proyectos integrados.
Entonces, mi opinión es que las herramientas de organización, los proyectos integrados y los espacios de trabajo tienen sus ventajas y problemas. Elijo usar uno u otro (o una combinación) dependiendo de las circunstancias particulares.