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:

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:

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:

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

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.

Uma coisa que tem aumentando muito por aqui são aplicações rack, sejam projetos em andamento, sejam apps de teste para as mais diversas gemas que aparecem por esse mundão do ruby, sempre preciso levantar uma app para testá-la e quase sempre isso quer dizer levantar uma app rack.

Não que digitar um comando como rackup, padrino start, rake start ou similares sejam a morte, mas eu acabo perdendo um tempinho gerenciando o que esta ou não em pé. Sem contar que na hora de acessar, o historico do browser acaba virando uma zona: http://localhost:3000, http://localhost:4567, http://localhost:9000 e por ai vai, acabo perdendo um pouco de comodidade que o Chrome oferece na busca de urls já acessadas. Evidente que existe a opção de adicionar uma host no /etc/host, mas mesmo isso acaba não sendo prático de manter.

Então surge o Pow, o Pow é uma aplicação escrita pelo Ryan McGeary, que tem como objetivo ser um zeroconf rack server para Mac OS X, voltado exclusivamente ao ambiente de desenvolvimento. Como ele suporta rack apps, consequentemente suporta Rails apps.

Como toda ferramenta zero-conf, a instalação e configuração do Pow é muito simples:

$ curl get.pow.cx | sh

Em algum momento ele vai pedir a senha do root para fazer configurações de firewall (ele redireciona fluxo da porta 80 da sua máquina para porta 20559 do Pow), e vai criar uma symlink no seu home: ~/.pow.

Agora basta criar um symlink para sua aplicação dentro dessa pasta, e configuração já esta pronta:

$ ln -s ~/Projects/myapp ~/.pow/myapp

Acessando http://myapp.dev o Pow vai reconhecer o virtual host e automaticamente levantar a aplicação, se depois de 15 minutos a aplicação não tiver mais acessos o Pow dece a aplicação e continua aguardando conexões. Aqui uma dica: no Chrome digitar apenas myapp.dev não funciona, ele não identifica isso como um host e acaba indo parar na busca, o http:// se faz necessário (pelo menos no chrome dev foi assim).

Alguns features interessantes:

• Auto refresh: Pelo menos aqui no testes com uma aplicação padrino (preciso falar um pouco mais sobre padrino), ele fez refresh dos meus controllers e models automaticamente, acredito que isso funcione também no Rails, vai depender mais de como o framework é desenvolvido;
• Suporte a rvm: Por padrão ele procura pelo seguintes arquivos na pasta da aplicação: .powrc, .powenv ou .rvmrc, o que acaba sendo uma mão na roda se você utiliza .rvm;
• Suporte a variáveis de ambiente: no arquivo .powenv você pode exportar variáveis de ambiente que sua aplicação utilize. Isso tem sido de grande utilidade por aqui, pois permite emular os comportamento de configuração que o Heroku utiliza;
• Subdomínio: Este é um dos pontos fortes na hora de executar testes, facilita bastante poder digitar subdomínios, principalmente quando você esta desenvolvendo aplicações que utilizam subdomínios dinâmicos.
• É mais: Mais detalhes sobre como utilizar e configuras as esta e vários outras opções na página do projeto: Pow

Como sempre o Pow não é a bala de prata, mas é sempre bom poder automatizar tarefas repetitivas, e quando isso envolve pouca configuração ou zero acaba ficando ainda melhor.

Uma das coisas que incomodam no codebase é o editor do wiki, que é bem limitador, para dizer a verdade um textarea sem nenhuma customização e com uma fonte safadinha. Pensando nisso resolvi melhorar um pouquinho o trabalho de editar a wiki e fiz um pequeno script que para facilitar minha vida, e quem sabe a sua.

Usando o elegante editor web: markitUp, criei um projeto no github. No README do projeto existe informações de como utilizar o script no chrome.

Basicamente você vai precisar instalar uma extensão para seu navegador que permita injetar javascript em uma determinada página, como meu navegador principal é chrome, normalmente eu utilizo a extensão “Personalized Web“, ela facilita bastante o trabalho de injetar código javascript ou mesmo css, além de permitir a criação de um match para saber quando o script deve ser executado.

Existem outras extensões, inclusive suporte a isso em outros browsers, no caso do Firefox você pode usar o Greasemonkey, se você souber de outras me mande para que possa listar aqui para ajudar mais gente a utilizar o recurso.

