Projekt Xcode vs. Obszar roboczy Xcode - Różnice

Próbuję zrozumieć, jak działa cały ekosystem iOS.
Do tej pory mogłem znaleźć odpowiedź na większość moich pytań (i wierzcie mi, było ich wiele), ale na to pytanie wydaje się, że nie ma jeszcze jasnej odpowiedzi.

Jaka jest różnica między plikami XcodeProject i XcodeWorkspace?

1. Jaka jest różnica między nimi dwoma?
2. Za co oni są odpowiedzialni?
3. Z którym z nich powinienem pracować, gdy tworzę aplikacje w zespole / samodzielnie?
4. Czy jest coś jeszcze, o czym powinienem wiedzieć w sprawie tych dwóch plików?

Myślę, że istnieją trzy kluczowe elementy, które należy zrozumieć w zakresie struktury projektu: Cele , projekty i obszary robocze . Cele określają szczegółowo, w jaki sposób budowany jest produkt / plik binarny (tj. Aplikacja lub biblioteka). Obejmują ustawienia kompilacji, takie jak flagi kompilatora i konsolidatora, i określają, które pliki (kod źródłowy i zasoby) faktycznie należą do produktu. Podczas budowania / uruchamiania zawsze wybierasz jeden konkretny cel.

Prawdopodobnie masz kilka celów, które współużytkują kod i zasoby. Te różne cele mogą być nieco różnymi wersjami aplikacji (iPad / iPhone, różne marki,…) lub testami, które naturalnie potrzebują dostępu do tych samych plików źródłowych co aplikacja. Wszystkie te powiązane cele można zgrupować w projekcie . Chociaż projekt zawiera pliki ze wszystkich swoich celów, każdy cel wybiera własny podzbiór odpowiednich plików. To samo dotyczy ustawień kompilacji: w projekcie możesz zdefiniować domyślne ustawienia dla całego projektu, ale jeśli jeden z celów wymaga innych ustawień, zawsze możesz je tam zastąpić:

Wspólne ustawienia projektu, które dziedziczą wszystkie cele, chyba że je zastąpią

Ustawienia docelowe betonowe: PSE iPhone przesłania projektu Base SDKustawienie

W Xcode zawsze otwierasz projekty (lub obszary robocze, ale nie cele), a wszystkie zawarte w nim cele można budować / uruchamiać, ale nie ma możliwości / definicji budowy projektu, więc każdy projekt potrzebuje co najmniej jednego celu, aby być czymś więcej niż zbiorem plików i ustawień.

Wybierz jeden z celów projektu do uruchomienia

W wielu przypadkach potrzebujesz projektów. Jeśli masz zależność zbudowaną ze źródła, możesz osadzić ją jako podprojekt . Podprojekty można otwierać osobno lub w ramach ich super projektu.

demoLib jest podprojektem

Jeśli dodasz jeden z celów podprojektu do zależności super projektu, podprojekt zostanie automatycznie zbudowany, chyba że pozostanie niezmieniony. Zaletą jest to, że możesz edytować pliki z projektu i zależności w tym samym oknie Xcode, a podczas kompilacji / uruchamiania możesz wybierać spośród celów projektu i jego podprojektów:

Jeśli jednak twoja biblioteka (podprojekt) jest wykorzystywana przez wiele innych projektów (a dokładniej ich cele), sensowne jest umieszczenie jej na tym samym poziomie hierarchii - do tego właśnie służą obszary robocze . Obszary robocze zawierają projekty i zarządzają nimi, a wszystkie projekty, które zawiera bezpośrednio (tj. Nie ich podprojekty) są na tym samym poziomie, a ich cele mogą być od siebie zależne (cele projektów mogą zależeć od celów podprojektów, ale nie odwrotnie).

Struktura obszaru roboczego

