intive Argentina Blog

Entornos Múltiples

Es un escenario muy común tener diferentes entornos (DEV, TEST, UAT, PROD, etc) en una aplicación de iOS. Cada entorno tiene diferente información relacionada a la app, como tokens, claves api o urls. Entonces, la idea es encontrar una manera conveniente de manejar estos valores múltiples, de manera ordenada.

 

Manualmente

Cuando el proyecto comienza, todavía no tenemos diferentes entornos, o varias propiedades diferentes entre ellos. Quizás simplemente tengamos una URL variable que cambiamos manualmente cuando necesitamos una o la otra.

 

Compilación Condicional

Otro enfoque (aun así no recomendable es utilizar «compilación condicional«):

Un problema de este enfoque es que cada vez que ejecutemos un entorno, deberíamos cambiar la configuración para definir los macros DEV, PROD, etc. También, necesitamos tener código definido globalmente. Finalmente, se está compilando un código diferente, para cada entorno.

Todos estos problemas crecen exponencialmente, si, además, se tienen varios entornos, donde necesitas crear condiciones anidadas para manejar cada caso.

Build Configuration

Esta es la solución. Aquí combinaremos:

  • Build Configurations
  • Schemes
  • Build Settings

Para alternar entre entornos, sin tocar el código, siempre compilaremos lo mismo, y todas las configuraciones serán almacenadas en un archivo de configuración (plist).

¿Qué es una “Build Configuration”? Es simplemente un conjunto de configuraciones que serán utilizados para la configuración. Cuando creamos un nuevo proyecto iOS, Xcode, por defecto, crea dos configuraciones: Debug y Release.

1

¿Qué es un «Xcode Scheme»? Un esquema encapsula todos los bits que describen el proceso de build de una aplicación. Por ejemplo: qué Target será construido o qué Configuración debería ser utilizada para construirlo (permite elegir una configuración diferente para ejecutar, analizar o archivar). Por defecto, se crea un esquema y es configurado para usar Build o Release, dependiendo de la acción del (para ejecutar, se configura Debug, mientras que para archivar, se utiliza Release).

2

Lo que haremos es crear una “Build Configuration” para cada entorno, setear el Build Settings con los valores apropiados para cada entorno (o, mejor aún, setear un archivo de configuración and setear toda la info en ese archivo) y, finalmente, crear Esquemas para ejecutar cada configuración fácilmente.

 

Paso 1: Crear una Build Configuration

En la info del proyecto, en la sección de Configuración, existen los valores default Debug y Release. Hacer click en el signo más (+), y duplicar cualquiera de la Configuraciones creadas. En el ejemplo, renombramos Debug y Release y creamos dos configuraciones más.

3

Notar que luego de crear la Configuración, el Build Settings en cuestión fue actualizado, para tener las nuevas Configuraciones, por ejemplo el Code Signing Identity, que previamente debería ser configurado para Debug o Release, ahora es así:

4
Paso 2: Crear User-Definded Settings

Una vez creadas las Configuraciones, necesitamos setear los valores del entorno que son diferentes en cada uno (tokens, endpoints, etc). Para eso, crearemos un User-defined Build Settings.

En el project build settings, hacer click en el signo más (+) y seleccionar «Add User-Defined Setting».

5

Aparecerá una nueva “User-Defined setting”, entonces actualizamos el nombre, y seteamos un valor apropiado para cada entorno.

6

Finalmente, tenemos diferentes maneras de acceder a esos valores, por ejemplo, podemos agregarlos en el archivo plist de la siguiente manera:

7

Ingresar la variable definida por el usuario como $(NombreVariable) en el archivo .plist, será así reemplazada la variable real durante la pre-compilación para que podamos acceder a la propiedad del plist en el código.

 

Paso 3: Creando Schemes

Ahora, que ya tenemos todas la Configuraciones creadas y sus variables establecidas, deberíamos crear una manera clara de ejecutar cada una. Para eso, crearemos un Schemes para ejecutar la aplicación utilizando cada una de esas configuraciones. Como crearemos nuevos entornos, crearemos también nuevos schemes.

Hacer click en el scheme del proyecto actual, y luego Manage Schemes.

8

9

Hacer click en el signo más (+) y crear cuatro schemes.

10

Una vez que se crean los schemes, deberíamos configurarlos para ejecutar la Configuración adecuada. Entonces seleccionamos el scheme, y hacemos click en la opción “Edit”. Para cada scheme necesitamos configurar qué Configuración debería ser utilizada en cada acción (Run, Test, Profile, Analyze y Archive, la acción Build no tiene configuración). Originalmente, Debug era utilizada en Run, Test y Analyze, mientras que la Release era usada en Profile y Archive, ahora queda a elección del usuario qué configuración debería ser utilizada en cada caso. Personalmente prefiero utilizar la misma en todas las acciones para ese target.

11

Ejemplo de Código

Environments.zip

Referencias

http://www.teratotech.com/blog/xcode-7-steps-to-easily-switch-between-multiple-environments/
http://www.annema.me/configure-your-ios-app-for-multiple-environments
http://www.blackdogfoundry.com/blog/migrating-ios-app-through-multiple-environments/

Adrián Duran

Es desarrollador iOS en intive – FDV desde 2011 y lidera la Brigada de dicha tecnología desde 2014. Es Ingeniero en Computación, graduado en la Universidad de Buenos Aires.

 

 

Deja un comentario