Para quem trabalha com desenvolvimento web em mobiles, já deve ter notado quanto tempo se perde em ter um ambiente de testes, muitas vezes temos que colocar o aparelho dentro da rede local e algumas empresas acham que o celular pessoal do desenvolvedor vem no pacote de desenvolvimento.
Tirando esses fatos corporativos e de falta de noção para com a realidade, o processo de testes dentro dos aplicativos normalmente é afetado pelos emuladores, que muitas vezes apenas simulam o tamanho de tela. Mas como saber se o resultado esperado será o mesmo no produto final?
Recentemente a Adobe publicou um prodto novo no Labs (http://labs.adobe.com), o Shadow, com certeza um nome novo será dado a ele, mas o importante mesmo é o que o programa se dispoém a fazer.
A instalação é dependente de três etapas, uma instalação no desktop, uma instalação no brwoser e um App no smartphone. Ná instalação desktop, processo normal NNF para windows e Mac. No browser, a instalação de uma extenção para o Google Chrome é necessária e só funciona nele. No smartphone você precisa ter um IOS ou um Android.
O que eu achei mais legal é o fato de você usar o navegador normalmente, ir alternando abas e o conteudo ser atualizado em tempo real, ou seja a emulação é quase perfeita, só faltando o teste final no navegador do aparelho para garantir que no final de tudo certo.
Ficou curioso? então da uma olhada e teste você mesmo.
http://labs.adobe.com/downloads/shadow.html
Mostrando postagens com marcador HTML 5. Mostrar todas as postagens
Mostrando postagens com marcador HTML 5. Mostrar todas as postagens
segunda-feira, 26 de março de 2012
sábado, 17 de dezembro de 2011
HTML 5, Flash, Flex, Air e Outras Drogras - Parte 2
No post anterior falei um pouco sobre essa guerra de flash, flex, air, html 5 e outras drogas que o mercado está nos impondo e empurrando garganta abaixo.
Mundo Desktop
Deixando o universo Mobile, temos o mundo dos desktops, onde passamos muito tempo no trabalho, escola, cursos e até em casa. É um mundo dominado pelas telas grandes, muita memória e espaço em disco. Com isso o flash player passa a ser quase que imperativo nesse mundo chegando a 99% das maquinas em todo mundo. A utilização dele é algo que em alguns casos chega a ser imperceptível, mas ele esta lá.
Ao contrário do mundo Mobile o Flash é o manda-chuva
dos plugins para desktop. O legal é que se formos observar o nosso
desktop é cheio desses plugins, são os plugins de audio, video, o
flash, o java, aquele que você usa para organizar o desktop e por ai
vai. Esse carinha a Adobe não deu para o pessoal do Apache, porém libera
o fonte para projetos voltados a novas distribuições, assim como
acontece com o plugin do Java.
O pessoal fanático por HTML 5 diz que o flash vai morrer, será? Para algumas coisas com certeza, principalmente para aquelas constrangedoras, como um banner rotator que não mostra os banners, ou uma propaganda do silverlight feita em flash.
A verdade dos fatos é que morrer é muito definitivo e o HTML 5 teria que se tornar um padrão real antes de mais nada. Como assim um padrão? O HTML 5 esta no W3C como um RASCUNHO de Projeto http://dev.w3.org/html5/spec/Overview.html e para ajudar as grandes novidades que ele oferece ainda não são suportadas 100% pelos principais navegadores do mercado exemplos disso podem ser vistos e testados em http://html5demos.com/.
Com base nisso existem alguns detalhes de mercado, onde você faz o seu banner? Em um plugin que está em 99% das maqunas no mundo ou em um padrão que está em cerca de 30% dos navegadores e nem todos esses 30% implementão o que você usa?
Não estuo dizendo para ignorarem o HTML5, ele é legal porém lembre-se que o usuário do seu site pode ainda estar rodando um windows XP com internet explorer 6, então a utilização desse recurso deve ser dosada e tratada para cada situação. Da mesma forma que não se deve fazer um site 100% em flash, não se deve fazer um site 100% em HTML 5, a dosagem depende de muitos fatores.
Nesse intervalo do primeiro post para este realizei vários testes para ter base no que estou falando. O HTML 5 não tem condições para competir com o Flash Player. Vamos aos fatos!
Uma das ferramentas em HTML mais usadas no mundo se chama GMail, e se engana quem pensa que essa maravilha do HTML é feita com HTML 5. O GMail trabalha com FRAMES, como mostra a imagem a seguir.
Para piorar as coisas para o lado do HTML 5 essa mesma maravilha tem uma função, que eu particularmente acho muito legal, que é o upload assincrono de arquivos, aquele recurso onde você seleciona o arquivo e ele vai sendo enviado enquanto você digita seu e-mail com direito até a barra de progresso, HTML 5? Não mesmo dessa vez é Flash Player, o mesmo que os adoradores do apocalipse dizem que vai morrer em 21/12/2012... Ops essa é outra história... quiz dizer os adoradores do HTML 5 dizem que vai morrer, mais uma vez, imagem na tela.
Então onde o HTML 5 se aplica? Onde o Flash não se aplica? O HTML 5 se aplica aos novos sites que focam em smartphones, tablet e novas versões dos navegadores. O flash se aplica a todo o resto, porém com doses de sabedoria.
Não se deve fazer um site 100% em flash, se eu quero acessar seu site do meu smartphone, posso ter que parar numa lanhouse por falta do plugin do flash, mas com certeza não ver o banner do seu site no meu smartphone seria muito bom.
Eu particularmente, tenho usado o flash player no backend dos sistemas atraves do Flex e Air, funciona muito bem e como o blackend é algo que me obriga a conhecer os usuários, eu posso falar "atualiza o plugin do flash" caso algo não funcione, porém em um site fica dificil ligar ou mandar um e-mail para alguém que eu nem sei quem é.
Resumo da ópera? O Flash Player tem mais chances de se tornar o novo HTML do que o HTML 5 se tornar um padrão real e funcional em todos os navegadores. Enquanto esse dia não chega a melhor opção se chama JQuery e HTML5 Fix.
O JQuery é um conjunto de códigos javascript que cria um novo padrão resolvendo problemas de compatibilidade entre navegadores e tem até uma versão mobile.
O HTML Fix é um projeto que esta hospedado no google e visa em fazer funcionar de forma padronizada as tags e atributos do HTML 5 que muitos navegadores não suportam.
Mundo Desktop
Deixando o universo Mobile, temos o mundo dos desktops, onde passamos muito tempo no trabalho, escola, cursos e até em casa. É um mundo dominado pelas telas grandes, muita memória e espaço em disco. Com isso o flash player passa a ser quase que imperativo nesse mundo chegando a 99% das maquinas em todo mundo. A utilização dele é algo que em alguns casos chega a ser imperceptível, mas ele esta lá.
O pessoal fanático por HTML 5 diz que o flash vai morrer, será? Para algumas coisas com certeza, principalmente para aquelas constrangedoras, como um banner rotator que não mostra os banners, ou uma propaganda do silverlight feita em flash.
A verdade dos fatos é que morrer é muito definitivo e o HTML 5 teria que se tornar um padrão real antes de mais nada. Como assim um padrão? O HTML 5 esta no W3C como um RASCUNHO de Projeto http://dev.w3.org/html5/spec/Overview.html e para ajudar as grandes novidades que ele oferece ainda não são suportadas 100% pelos principais navegadores do mercado exemplos disso podem ser vistos e testados em http://html5demos.com/.
Com base nisso existem alguns detalhes de mercado, onde você faz o seu banner? Em um plugin que está em 99% das maqunas no mundo ou em um padrão que está em cerca de 30% dos navegadores e nem todos esses 30% implementão o que você usa?
Não estuo dizendo para ignorarem o HTML5, ele é legal porém lembre-se que o usuário do seu site pode ainda estar rodando um windows XP com internet explorer 6, então a utilização desse recurso deve ser dosada e tratada para cada situação. Da mesma forma que não se deve fazer um site 100% em flash, não se deve fazer um site 100% em HTML 5, a dosagem depende de muitos fatores.
Nesse intervalo do primeiro post para este realizei vários testes para ter base no que estou falando. O HTML 5 não tem condições para competir com o Flash Player. Vamos aos fatos!
Uma das ferramentas em HTML mais usadas no mundo se chama GMail, e se engana quem pensa que essa maravilha do HTML é feita com HTML 5. O GMail trabalha com FRAMES, como mostra a imagem a seguir.
Para piorar as coisas para o lado do HTML 5 essa mesma maravilha tem uma função, que eu particularmente acho muito legal, que é o upload assincrono de arquivos, aquele recurso onde você seleciona o arquivo e ele vai sendo enviado enquanto você digita seu e-mail com direito até a barra de progresso, HTML 5? Não mesmo dessa vez é Flash Player, o mesmo que os adoradores do apocalipse dizem que vai morrer em 21/12/2012... Ops essa é outra história... quiz dizer os adoradores do HTML 5 dizem que vai morrer, mais uma vez, imagem na tela.
Então onde o HTML 5 se aplica? Onde o Flash não se aplica? O HTML 5 se aplica aos novos sites que focam em smartphones, tablet e novas versões dos navegadores. O flash se aplica a todo o resto, porém com doses de sabedoria.
Não se deve fazer um site 100% em flash, se eu quero acessar seu site do meu smartphone, posso ter que parar numa lanhouse por falta do plugin do flash, mas com certeza não ver o banner do seu site no meu smartphone seria muito bom.
Eu particularmente, tenho usado o flash player no backend dos sistemas atraves do Flex e Air, funciona muito bem e como o blackend é algo que me obriga a conhecer os usuários, eu posso falar "atualiza o plugin do flash" caso algo não funcione, porém em um site fica dificil ligar ou mandar um e-mail para alguém que eu nem sei quem é.
Resumo da ópera? O Flash Player tem mais chances de se tornar o novo HTML do que o HTML 5 se tornar um padrão real e funcional em todos os navegadores. Enquanto esse dia não chega a melhor opção se chama JQuery e HTML5 Fix.
O JQuery é um conjunto de códigos javascript que cria um novo padrão resolvendo problemas de compatibilidade entre navegadores e tem até uma versão mobile.
O HTML Fix é um projeto que esta hospedado no google e visa em fazer funcionar de forma padronizada as tags e atributos do HTML 5 que muitos navegadores não suportam.
HTML 5, Flash, Flex, Air e Outras Drogras - Parte 1
Resolvi aproveitar o sábado de sol para fala sobre o tumulto no mercado web sobre Adobe com o Flash, Flex, Air e o HTML 5. Não vou puxar sardinha para o lado de ninguém, porém vou montar um cenário para cada uma das plataformas.
A cerca de mais ou menos um mês a Adobe anunciou descontinuar o plugin do flash para Mobile, o mercado entendeu descontinuar o Flash e muitos falaram "HTML 5 ganhou".
Flash Player Mobile
Em primeiro lugar, vamos pensar o seguinte, esse plugin comia bateria dos poucos celulares que rodavam o plugin e não previa a virada de mesa dos smartphones sem teclado como o iPhone. O mercado mobile para o flash era pequeno por conta disso e ficou ainda menor com o iPhone que aproveitou o conceito de Apps para matar o plugin, com isso os números da Adobe para mobile não foram nada bom.
Não preciso explicar o gráfico, certo? Esses números eu peguei no próprio site da Adobe, e representa a penetração do Flash Player Mobile no mercado e a previsão até 2015. Então com isso a gente pode dizer que foi uma decisão sábia focada na resposta do mercado e não tem absolutamente nada a ver com o HTML 5.
HTML Mobile
Partindo para o HTML, não estou falando do 5, focado em Mobile temo um cenario favoravel a plataforma, nem todos os celulares e smartphones tem flash player, mas todo celular e smartphone tem navegador, que muito provavelmente aceita HTML.
Nesse ponto temos vários celulares com suporte a html e com a tela pequena toda navegação se torna vertical e os desafios de renderizar ficam a cargo dos navegadores que tem como trabalho transformar texto em visual e interpletar um pouco de javascript. No caso dos smartphones existem algumas diferenças por conta de recursos como o acelerômetro, multi touch e geolocalização, o que na maioria dos casos se resolvem por acesso nativo a API do aparelho pelo browser que os desenvolvedores realizam acesso pelo javascript de API's ao meu ver ainda muito pesadas como o JQuery Mobile. O lado bom dessa história para o HTML é que existem pelo menos 18 navegadores que vem instalados nos smartphones e outros a serem instalados, a lista consegui em http://en.wikipedia.org/wiki/Mobile_browser, dando ao usuário final as 2 opções: usar o que tem ou trocar e isso o flash player nunca terá como opção.
Então de forma clara e objetiva, sim o HTML é uma boa opção para mobiles, porém ainda temos outra opção de aplicativos mobile que são aqueles instaláveis, baixados, comprados na Apple Store, Android Market. Nessa hora é onde entra a comparação HTML 5 com o Air Mobile.
Air Mobile
Em primeiro lugar o que é o Air Mobile? Ele não é o Flash Player Mobile descontinuado e sim um ruimtime que possui um SDK que permite criar aplicativos nativos para plataformas específicas.
Pontos positivos para ele começam com o fato de que o desenvolvedor que conhece Flex e ActionScript consegue criar aplicativos instalaveis para iPhone, iPad, iPod, Android e Playbook sem saber nada dessas plataformas, o que para a empresa é abrir um mercado com INVESTIMENTO ZERO no profissional.
Por ser um complilador para multiplos dispositivos alguns recursos ativos e específicos acabam ficando de fora o que dependendo do aplicativo pode ser um problema, mas dependendo do recurso pode-se criar uma extenção nativa ou ANE (ActionScript Native Extenssion) que é um recurso novo no SDK do Flex e até agora nos testes que eu tenho feito resolvem boa parte dos problemas.Uma coisa que achei muito legal no ANE é que ele não se limita a gerar extensões nativas ao mobile, mas também ao desktop, as isso é assunto para outro post.
Um caso legal para o Air Mobile é pensar nas possibilidades geradas em termo de negócio e produtividade, o mesmo App se montado seguindo uma metodologia de skins, bibliotecas, orientação a objetos, pode ser fácilmente distribuido em versão web, desktop e mobile simplesmente mudando a forma de compilação.
Pontos negativos do Air mobile? Bom o principal e não estou puxando para o lado da Adobe é o fato do projeto ter sido doado a Apache Software Foundation, ponto negativo porque a comunudade de desenvolvedores Adobe esta acostumada a reportar problemas e aguardar novo releases e correções, indo para a Apache o Air e o Flex vão ficar nas nossas mãos, se tem um problema vamos resolver e isso não é muito a cara do profissional que esta mais acostumado a reclamar do que colocar a mão na massa e resolver.
Acredito que essa mudança vai exigir alguns anos de adaptação, mas por sorte a Adobe se comprometeu a continuar no projeto até final de 2012 e entregar todos os componnetes em modelo spark, o que me deixa aliviado.
Então quando usar o Air Mobile? Quando ele ganha do HTML 5?
O primeiro ponto para o Air esta no fato dele se tornar um aplicativo nativo, ou seja, você tem um ícone no smartphone com o seu app e não tem que acessar o browser e buscar nos favoritos.
O segundo é o acesso a alguns recursos que dependendo do aplicativo podem fazer diferença, se vocÊ cria um e-commerce pode ter um aviso de entrega, disponibilidade em tempo real com direito a saber se o cara recebeu e abriu a informação, se for uma loja física o app pode rodar em background e apitar que você esta perto da loja
O terceito e na minha opinião o mais importante, você pode restringir e quantificar a utilização do app, se é um ERP não é muito legal garantir acesso a qualquer um e o app instalado é uma forma de garantia uma vez que podemos gerar um token de acesso
HTML 5 Mobile
No HTML 5 mobile temos muitas coisas que o Air mobile faz, a única diferença é que não instalamos o aplicativo, pelo menos era o que eu pensava, mas ao publicar este artigo o amigo Janderson @jandersonfc informou que já tem como se resolver isso através do appcelerator, mas continua o fato dele ser acessado via web. Boa parte do que foi dito sobre o html se aplica ao HTML 5 a diferença fica nas novas tags que fazem coisas que o Flash Player faz a mais de 10 anos.
Pontos positivos? Se não precisa instalar é só acessar e usar o usuário não tem o impacto de fazer download do app para usar, não gasta o espaço em disco do aparelho, só consome a sua internet, se estiver num wifi sem muitos problemas, mas se tiver que depender do 3g é chorar e esperar. Outro problema que se tem no HTML 5 é a questão de padronização. No mercado existem pelo menos 18 navegadores que vem instlados como padrão nos celulares e smartphones e outros montes a serem instlados, a conseguência disso é que cada um nterpleta o código ao seu bel prazer, e o que seria uma coisa simples passa a ser um trabalho de condicionais do tipo "se for navegador X faz assim se for navegador Y faz assado", isso tem se resolvido com as libs de javascript, mas mesmo elas tem esse problema e sem contar que muitas vezes não são planejadas para as baixas velocidades que temos aqui no Pais.
Então vem a mesma pergunta. Quando o HTML 5 ganha de um App instalvel?
Assim como no Air vou tentar passar três vantagens do HTML 5 em relação aos aplicativos instalávies.
O primeiro é muito claro, se o seu aplicativo atende vários usuários então acessar o app é mais lógico do que baixar e instalar para só depois usar.
O segundo foca um pouco mais no custo, no momento em que você tem um aplicativo em HTML 5 é só gritar pela janela perguntando se alguém conhece que você provavelmente vai ouvir um "eu sei". A falta de regras, padrões do HTML 5 faz que cada dia mais pessoas usem ele.
O terceiro aspecto de vantagem é que dependendo da forma com que o código seja feito e quais bibliotecasa sejam usadas, o mesmo app mobile poderá funcionar em um navegador desktop tratando apenas algumas questões visuais.
A cerca de mais ou menos um mês a Adobe anunciou descontinuar o plugin do flash para Mobile, o mercado entendeu descontinuar o Flash e muitos falaram "HTML 5 ganhou".
Flash Player Mobile
Em primeiro lugar, vamos pensar o seguinte, esse plugin comia bateria dos poucos celulares que rodavam o plugin e não previa a virada de mesa dos smartphones sem teclado como o iPhone. O mercado mobile para o flash era pequeno por conta disso e ficou ainda menor com o iPhone que aproveitou o conceito de Apps para matar o plugin, com isso os números da Adobe para mobile não foram nada bom.
HTML Mobile
Partindo para o HTML, não estou falando do 5, focado em Mobile temo um cenario favoravel a plataforma, nem todos os celulares e smartphones tem flash player, mas todo celular e smartphone tem navegador, que muito provavelmente aceita HTML.
Nesse ponto temos vários celulares com suporte a html e com a tela pequena toda navegação se torna vertical e os desafios de renderizar ficam a cargo dos navegadores que tem como trabalho transformar texto em visual e interpletar um pouco de javascript. No caso dos smartphones existem algumas diferenças por conta de recursos como o acelerômetro, multi touch e geolocalização, o que na maioria dos casos se resolvem por acesso nativo a API do aparelho pelo browser que os desenvolvedores realizam acesso pelo javascript de API's ao meu ver ainda muito pesadas como o JQuery Mobile. O lado bom dessa história para o HTML é que existem pelo menos 18 navegadores que vem instalados nos smartphones e outros a serem instalados, a lista consegui em http://en.wikipedia.org/wiki/Mobile_browser, dando ao usuário final as 2 opções: usar o que tem ou trocar e isso o flash player nunca terá como opção.
Então de forma clara e objetiva, sim o HTML é uma boa opção para mobiles, porém ainda temos outra opção de aplicativos mobile que são aqueles instaláveis, baixados, comprados na Apple Store, Android Market. Nessa hora é onde entra a comparação HTML 5 com o Air Mobile.
Air Mobile
Em primeiro lugar o que é o Air Mobile? Ele não é o Flash Player Mobile descontinuado e sim um ruimtime que possui um SDK que permite criar aplicativos nativos para plataformas específicas.
Pontos positivos para ele começam com o fato de que o desenvolvedor que conhece Flex e ActionScript consegue criar aplicativos instalaveis para iPhone, iPad, iPod, Android e Playbook sem saber nada dessas plataformas, o que para a empresa é abrir um mercado com INVESTIMENTO ZERO no profissional.
Por ser um complilador para multiplos dispositivos alguns recursos ativos e específicos acabam ficando de fora o que dependendo do aplicativo pode ser um problema, mas dependendo do recurso pode-se criar uma extenção nativa ou ANE (ActionScript Native Extenssion) que é um recurso novo no SDK do Flex e até agora nos testes que eu tenho feito resolvem boa parte dos problemas.Uma coisa que achei muito legal no ANE é que ele não se limita a gerar extensões nativas ao mobile, mas também ao desktop, as isso é assunto para outro post.
Um caso legal para o Air Mobile é pensar nas possibilidades geradas em termo de negócio e produtividade, o mesmo App se montado seguindo uma metodologia de skins, bibliotecas, orientação a objetos, pode ser fácilmente distribuido em versão web, desktop e mobile simplesmente mudando a forma de compilação.
Pontos negativos do Air mobile? Bom o principal e não estou puxando para o lado da Adobe é o fato do projeto ter sido doado a Apache Software Foundation, ponto negativo porque a comunudade de desenvolvedores Adobe esta acostumada a reportar problemas e aguardar novo releases e correções, indo para a Apache o Air e o Flex vão ficar nas nossas mãos, se tem um problema vamos resolver e isso não é muito a cara do profissional que esta mais acostumado a reclamar do que colocar a mão na massa e resolver.
Acredito que essa mudança vai exigir alguns anos de adaptação, mas por sorte a Adobe se comprometeu a continuar no projeto até final de 2012 e entregar todos os componnetes em modelo spark, o que me deixa aliviado.
Então quando usar o Air Mobile? Quando ele ganha do HTML 5?
O primeiro ponto para o Air esta no fato dele se tornar um aplicativo nativo, ou seja, você tem um ícone no smartphone com o seu app e não tem que acessar o browser e buscar nos favoritos.
O segundo é o acesso a alguns recursos que dependendo do aplicativo podem fazer diferença, se vocÊ cria um e-commerce pode ter um aviso de entrega, disponibilidade em tempo real com direito a saber se o cara recebeu e abriu a informação, se for uma loja física o app pode rodar em background e apitar que você esta perto da loja
O terceito e na minha opinião o mais importante, você pode restringir e quantificar a utilização do app, se é um ERP não é muito legal garantir acesso a qualquer um e o app instalado é uma forma de garantia uma vez que podemos gerar um token de acesso
HTML 5 Mobile
No HTML 5 mobile temos muitas coisas que o Air mobile faz, a única diferença é que não instalamos o aplicativo, pelo menos era o que eu pensava, mas ao publicar este artigo o amigo Janderson @jandersonfc informou que já tem como se resolver isso através do appcelerator, mas continua o fato dele ser acessado via web. Boa parte do que foi dito sobre o html se aplica ao HTML 5 a diferença fica nas novas tags que fazem coisas que o Flash Player faz a mais de 10 anos.
Pontos positivos? Se não precisa instalar é só acessar e usar o usuário não tem o impacto de fazer download do app para usar, não gasta o espaço em disco do aparelho, só consome a sua internet, se estiver num wifi sem muitos problemas, mas se tiver que depender do 3g é chorar e esperar. Outro problema que se tem no HTML 5 é a questão de padronização. No mercado existem pelo menos 18 navegadores que vem instlados como padrão nos celulares e smartphones e outros montes a serem instlados, a conseguência disso é que cada um nterpleta o código ao seu bel prazer, e o que seria uma coisa simples passa a ser um trabalho de condicionais do tipo "se for navegador X faz assim se for navegador Y faz assado", isso tem se resolvido com as libs de javascript, mas mesmo elas tem esse problema e sem contar que muitas vezes não são planejadas para as baixas velocidades que temos aqui no Pais.
Então vem a mesma pergunta. Quando o HTML 5 ganha de um App instalvel?
Assim como no Air vou tentar passar três vantagens do HTML 5 em relação aos aplicativos instalávies.
O primeiro é muito claro, se o seu aplicativo atende vários usuários então acessar o app é mais lógico do que baixar e instalar para só depois usar.
O segundo foca um pouco mais no custo, no momento em que você tem um aplicativo em HTML 5 é só gritar pela janela perguntando se alguém conhece que você provavelmente vai ouvir um "eu sei". A falta de regras, padrões do HTML 5 faz que cada dia mais pessoas usem ele.
O terceiro aspecto de vantagem é que dependendo da forma com que o código seja feito e quais bibliotecasa sejam usadas, o mesmo app mobile poderá funcionar em um navegador desktop tratando apenas algumas questões visuais.
Assinar:
Postagens (Atom)