Olá, sou Sanya - desenvolvedor de iOS e, neste artigo, compartilharei meu caminho para solucionar a dor de cabeça que ocorre ao trabalhar em um projeto com vários destinos.
Prevejo a pergunta "por que você precisa de vários alvos no projeto, Sanya?" Eu respondo: no projeto em que trabalhei, havia um alvo vinculado à conta do cliente, de modo que:
- não tivemos acesso a esta conta;
- não havia possibilidade de gerar perfis de provisão e certificados de distribuição;
- a pior parte era que não era possível adicionar novos dispositivos aos perfis de provisão.
Assim, ao comprar novos dispositivos no estúdio, toda uma série de negociações com o lado do cliente estava esperando por nós para adicioná-los à conta e ter a oportunidade de testá-los.
A solução foi óbvia - criar um segundo destino, que será semelhante ao principal, mas tenha um ID de pacote diferente e que estará completamente e completamente vinculado à nossa conta do estúdio. Mal disse o que fez! O segundo objetivo nos permitiu realizar um desenvolvimento completo, independentemente dos desenvolvedores do lado do cliente, o que salvou o processo de desenvolvimento mais de uma vez, por exemplo, quando os desenvolvedores do cliente removeram todos os nossos dispositivos no perfil de fornecimento do alvo principal e não pudemos executar o aplicativo em seus dispositivos.
Vários destinos ainda podem aparecer no seu projeto quando necessário, por exemplo:
- Colete vários aplicativos de uma base de código, mas com recursos diferentes;
- Mantenha várias instâncias do aplicativo em um dispositivo.
Mas o trabalho em vários destinos leva a seus inconvenientes, o principal é a necessidade de controlar rigorosamente o processo de adição de novos arquivos ao projeto. Os dois são idênticos, respectivamente, ao adicionar um novo arquivo ao projeto, é necessário colocar uma marca na frente dos dois destinos.
Isso é muito difícil quando se trabalha em uma grande equipe multinível, tanto em habilidade quanto em boa fé.
Se você não seguir esta regra simples, após a próxima mesclagem, poderá descobrir que um dos alvos parou de colecionar e o Xcode jura que não consegue encontrar uma ou outra classe. Mas o mais interessante é que, se alguém não incluiu um arquivo de Copy Bundle Resources nos dois destinos (por exemplo, células xib), você poderá encontrar apenas esse erro no tempo de execução.
Após outro problema com o destino de depuração, decidimos dar controle sobre a consistência dos destinos de script. Escolhemos a linguagem Ruby como uma ferramenta, pois ela possui uma excelente jóia xcodeproj , que é quase o padrão para ferramentas de escrita para o desenvolvimento do iOS (consulte fastlane, generamba etc.).
Como resultado, desenvolvemos um script que implementa a seguinte lógica de trabalho:
- o caminho para o arquivo do projeto e os nomes dos destinos testados são alimentados na entrada;
- no caminho para o projeto, o script encontra o próprio projeto;
- seleciona os destinos desejados, coleta arquivos deles (fontes de compilação, recursos do pacote de cópias e estruturas);
- procurando a diferença entre listas de arquivos;
- jogamos arquivos da nossa lista de permissões fora dessa diferença. Por exemplo, arquivos com constantes que diferem dependendo do destino (baseUrl, se você decidir organizar o projeto para que aplicativos de destinos diferentes acessem servidores diferentes) ou arquivos GoogleService-Info.plist, que serão diferentes para destinos diferentes.
Se o script encontrar uma diferença, temos um problema. Isso significa que este ou aquele arquivo / estrutura foi adicionado a um destino, mas não adicionado a outro.
Assim, o script permite:
- verifique se todos os arquivos do Compile Sources e Copy Bundle Resources foram adicionados corretamente aos dois destinos;
- a identidade das listas de estruturas adicionadas também é verificada, o que é muito importante se o seu projeto tiver arquitetura com vários módulos;
- a integração do script na fase de criação permitirá identificar o problema antes mesmo da fase de criação do projeto;
- e se anteriormente você coletou os dois destinos no IC para isso, agora você pode deixar o assembly para apenas um, reduzindo o tempo de montagem no IC pela metade.
Em caso de erro, no Xcode, você pode observar a seguinte mensagem:
Em caso de sucesso, você encontrará unicórnios:
Instruções detalhadas para adicionar ao projeto, configurações, bem como Exemplo de projeto no repositório .
O utilitário resultante mostra perfeitamente que, mesmo como desenvolvedor iOS, você pode criar um pequeno pedaço de criatividade no seu trabalho diário e automatizar e criar scripts que simplificarão sua vida!
Obrigado pela atenção!