O celular nunca mudou tanto desde sua invenção quanto mudou com a chegada da banda larga. Com sua história recente mais relacionada com Internet as coisas acontecem mais ou menos da mesma maneira: o custo de desenvolvimento, promoção e distribuição fica cada vez mais barato, permitindo a criação de aplicativos por mais pessoas.

Como vemos atualmente, 3 novas “grandes” plataformas estão sendo construídas: iPhone OS, Android, webOS. Todas são plataformas já consideradas sucedidas e apesar de dizerem que já fechou a conta e o futuro é iPhone, Android e WebOS eu acho que em breve outras também adotarão uma interface boa o suficiente combinada com o WebKit (touch é o grande trunfo do iPhone, Androids e webOS).

Então o mercado está aquecido. Isso é verdade?

As empresas que se arriscaram a construir essas plataformas conseguiram uma base instalada absurda em pouco tempo.

Em novos mercados a concorrência é baixa e a audiência de cada “player” é alta. Por isso muitos estão ganhando com publicidade em apps com baixa qualidade no iPhone. Também por isso outros estão ganhando com apps de boa qualidade em plataformas mais novas…

No último ano coloquei aplicações na iTunes Store e na Palm Pre Store e venho tentando tanto o modelo de publicidade quanto apps pagas.

Eu não ganho muito. Principalmente devido ao fato do AdMob ser um sistema quebrado. Mas pretendo ganhar um pouco e por isso acho interessante tornar a brincadeira um pouco mais seria: criei a página da doin apps. Não é nada muito serio (por enquanto fazemos somente nossas apps), mas também sem deixar o profissionalismo de lado.

Logo mais o Mikael faz uma logo E a gente coloca um site no ar…

Valeu

Um dia o Mafra mandou um e-mail interessante. O plano era ficar milionário com um aplicativo de iPhone. Eu não tinha o aparelho e também não fazia parte do Apple Developer Program.

No Simulador comecei a fazer algumas brincadeiras com PhoneGap que poderiam um dia se tornar o aplicativo pronto. Não me preocupei com o problema que o PhoneGap enfrentou na App Store e continuei implementando o que precisava em JavaScript.

Quando implementei em JS uma copia do componente de DatePicker da SDK do iPhone ficou claro que eu teria que deixar o PhoneGap de lado e me apoiar em algo mais robusto.

O Cocoa tem suas peculiaridades mas depois que se aprende a ler e brincar com o Objective-C nos exemplos da Apple, tudo fica mais fácil.

Minha App se tornou um frankenstein. Em partes roda no WebKit (HTML/CSS/JS) e onde algo se move rápido na tela usa as animações da SDK.

Mas não é só na velocidade que o desenvolvimento com PhoneGap pode limitar o que o aplicativo pode fazer. Fazer requisições HTTP é complicado com as restrições impostas no navegador com o sentido de evitar cross-domain HTTP.

Código Objective-C pode ser usado para permitir chamadas em funções da SDK via JavaScript. Na verdade para mim é isso que resume o PhoneGap.

AlarmGame

O aplicativo tinha poucas funções programadas e não tinha nome definido ainda quando o @laka começou a desenhar e a criar o visual para ele. Foi nesse dia que fiz a inscrição para o concurso ARENA INFO. Concorreríamos na categoria iPhone. O premio: R$1000 para os primeiros de cada categoria e uma viagem a NY + U$2000 para o primeiro geral.

Em vez de tentar vender um aplicativo que não funciona*, tentei ir para NY na faixa.
Não deu certo. O aplicativo não foi classificado para a última fase de concurso.

Não vou ficar milionário nem ir para NY, mas fico feliz se você baixar o aplicativo.

Na próxima versão vou apostar no Admob.

*A SDK do iPhone não tem uma API de Alarm como o Palm Pre tem, fazendo com que para usar o despertador o aplicativo não possa ser fechado.

Eu precisava de uma maneira de exibir um conteúdo na tela do iPhone/Touch sempre do mesmo tamanho, independente do zoom usado no navegador (Safari/Webkit).

Então pesquisei algumas propriedades da tela e cheguei ao JavaScript que pode ser visto em ação aqui: iPhone Viewport/Zoom Test.

No aparelho ou no simulador tente dar zoom na imagem e você vai perceber que ela continuara do mesmo tamanho na tela.

Ninjas JS: fiquem a vontade para ganhar dinheiro a partir desse exemplo.

Ter uma tabela de referências em mãos, com as funções disponíveis na linguagem de programação ou framework que você está utilizando ajuda muito.

Manter essa tabela sempre aberta, e não em outra aba do navegador também é um bom truque, que evita o desvio de atenção.

A Colorcharge preparou uma versão especial para iPhone da documentação do jQuery. Com o nome de jTouch o projeto deixa as funções e formas de uso do jQuery na ponta do dedo (aha).

Quem não possui o aparelho da Apple, pode também imprimir uma versão pronta para o formato A4. Check this out.

