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é +

Iniciando a série de artigo técnicos sobre o iPhone, queria começar pelo último problema que enfrentamos no nosso projeto: tradução de arquivos xib.

Para quem ainda não começou a mexer no SDK do iPhone, eu com certeza estou falando grego, mas prometo que em breve trataremos outros assuntos mais básicos sobre o mesmo. Sendo assim... esse artigo fica como referência para aqueles que se aventurarem pelo mesmo caminho no futuro.

Bom, o desafio era pegar um arquivo MainWindow.xib, p. ex. e fazer uma tradução para o Inglês. O modo chato é fácil:

1. No XCode, selecione o MainWindow.xib, e execute Command-i;
2. Clique em Make File Localizable - será criada uma versão do arquivo em inglês;
3. Na aba General, Add Localization;
4. Nomeie como Portuguese.

Pronto, o XCode fez o seguinte: copiou seu MainWindow.xib para a pasta English.lproj e apagou o original da pasta raiz; depois fez outra cópia para a pasta Portuguese.lproj.

Com isso, basta você abrir o arquivo que desejar modificar a linguagem e alterar todas as strings na munheca.

Tosco, não? Afinal, qualquer modificação que quiser fazer no layout, você terá de lembrar de reproduzí-la em todas as linguas disponíveis. Ai, ai....

Procurando uma alternativa com um potencial menos explosivo, encontramos a primeira referência a partir da API dentro do próprio XCode: Preparing Your Nib Files for Localization - (precisa ter login no ADC da Apple pra acessar esse artigo). A segunda foi pelo Google, chegando ao Internationalization with Cocoa.

Incompetência nossa ou não, não conseguimos executar os comandos com sucesso. Em ambos os casos terminamos com o erro:

Invalid stringsfile. The keypath "com.apple.ibtool.document.localizable-strings" could not be parsed.

Fomos para casa dormir e no dia seguinte, surgiu a resposta: Localizing Your Nib File’s Content.

Assumindo que seu xib está em português, faça o seguinte:

1. repita os passos lá de cima;
2. entre na pasta Portuguese.lproj e gere o arquivo de strings do seu Xib original
   ibtool MainWindow.xib --generate-stringsfile MainWindow.strings
3. copie o arquivo .strings para a pasta English.lproj e faça as traduções;
4. gere o arquivo xib em inglês a partir do xib em português e do arquivo traduzido
   ibtool Portuguese.lproj/MainWindow.xib --strings-file English.lproj/MainWindow.strings --write English.lproj/MainWindow.xib

Qual a diferença agora? Qualquer alteração no layout de um xib não precisa mais ser refeita nos outros correspondentes. Basta rodar o segundo comando acima para propagar as mudanças. E se o número de xib's crescer, prepare um batch com o comando moficado de acordo com cada xib. Assim, você poderá rodar sempre e garantir que seus xibs estão sempre atualizados.

Em breve, voltamos com mais dicas para o iPhone.