W tym przykładzie, obie aplikacje ( AnotherApplication / ProjectStructureExample ) mogą odwoływać się demoLib cele projektu. Byłoby to również możliwe poprzez włączenie projektu demoLib w obu innych projektach jako podprojektu (który jest jedynie referencją, więc nie jest konieczne powielanie), ale jeśli masz wiele zależności krzyżowych, obszary robocze mają większy sens. Jeśli otworzysz obszar roboczy, możesz wybierać spośród wszystkich celów projektu podczas budowania / uruchamiania.

Nadal możesz otwierać pliki projektu osobno, ale jest prawdopodobne, że ich cele nie zostaną zbudowane, ponieważ Xcode nie rozwiąże zależności, chyba że otworzysz plik obszaru roboczego. Obszary robocze dają tę samą korzyść, co podprojekty: po zmianie zależności Xcode przebuduje ją, aby upewnić się, że jest aktualna (chociaż miałem z tym pewne problemy, wydaje się, że nie działa niezawodnie).

Wasze pytania w skrócie :

1) Projekty zawierają pliki (kod / zasoby), ustawienia i cele, które tworzą produkty na podstawie tych plików i ustawień. Obszary robocze zawierają projekty, które mogą się nawzajem odnosić.

2) Oba są odpowiedzialne za uporządkowanie całego projektu, ale na różnych poziomach.

3) Myślę, że projekty są w większości przypadków wystarczające. Nie używaj obszarów roboczych, chyba że istnieje konkretny powód. Ponadto zawsze możesz później osadzić swój projekt w obszarze roboczym.

4) Myślę, że do tego właśnie służy powyższy tekst…

Jedna uwaga dotyczy 3): CocoaPods , która automatycznie obsługuje biblioteki innych firm, używa obszarów roboczych. Dlatego też musisz ich używać, kiedy używasz CocoaPods(co robi wiele osób).

Obszar roboczy to zbiór projektów. Przydatne jest organizowanie projektów, gdy istnieje między nimi korelacja (np .: Projekt A zawiera bibliotekę, która jest udostępniana jako sam projekt jako projekt B. Podczas budowania obszaru roboczego projekt B jest kompilowany i łączony w projekcie A).
W popularnych CocoaPods często używa się obszaru roboczego . Po zainstalowaniu zasobników są one umieszczane w obszarze roboczym, który zawiera projekt i biblioteki zasobników.

W skrócie

• Xcode 3 wprowadził podprojekt, którym jest relacja rodzic-dziecko, co oznacza, że ​​rodzic może odwoływać się do swojego celu potomnego, ale nie odwrotnie
• Xcode 4 wprowadził obszar roboczy, który jest relacją rodzeństwa, co oznacza, że ​​każdy projekt może odwoływać się do projektów w tym samym obszarze roboczym

Kiedy użyłem CocoaPods do opracowania projektów iOS, istnieje .xcworkspaceplik, musisz otworzyć projekt z .xcworkspaceplikiem związanym z CocoaPods.

Ale kiedy Show Package Contentsz .xcworkspacepliku, znajdziesz contents.xcworkspacedataplik.

<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "group:BluetoothColorLamp24G.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:Pods/Pods.xcodeproj">
   </FileRef>
</Workspace>

zwróć uwagę na tę linię:

location = "group:BluetoothColorLamp24G.xcodeproj"

.xcworkspacePlik ma odniesienia z .xcodeprojpliku.

Środowisko programistyczne:

macOS 10.14
Xcode 10.1

1. Jaka jest różnica między nimi dwoma?
   Obszar roboczy to zestaw projektów

2. Za co oni są odpowiedzialni?
   Projekt jest odpowiedzialny za kod źródłowy. Obszar roboczy odpowiada za zależności między projektami

3. Z którym z nich powinienem pracować, gdy tworzę aplikacje w zespole / samodzielnie?
   Twój wybór powinien zależeć od rodzaju projektu. Na przykład, jeśli projekt opiera się na menedżerze zależności CocoaPods, tworzy obszar roboczy.

4. Czy jest coś jeszcze, o czym powinienem wiedzieć w sprawie tych dwóch plików?
   Konkurentem obszaru roboczego jest cross-project references^{[O firmie]}

[Komponenty Xcode]