Na última semana reuni vários novos skills de desenvolvimento para iPhone. Não foi fácil. O pessoal que desenvolve para a plataforma parece que não curte muito compartilhar o que sabe… foda…

Seguindo a dica do @evertonfraga fui dar uma brincada com um plugin do jQuery que facilita a diversão com as funções de touch (touchstart, touchend, touchmove) e com a API de gestures (gesturestart, gesturechange, gestureend): jQuery Touch.

O problema é que versão original tem algumas cagadas jumentais.

O cara chamava N! vezes a função $() do jQuery e isso deixava o Safari puto (digo, muito lento).

Uma das utilizades da “função $()” do jQuery é buscar um elemento na página.

Na mais rápida das hipóteses, a busca pode ser feita pelo id, tipo $(’#content’), o que vai encadear uma chamada ao método document.getElementById(’content’) do navegador.

No WebKit/Safari essa função é bem rápida e chamar ela em um computador normal não deve deixar nada lento, mas meu amigo, no iPhone é outra história.

Arrumei rapidinho e agora tudo roda mais suave. Com o tempo devem surgir mais melhoras, mas você já pode se divertir também:

Baixe minha versão
Veja aqui como faz para usar isso

Acabei de terminar minha primeira aplicação nativa para iPhone.

Eu já havia falado anteriormente sobre o PhoneGap, o maravilhoso framework que permite ao desenvolvedor utilizar JavaScript para desenvolver aplicações instaláveis no iPod Touch e iPhone. Apesar do PhoneGap ainda não permitir a execução de aplicações mais serias e não ter acesso a todos recursos do aparelho, é possivel rodar aplicações simples como a que criei:

Assim que minha conta como desenvolvedor Apple for aprovada, vou disponibilizar a aplicação na Apple Store e posto o link aqui.

E ah! Durante a semana pode ser que eu caia um pouco para Objective-C, assine o RSS e acompanhe

Comecei a estudar desenvolvimento para mobile recentemente. O iPhone me abriu os olhos para o que vai acontecer na industria nos próximos anos.

O jornal só morreu de verdade nesse ano. Mesmo com aumento de banda na Internet (muitas vezes gratuito por parte da operadora), no Brasil (onde não temos o Hulu) não pode se dizer que a TV está morta. Assim sendo, eu não vou dizer que a industria mobile matou toda industria de computadores pessoais. Mesmo a última sendo, tecnicamente, do século passado, ela definitivamente ainda não morreu.

Espero poder falar mais sobre o mercado na ressaca desse natal, onde tem netbook sendo vendido por 800 reais e onde todo mundo vai sair com um celular mais avançado.

Sobre desenvolvimento, tenho ouvido muitas pessoas falarem do PhoneGap. Ele é um framework para desenvolvimento no iPhone escrito em Objective-C e que usa o engine WebKit (o mesmo que o navegador Safari usa).

PhoneGap iPhone Framework Demo from Jeff McFadden on Vimeo.

Toda conversa que rolou em volta da velocidade do JavaScript nos navegadores agora parece fazer bastante sentido.

O iPhone não é um aparelho esbanjando capacidade como um computador normal. A diferença em capacidade de processamento entre ele e os computadores atuais é abismal.

Não seria possível rodar JavaScript em um equipamento como o iPhone se não fossem feitas melhorias nos interpretadores de JavaScript. Assim como a Mozilla o pessoal responsável pelo WebKit também apresentaram um navegador de primeira.

Nos próximos dias vou brincar bastante com as possibilidades. Uma linguagem script como JavaScript, um framework como o jQuery, um acelerômetro, tela multi touch, câmera e GPS: diversão.

Saiba mais

Código que permite produção de aplicativos para iPhone OS com JavaScript na mira da Apple

O desenvolvimento do AlarmGame – Um jogo despertador

Sabe como é. Sou solteiro, moro em São Paulo e trabalho em uma startup. O que eu iria fazer depois de um dia puxado no trabalho?
Comecei a trabalhar em cima de uma versão enxuta do jQuery para rodar somente no Safari (focando o iPhone) as 10 da noite. O checkout no repositório do jQuery demorou um pouco, mas logo eu já estava com a versão mais atual e com o mais importante: os testes.

A missão era retirar toda e qualquer gambiarra do código do framework responsáveis por faze-lo passar nos testes em todos navegadores, deixando somente o que seria executado no Safari (WebKit).

Eu nunca havia trabalhado em um ambiente 100% coberto por testes. Foi bem mais fácil cumprir a missão coberto por testes. Enquanto fui retirando os browsers sniffings rodava os testes para saber se estava no caminho certo.

No final não sobrou nenhum browser sniffing no jQuery (mas eu deixei o objeto $.browser lá para quem precisar).

Aproveitei e alterei para as buscas por $(’#id’) usarem a função “document.querySelector” que é uma implementação do CSS3 Selectors da W3C. De qualquer forma isso foi mais uma brincadeira do que algo para aumentar a performance.

Antes de substituir o mecanismo de busca do jQuery para usar as funções de busca que WebKit e Firefox agora implementam, perguntei ao John Resig sobre. Segundo ele a próxima versão do jQuery vai contar com um novo seletor que saberá quando usar os métodos nativos.

Agora eu tenho essa versão do jQuery sob medida para o Safari. A diminuição no tamanho do arquivo foi minima e quem usar essa versão deve ter ganho em processamento muito pequeno (sim, estou desmotivando as pessoas a usarem). O que valeu foi o aprendizado, e agora eu sei alguns dos planos do John.

Quando o novo jQuery sair a intenção vai ser deixar somente a parte que utiliza esses métodos, esquecendo os navegadores que não implementam. Como o alvo é o Safari do iPhone, nenhum problema

O que torna ruim o desenvolvimento para mobiles hoje é a falta de padrões existentes nos navegadores.

O uso de técnicas avançadas que poderiam permitir uma melhor utilização da plataforma, da momentaneidade e da mobilidade é praticamente impossível uma vez que o acesso aos recursos do aparelho variam dependendo do fabricante e nem todos navegadores seguem padrões da industria.

Provavelmente a maior dificuldade na área é a existência de arquiteturas de hardware diferentes e também o problema de consumo de bateria.

Isso faz com que existam barreiras no desenvolvimento de navegadores que impedem a implementação de certas normas da W3C por exemplo. As grandes lutam próximos da W3C para definirem da melhor forma possivel esses padrões, mas mesmo assim, nem tudo sai como deveria.

As mentes que trabalham em empresas como Google e Mozilla não conseguem esperar que tal tecnologia seja debatida para se tornar um padrão. Eles simplesmente vão lá e implementam.

Os navegadores para Web atuais possuem centenas de características que para serem exploradas estão somente esperando a definição como padrão.

Firefox 3.0, Safari, Chrome e todos que utilizam das mais atuais ferramentas disponiveis, incluem mais ou menos a seguinte lista de “inovações” esperando para virarem tecnologias de larga adoção:

• JavaScript com seletores
• CSS3
• SQLite para armazenamento client-side (substitui os cookies)
• SVG para vetores
• Canvas

A maioria dos itens estão nas especificações do HTML 5.

iPhone

Para felicidade de todos, o WebKit (motor de renderização do Safari) já possui a maioria deles e até vai além em alguns itens, permitindo por exemplo o uso de animações com CSS.

Ok, mas se eu disse que o problema para se desenvolver em mobile é justamente a falta de padrões. Por que o suporte a um monte de coisa que ninguém mais suporta como existe no iPhone não é problema?

A plataforma do iPhone é muito melhor que a plataforma oferecida pelos outros celulares. O maior problema da entrada do iPhone em um mercado como o brasileiro é o preço, que fica elevado até para parte da classe média.

Lá fora, pela quantidade de vendas e tendencia em continuar vendendo milhões de unidades, a Apple sabe que a briga por enquanto não tem a ver com o navegador. A briga que a Apple quer travar é para ver quem vai ter a plataforma mobile com maior mercado. E para isso ela vai usar manhãs como por exemplo permitir uma experiência mais ricas nos sites e aplicações desenvolvidos para iPhone implementando inovações no WebKit.

Se a maçã ganhar, teremos algo parecido com o que ocorre com o Windows e Internet Explorer: a grande adoção do Windows é responsável pela distribuição do Internet Explorer.
Pelo menos ao contrario do que acontece com o caso do Windows, temos agora um excelente navegador que pode se tornar o líder na plataforma mobile.

Enquanto ela sai na frente podemos desenvolver nossos sites somente para iPhone, utilizando a mesma característica de cobrir os custos entregando uma experiência mais rica a cada usuário.

Eu também já postei sobre o que é possivel fazer com CSS no Safari

O pessoal da Apple que trabalha no projeto do WebKit vem fazendo um ótimo trabalho nos últimos dois anos. Na véspera de lançamento do iPhone a equipe apresentou o mais avançado navegador da atualidade. A quantidade de padrões da W3C implementados e as possibilidades que temos para desenvolvimento no iPhone são enormes.

Atualmente algumas técnicas permitem a site desenvolvidos para iPhone o acesso ao acelerômetro.

É uma pena que o acesso não é o mesmo possivel com aplicações escritas em Objective-C.

Inspirado por esses avanços do CSS3, principalmente quanto o uso da função “transition”, eu criei o “Safari haz CSS Superpower“. A página tem a intenção de me ajudar a acompanhar o que acontece no desenvolvimento do WebKit (nome do engine do Safari), o navegador mais avançado do momento.

Para visualizar a página é necessário abrir no navegador Safari

Sombras e bordas também são cortesias do CSS3.

Safari haz CSS Superpower.

Como foi lembrado pelo @laka, o Chrome também usa WebKit