usar como xcode

como - Proyecto Xcode vs. Área de trabajo Xcode-Diferencias



como usar xcode (3)

Estoy tratando de entender cómo funciona todo el ecosistema de iOS .
Hasta ahora, pude encontrar una respuesta para la mayoría de mis preguntas (y créeme, ha habido muchas), pero para esta pregunta no parece haber una respuesta clara todavía.

¿Cuál es la diferencia entre los archivos XcodeProject y XcodeWorkspace?

  1. ¿Cuál es la diferencia entre los dos?
  2. ¿De qué son responsables?
  3. ¿Con cuál de ellos debo trabajar cuando estoy desarrollando mis aplicaciones en equipo / solo?
  4. ¿Hay algo más que deba tener en cuenta en estos dos archivos?

Creo que hay tres elementos clave que debe comprender con respecto a la estructura del proyecto: objetivos , proyectos y áreas de trabajo . Los objetivos especifican en detalle cómo se construye un producto / binario (es decir, una aplicación o biblioteca). Incluyen configuraciones de compilación, como las marcas de compilador y vinculador, y definen qué archivos (código fuente y recursos) pertenecen realmente a un producto. Cuando construyes / ejecutas, siempre seleccionas un objetivo específico.

Es probable que tenga algunos objetivos que compartan código y recursos. Estos diferentes objetivos pueden ser versiones ligeramente diferentes de una aplicación (iPad / iPhone, diferentes marcas, ...) o casos de prueba que naturalmente necesitan acceder a los mismos archivos de origen que la aplicación. Todos estos objetivos relacionados se pueden agrupar en un proyecto . Si bien el proyecto contiene los archivos de todos sus destinos, cada destino elige su propio subconjunto de archivos relevantes. Lo mismo ocurre con la configuración de compilación: puede definir la configuración predeterminada de todo el proyecto en el proyecto, pero si uno de sus objetivos necesita una configuración diferente, siempre puede anularla allí:

Configuraciones de proyecto compartidas que todos los destinos heredan, a menos que lo anulen

Configuración de destino concreta: el iPhone de PSE anula la configuración del Base SDK del proyecto

En Xcode, siempre abre proyectos (o áreas de trabajo, pero no objetivos), y todos los objetivos que contiene pueden construirse / ejecutarse, pero no hay forma ni definición de construir un proyecto, por lo que cada proyecto necesita al menos un objetivo para Ser más que una simple colección de archivos y configuraciones.

Seleccione uno de los objetivos del proyecto para ejecutar

En muchos casos, los proyectos son todo lo que necesitas. Si tiene una dependencia que construye desde la fuente, puede incrustarla como un subproyecto . Los subproyectos se pueden abrir por separado o dentro de su súper proyecto.

demoLib es un subproyecto

Si agrega uno de los objetivos del subproyecto a las dependencias del superproyecto, el subproyecto se construirá automáticamente a menos que se haya mantenido sin cambios. La ventaja aquí es que puede editar archivos tanto de su proyecto como de sus dependencias en la misma ventana de Xcode, y cuando construye / ejecuta, puede seleccionar entre los objetivos del proyecto y sus subproyectos:

Sin embargo, si su biblioteca (el subproyecto) es utilizada por una variedad de otros proyectos (o sus objetivos, para ser precisos), tiene sentido colocarla en el mismo nivel jerárquico, para eso sirven las áreas de trabajo . Las áreas de trabajo contienen y administran proyectos, y todos los proyectos que incluye directamente (es decir, no sus subproyectos) están en el mismo nivel y sus objetivos pueden depender unos de otros (los objetivos de los proyectos pueden depender de los objetivos de los subproyectos, pero no al revés).

Estructura del espacio de trabajo

En este ejemplo, ambas aplicaciones ( AnotherApplication / ProjectStructureExample ) pueden hacer referencia a los objetivos del proyecto demoLib . Esto también sería posible al incluir el proyecto demoLib en los otros dos proyectos como un subproyecto (que es solo una referencia, por lo que no es necesaria la duplicación), pero si tiene muchas dependencias cruzadas, los espacios de trabajo tienen más sentido. Si abre un área de trabajo, puede elegir entre los objetivos de todos los proyectos al construir / ejecutar.

Aún puede abrir sus archivos de proyecto por separado, pero es probable que sus objetivos no se creen porque Xcode no puede resolver las dependencias a menos que abra el archivo del área de trabajo. Las áreas de trabajo le brindan el mismo beneficio que los subproyectos: una vez que cambia la dependencia, Xcode la reconstruirá para asegurarse de que esté actualizada (aunque he tenido algunos problemas con eso, no parece funcionar de manera confiable).

Sus preguntas en pocas palabras :

1) Los proyectos contienen archivos (código / recursos), configuraciones y objetivos que crean productos a partir de esos archivos y configuraciones. Los espacios de trabajo contienen proyectos que pueden hacer referencia entre sí.

2) Ambos son responsables de estructurar su proyecto general, pero en diferentes niveles.

3) Creo que los proyectos son suficientes en la mayoría de los casos. No use espacios de trabajo a menos que haya una razón específica. Además, siempre puedes incrustar tu proyecto en un área de trabajo más tarde.

4) Creo que para eso es el texto anterior ...

Hay un comentario para 3): CocoaPods , que maneja automáticamente bibliotecas de terceros para ti, usa espacios de trabajo. Por lo tanto, también tiene que usarlos cuando utiliza CocoaPods (lo que mucha gente hace).

En breve

  • Xcode 3 introdujo el subproyecto, que es una relación padre-hijo, lo que significa que el padre puede hacer referencia a su objetivo secundario, pero no al revés
  • Xcode 4 introdujo el espacio de trabajo, que es una relación entre hermanos, lo que significa que cualquier proyecto puede hacer referencia a proyectos en el mismo espacio de trabajo

Un espacio de trabajo es una colección de proyectos. Es útil organizar sus proyectos cuando existe una correlación entre ellos (por ejemplo: el Proyecto A incluye una biblioteca, que se proporciona como un proyecto en sí como proyecto B. Cuando construye el área de trabajo, el proyecto B se compila y vincula en el proyecto A).
Es común usar un espacio de trabajo en los populares CocoaPods . Cuando instala sus pods, se colocan dentro de un área de trabajo, que contiene su proyecto y las bibliotecas de pod.