genymotion2

Emulando aplicativos Ionic/Cordova no Genymotion

Fala pessoal, beleza? Esse é um post rápido pra dar uma dica de algo que descobri hoje. Bom, todo mundo sabe, e não é de hoje, que o emulador android presente no Android Studio é uma porcaria maravilha. E é por isso que grande parte dos desenvolvedores android utilizam o Genymotion como alternativa.

O Genymotion é um emulador rápido e essa palavra “rápido” define ele. Enfim, se você ainda não o conhece e/ou não o utiliza cadastre-se no site www.genymotion.com, faça o download e seja feliz. A utilização dele é muito fácil. É só criar um novo “Virtual Device” e rodar.

E para rodar aplicativos feitos com o Cordova ou Ionic dentro do Genymotion basta rodar seu Virtual Device e executar o código:

ionic run android

Mas por que “run” e não “emulate”?

Isso ocorre pois o Genymotion não notifica o Android/ADB que ele é um emulador. Ele se “apresenta” como sendo um dispositivo e é por isso que nós temos que executar o comando do Cordova para rodar o aplicativo em um dispositivo real, pois assim ele encontrará o Genymotion.

Debugando

Como vocês já sabem, pois leram na documentação, o Ionic Framework é um framework feito para rodar em dispositivos recentes (Android 4+ e iOS 6+) não adiantará criar um virtual device do Galaxy S2 com Android 2.3.6. Particularmente, eu recomendo que criem o virtual device de qualquer dispositivo com Android Kit Kat, pois no Kit Kat o navegador padrão é o Chrome e não mais o Android Browser, logo, a WebView do dispositivo também roda o Chrome.

Faço essa recomendação pois no Chrome é possível debugar sites abertos no navegador remotamente. E isso também serve para aplicativos que usam a WebView. Para inspecionar o dispositivo basta você ir em Menu > Ferramentas > Dispositivos ou abrir uma nova aba no Chrome e digitar:

chrome://inspect

Então ele irá carregar uma página como a seguinte e então é só clicar em “inspect” para começar a trabalhar.

Aba de dispositivos

Ao clicar em “inspect” o Chrome irá abrir o Developer Tools e você terá todos os recursos dele para se divertir.

Inspetor Remoto

Qualquer dúvida quanto a inspeção de dispositivos remotos utilizando o Google Chrome é só acessar esse tutorial.

Javascript vai resolver tudo mesmo?

Fala galera, meu nome é Diogo. E como proposto pelo Jean, vou falar um pouco mais sobre mim neste primeiro post.

Fui graduando de Engenharia de Software na UFG, porém tranquei o curso em busca de me “autodidatizar” (discussão que quero trazer pra outro post). Desde então tenho estudado vários assuntos, até que me descobri apaixonado pelo Frontend.

Sou desenvolvedor Frontend na Meta Tecnologia. Fã de conhecimento holístico. E curto muito ler quando não estou programando. Além de ter idéias horríveis todos os dias.


A “nova era” do desenvolvimento web

Bom, eu já tinha um post semi-pronto sobre Web Storage. Porém, um podcast¹ que eu escutei hoje (13/08) me inspirou a escrever esse post. E me fez pensar bastante sobre o seguinte assunto: “Estamos mesmo usando Javascript da forma certa?”

Desde 2006-07 com a popularização de bibliotecas como jQuery e YUI, até hoje em dia com a evolução destas para os frameworks MV* (model-view-whatever) como Angular, Ember, Backbone, ExtJS, fora o uso de JS no servidor. Muitas das atividades, antes designadas ao backend, foram transferidas para o frontend. Por vários motivos, tais como: facilidade de desenvolvimento, performance, menor consumo de banda, entre outras.

No podcast, Nicholas C. Zakas (@slicknet) comenta sobre esse crescimento da “cultura do javascript” e levanta 2 pontos importantes:

  1. JS é a melhor solução para o meu problema?

  2. Qual o peso de usar uma ou várias bibliotecas javascript? E o que fazer para diminuí-lo?
     