Já faz um tempo que estou aprendendo a desenvolver para iOS. Mas esta foi uma boa oportunidade de colocar em pratica alguns conceitos, principalmente no que tange a desenvolvimento de games, área que estou começando a dar os primeiros passos.

O evento como um todo foi legal, vários jogos criados (cerca de 1500 games criados pelo mundo em 48 horas o.O), muita comida de nerd e uma boa quantidade de refrigerante e cerveja consumida. O calor atrapalhou um pouco mas deu para concentrar e acabamos por conseguir colocar 3 games no ar. Dois para PC e uma para iOS, ainda falta um bom trabalho para que eles se tornem jogáveis, mas esperem um pouco e teremos novidades sobre isso.

E por falar em novidade, em breve devo liberar alguns novos post que estou escrevendo sobre desenvolvimento para iOS. Foram 6 meses de desenvolvimento de uma app para iOS, muita coisa aprendida, muita dica e ideias a serem transmitidas.

Motivado pelo post anterior acabei lendo um pouco mais a documentação e encontrei uns scriptizinho bem interessante. Como saber rapidamente qual a versão atual da minha VM? Para isso podemos contar com o script ~/.rvm/bin/rvm-prompt, ele pode ser usando adicionando a seguinte linha ao seu .bash_profile:

Com isso ele mostra qual maquina virtual do Ruby você esta usando, mas apenas quando essa for diferente da default. Só isso já seria o suficiente, mas o que me incomoda nesta solução, é que eu já tenho uma linha de comando grande, e nem sempre eu preciso saber qual versão eu estou usando, isso é particularmente interessante quando estou em um projeto Ruby. Como normalmente um projeto Ruby temos um arquivo Rakefile podemos procurar por este arquivo e exibir a versão da máquina apenas quando estivermos no diretório de um projeto Ruby. Vamos adicionar as seguintes linhas ao nosso .bash_profile:

Agora podemos mudar a linha anterior para:

Espero que ajude alguém e qualquer dica que possa melhor é só comentar a baixo.

Mas o que raios é esse RVM? Ruby Version Manager, é basicamente um instalador e gerenciador de máquinas virtuais Ruby, e adicionalmente um gerenciador de sets de gemas. Por baixos dos panos ele é um script bash que troca algumas variáveis de ambiente e permite ter varias versões das máquinas virtuais Ruby (MRI, Jruby, etc) instaladas diretamente na pasta do usuário, dessa forma ele ainda permite um isolamento entre as instalações de VMS dos usuário de uma máquina.

A grande vantagens dele esta em não misturas as coisas de uma VM com a outra, e permite uma rápida troca entra uma VM e outra. A vantagem adicional de gerência sets de gemas é na verdade um grande achado, pois juntas as duas coisas permite criar ambientes isolados por aplicação, e quem trabalha com Ruby sabe como é difícil lidar com o o esquema de gemas, famoso “DLL Hell”.

Mas vamos deixar de conversa e vamos mostrar como usar. A instalação é simples, e feita usando o gem, que no caso de você esta usando Leopard já vai estar instalado:

O segundo comando vai criar a pasta ~/.rvm, é nela que toda a magia acontece, dentre outras coisas dentro dessa pasta esta os scripts que permite o funcionamento do rvm, observe que este comando mostra uma instrução sobre como adicionar o carregamento do RVM no seu bash, isso pode variar dependendo de máquina e SO.

Uma vez que bash esteja configurado, o comando rvm deve estar disponível, sua utilização é simples:

Bom até aqui temos o bem básico, você pode ver mais sobre a instalação e configuração do RVM aqui. Agora vamos a um exemplo de para o esquema de sets de gemas. Vamos criar um set para um blog, típico não

