Estão entre as vantagens de se tornar root, conseguir utilizar mais funcionalidades do seu aparelho, como atualizar para as versões mais novas do Android.

ATENÇÃO: Lembro a todos que esses passos e métodos são perigosos e podem danificar seu aparelho. Utilizem a sua conta e risco. Recomendo a utilização apenas para usuários avançados e que não temam inutilizar seus aparelhos.

Eu testei em um telefone Galaxy Vibrant com Android 2.1 e funcionou bem. Todos os outros aparelhos e métodos eu não testei.

Cliq e Dext: link

Motorola Droid, Droid X e Milestone e HTC/Google Nexus One: link

Aparelhos HTC: link

Galaxy Vibrant e Captivate: link

Galaxy GT-I9000B e Outros: link

Até a próxima.

Existe uma premissa que no Android só podem haver três tipos de dispositivos para relação aos tamanhos, aonde os smartphones estão geralmente classificados em médios e os tablets, por exemplo, estão classificados como grandes. Então no desenvolvimento, três pastas devem ser criadas por padrão para construção de aplicações Android e dentro de cada uma pasta (em inglês), “baixa”, “média” e “alta”, deve-se colocar as imgens com as resoluções respectivas. O sistema operacional cuida do resto. De acordo com a resolução do dispositivo ele exibe a imagem correta.

Ainda existe mais opções com relação a diferenças de tamanho de tela, aonde ele ainda pode no caso do tablet, por exemplo, exibir mais informações ou melhorar a organização dos componentes aproveitando melhor o espaço.

Existe uma discussão ampla em torno disso que diz que existem problemas nessa abordagem. Dizendo que pequenas diferenças de resolução que podem afetar muito o design da tela, não podem ser tratadas utilizando essa abordagem e dessa forma criando aplicações para cada resolução. Acredito que aplicações que são sensíveis a pequenas alterações de tamanho devem ser tratadas de forma especial e serem homologadas em alguns padrões oficiais de tamanho. Criar perfis de telas para cada resolução especifica a ser verificada no momento do carregamento da aplicação, após identificar o perfil do dispositivo utilizado.

Existem muitos pontos de vista sobre esse problema e não tenho a intenção de dizer que o problema não é um problema, mas existem formas hoje de tratar o problema e existem muitas empresas de peso tentando resolver essa questão.

Há muitos anos tenho tido algumas iniciativas para desenvolvimento móvel mas a falta de padrões sempre me desanimou. Com o desenvolvimento do android vejo um novo e poderoso meio de criar aplicações para dispositivos móveis.

Venho criando pequenas aplicações faz uns meses e esse final de semana resolvi dar mais um passo para consolidar meus conhecimentos sobre o assunto. Fui há São Paulo fazer um curso de android e consegui absorver conhecimentos mais detalhados e ampliei minha visão sobre o android.

O android é espetacular e já amplamente adotado pelas grandes empresas fabricantes de aparelhos móveis.

O android nos possibilita alterar todas as aplicações do telefone e utilizar todos os recursos de hardware de uma forma transparente e amigável ao desenvolvedor. Através do plugin para a IDE de desolvimento eclipse é possível debugar aplicações no emulador e até no telefone conectado a USB. Esse é apenas um exemplo do que o Google tornou possível no ambiente de desenvolvimento, pois com a possibilidade de desenvolver utilizando apis Java o android ganhou grande parte do poder do Java.

Devo voltar a falar de android nos próximos posts. Obrigado pelo seu tempo.

Geralmente ao utilizar o plugin de inicialização do Servidores de Aplicação dentro do Eclipse acontece um erro de TimeOut, esse erro pode ocorrer por alguns motivos, mas os pricipais são:

- Ao inciar o servidor de aplicação é necessário iniciar todas as aplicações que estão deployed dentro dele e isso requer, as vezes, um tempo maior que o configurado dentro do plugin. Isso pode gerar o erro de timeout.

Solução: Nesse caso configure a aba Timeouts “Start in seconds” para um valor maior.

- Ao iniciar o servidor JBoss embora não exiba nenhum erro de Deploy ele não inicia e após um período o eclipse exibe uma excessão de Timeout.

Solução: Esse erro geralmente ocorre quando o Tomcat interno utilizado no JBoss está utilizando um porta diferente da configurada dentro do Eclipse. Para equalizar as portas modifique ou equalize com a porta configurada no arquivo “\jboss-4.0.5.GA\server\default\deploy\jbossweb-tomcat55.sar\server.xml” HTTP port.

Se ao tentar inicializar o Servidor de aplicação JBoss você pegar um erro dizendo “Port 1099 already bound”, isso significa que a porta já está em uso por outra aplicação. Normalmente as aplicações que usam essa porta podem ser o Firefox ou MSN/Yahoo Messenger. Você pode parar essas aplicações e tentar iniciar o Servidor novamente. Se obtiver sucesso você pode iniciar novamente essas aplicações, pois elas sabem utilizar portas alternativas para inicializar os serviços.

Um comando interessante no windows para saber qual aplicação utiliza qual porta, utilize o DOS e rode o comando.

netstat -b