Entender o problema é a melhor solução

 

No primeiro ponto abordado, é discutida a real necessidade do uso de bibliotecas/frameworks JS nas aplicações. O entrevistado fala da “jqueryzação” do desenvolvedor, citando a frase: “Bom, eu tenho esse problema. Como eu vou usar jQuery pra resolvê-lo?”. Ele critica o modo com muitos desenvolvedores não estendem os limites impostos pelas bibliotecas usadas, como criar plugins, forks, etc.

Outro argumento utilizado é o de que já existem tecnologias que fazem as mesmas coisas, no backend, por exemplo. E que podemos usar de Progressive Enhancement (melhoria progressiva) com Javascript para melhorar a experiência do usuário.

Eu divirjo um pouco dessa opinião. Pois penso que essa cultura de estender as bibliotecas tem crescido bastante. Muito pelo fato de que o GitHub (a.k.a: presença open-source) dos desenvolvedores tem se tornado uma espécie de currículo na visão de muitas empresas.

Porém, concordo com o fato de que JS deve ter uma abordagem de Progressive enhancement². O fato de se ter uma stack toda em Javascript é bastante atraente e resolve boa parte dos problemas. Mas nem todos eles exigem uma baita interface rica, ou uma ótima performance. Ou seja, conforme a necessidade surgir, a solução deve ser implementada.
 

Optei por Javascript, e agora?

 

Um dos principais problemas que surgem quando usamos javascript, principalmente no browser, é o excesso de alternativas.

Por exemplo, hoje eu preciso de uma lib para navegar na DOM, amanhã de widgets, depois de promises, autocomplete, etc. Além do meu próprio código, que faz o projeto realmente funcionar. Chegará um dia em que eu terei arquivos demais, consequentemente mais tempo de carregamento.

Para melhorar esse problema de carregamento, o Nicholas fala sobre os quatro tempos de carregamento no browser (os quais você pode se aprofundar mais nos slides³ da palestra que ele deu sobre o assunto).

Dentre eles, o que mais me chamou a atenção é o quarto: “On demand”. Neste tipo de abordagem, nós devemos pensar em como o cliente usará a aplicação.

Um bom exemplo citado no podcast, é de uma página de produto da Amazon.

 

amazon

 

  • Qual deve ser o primeiro passo do usuário logo após ter aberto a página? (assumindo que ele veio de uma pesquisa)

  1. Prioritariamente o botão “Add to Cart”, pois, se o usuário gostar do produto, essa será a primeira ação a ser tomada.

  2. Se o usuário não quiser o produto, provavelmente ele vai querer fazer outra pesquisa. Então, por exemplo, o autocomplete da pesquisa, não precisa estar carregado junto com a página. Podemos atrasar um pouco seu carregamento.

  3. O botão “Sell on Amazon”, por ser menos usado, pode ter sua funcionalidade carregada quando o mouse estiver a uma certa distância dele, por exemplo.

Só neste pequeno exemplo, nós economizamos o carregamento de 2 scripts. A partir daí, nós podemos viajar e pensar melhor em outras formas de trazer o mínimo viável de arquivos para o funcionamento da página. Tudo isso com base no comportamento do usuário. Achei isso muito foda e pretendo usar nos meus próximos projetos.
 

Conclusão

Apesar de causar xiismo e polêmica em muitos casos. Acho muito válidas as discussões sobre o uso ou não das tecnologias. Pois muita gente defende muito tecnologias em si, e não a solução para o problema.

Pra quem tiver um bom nível de inglês eu recomendo que escute o podcast, pois há outras discussões que eu não citei aqui. E espero que vocês tragam suas opiniões nos comentários, para que a gente possa discutir melhor sobre o assunto.

 

Referências

¹ Hanselminutes #383: Enough With The JavaScript Already! with Nicholas Zakas?
² Progressive enhancement is still important
³ Enough with the Javascript already!