Jak skonfigurować niezależne zestawy ustawień runtime w XCode

Moja aplikacja na iPhone ' a łączy się z trzema różnymi serwerami, powiedzmy: Produkcja, inscenizacja i testowanie . Istnieje kilka wartości konfiguracyjnych, które aplikacja używa w zależności od tego, do którego serwera się łączy, np. Facebook App ID, TestFlight team key, itp.

Chciałbym mieć wszystkie ustawienia w GIT i tylko wybrać konfigurację, której aplikacja ma użyć podczas kompilacji lub zwolnienia. Na przykład, gdy wybrano testowanie , Product - > Run w XCode uruchamia wersję debugowania aplikacji łączącej się z testing, a Product -> Archivetworzy plik IPA z wersją release, która łączy się również z testing.

Nie chcę tworzyć więcej konfiguracji build niż debug i release (ponieważ oznaczałoby to 6 różnych kombinacji konfiguracji build / run-time). Idealnym rozwiązaniem, jak widzę, byłoby to, że mam trzy schematy: Produkcja , testowanie i staging , a każdy schemat wybiera jedną z trzech informacji.pliki plist do użycia z aplikacją. To pozwoliłoby mi nie tylko zdefiniować różne ustawienia czasu pracy, ale także różne wersje aplikacji lub identyfikatory pakietów w zależności od serwera zaplecza. Ale wygląda na to, że nie mogę skonfigurować akcji Archive w żaden inny sposób, poza zaznaczeniem innej konfiguracji kompilacji. Jakieś pomysły, czy można to w jakikolwiek sposób osiągnąć?

Edit: To zrób to trochę bardziej jasne, Produkcja/staging / testowanie jest serwerem back-end, a nie wersją aplikacji iOS. Aplikacja na iOS jest dostępna w dwóch wersjach: debug/release. Innymi słowy, mogę chcieć uruchomić debugwersję aplikacji łączącą się z serwerem production, na przykład, aby debugować awarię spowodowaną przez JSON zwrócony z tego serwera. Mogłem nazwać serwery A, B I C dla jasności.

Author: Amiramix, 2012-05-08

4 answers

Sugerowałbym użycie różnych celów budowania dla każdego środowiska. Z powodzeniem korzystałem już wcześniej z tego modelu. W ustawieniach projektu możesz zduplikować bieżący cel i zmienić ustawienia budowania w razie potrzeby. Istnieje właściwość Info.plist File, która pozwoli Ci zmienić domyślny plist dla tego celu.

Po tym, można utworzyć schemat dla każdego środowiska, które będzie używać według celu.

Możesz pójść o krok dalej i użyć innego identyfikatora pakietu dla każdego celu i różne nazwiska. Pozwoli to na zainstalowanie na przykład kompilacji staging i production na tym samym urządzeniu.

Jedynym minusem jest to, że masz więcej pracy podczas aktualizacji profili obsługi.

 10
Author: adig,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-08 11:28:23

Dobrym sposobem na to jest konfiguracja kompilacji i makra C. Pozwala to uniknąć konieczności tworzenia osobnego celu dla każdej konfiguracji, która nie jest tak naprawdę prawidłowym wykorzystaniem celów.

Najpierw chcesz skonfigurować konfiguracje na poziomie projektu:

Tutaj wpisz opis obrazka

Możesz tworzyć różne konfiguracje do debugowania, dystrybucji korporacyjnej i dowolnego innego rodzaju specjalnej kompilacji.

Następnie możesz zdefiniować kilka flag makr dla każdej konfiguracji które zostaną przekazane kompilatorowi. Następnie możesz sprawdzić te flagi podczas kompilacji. Znajdź ustawienie budowania "flagi preprocesora" na poziomie docelowym:

Tutaj wpisz opis obrazka

Po rozwinięciu trójkąta można zdefiniować różne wartości dla każdej konfiguracji. Tutaj możesz zdefiniować makra KEY=VALUE lub po prostu KEY.

Tutaj wpisz opis obrazka

W kodzie możesz sprawdzić istnienie tych makr lub ich wartość (jeśli takie istnieją). Na przykład:

#ifdef DISABLE_FEATURE_X
    featureXButton.hidden = YES;
#endif

// ...

#if FOOBAR_VISIBLE == 0
    foobarView.hidden = YES;
#elif FOOBAR_VISIBLE == 1
    foorbarView.hidden = NO;
#else
    #error Invalid value for FOOBAR_VISIBLE
#endif

Możesz przejść w również wartości łańcuchowe, które muszą być owinięte pojedynczymi cudzysłowami w ustawieniu budowania, np. DEFAULT_LOCALIZATION_NAME='@"en"'.

Możesz również skonfigurować konfigurację używaną podczas debugowania i archiwizacji za pomocą Edytora Schemes. Jeśli wybierzesz "Uruchom" lub "archiwum" w edytorze schematów, możesz wybrać odpowiednią konfigurację.

Tutaj wpisz opis obrazka

Jeśli chcesz sparametryzować wpisy w Info.plik plist, można zdefiniować ich wartość za pomocą niestandardowego ustawienia budowania. Dodaj niestandardowe ustawienie budowania dla Twojego "target": {]}

Tutaj wpisz opis obrazka

A następnie nadaj jej odpowiednią wartość dla różnych konfiguracji:

Tutaj wpisz opis obrazka

Następnie w Info.plik plist można odwołać się do tego ustawienia:

Tutaj wpisz opis obrazka

Zauważ, że jedynym ograniczeniem tego podejścia jest to, że nie można zmienić następujących elementów:

  • Ustawienia.pakiet

Dodatkowo, w starszych wersjach Xcode bez obsługi katalogu zasobów, nie można zmienić następujących items:

  • ikona.png
  • Default.png

Nie mogą być jawnie zdefiniowane w Info.plik plist lub gdziekolwiek indziej, co oznacza, że potrzebujesz różnych celów, aby je zmienić.

Mam nadzieję, że to pomoże.
 112
Author: Mike Weller,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-01-23 04:53:20

Oto o wiele łatwiejsze rozwiązanie, jeśli dane biblioteki pozwalają ustawić klucze w kodzie, co oznacza, że możesz mieć wartość produkcyjną w pliku plist, ale zmień je w AppDelegate(lub w którym pliku są używane po raz pierwszy).

Współpracuje z facebook, twitter i Google sdk w tej chwili.

Ex:

#ifdef DEBUG
  // Facebook
  [FBSettings setDefaultAppID:@"SandboxID"];
  // Fabric / TwitterKit - must be called above [Fabric with:@[TwitterKit]];
  [[Twitter sharedInstance] startWithConsumerKey:@"SandboxKey" consumerSecret:@"SandboxIDSecret"];
#endif

To samo w języku Swift, wystarczy użyć #if zamiast # ifdef.

Uwaga O Facebook to działało z wersją 3 ich SDK, nie jestem pewien, czy jest to możliwe z późniejsze wersje.

 2
Author: Nycen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-10-20 15:14:37

Jest to prawdopodobnie bardzo niska technologia, ale po prostu mam metodę o nazwie apiURL(), która zwraca adres URL API, którego chcę. Mam localhost, scenę i produkcję i po prostu odkomentuję tę, którą chcę. Jak na razie dobrze mi to wyszło. Zapomniałem go tylko kilka razy zmienić. UPS.

 0
Author: Dan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-02-27 18:34:15