Éverton Antônio

Uma das coisas que mais incomoda no desenvolvimento para iOS é a falta de um suporte (decente) ao compartilhamento de código entre projetos.

Na maior parte dos casos tem se optato por três soluções: “copiar o código”, “biblioteca estática” e “projeto dependente”, no primeiro caso você faz uma copia do código que vai reutilizar e adiciona este código no projeto onde quer reutilizar, este é um método ruim, primeiro porque você vai ter que acertar as dependências desse código, adicionando frameworks indiretos (que o código compartilhado utiliza, mas seu projeto não), depois você tem que definir informações sobre compilação, flags e variáveis.

Outro efeito colateral é na hora de compilar, dependendo do tamanho do código adicionado você pode perder tempo de compilação considerável, principalmente se você precisar limpar constantemente a compilação. Por ultimo mas não menos importante, aumenta-se em muito o gral de complexidade na manutenção do código compartilhado, você vai ter que ficar copiando código de um lado para outro quando houver atualizações, além de que se tivermos testes (eu recomendo) a coisa pode ficar ainda mais complicada.

A segunda alternativa é a “biblioteca estática”, talvez a melhor dentre as atuais opções. Nesta opção você cria um projeto que tem como target gerar uma lib static, um .a, que deve ser adicionado como dependência de linkagem ao projeto final. O bom dessa opção é que além de ser suportada oficialmente pelo SDK, você pode criar um projeto separada para conte-la, o que facilita sua manutenção. Mas ela sofre de dois problemas chatos, primeiro você tem que administrar os “headers” manualmente, copiando de um projeto para o outro, e definindo os “path load” dos arquivos “headers”, o que recai sobre os problemas na opção anterior.

Depois temos um outro um outro problema, a compilação tem como resultado .a’s para diferentes arquiteturas, acabamos com um .a para o simulador (i386) e um .a para o device (arm), o que nos obriga a juntar esses arquivos com uma ferramenta como “lipo”, um utilitário de linha de comando que junta binários de diferente arquiteturas, claro, isso se quisermos algo mais útil.

O esquema de “projeto dependente” é uma complemento da solução anterior, você cria um projeto de biblioteca estática depois arrasta este projeto para dentro do outro projeto, configura o target dependente, seta o produto desse target como dependência de linkagem do target do seu projeto, e acaba com um projeto mega confuso e difícil de manter . Eu nunca consegui usar isso de forma prática, primeiro que o Xcode se perde com os arquivos de cabeçalho, com os targets e outras coisas malucas que só o Xcode faz por você, depois essa solução gera um projeto final complicado de entender, se forem muitas as dependências você acaba com um monte de projeto dentro do outro, e se estes projetos não estiverem no mesmo diretório (o que pode ser inviável se você mantém os projetos em diferentes controls de versão) você acaba com projeto todo quebrado, que vai demandar mais atenção de terceiros e sua na hora de dar manutenção.

Mas então o que fazer? Surge então os framework. Mas o que vem a ser frameworks? Pela definição da Apple: “A framework is a dynamic (loaded only when used) shared library along with its associated resource information. This information is packaged as a bundle. This is analogous to the shared libraries, which are placed in the Extensions folder in Mac OS 9.”. Em termos gerais é a forma pela qual você pode re-utilizar partes dos seus projetos em outros projetos em ambientes de desenvolvimento da Apple, tanto o SDK para Mac OS X como para iOS contam com alguns frameworks fornecidos pela Apple, que estão longe de cobrir todas as necessidades, principalmente de projetos mais complexos. O que leva aos desenvolvedores a criar seus próprios frameworks.

Mas, eis que surge a pegadinha, atualmente (minha esperança é que isso mude), você só pode escrever seu próprio framework para Mac OS X, e não para iOS. O que é uma verdadeira chatice, por falta de um termo melhor. Isso além de dificultar a organização de projetos dependentes, dificulta em muito disseminação de código Open Source pelo ecossistema iOS.

Bom essa foi uma introdução ao problema, nó próximo post vamos ver como resolver esse problema, e começar a compartilha códigos de uma forma mais prática.