No nosso projeto, precisamos comprar um iPhone para, obviamente, fazer os testes da aplicação. O nosso cliente optou por comprar um iPhone pré-pago da Tim. Como um de nossos colaboradores possuía um chip da Oi com plano de dados ilimitado, gostaríamos de poder utilizá-lo já que a nossa aplicação realiza conexões de rede para se comunicar com um servidor. Partimos então para tentar o desbloqueio.

Jailbreak não rola
Claro que a primeira opção que veio a mente foi a utilização do jailbreak para liberar o iPhone, mas num projeto como o nosso essa não é uma opção interessante, pois queríamos que o nosso iPhone fosse o mais próximo possível do aparelho usado em produção e ainda haveria o envolvimento de uma operadora no projeto.

Munidos do nosso direito de consumidor garantido pela Anatel, fomos à Tim pedir o desbloqueio do iPhone. Na primeira loja que fomos, o vendedor disse que não faziam o desbloqueio, mas como eles não eram loja própria da Tim, sugeriram que nos informássemos melhor em uma destas.

Fomos à loja própria da Tim e, para nossa felicidade, eles faziam o desbloqueio lá \o/!! Contudo, o desbloqueio levaria 5 dias úteis e eles aplicam uma multa decrescente a cada mês após a compra. Funciona assim: se você desbloquear o iPhone, ou qualquer aparelho, no primeiro mês, pagará R$72,00, e a cada mês pagará R$6,00 a menos até um ano que é quando a multa chega a zero.

Antes de decidir pelo desbloqueio, tentamos a Oi, que anuncia desbloquear o aparelho de qualquer operadora, mas eles disseram que no iPhone eles não mexiam. :( Decidimos pela Tim.

Desbloqueio da Tim

Você leva o seu iPhone com a nota fiscal à Tim e eles abrem um protocolo. No caso do pré-pago, basta possuir créditos suficientes para pagar o valor da rescisão no momento em que o desbloqueio for efetuado - normalmente 5 dias úteis após a abertura do protocolo.

Infelizmente, o processo de desbloqueio do iPhone ainda não está bem estabelecido entre os funcionários da Tim, o que gerou uma série de confusões e, para resumir, foram necessárias 3 idas à loja e 3 protocolos diferentes.

O pulo do gato
O problema nos 2 protocolos anteriores é que não sabiam/explicaram como nós deveríamos proceder para concluir o desbloqueio. Apenas informaram que receberíamos uma ligação ou uma mensagem informando que o desbloqueio estaria concluído e os créditos seriam consumidos. Mas o tempo passava e nada acontecia.

Apenas no último protocolo recebemos a bendita ligação que explicava como deveríamos proceder:

1. Troque o chip do iPhone
2. Conecte ele no seu micro e abra o iTunes
3. Tente acessar a internet
4. (esse é por nossa conta) repita os 2 últimos passos até conseguir.

Depois de plugar e desplugar o cabo usb 2 vezes, de repente apareceu o nome "Oi" no status bar e tudo deu certo.

Só uma curiosidade: os créditos do chip da Tim, até o momento da escrita deste artigo, ainda não haviam sido descontados :D

Até a próxima.

Conforme comentamos aqui, a RIM, fabricante do Blackberry, terá sua própria loja de aplicativos. A novidade é que recentemente ela acaba de permitir aos desenvolvedores de todo o mundo que submetam suas aplicações à sua loja que está prestes a ser lançada.

A RIM, para quem não sabe, ocupa hoje o segundo lugar no mercado de smartphones, logo atrás da Nokia. E além disso, também lançou recentemente o Blackberry Storm, que pretende ser mais um concorrente do iPhone. Isso tudo representa um grande e potencial mercado a ser explorado pelos desenvolvedores. =)

Inté.

Apesar da Apple acabar de anunciar na sua página principal do site que mais de 500.000.000 de apps já foram baixadas, ela continua dificultando quem quer entrar e disponibilizar seus aplicativos na App Store. Sabemos disso, pois nós da Mobits estamos passando por este problema.

Há mais ou menos 1 mês e meio, fizemos o nosso primeiro contato com a Apple para ter a licença da App Store, já que tínhamos e temos várias idéias para colocar no ar. Após alguns dias, recebemos um contato deles para disponibilizar o pagamento. Até aí tudo bem, a novela começou depois disso. Até agora estamos esperando um contato da área financeira da Apple para confirmar o pagamento, pois depois de inúmeros e-mails e telefonemas, descobrimos que não há nenhum problema com os dados enviados.