Outro motivo para gerar o problema é o Servidor já estar iniciado ou ter algum outro serviço utilizando essa porta. Nesse caso você pode alterar a porta no arquivo “\jboss-4.0.5.GA\server\ports-bindings.xml”.

Espero ter ajudado.

O Hudson na análise se mostrou uma ferramenta mais prática e fácil de utilizar, tem interface gráfica e possibilita a construção de projetos auxiliares (dependências), inclusive com a possibilidade de utilizar várias máquinas para acelerar o processamento das construções.

A função da Integração Contínua é fornecer automatização da construção de aplicações e testes integrados, gerando relatórios que facilitam a homologação da aplicação e possível resgate de uma construção anterior.

O Hudson integra com repositórios como CVS, possibilitando fazer checkout do projeto e configurar um listener para gerar uma nova construção da aplicação toda vez que existir alteração da versão de qualquer aquivo no projeto. Existe ainda integração com ferramentas para construção de aplicação como ANT, que é aonde devem ser configurados para serem executados os testes Junit.

Foram testados Junit que utilizam o Selenium, uma ferramenta de testes de interface WEB ou seja ferramenta para testar o Client Side da aplicação. Este teste obteve sucesso.

Não entrei em detalhes profundos sobre o Hudson, pois já existe bastante conteúdo sobre ele no Google, um bom link para começar é : http://blog.dilas.com.br/index.php/2007/07/25/integracao-continua-com-hudson/

Com certeza manter um processo de Integração Contínua em um projeto, adiciona muito para a qualidade do projeto além da transparência para todos os participantes do processo de desenvolvimento.

Conforme for havendo o amadurecimento do projeto devo trazer algumas funcionalidades interessantes do Hudson .

Na tentativa de melhorar a qualidade de testes unitários percebi que não bastava apenas visualmente verificar classe por classe, sua utilização e tentar cobrir o máximo de possibilidades, verifiquei que isso seria impossível ser alcançado utilizando apenas o bom senso. Principalmente quando são projetos muito grandes com muitas pessoas desenvolvendo testes e artefatos do software.

Um boa prática para os projetos foi implantada recentemente em um dos projetos que eu trabalho, a ferramenta Emma, bem como outras ferramentas como por exemplo: Cobertura e CodeCover, que tem como objetivo gerar relatórios sobre o código que está sendo utilizado no momento de execução dos testes unitários. Com isso eu pude verificar com exatidão quais classes, métodos, blocos e linhas do meu código não estão sendo utilizados pelos testes. Permitindo então construir novos testes para essa parte da aplicação que até então não está sendo testada, mas deveria.

A ferramenta Emma que foi implantada em um sistema EJB 2.0 e foi publicada no Jboss 3.2.7, é muito fácil de utilizar, vou descrever abaixo os passos para gerar um relatório.

Copie o arquivo “emma.jar” quem vem dentro “emma-*****-lib.zip”, é pode ser baixado no site http://emma.sourceforge.net/, para dentro do diretório do Servidor da Aplicação, no meu caso “/java/jboss-3.2.7/server/default/lib”.

É necessário gerar a versão da sua aplicação publicada com as classes instrumentadas, o que significa que suas classes originais serão modificadas para que possa ser possível o Emma verificar o que do código está sendo utilizado. Para gerara as classes instrumentadas utilize o comando “java –cp emma.jar emma instr -d output -ip ****.jar” com isso será gerado o arquivo “coverage.em” e a nova versão instrumentada do “****.jar”. Agora basta substituir o JAR publicado no seu Servidor de Aplicação por esse novo que foi instrumentado e iniciar o servidor.

Rode os testes normalmente e ao terminar desligue o Servidor de Aplicação. Com isso o Emma utilizando suas classes instrumentadas já gerou o arquivo de onde se origina o relatório no diretório aonde está sendo executado o Servidor, no meu caso “C:\java\jboss-3.2.7\bin\ coverage.ec”. Para concluir e gerar o relatório basta rodar o comando: 
C:\java\jboss-3.2.7\bin>java -cp emma.jar emma report -r html -in coverage.em -in C:\java\jboss-3.2.7\bin\coverage.ec, lembrando que o arquivo que foi gerado no momento da instrumentação “coverage.em”, deve estar no mesmo diretório que o “coverage.ec” ou descrever o caminho para esse arquivo. O relatório será gerado em “coverage\index.html”, existem ainda a possibilidade de gerar esse relatório em Plain Text ou XML.

Uma outra forma de utilização do Emma é executar a instrumentação e processamento do relatório através do Ant, abaixo segue o exemplo de instrumentação:

<emma>
   <instr destdir=“${emma.bin.dir}” mode=“fullcopy” merge=“false” metadatafile=“${emma.metadado.dir}/coverage.em” instrpath=“${bin.dir}”/>
</emma>

É isso, espero ter ajudado!

Tenho trabalhado com informática já faz bons anos, gostaria de compartilhar

minhas idéias e experiências.

Vou tentar postar aqui algumas experiências já passadas e algumas tecnologias
interessantes que eu for conhecendo daqui para frente.

Às vezes vou escrever umas bobeiras J.