um pluguinho
Posts tagged xcode
Compartilhando código entre projetos iOS: A solução
Jul 12th
No post anterior apresentei o problema sobre o compartilhamento de código entre projetos iOS, falei das soluções mais utilizadas e seus problemas, também falei da solução usando framework, e acabei falando sobre a pegadinha de que o framework só esta disponível para Mac OS X. Na verdade eu menti (era para o seu bem), essa opção só está disponível (oficialmente) para Mac OS X, podemos fazer para iOS, mas como tudo no iOS: com um certo trabalho.
Vamos a solução, primeiro vamos criar um novo projeto no Xcode, este projeto deve ser do tipo “iOS > Framework & Library > Cocoa Touch Static”:
Defina um nome para seu framework:
Obs: atenção a esse nome, no final vamos ter é alguma coisa como: [nome-do-projeto].framework.
Vamos adicionar aqui um código de exemplo:
Uma vez com um código de exemplo ou o código que você queira compartilha adicionado, já podemos compilar e verificar se tudo esta indo bem. Se tudo estiver certo vamos passar ao passo seguinte que é montar o framework. Para isso vamos adicionar um novo target do tipo: “iOS > Other > Aggregate”:
Vou dar o nome de “iOS-Framework”, mas você pode escolher o nome que lhe convier:
Agora precisamos adicionar 3 entradas na aba “Build Settings” desse target:
As entradas são as seguintes:
# Set in Build Settings
PRODUCT_NAME = ${PROJECT_NAME}
STATIC_TARGET_NAME = ${PRODUCT_NAME}
FRAMEWORK_DIR = ${PROJECT_DIR}/${PRODUCT_NAME}.framework
PRODUCT_NAME = ${PROJECT_NAME}
STATIC_TARGET_NAME = ${PRODUCT_NAME}
FRAMEWORK_DIR = ${PROJECT_DIR}/${PRODUCT_NAME}.framework
Lembra que falei que o resultado final do projeto é algo como [nome-do-projeto].framework? Pois bem, será assim se você seguir os valores que sugeri para essas entradas, evidente que você pode variar de acordo com o que lhe convier.
Na sequência vamos para aba “Build Phases”, e adicionamos duas fases do tipo “Run Scripts” e uma do tipo “Copy Files”, a baixo dou exemplo de nomes que você pode dar a essas fases:
Para primeira fase, no exemplo a fase “Build architecture-specific static libs”, que será responsável por compilar o código nas duas arquiteturas: x386 e ARM, Simulador e Device respectivamente vamos definir o seguinte script:
xcodebuild -project ${PROJECT_NAME}.xcodeproj -sdk iphonesimulator -target ${STATIC_TARGET_NAME} -configuration ${CONFIGURATION} clean build SYMROOT=${SYMROOT}
xcodebuild -project ${PROJECT_NAME}.xcodeproj -sdk iphoneos -target ${STATIC_TARGET_NAME} -configuration ${CONFIGURATION} clean build SYMROOT=${SYMROOT}
xcodebuild -project ${PROJECT_NAME}.xcodeproj -sdk iphoneos -target ${STATIC_TARGET_NAME} -configuration ${CONFIGURATION} clean build SYMROOT=${SYMROOT}
Já para segunda fase, a “Build framework package”, que vai montar a pasta do framework usando os arquivos compilados com o script anterior, vamos definir o script:
# Variables
LIBRARY_NAME_PATH="lib${STATIC_TARGET_NAME}.a" &&
DEVICE_LIBRARY_PATH="${BUILD_DIR}/${CONFIGURATION}-iphoneos/${LIBRARY_NAME_PATH}" &&
SIMULATOR_LIBRARY_PATH="${BUILD_DIR}/${CONFIGURATION}-iphonesimulator/${LIBRARY_NAME_PATH}" &&
UNIVERSAL_LIBRARY_PATH="${FRAMEWORK_DIR}/Versions/A/${PRODUCT_NAME}"
# Create framework directory structure.
rm -rf "${FRAMEWORK_DIR}" &&
mkdir -p "${FRAMEWORK_DIR}/Versions/A/Headers" &&
mkdir -p "${FRAMEWORK_DIR}/Versions/A/Resources" &&
# Generate universal binary from desktop, device, and simulator builds.
lipo "${SIMULATOR_LIBRARY_PATH}" "${DEVICE_LIBRARY_PATH}" -create -output "${UNIVERSAL_LIBRARY_PATH}" &&
# Move files to appropriate locations in framework paths.
cd "${FRAMEWORK_DIR}/Versions" &&
ln -s "A" "Current" &&
cd "${FRAMEWORK_DIR}" &&
ln -s "Versions/Current/Headers" "Headers" &&
ln -s "Versions/Current/Resources" "Resources" &&
ln -s "Versions/Current/${PRODUCT_NAME}" "${PRODUCT_NAME}"
LIBRARY_NAME_PATH="lib${STATIC_TARGET_NAME}.a" &&
DEVICE_LIBRARY_PATH="${BUILD_DIR}/${CONFIGURATION}-iphoneos/${LIBRARY_NAME_PATH}" &&
SIMULATOR_LIBRARY_PATH="${BUILD_DIR}/${CONFIGURATION}-iphonesimulator/${LIBRARY_NAME_PATH}" &&
UNIVERSAL_LIBRARY_PATH="${FRAMEWORK_DIR}/Versions/A/${PRODUCT_NAME}"
# Create framework directory structure.
rm -rf "${FRAMEWORK_DIR}" &&
mkdir -p "${FRAMEWORK_DIR}/Versions/A/Headers" &&
mkdir -p "${FRAMEWORK_DIR}/Versions/A/Resources" &&
# Generate universal binary from desktop, device, and simulator builds.
lipo "${SIMULATOR_LIBRARY_PATH}" "${DEVICE_LIBRARY_PATH}" -create -output "${UNIVERSAL_LIBRARY_PATH}" &&
# Move files to appropriate locations in framework paths.
cd "${FRAMEWORK_DIR}/Versions" &&
ln -s "A" "Current" &&
cd "${FRAMEWORK_DIR}" &&
ln -s "Versions/Current/Headers" "Headers" &&
ln -s "Versions/Current/Resources" "Resources" &&
ln -s "Versions/Current/${PRODUCT_NAME}" "${PRODUCT_NAME}"
Escolhendo o target “iOS-Framework” e compilando já devemos obter uma pasta [nome-do-projeto].framework nas pasta do projeto, isso é o suficiente para termos uma framework que pode ser usando em outro projeto, mas apenas bibliotecas estáticas não compõe um framework, um dos pontos principais de um framework são os arquivos de cabeçalho, os famosos .h. Precisamos copiar os arquivos .h para pasta “Headers”, para isso vamos usar a ultima fase que adicionamos ao target:
Neste ponto devemos arrastar os arquivos de cabeçalhos que precisarmos para esta fase. Assim podemos compilar e obter uma pasta .framework que podemos utilizar em qualquer projeto iOS. Mas como usar este framework?
O processo é bem parecido com adicionar um framework oficial, a diferença é que devemos procurar pela pasta .framework no lugar de escolher uma da lista:
Observe que no exemplo eu arrastei o MyFramework.framework para o grupo Frameworks, para uma melhor organização do código. Se você tiver interesse em ver como ficou esse projeto de exemplo pode baixa-lo aqui.
Update: Ficou faltando alguma referência ne?
Referência 1: Eu cheguei a escrever um artigo antes desse falando de um metodo que usava target do tipo “Mac Framework”, mas como não funcionou com o Device, e era bem complexo quando comparado a essa solução, resolvi mudar a abordagem, mas se tiver interesse nessa solução de uma olhada neste post.
Referência 2: A solução que descrevi aqui não veio do nada, na verdade ela é uma simplificação e um roteiro para solução que o pessoal do Pivotal Labs utilizou na criação do Framework Cedar, um framework de testes que vale dar uma olhada, e quem sabe um post 
Compartilhando código entre projetos iOS: O problema
Jul 6th
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.