Se alguém passou ou estiver passando pelo mesmo problema, por favor, comentem. Aceitamos sugestões para terminar essa novela.

Infelizmente estamos com esta dificuldade de obter a licença, porém isso não nos desanima, pelo contrário, estamos com várias idéias e aplicativos no forno prontos para entrarem na App Store. Aguardem e confiem!

Este é um assunto que aprendi a dar valor no meu último projeto antes da Mobits e que consegui trazer para o nosso projeto atual por causa da sua importância para o desenvolvimento de um software de qualidade: os Testes Unitários.

Não vou me alongar sobre os benefícios do TDD (Test Driven Development), pois acho que há muita referência na internet e quem já experimentou sabe de como esse método contribui para um código limpo, bem organizado e com maior resistência a falhas.

Vamos direto ao assunto, então.

Ruby to the rescue

Logo na minha primeira busca, fiquei muito feliz de descobrir que um dos mestres do mundo digital o Dr. Nic já havia tido a bondade de contribuir com um projeto que permite escrever testes em Ruby para suas classes ObjectiveC. Não perdi tempo e comecei a fuçar a novidade.

Utilizei o framework por algum tempo, contudo comecei a querer fazer alguns testes mais complexos e incluir alguns frameworks novos - p. ex. ActiveRecord para iPhone que já comentamos. E, por causa dessa necessidade, os testes passaram a não funcionar como eu gostaria. Gastei um bom tempo tentando editar o próprio framework de teste para me atender, mas foi em vão.

Resumindo, os testes em Ruby são excelentes para o aprendizado, para realizar testes simples sobre classes NSObject, mas começam a complicar a medida que você testa coisas mais complexas.

Ok, voltando ao Objective C

Desmotivado, sem vontade de cantar uma bela canção, resolvi buscar alternativas dentro do mundo ObjectiveC e encontrei o framework de testes do GTM - Google Toolbox for Mac. Com esse framework consegui testar tudo que precisava e pude continuar a tocar o projeto com os queridos testes.

Para usar o GTM no seu projeto faça o seguinte:

1. Baixe o GTM e extraia para uma pasta qualquer ;
2. No seu projeto no XCode, crie um novo iPhone Target (Cocoa Touch Application) via Project > New Target... e nomeie como algo como Testes Unitarios ;
3. Modifique o Active Target para o novo target;
   
   
4. Crie um novo grupo GTM na raiz do seu projeto;
5. Adicione os seguintes arquivos ao grupo (garantindo que estejam associados somente ao target de testes):
   • google-toolbox-for-mac/UnitTesting/GTMIPhoneUnitTestMain.m
   • google-toolbox-for-mac/UnitTesting/GTMIPhoneUnitTestDelegate.m
   • google-toolbox-for-mac/UnitTesting/GTMIPhoneUnitTestDelegate.h
   • google-toolbox-for-mac/UnitTesting/GTMSenTestCase.m
   • google-toolbox-for-mac/UnitTesting/GTMSenTestCase.h
   • google-toolbox-for-mac/GTMDefines.h
   
   
   
6. adicione uma build phase ao seu target do tipo run script atraves do menu Project > New Build Phase > New Run Script Build Phase. Arraste para o fim das atividades do seu target se for necessário;
   
   
7. Duplo-clique nessa nova build phase para editar. Defina o shell como "/bin/sh" e o script como "CAMINHO_GTM_NA_SUA_MAQUINA/UnitTesting/RunIPhoneUnitTest.sh";
   
   
8. Execute o Build - não Build and Go. Abra o Build Results (command+shift+B) para ver o resultado dos testes.
   

Escrevendo os testes

Para organizar, crie uma pasta para seus testes (ex. Testes :P) e adicione ao projeto. Cada classe do projeto que você quiser testar, basta adicionar seu arquivo .m* ao target de teste (ele passará a estar associado aos dois targets) e criar uma classe de teste correspondente, convencionada como *NomeDaClasseTestadaTest.m - embora este formato não seja obrigatório.

Uma sugestão para facilitar a manipulação dos testes, é manter a @interface e @implementation no mesmo arquivo .m, ou seja, dispensando o arquivo .h das classes de teste.

Todos os métodos que serão executados como teste, devem iniciar por test e não precisam ser declarados na interface. O método setUp pode ser sobrescrito e será executado sempre antes de cada método de teste. O mesmo ocorrerá com o método tearDown no final de cada teste.

Quando escrever o teste, você poderá utilizar os asserts que o GTM lhe provê: todos estão definidos começando com STAssert... e se encontram no GTMSenTestCase.h. A qualquer momento, rode o Build e verifique os erros. Note que cada erro sempre aparece duplicado.