Agora é só criar sets diferentes para suas aplicações e evitar a colisão das malditas gemas. Mas antes disso duas observações importantes: Evite o uso do sudo quando for instalar a gemas dentro de uma das máquinas virtuais, elas podem ate funcionar, mas isso vai fazer com que as gemas sejam instaladas como root e os arquivos dentro de pasta ~/.rvm/** não vão pode ser removidos pelo usuário normalmente.

Outra dica que eu acho importante, mesmo ele permitindo que volte a VM default do sistema, prefira fazer uma instalação limpa dela dentro do rvm, isso permite manter as coisas separadas e facilita na hora de criar um set ou mesmo atualizar sua VM.

Habitualmente tenho uso dois monitores para desenvolver, onde em um eu deixo o autotest rodando e no outro eu vou alterando o código no editor. Um problema é que uma vez salvo o arquivo e o autotest inicie um novo teste acaba misturando visualmente um teste com outro. No mac da para usar o command+k para limpar o boffer do terminal, mas o que não chega a ser uma solução boa, pq acabo perdendo os testes que já se passaram.

Ontem o @jcmlima deu uma idéia: “e se ele limpasse automaticamente”, hoje depois de alguns palpites do @fnando e do @willian acabei achando o um jeito de fazer isso, o esquema é editar seu ~/.autotest ou o .autotest do projeto que você gostaria que tivesse essa funcionalidade e adicionar o código a baixo:

Em resumo o resultado final é que a cada nova rodada de teste ele vai inserir 20 linhas em branco e depois limpar a tela, mas diferente da opção de command+k ele ainda vai permitir que você role a tela e possa ver os testes que se passaram.

O concurso da Intel tinha como objetivo o desenvolvimento de um aplicativo de sua escolha para plataforma móvel batizada de MID, teve inicio no mês de Julho do ano passado. Fiquei sabendo do concurso antes de abrir as inscrições, através do site br-linux.org, mas acabei por esquecer e quase não consegui me cadastrar a tempo de participar da votação popular, para escolha das melhores idéias.

Nesta primeira fase tivemos um probleminha, algum engraçadinho resolveu que iria sair do ultimo lugar e chegar ao primeiro, e em menos de 1 dia tinha mais votos do que o primeiro colocado, depois de alguns protestos através de comentários, o filho da mãe em vez de se retirar da disputa, fez o favor de adicionar votos para outros participantes, você podia escolher 10 idéias que lhe agradasse, com isso gerou-se mais confusão e protestos. Para finalizar a confusão quem estava administrando o site do concurso, se descuidou e a opção de votar ficou aberta além da data limite, o que gerou mais alguns protestos, e por fim a Intel desconsiderou os votos apos a data limite e liberou a classificação final, minha idéia ficou em quinto lugar.

Em um outro post vou dar mais detalhes sobre o que se trata a minha idéia, e também apresentar a primeira versão aberta ao público.

O regulamento previa que os 10 primeiros ganhariam um MID da Intel para desenvolver o aplicativo e apos o envio do beta para a Intel, ganharíamos um Netbook, ambos com processadores Atom. Mas infelizmente pelos entraves da Receita Federal os MID que eram para ter chegado em 30 dias, levaram quase 5 meses para chegar, o que levou a Intel a estender o prazo de entrega dos beta, e também adiar o evento de apresentação dos projetos.

Do dia 31/10 passamos para o dia 31/01 como data limite, o que em termos aumentou em muito o tempo para o desenvolvimento do programa, mas sem o MID de quase nada adiantava este tempo extra. Por volta do dia 15/12 recebemos os “brinquedinhos”, a primeira impressão foi ótima, pelo pacote já deu para perceber que o produto tinha bom acabamento:

Com o aparelho em mãos deu para ter um idéia melhor do que era, do que poderia ser feito, e para dizer a verdade, poderia ter trabalhado no programa a mais tempo, afinal com porta USB host, leitor de Micro SD, teclado slider padrão qwerty, GPS, tela touch, 512MG de RAM, dois SD de 2GB internos, e um processador de Intel Atom de 900Mhz, o AIGO P8860 é um PC em miniatura.

Como o espirito hacker manda mais do juízo, as primeiras semanas foi de hackerismo total, instalações e formatações suscetivas, passando de Ubuntu, Slax, Debian, Arch e chegando ao próprio Moblin, resultados variados, mas em geral agradáveis. Os problemas mais recorrentes ficam por conta da tela touch e do GPS, já a wireless é quase sempre suportada, precisando apenas copiar os Firmwares devidos. A curiosidade fica para a webcam integrada que funcionou em todas as distros sem nenhuma interversão.

Passadas as festividades de fim de ano (lembranças boas da Chapada Diamantina), comecei a trabalhar na aplicação. Entre indas e vindas, pensei em desenvolver em diverso tipos de ambiente:

• Ruby com GTK. Era uma boa opção visto que estou trabalhando com Ruby a mais de um ano e tem sido minha linguagem principal, mas sinceramente o suporte a GTK, ou mesmo QT e outras toolkits gráficas ainda não é lá essas coisas em Ruby, por esse motivo ou outro que eu desconheço as libs e dependências não estão disponíveis facilmente em qualquer ambiente;
• C++ e Clutter. Para quem não conhece o Clutter é um projeto relativamente novo, que ainda não chegou a versão 1.0, sua principal característica e torna fácil lidar com objetos 2D, animações e eventos, criando uma serie de efeitos que lembram interfaces como a do Canola, Iphone, dentre outros. Mas meu conhecimento em C++ não chega ao nível Jedi, talvez um jovem Padawan, o que seria muito complicado com o curto espaço de tempo.
• Algum ambiente RIA. Como programador web a muito anos, eu sempre gostei da idéia de desenvolver aplicações desktop com base em navegador, a facilidade em lidar com HTMl e CSS aliadas ao poder que Javascript, permitem construir aplicações muito ricas em termos de interface. Prova disso é o que a Palm fez com o novo WebOS, um Webkit sobre um kernel linux e temos um ambiente de desenvolvimento relativamente fácil, e principalmente facilmente extensível visualmente

Por fim acabei por escolher a terceira opção, mas ai apareceu um pequeno problema: qual ambiente RIA utilizar? Talvez um dos mais conhecidos ultimamente seja o Adobe AIR, mas seu suporte a Linux ainda é limitado e seu peso era um empecilho grande ao uso do mesmo no MID. Uma alternativa Open Source é o Titanium, um projeto bem interessante que juta vários outros projetos, como Google Gears, Webkit, Rake, JazzRecord, dentre outros e criam um ambiente de desenvolvimento muito bom. Mas a versão para Linux ainda esta no campos das promessas, e apesar das minhas tentativas (foram varias) não conseguir obter uma ambiente, mesmo que beta, no qual pudesse trabalhar.

Bom só me restou uma saída, trabalhar no meu próprio ambiente RIA, nasce então o Eibox, meu primeiro framework público. A principal idéia por trás do Eibox é criar um framework Python, compatível tanto com desktops quanto com aparelhos móveis. Sei que o projeto é ousado, e vou precisar de muita colaboração para conseguir este feito, mas com a primeira versão do podMobile em funcionamento acredito que sera combustível o suficiente para que outras pessoas possam contribuir.

No momento o Eibox esta construído sobre Python e Qt4, a QT entra na joga para fazer a ponte entre o Python e Webkit, ao mesmo tempo que fornece uma rica biblioteca que pode ser utilizada para completar a aplicação. Mas existe um porem nisso, a QT por mais leve que seja, adiciona peso extra ao ambiente, e limita o Eibox ás plataformas em que a QT esteja disponível. Para ter acesso ao código fonte do Eibox basta acessar o repositório do podMobile.

Deixando o Eibox de lado, conseguir fazer a aplicação funcional, pelo menos o suficiente para apresentar no evento. A baixo você pode conferir o vídeo da apresentação da minha aplicação e tirar suas próprias conclusões:

A decisão do vencedor ficou a cargo de uma bancada formada pela Intel, e um voto do público do evento. Infelizmente minha aplicação parece não ter agradado os jurados, ou seria o fato de dar palpite de mais nas outras apresentações (eu e minha boca grande). Mas em fim o fato de que o publico escolheu com 37% dos votos a minha aplicação me deixou muito feliz. Evidentemente que vencer o concurso era o objetivo maior, mas o retorno dado pelas pessoas foi muito gratificante, vários me procuram depois da apresentação para parabenizar pela idéia e pelo framework.

Bom é isso, e a quem interesse, o Eibox vai continuar em desenvolvimento e tenho muitos planos para ele, em breve devo postar mais algumas coisas falando do que fiz e sobre o futuro do mesmo, quero melhorar bem o código, e levar o framework para outras plataformas.

A versão anterior era bem engessada, e muitas das vezes lenta, complicando na hora de lembrar onde estava cada uma das funções, é na seção Traversing ou na Manipulation? E fim esta nova versão facilita em muito achar as coisas, afinal a API do Jquery não é o que se pode dizer de padrão, resultado de uma abordagem um pouco diferente da usada pelo Prototype, por exemplo, que acaba por confundir quem esta vindo de outros frameworks.