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

Acabei de instalar o Fluid para o OS X. Mesmo já tendo ouvido falar antes nunca dei atenção para o poder dele.

A principio parece que ele vai somente adicionar aqueles iconezinhos chatos na Dock, você acha que isso vai atrapalhar sua produtividade e fecha o site.

Nós estamos na cloud. Temos aplicações reais que ficam o dia inteiro abertas nos computadores, como Gmail, Google Docs, os outros do Google e até mesmo o Campfire (muito comum nos Estados Unidos). O problema é que até mesmo o Firefox sofre com um pouco de instabilidade ao rodar serviços pesados como esses.

Para começar o Fluid é inspirado no Prism do Mozilla Labs e tudo que é inspirado em algum produto do Mozilla Labs merece meu respeito.

Ele inclui scripting (no estilo do Greasemonkey), ícones para a Dock, integração com Quicksilver, notificações no Glow, uma API de Javascript no estilo do Greasemonkey (esqueça extensões para Firefox, elas são muito chatas difíceis de fazer), algumas integrações com as características do sistema operacional como “drag and drop” (apesar que na minha opinião essas características muito dependentes de sistema devessem fazer parte de plug-ins), separa cada “Aplicação” em um processo diferente e faz muito bem o trabalho para que a falha em um aplicativo não atrapalhe outro.

A diferença básica que encontrei entre ele e o Chrome é que o Fluid prefere não utilizar abas para navegação. Ainda estou em dúvida se foram as características melhores ou se foi a interface diferenciada que fizeram a diferença positiva no meu uso. De qualquer forma, com processos separados ou não, a escolha do usuário fica com a melhor interface.

O Chrome foi um grande sucesso de lançamento do Google e assim que o pessoal voltar a ler o que ele faz com certeza irão começar a usa-lo. Algumas melhoras na interface podem ajuda-lo a conquistar espaço entre o usuário comum (que ainda pode estar chocado com a aparência muito igual ao Firefox e diferente ao Internet Explorer). Estou definindo usuário comum como o cara que usa Windows XP rodando Internet Explorer, ok?

Enquanto isso o pessoal do Fluid saiu na frente entregando um produto que utiliza da interface gráfica do OS X (Cocoa) para entregar algo competente igual o Chrome. Se eles se empenharem em produzir um produto de qualidade para o Windows, tenho certeza que podem concorrer com o navegador do Google na próxima geração dos browsers. Vale a pena testar, mesmo.