Utilizando "schemes" no projeto iOS

Existem momentos em que trabalhamos com diversas URLs, apontando para diversos ambientes diferentes, trocando configurações, ativando ou desativando recursos, inclusive comentando código, em cada um dos diversos tipos de testes que executamos, quando estamos gerando nossas versões. Podemos simplificar muito esse processo trabalhando com "Schemes".

Quando estamos compilando um aplicativo, o nosso querido Xcode utiliza um esquema de compilação para determinar alguns pontos, como: destinos, detalhes de configuração, ambiente e ações a serem realizadas. Isso é o que chamamos de “Schemes”.

Por padrão já nos é fornecido um esquema para utilizarmos, que podemos personalizá-lo e/ou adicionar quantos novos esquemas quisermos. Contudo, só poderemos utilizar um a cada compilação.

Para encontrá-los, este é o caminho:

Ao selecionar “Manage Schemes…”, você tem acesso ao esquema padrão, que é fornecido no momento da criação de um novo projeto.

Esquema padrão fornecido.

À frente vou te explicar como implementar os Schemes, mas antes precisamos discutir o objetivo deles!

OBJETIVO

Com os esquemas é possível trabalhar de forma direcionada. Um bom exemplo disso seriam as configurações que aplicamos para trabalhar ambientes diferentes; outro exemplo seria uma configuração para rodarmos trechos bem específicos no aplicativo.

Nosso objetivo neste artigo é criar 3 novos esquemas que são: DEVELOPMENT, HOMOLOG e PRODUCTION.

Iremos utilizar também um “pod” chamado NETFOX para consultarmos de forma mais prática os consumos de API’s utilizadas pelo aplicativo.

ESQUEMAS

DEVELOPMENT: Este esquema aponta para o ambiente de desenvolvimento, comumente chamado de ambiente de homologação por desenvolvedores de backend. Ele será nosso DEBUG e terá o NETFOX habilitado.

HOMOLOG: Apontando para o ambiente de produção, este é o nosso RELEASE, porém terá o NETFOX habilitado para realizarmos nossos testes.

PRODUCTION: Apontando para ambiente de produção, também é o nosso RELEASE, porém, como é aqui que geramos nossa compilação para a loja, é estritamente necessário desativar o NETFOX. Se ele estiver ativo, pessoas mal intencionadas podem utilizar dele para obter informações sensíveis do aplicativo.

O ambiente é a Base URL utilizada no consumo da API.

IMPLEMENTAÇÃO

1. Adicionar Configuração

Quando acessamos a raiz do projeto, na aba “Info”, conseguimos visualizar “Configurations”, onde podemos notar a existência de 2 configurações padrão do projeto: a “Debug” e “Release”.

Quando criarmos nossas próprias configurações, iremos duplicar uma delas.

Configurations.

Ao clicar no “+”, nos é dada a opção de duplicar uma das 2 configurações padrão.

Iremos duplicar “Debug” para criar a configuração DEVELOPMENT, duplicar “Release” para criar HOMOLOG e duplicar “Release” novamente para criar PRODUCTION, por fim, podemos remover as configurações criadas por padrão.

Resultado final da adição de configurações.

2. Adicionando Condicionais

Para podermos utilizar o "#if #endif" com as configurações que acabamos de criar, precisamos criar os identificadores dessas condicionais.

Na aba de “Build Settings” podemos encontrar, quase no final, “Swift Compiler - Custom Flags”

“Swift Compiler - Custom Flags”.

Adicionaremos os identificadores para cada uma das configurações que nós criamos.

3. Configurando “Product Bundle Identifier”

Essa configuração eu julgo opcional. Você pode executá-la caso queira que cada esquema gere o seu próprio binário em um local diferente. Dessa forma, ele irá criar um novo ícone apontando para uma das builds que você gerar, DEVELOPMENT, HOMOLOG ou PRODUCTION.

Depois de acessar “Packaging” nos “TARGETS” do projeto, você encontrará o “Product Bundle Identifier”. Ao expandi-lo, você verá que todas as configurações apontam para a padrão do projeto.

Acessando “Packaging” em “TARGETS”.

“Product Bundle Identifier” expandido.

Podemos definir um “bundle” diferentes para DEVELOPMENT e HOMOLOG e a configuração de PRODUCTION no “bundle” padrão.

Resultado final da configuração de “Product Bundle Identifier”.

4. Criação dos “Schemes”

Agora iremos criar os esquemas que utilizarão das configurações que acabamos de criar.

Quando você acessa a gestão de esquemas é possível adicionar, apagar ou simplesmente desabilitar a exibição de um esquema.

Acessando “Manage Schemes…”.