Considerações

Se estiver usando controle de versão, talvez seja interessante que os arquivos do GTM estejam dentro da pasta do seu projeto. Não há a necessidade de copiar a pasta inteira, somente os arquivos que citei acima, preservando a estrutura de diretórios.

Existem outros recursos que precisei desenvolver ou obter para atender minhas necessidades como uma imitação de test fixtures para controlar meu banco de testes e uma biblioteca de mock para abstrair algumas dependências a classes mais complexas. Pretendo abordar o uso destes em futuros posts.

Se o simulador do iPhone estiver aberto durante os testes, dá um erro esquisitão. Verifique sempre que ele esteja fechado.

Bom Desenvolvimento Orientado a Testes para todos e até a próxima!

Mapeamento Objeto Relacional (ORM) é a técnica de desenvolvimento utilizada para representar as tabelas de um banco de dados relacional em classes e objetos em linguagens orientadas a objetos. Os objetos são persistidos no banco relacional sem a necessidade da utilização de SQL, que é utilizada apenas para consultas mais complexas.

A plataforma de desenvolvimento do iPhone não possui nenhuma solução nativa para ORM, contudo, existem alguns frameworks desenvolvidos por terceiros e disponíveis na internet que podem conectar os objetos na linguagem Objective-c com o banco de dados SQLite do iPhone. No nosso projeto estamos utilizando o Active Record.

O Active Record é um padrão muito utilizado no Ruby on rails. Para utilizá-lo no iPhone, é preciso baixar o código no site do projeto e incluí-lo na sua aplicação. Depois siga o passo a passo a seguir:

• Crie um banco de dados com o sqlite3, como o abaixo:

  CREATE TABLE alunos
     (
     id  integer primary key,
     nome varchar(255),
     inscricao varchar(255)
     );

• Arraste o banco para o seu projeto e o coloque no grupo Resources

• Desenvolva uma classe no seu projeto, como a seguinte:

    @interface Aluno : ARBase {}

    @property (readwrite,assign) NSString *nome, *inscricao;

    @end

    @implementation Aluno

    @dynamic nome,inscricao;

    @end

Todas as classes que serão mapeadas devem herdar de ARBase. Como podemos perceber, o nome da tabela é sempre o nome da classe em minúsculo e no plural. Esse padrão é utilizado pelo Active Record para relacionar a tabela com a classe. Se o nome de sua tabela estiver em português e o plural for diferente do gerado pelo Active Record, sobrescreva o método de classe tableName na classe a ser mapeada e retorne o nome da tabela.

• Escreva o código para manipular as classes, como o seguinte:

for (Aluno *aluno in [Aluno findAll]) {

  NSLog(@"Nome:%@; Inscrição: %@",aluno.nome,aluno.inscricao);

}

As classes sempre são persistidas no banco. Quando você cria uma nova instância de aluno, o Active Record criará um registro na tabela aluno automaticamente. Isso às vezes é ruim, pois não é possível utilizar objetos não persistidos, como na API JPA do Java. Utilize VOs para fazer isso.

Um dos principais problemas que notamos no Active Record foi a sua lentidão. Quando testamos o nosso sistema no SDK, estava tudo ótimo, mas quando testamos no iPod Touch, percebemos que o programa demorava bastante para exibir listas de objetos persistidos e seus atributos.

Fuçando o código-fonte, percebemos que o mecanismo do Active Record funciona da seguinte maneira: primeiro ele obtém os ids de todos os objetos que queremos exibir, depois a cada vez que queremos buscar um atributo no banco, ele faz uma consulta SQL e obtém o atributo individual. Para exibir o resultado do código acima, se tivermos 10 alunos no banco, ele fará 21 consultas SQL, 1 para obter os IDs, 10 para obter o nome dos alunos e 10 para obter as inscrições. Na verdade, só precisamos de uma consulta e é o que eu sugiro que deva ser feito para casos muito grandes: utilizem consultas SQL ao invés da busca do Active Record.

Uma coisa que ajuda no desempenho é o uso do cache, que mantém o resultado das consultas em memória para evitar outras consultas ao banco.

Mas apesar das desvantagens, o Active Record ainda traz muitos ganhos ao mapear objetos, relacionamentos e automatizar toda a parte de conexões com o banco. Contudo, ele ainda tem que evoluir muito. Outra opção para o Active Record é o sqlitepersistentobjects. Eu ainda não testei, mas pretendo fazê-lo em breve, pois tenho lido boas impressões sobre ele. Quando eu testar, postarei no blog.

Até +