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

Com o anúncio feito em novembro de uma distribuição Linux rodando no iPhone, diversas possibilidades foram levantadas, mesmo que ainda no campo das hipóteses.

iPhone Linux Demonstration Video from planetbeing on Vimeo.

A mais discutida é a questão do Android. A discussão, vista em alguns comentários no Engadget Mobile, surge principalmente por conta das dificuldades iniciais para se programar em Objective-C. Isso sem contar a preferência natural de muitos desenvolvedores por padrões abertos open-source.

A questão levantada é: uma vez lançada uma versão estável do kernel 2.6 para iPhone, quão complicado seria permitir que programas fossem criados em Android e funcionassem? Para muitos, a parte mais complexa seria obter acesso ao hardware do aparelho. Se isso for possível, o próximo passo seria mais fácil: criar profiles de hardware para a linguagem.

A questão comercial também é outro ponto de discussão: qual seria a legalidade da venda de aplicativos distribuídos para essa distribuição, rodando no iPhone? E toda a possibilidade de softwares gratuitos que podem ser disponibilizados? Poderia isso chegar a um ponto de afetar a venda de aplicativos no Appstore?

Muito há de se discutir, mas, por hora, tudo na base da especulação. Há de se esperar por versões finais, onde todos os recursos do iPhone consigam ser utilizados, se é que serão. Nesse último caso, todas as discussões aqui não caberiam mais. Porém, creio que isso ainda dará assunto para muitos outros posts, e estaremos aqui para analisar mais e mais as possibilidades.

Parece que a onda de ter sua própria loja de aplicativos está pegando. Depois da criação e sucesso da App Store da Apple, outros peixes grandes também embarcaram nessa idéia: o Google (com o seu Android Market) e a Research In Motion (com o novo BlackBerry Application Center). Sem contar a Microsoft que já anunciou que irá lançar a sua loja também com possível nome de Sky Market.

Agora, recentemente, a Palm entrou na jogada, lançando a Palm Software Store. Ela foi fruto de uma parceria realizada entre a empresa e o PocketGear, que é um distribuidor renomado, tendo desenvolvido mais de 50 mil aplicativos para smartphones. O acesso à loja de aplicativos é feito através de um aplicativo instalado no dispositivo, que possui versão para Palm OS e para Windows Mobile.

Com algumas diferenças no tipo de abordagem, a verdade é que ter uma loja de aplicativos representa ter uma maior visibilidade entre os consumidores e claro um grande negócio. Prova disso, é que até 1º de dezembro já haviam sido baixados mais de 300 milhões de aplicativos da App Store. Além disso, a Apple afirmou em seu resultado trimestral que a média de faturamento com a loja foi de US$1 milhão por dia.

Boas notícias os desenvolvedores e consumidores, pois uma loja de aplicativos representa um fácil acesso entre os consumidores finais e as aplicações. =)

Inté!

Se os amantes do iPhone achavam que a Nokia ficaria para trás só observando o sucesso da Apple, estavam muito enganados. No dia 02 de dezembro, a Nokia anunciou o lançamento de seu novo aparelho: Nokia N97.

Mas o que ele faz?

• Tela widescreen (16:9) com resolução maior que a do iPhone (640 x 360 contra 480 x 320);
• Câmera digital com mais megapixels (5 no Nokia, 2 no iPhone);
• Capacidade de fazer videochamadas em 3G e gravar filmes em qualidade VGA (640 x 480, igual ao N96);
• Possui 32 GB de armazenamento, expansível até 48 GB com o uso de cartões de memória (8 GB / 16 GB internos no iPhone);
• Permite enviar e receber mensagens multimídia e a troca de arquivos via Bluetooth (inexistente no iPhone);
• Recurso de copiar e colar texto, uma reclamação constante dos donos de iPhone;
• Teclado QWERTY embutido, não virtual, bastando deslizar para usá-lo, deixando-o numa posição parecida com a de um notebook;
• Além de todas as funcionalidades já conhecidas de seus antecessores.

E o iPhone?

A Nokia parece ter aprimorado bastante a interface sensível ao toque (touchscreen), porém essa é uma área em que o iPhone se destaca. Pelo menos o N97 não vem (aparentemente) com uma caneta stylus ou uma palheta para toque na tela, mas não tem suporte a múltiplos toques na tela como o iPhone.

E quem ganha no final?

Nós. Porque enquanto eles brigam para desenvolverem produtos cada vez melhores, nós só ficamos de espectador brincando com essas maravilhas! Bom proveito!

A Sun lançou a primeira versão do Java FX (finalmente \0/). Esta plataforma visa a construção de conteúdos mais ricos para a web e também para o celular. As funcionalidades da versão 1.0 são:

• Ambiente de implantação e de desenvolvimento, incluindo suporte e compilador para a linguagem FX Script;
• Ferramentas gráficas, de multimídia, WebServices e diversas bibliotecas;
• Suporte no NetBeans 6.5;
• JavaFX ProductionSuite;
• JavaFX Desktop Runtime - para rodar no desktop;
• JavaFX Mobile Runtime - este ainda em fase de teste.

A principal vantagem da plataforma, de acordo com a Sun, é que com ela é possível criar aplicações com interface rica e interativa para desktops, para a web e para celulares com exatamente as mesmas linhas de código.

Para utilizar o JavaFX, será preciso atualizar a versão do java SDK para a versão 6 update 11 nesse link e depois baixar o NetBeans 6.5 com suporte ao JavaFX nesse link.

Para mais informações sobre o JavaFX, acesse o blog do Java FX. Para começar a aprender, acesse o guia inicial e o tutorial.