Tela de gestão de esquemas.

Vamos adicionar os esquemas referentes a cada configuração que criamos e excluir o esquema padrão que foi fornecido na criação do projeto.

Ao clicar em “+” é possível adicionar novos esquemas e ao clicar em “-” é possível excluir o esquema selecionado.

Logo depois de criarmos cada esquema é necessário definir, em cada um, o seu “Build Configuration” correspondente a aquela configuração. Essa configuração se repetirá para as seguintes abas: “Run”, “Test”, “Profile”, “Analyze” e “Arquive”.

Ao clicar em “Edit…” você tem acesso a tela de edição do esquema selecionado.

Editando esquema de DEVELOPMENT.

Selecionando configuração de “HOMOLOG” em “Test” para o esquema de HOMOLOG.

Resultado de cada esquema com sua respectiva configuração.

Agora possuímos 3 esquemas que podemos selecionar.

5. Adicionando propriedade de nome dos binários

Neste momento, vamos adicionar uma nova propriedade que irá definir um nome para cada binário do projeto.

Ao clicar em “+” em “Build Settings” é possível adicionar uma propriedade.

Vamos criá-la como “APP_NAME”.

Após criar a nova propriedade, podemos expandi-la e adicionar um nome diferente para cada configuração.

Nomes definidos.

Para que o aplicativo possa utilizar da recém propriedade criada, devemos referenciá-la desta forma: “$APP_NAME”.

Referenciando a propriedade no “Display Name” em “General”.

6. Adicionando a propriedade “BASE_URL”

Esta parte é muito importante, pois aqui definimos a URL Base que cada ambiente irá utilizar. Vamos adicioná-la como uma propriedade, assim como adicionamos o “APP_NAME” no passo anterior.

Logo depois iremos adicioná-la ao “Info.plist” para que possamos acessá-la no código e realizarmos nossas requisições.

Propriedade “BASE_URL” já adicionada.

No “+” é possível adicionar mais uma chave ao “Info.plist”

Chave adicionada ao “Info.plist” e referenciando “BASE_URL” de “Targets” do projeto utilizando o “$BASE_URL”.

Acessando a chave em “Info.plist”.

7. Adicionando ícones para cada “Scheme”

No arquivo de “Assets” nós temos acesso ao “AppIcon”, que nos é fornecido por padrão. Vamos utilizá-lo para representar o “Scheme” de PRODUCTION e criar mais 2 ícones que irão representar os schemes de DEVELOPMENT e HOMOLOG.

“AppIcon” em “Assets”.

Você pode criar um novo ícone a partir do botão direito do mouse.

Vamos adicionar os ícones da seguinte forma: em “AppIcon” que representará o “Scheme” de produção, iremos adicionar o ícone normal, sem alterações.

Para “AppIcon-dev” vamos adicionar uma tarja azul ao ícone e para “AppIcon-homo” uma tarja verde.

Nomenclatura dos ícones.

Para utilizarmos um ícone específico em cada binário, precisamos configurá-lo dentro de “Build Settings”, expandindo a propriedade “Primary App Icon Set Name” e alterando o nome para os respectivos que criamos em “Assets”. Por padrão todos virão como “AppIcon”.

“Primary App Icon Set Name” padrão.

“Primary App Icon Set Name” configurado.

Após a execução do aplicativo nos 3 “Schemes” diferentes, teremos 3 binários diferentes, cada um com seu ícone respectivo.

8. Utilizando NETFOX

No final do processo, veremos como ativar o NETFOX somente para os “Schemes” de DEVELOPMENT e HOMOLOG.

O objetivo é realizarmos consultas e obtermos informação de como estão sendo realizados os consumos de API, tanto em produção como em desenvolvimento (Homologação). Para isso, você já deve ter executado o processo de adição do “pod netfox” ao seu projeto.

A configuração da chamada neste exemplo será realizada no “appDelegate” em “didFinishLaunchingWithOptions” para que ao final do processo de lançamento o aplicativo ative o NETFOX.

Importação do “pod” em “appDelegate”.

Função que inicia o “netfox” somente em “Scheme” de DEVELOPMENT ou HOMOLOG utilizando o “#if” e “#endif” utilizando os identificadores que criamos.

CONCLUSÃO

Depois de realizar todo o processo de implementação, será possível trabalhar de forma mais segura e prática, alternando entre os ambientes e podendo consultar as respostas dos consumos de API.

Com toda certeza você não vai querer enviar uma versão para a loja apontando para o ambiente errado, nem mesmo que o usuário tenha acesso a informações diretas vindas do banco de dados.

Espero ter ajudado e muito obrigado pela atenção.