Estamos particularmente interessados no suporte a dispositivos móveis. Será que a Sun vai finalmente entrar com uma plataforma de peso para concorrer diretamente com os grandes players (Symbian, iPhone, etc) que vêm tirando espaço e destaque da plataforma Java ME? Só o futuro dirá...

A Apple acaba de lançar a versão 2.2 do seu sistema operacional para o iPhone, conhecido como firmware. Esta versão pode ser baixada pelo iTunes.

De acordo com o Blog do iPhone, as principais funcionalidades são:

Mapas:

• Google Street View
• Itinerários para pedestres e transporte público
• Exibição do endereço de alfinetes fixados
• possibilidade de compartilhar as localizações através de email

Mail:

• solucionados problemas isolados relacionados à obtenção programada de emails
• formatação aprimorada de emails HTML extensos

Geral:

• estabilidade e desempenho melhorados no Safari
• downloads de podcasts (via wi-fi e rede celular)
• diminuição das falhas na configuração de ligações e nas quedas de ligações
• melhoria da qualidade de som nas mensagens do visual voicemail
• ao pressionar o botão de Início (home) em qualquer tela de início você será levado à primeira página
• preferência para ativar ou desativar a auto-correção de texto

Ainda não foi desta vez que a Apple trouxe as funcionalidades mais esperadas, como o copiar e colar, o GPS turn-by-turn e o MMS, mas continuamos a espera destas funcionalidades. Acesse este link para saber mais sobre a atualização.

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.

Tenho lido os artigos do blog Mobideia: Idéias, Mobilidade & Convergência, onde o autor (Marcel) tem feito análises muito interessantes das diversas plataformas de desenvolvimento para dispositivos móveis. Os posts abaixo são análises das plataformas JavaME e PyS60:

Análise JavaME

Análise PyS60

Como este é o primeiro post deste blog e pretendemos falar, entre outras coisas, da plataforma de desenvolvimento para o iPhone, vou aproveitar a deixa do Marcel e fazer uma análise desta plataforma, assim os leitores leigos serão introduzidos à tecnologia (que era minha idéia inicial) e ainda poderão compará-la com as outras plataformas, descritas nos links acima.

Tecnologia: iPhone SDK

Prós:

• Facilidade de projetar a interface: A ferramenta Interface Builder facilita muito a criação de interfaces no iPhone. É igual em VB, só arrastar os componentes para a tela e ela está pronta. Isso também é facilitado pois já sabemos as dimensões do dispositivo ao implementar a interface (não temos que implementar algo genérico que funcione em diversas telas).
• Facilidade de manipular o Hardware do aparelho: Como toda linguagem nativa, o iPhone SDK permite acesso aos mais variados recursos do iPhone, como o acelerômetro, Multitouch, GPS, conexão WI-Fi e 3G. Diferente de JavaME, que tínhamos problemas ao acessar estes recursos, no iPhone tudo funciona perfeito e condiz com o emulador.
• Possibilidade de desenvolver para a AppStore: A venda de aplicativos diretamente para o cliente na AppStore vem seduzindo diversos desenvolvedores, não só pela facilidade que a Apple provê em vendê-los sem muito trabalho, mas também porque o público que tem um iPhone é de alta renda e, de acordo com pesquisas, é o que mais investe em tecnologia.
• Ambiente integrado: O ambiente de desenvolvimento é muito bom. Possui ferramentas para testar o sistema no emulador, para efetuar testes de desempenho, de alocação de memória, entre outras coisas.

Contras:

• Customização da interface: Se desenvolver a interface é fácil, customizá-la não é. Mudar a cor de um componente ou o fundo até vai, mas quando queremos componentes diferentes dos que a Apple nos provê aí o bicho pega, é complicado criar componentes personalizados. E a quantidade de componentes padrão também é pequena, o resultado: muitos aplicativos com a mesma interface.
• Linguagem Objective C: Para desenvolver para iPhone, temos que nos submeter a Apple e utilizar sua linguagem no seu SDK. Coloco a linguagem aqui como uma desvantagem pois não é uma linguagem conhecida, sua sintaxe é complicada e não existe um mecanismo próprio de gerência de memória (o desenvolvedor deve alocar e desalocar cada objeto). Mesmo que a linguagem fosse simples, acredito que uma plataforma deva permitir o desenvolvimento através de diversas linguagens, como Ruby, Java, Python ou qualquer outra, o que não é o caso do iPhone SDK.
• Dificuldades de obtenção de tutoriais e suporte: Até pouco tempo atrás, a Apple impedia a comunicação entre os desenvolvedores e que eles publicassem o código das suas aplicações, mesmo após a liberação ainda é muito complicado achar códigos prontos na internet com soluções para os problemas mais básicos já que a comunidade ainda está amadurecendo.
• É preciso ter um Mac: Pra galera que não tem um Mac, a má notícia é que para desenvolver para esta plataforma é preciso ter um. O SDK do iPhone não roda em outra plataforma. É até possível tentar instalar um "hackintosh" em um PC normal, mas pra isso será preciso quebrar muito a cabeça e depois ter que se adaptar a um sistema operacional totalmente diferente, onde até o copiar e colar não é Ctrl+C, Ctrl+V e sim command+C e command+V - pra quem não sabe o command fica no lugar do alt (isso confunde pacas).
• Submissão a Apple: Para desenvolver um aplicativo que possa ter instalado no iPhone é preciso ter um contrato com a Apple, e tem que pagar. Isso restringe um pouco que os aventureiros desenvolvam nessa plataforma e torna os testes em dispositivos reais mais complicados.