Um estudo de caso da plataforma Android com Interfaces Adaptativas

Marco Antônio PACHECO JÚNIOR1

Reinaldo de Oliveira CASTRO2

Resumo
Com a finalidade solucionar problemas para dispositivos que contenham diferentes
tamanhos de telas e necessitem de reescrita de código, este artigo propõe um método para
a criação de interfaces adaptativas com foco na reutilização de código. Tal método tem
como objetivo criar uma única interface que seja aplicável em diversos dispositivos, por
meio de imagens e renderização em 2D, com base na plataforma Android. Um estudo de
caso também é apresentado para validação da proposta.

Palavras-chave: interface; código; imagens; renderização; Android

Introdução
Android como uma tecnologia promissora e com tantos os recursos disponíveis, atrai
desenvolvedores por suas diversas características. Estas serão apresentadas neste artigo, para
demonstrar vantagens e justificar a escolha consciente da tecnologia para dispositivos móveis
adotadas para este trabalho.
Segundo a revista Forturne3, a Google registra a venda de mais de 200 mil aparelhos
Android por dia e que a expectativa é de vender 25 milhões no ano de 2011 (WEINTRAUB,
2010). Neste cenário, a venda de smartphones que contêm esta plataforma se repete no Brasil.
Como padrão adotado por empresas do ramo, a versão Android 2.1 e 2.2, que historicamente
demonstra-se estável perante outras, é distribuída na maioria dos dispositivos vendidos.
Com este número exorbitante de vendas e a concorrência incessante das empresas do
ramo pela fatia de mercado, o consumidor desfruta da diversidade de produtos à venda que
contenha esta plataforma.
Cada empresa, com a esperança de aumentar suas vendas opta pelo design
diferenciado, hardware com maior poder de processamento, funcionalidades extravagantes.
No âmbito deste trabalho o principal ponto são as diversidades de telas que um
dispositivo pode conter, como exemplo, 3” (polegadas), 4”, 7” e até 10” para tabletes.
Com estes tamanhos de tela o desenvolvedor ao disponibilizar um software necessita
se preocupar em como o software será apresentado ao usuário, para não cair em um erro
comum de usabilidade. Por exemplo, uma tela 7” de um Galaxy Tab pode apresentar o
software ao usuário em uma resolução distorcida de imagem, pois o software foi preparado
1
Professor do CEUNSP; Especialista em Desenvolvimento para Web pela UFSCAR, São Carlos/SP.
2
Mestre em Ciência da Computação pela UFSCAR, São Carlos/SP.
3
Fortune, revista de pesquisa sobre negócios americana. http://money.cnn.com/magazines/fortune/
 2

para dispositivos com tela de 3”.

Para atender esta finalidade, contemplando, requisitos de arquitetura do Android e
reusabilidade, esta pesquisa concentra na exploração de recursos desta plataforma para o uso
de interfaces adaptativas. Enfatizando o desenvolvimento de um aplicativo que atenda todas
estas diversidades de telas.
Uma maneira para se solucionar é desenvolver diversas imagens, telas, para cada
resolução de tela controlar a inicialização conforme a resolução do dispositivo. Outra maneira
é a busca de linguagem nativa do Android, a qual não será explorada neste artigo. A terceira é
não usar contexto gráfico e sim com componentes já disponíveis no ambiente de
desenvolvimento e trabalhar estas limitações.
Diante destas opções, este trabalho explora uma proposta de redimensionar imagens e
verificar posicionamento de objetos para que em um único desenvolvimento o programador
consiga atender inúmeros dispositivos. Eliminando assim retrabalho, distribuição de
aplicativos específicos para um modelo de aparelho e compilação especifica para cada
dispositivo.
Este trabalho está dividido em seções. Capítulo dois, demonstrado um contexto
histórico e evolução das plataformas até o surgimento Android, justificando a escolha da
plataforma. Capitulo três, apresenta a arquitetura Android e seu funcionamento. Capitulo
quatro, demostra pesquisas sobre interface adaptativa e as limitações para este trabalho.
Capitulo cinco, contextualização do problema, solução e testes. Capitulo seis, conclusão
levantando em consideração vantagens, pontos falhos e a melhorar em um futuro trabalho.

Android
Hoje, há 1,5 bilhão de televisores em uso ao redor do mundo. Um bilhão de pessoas
estão na Internet. Mas quase três bilhões de pessoas têm um telefone celular, tornando-o um
dos produtos de consumo do mundo de maior sucesso. Dessa forma, construir um aparelho
celular superior enriqueceria e melhoraria as vidas de inúmeras pessoas (OHA, 2011). Em um
contexto mundial, esta é a missão do Open Handset Alliance™, grupo formado pelas
empresas lideres de mercado em tecnologia móvel.
Como objetivo, o grupo tende a definir uma plataforma única e aberta para celulares
para deixar os consumidores mais satisfeitos com o produto final. Também criar uma
plataforma aberta e flexível para o desenvolvimento de aplicações coorporativas (LECHETA,
2010).
Segundo Dimarzio, esta aliança nasceu em novembro de 2007 para quebrar diversas
 3

barreiras no âmbito de desenvolvimento de aplicações móveis e hardware. Por meio de uma

plataforma livre e simples, qualquer desenvolvedor com conhecimento da linguagem Java
poderia desenvolver aplicações. Assim como, qualquer fabricante de celulares que em seu
hardware suporte a plataforma, pode produzir e desfrutar das vantagens que serão
demonstradas. Neste contexto a plataforma Android é o resultado.

Contexto Histórico
Desde 1997 os celulares ainda não tinham se tornado multiuso, não tinham
ferramentas multifuncionais pessoais. Ninguém ainda via a necessidade de navegação na
Internet, tocar MP34, ou qualquer uma das muitas funções que estamos acostumados a usar
em um celular (DIMARZIO, 2008). No entanto, mesmo se a necessidade estava presente na
época, a falta de memória do dispositivo e capacidade de armazenamento era um obstáculo
ainda maior para superar, ou seja, os celulares até meados 2002 serviram apenas para executar
e receber chamadas, acompanhar seus contatos, e, eventualmente, enviar e receber mensagens
de texto curtas mensagens, pois até câmeras em celulares não eram comumente encontrados
nas mãos dos consumidores (DIMARZIO, 2008).
Ao decorrer dos anos, com evolução da tecnologia, principalmente na questão de
hardware superior aos existentes e tamanhos reduzidos, proporcionou a evolução tecnológica
de celulares.
Neste âmbito, os dispositivos móveis começaram a ganhar outras funções além da
chamada por voz e o envio de SMS e, por isso, foi necessário um avanço nos programas para
gerenciar as novas funções e até repensar completamente nos sistemas operacionais exististes
para estes.
Quanto mais recursos tecnológicos o dispositivo continha, maiores possibilidades
surgiam, em questões tecnológicas (CINDRAL, 2010) e financeiras. Como exemplo, a venda
de jogos para celulares.
De acordo com CINDRAL (2010), “um dos grandes avanços ocorreu com o
surgimento do Symbian, um SO mobile aberto. Adotado pela Nokia, o sistema permitiu que
milhares de desenvolvedores no mundo pudessem criar aplicativos baseado nos novos
recursos”.
Outros nomes como iOS, BlackBerryOS, além do Symbian, ganharam espaço no
mercado, e lideravam praticamente absolutos até a Google lançar seu próprio Sistema

4
MP3 - MPEG 1 Layer-3, padrão de arquivos digitais de áudio.
 4

Operacional (SO) junto com a OHA (CINDRAL, 2010).

Controle sobre os aplicativos lançados, localidade da publicação do aplicativo,
plataforma de desenvolvimento proprietária e exclusiva, hardware especifico, design
diferenciado e funcionalidades inovadoras entre outros pontos. Foram pontos focais para a
liderança da Apple, com iOS. Consequentemente, apresentando um custo superior na
construção de aplicativos, para inicio de desenvolvimento, mas com grande perspectiva de
vendas.
Porém, o controle total da plataforma e do desenvolvedor, pode ter sido um dos fatores
a desestimular os desenvolvedores e consequentemente causado o êxodo do desenvolvimento
com esta tecnologia, além de alavancar o crescimento dos concorrentes.
Diante destas lideranças, outra solução emergente e difundida no mercado corporativo
foi o Blackberry OS da Research In Motion.
Acredita-se que a perpetuação deste produto neste segmento se deu ao fato dos
produtos liberados pela empresa suportar Java ME (Java Micro Edition). Logicamente,
atrelado aos fatores que acarretam ao uso desta tecnologia: custo de desenvolvimento de
aplicativos baixo, desnecessidade de hardware especifico, simuladores dos aparelhos que a
própria empresa disponibiliza e a facilidade de encontrar profissionais que dominem Java ME.
Em contra proposta, seus problemas, como alto consumo de memória e limitações de
hardware. (MCQUEEN AT. ALL, 2010).
Por fim, a última plataforma em destaque foi o Symbian. Diferentemente das outras
tecnologias proposta este se apoiou no desenvolvimento de código livre, porém, apresentava
diversos problemas, peculiaridades no hardware e no desenvolvimento (GRUMAN, GALEN,
2011).
O Windows Mobile da Microsoft foi uma dos sistemas a usar Symbian que não atingiu
o retorno financeiro previsto inicialmente, segundo alguns especialistas (GRUMAN, GALEN,
2011).
Enfim, dado o contexto histórico, temos dispositivos sem capacidade de
processamento, a imersão de novas tecnologias e aplicativos no mercado, a necessidade de
explorar melhor desempenho e funcionalidades dos sistemas operacionais embarcados e uma
concentração do nicho de mercado a poucas empresas.
Todos estes pontos falhos convergiram na busca de alternativas. Mercado
consolidado, em 2007 surge do Sistema Operacional Android.
Android consolidou em sua plataforma todas as expectativas de um desenvolvedor,
plataforma livre, confiável, robusta, de código aberto e fácil de usar. Expectativas das
 5

empresas, customização fácil e de toda plataforma, hardware barato e acessível. E o principal,

expectativa de todos consumidores, aplicações ricas, interativas e com integrações
(PEREIRA, 2009).
Enfim, um SO que converge à liderança nos próximos anos, como mostrado nos
gráficos abaixo. Na Figura 1 é demonstrado o número de desenvolvedores em apenas um ano
de publicação da plataforma, um dos itens principais que a pesquisa aponta é a facilidade de
desenvolvimento na linguagem, integração de recurso sem complicações, plataforma de
desenvolvimento sem custos e por fim o preço acessível para a publicação no Android
Market5.

Figura 1: Número de desenvolvedores

em plataformas (YAROW ET AL.,
2010).

Na figura 2, segundo Nielsen Company6, é apontada a venda crescente de dispositivos

moveis Android no ultimo semestre 2010 o que definitivamente mostra o rumo e as
possibilidades de lucro tanto para empresas e desenvolvedores.

Figura 2: Vendas de dispositivos

(NILSEN COMPANY,2010).
Na figura 3 é demonstrado o resultado de toda convergência do mercado, maior

5
Android Market: loja virtual de aplicativos Android, onde se concentra o maior número de aplicativos
disponibilizados e é onde será realizado download gratuito ou compra de aplicativos.
6
Nielsen Company: empresa líder global em pesquisa de mercado, informações e ferramentas de análise.
 6

número de venda de dispositivos móveis com Android, desenvolvedores publicando seus

softwares e a empresa Google fornecendo suporte com uma plataforma estável.
Este estudo aponta que atualmente o Android contém maior número de aplicativos
gratuitos disponíveis que seus concorrentes e que nos próximos anos seria possível o Android
Market conter maior número de aplicativos tanto pagos como gratuitos e se tornar a líder de
mercado.

Figura 3: Número de aplicativos por plataforma (WAUTERS, 2011).

Plataforma Android
A plataforma Android é um sistema operacional baseado em Java que é executado no
kernel 2.6 do Linux. O sistema é muito leve e com muitos recursos. Os aplicativos do Android
são desenvolvidos utilizando Java e podem ser portados com bastante facilidade. Android
também incluir aceleração 3D motor gráfico (baseado no suporte de hardware), suporte de
banco de dados alimentado por SQLite7, e um navegador web integrado (DIMARZIO, 2008).
O paradigma é Orientação a Objeto, baseados em XML, o layout da interface do usuário.
Em sua arquitetura, os aplicativos de terceiros, são executado com a mesma prioridade
com os que estão junto com o núcleo do sistema (CINDRAL,2011) dando flexibilidade ao
âmbito corporativo a executar e colocar suas aplicações. Além disso, cada aplicação é
executada dentro de seu próprio segmento.
Outro ponto pertinente é o recurso de acesso a qualquer parte que o sistema
operacional tenha acesso. Em outras palavras, se o desenvolvedor desejar criar um aplicativo
que faça a discagem, será possível; se desejar criar uma aplicação que utilize o GPS interno,
também terá acesso. O potencial para os desenvolvedores criarem aplicações dinâmicas e
integradas é enorme.
No topo de todos os recursos que estão disponíveis é a integração com aplicativos do

7
http://www.sqlite.org/
 7

Google8 (DIMARZIO, 2010). Abaixo segue a figura com a arquitetura Android.

Figura 4: Arquitetura Android (GOOGLE, 2007).

Framework de Aplicações
A arquitetura deste framework foi desenvolvida para simplificar a reutilização dos
componentes. Desta forma qualquer desenvolvedor pode construir um aplicativo e
disponibilizar suas “capacidades”, permitindo que elas sejam utilizadas por outros programas.
Segundo o GOOGLE (2007), “vale lembrar que o desenvolvedor tem acesso total à mesma
estrutura de APIs usada nos aplicativos centrais, podendo, desta forma, aproveitá-las
conforme achar”.

Bibliotecas
O sistema inclui um conjunto de bibliotecas usadas por diversos componentes do
Android (GOOGLE, 2007). Exemplos destas são:
• Bibliotecas de mídia: permitem trabalhar com arquivos como MPEG4, H.264,
MP3, AAC, AMR, JPG e PNG.
• Bibliotecas Gráficas: exibição de conteúdo tanto em 2D como em 3D.
• Biblioteca para acesso e suporte a Banco de Dados SQLite, banco de dados
relacional.
8
http://www.google.com/mobile/android/
 8

Para as bibliotecas gráficas, há uma biblioteca 3D para controle e acesso a todos os

recursos do hardware de vídeo. A implementação foi baseada no OpenGL9 (Open Graphics
Library).

Android Runtime
De acordo com o manual de referência, GOOGLE (2007), cada aplicação do Android
roda em seu próprio processo e cada processo é uma instância da máquina virtual Dalvik,
criada para que o dispositivo possa rodar múltiplas máquinas virtuais eficientemente. Os
arquivos são executados no formato Dalvik Executable (.dex) e são otimizados para consumo
de memória mínimo. Os arquivos são criados por um compilador Java, que converte o
resultado no formato .dex.

Kernel do Linux
Usando a versão do kernel Linux 2.6 para serviços essenciais do sistema, como
segurança, gerenciamento de memória, gerenciamento de processos, rede e drivers. O kernel
também funciona como uma camada de abstração entre o hardware do dispositivo e o resto do
conjunto de softwares que são desenvolvidos em paralelo (GOOGLE, 2007).

Ciclo de Vida
Um dos pontos chaves para o desenvolvimento de aplicativos Android é o ciclo de
Vida. Com este conceito é possível entender seu funcionamento e realizar alterações no que
for necessário.
O desenvolvedor não tem controle sobre as mudanças de estado de uma aplicação, isso
é responsabilidade do sistema operacional, no entanto, ele pode ser notificado quando um
estado está prestes a mudar através da chamada de um método on[Evento](). Sobrescrevendo
esses métodos na sua classe Activity, o Android vai executá-los no momento apropriado
(BURNETT, 2009). Uma visão geral sobre estes métodos é mostrada na Figura 5.

9
OpenGL - API multi-plataforma para escrever aplicações que produzem computação gráfica 2D e
3D desenvolvido pela Silicon Graphics Inc. (SGI) em 1992.
 9

Figura 5: Ciclo de vida de um aplicativo.

Interfaces Adaptativas
Diante do número vendas de dispositivos móveis já apresentados, diversidades
tecnológicas e designers diferenciados (WEINTRAUB, 2010), faz-se necessário a buscas de
tecnologias e pesquisas que versam sobre adaptação de interfaces para dispositivos móveis, ou
melhor, interfaces adaptativas (BARTH; SATAHSI, 2004).
Segundo ITO et. al. (2006), “As interfaces adaptativas se apresentam promissoras na
tentativa de superar os problemas atuais de complexidade na interação homem- computador.
Para melhorar esta interação, são necessárias interfaces que sejam capazes de se ajustar às
necessidades do usuário”.
Na área de interfaces adaptativas, há diversas pesquisas que exploram de diferentes
maneiras mecanismos que permitam a elas se adaptarem. Porém, cada qual leva em
consideração um tipo de ambiente. Abaixo segue alguns exemplos e que serviram de base
para este estudo.
Dynamically Generating Interfaces for Móbile and Embedded Systems (DIGYMES) é
uma arquitetura apresentada por CONINX, et. al. (2003). Através de um framework
desenvolvido, tem como objetivo de criação de design para tipos de dispositivos móveis.
Utilizando a separação entre as camadas lógica e de apresentação, técnicas de modelo de
desenvolvimento de interface do usuário, linguagens como eXtensible Markup Language
(XML), gerenciamento automático de layout e transparência de localização, contém falhas.
Uma destas é que não é possível garantir uma apresentação do visual agradável da interface
perante a migração da mesma entre dispositivos móveis e desktops.
 10

MUSA - Multi User Interfaces Single Application, proposto por MENKHAUS (2002).
Da mesma forma que DIGYMES, tinha como objetivo a separação entre camadas e trabalhou
com diferentes técnicas, porém apresenta os mesmo problemas com relação a interfaces
adaptativas.
Neste contexto, houve diversas pesquisas nesta área, mas devido estabilidade das
tecnologias e facilidades dos frameworks, as pesquisas foram tendenciadas a relacionar outras
áreas. Exemplo disto são as pesquisas sobre as interfaces adaptativas relacionadas a não só
divergentes dispositivos, mas sim a adaptação conforme o perfil do usuário, modo de
operação do usuário entre outros pontos, onde foco é a usabilidade.
Já em 2007, como a ascensão da plataforma Android, o mercado e as pesquisas
voltaram a resgatar as formas de realizar interfaces adaptativas.
Como já mencionado, há diversas formas e ambientes a se referenciar em interfaces
adaptativas. Como exemplo, são interfaces adaptativas entre um desktop e dispositivos
móveis, interfaces que consideram a perfil do usuário e até pesquisas que referenciam
adaptações para pessoas como problemas visuais.
Este trabalho está limitado no âmbito da plataforma Android. O principal ponto é
desenvolver mecanismos de interface adaptativa especificas, onde se consiga atingir qualquer
aparelho que a use, seja ele celular ou tablete, independentemente de sua tela, processamento.

Renderização Gráfica
Android coloca duas das bibliotecas gráfica disponíveis em um dispositivo móvel: um
para gráficos bidimensionais (2D) e um para três dimensões (3D). (BURNETTE, 2009)

Renderização Gráfica 2D
Android fornece uma completa nativa biblioteca bidimensional de gráficos em seu
pacote android.graphics. Com uma compreensão básica de classes tais como cor e Canvas
(BURNETTE,2009).
As cores em são representadas com quatro números, um para cada alfa, vermelho,
verde e azul – ARGB (BURNETTE, 2009), onde alpha é uma medida de transparência. Cada
componente pode ter 256 possíveis valores, ou oito bits, por isso uma cor é normalmente em
um inteiro de 32 bits.
Exemplo em Java:
color = Color.argb(127, 255, 0, 255);
Exemplo através do XML:
 11

<?xml version="1.0" encoding="utf-8"?>

<resources>
<color name="mycolor">#7fff00ff</color>
</resources>

A classe Canvas representa uma superfície em que se pode desenhar. Métodos na

classe Canvas permitem desenhar linhas, retângulos, círculos, ou outros gráficos arbitrários na
superfície (BURNETT, 2009).
No Android, a tela é ocupada por uma atividade que acolhe uma View, que por sua vez
apresenta um Canvas (tela). Para que o mesmo iniciar a renderização, é necessário substituir
método o View.onDraw (), em que o parâmetro passado é a própria tela. Abaixo é
demonstrado um exemplo para desenhar um circulo na tela.
circle = new Path();
circle.addCircle(150, 150, 100, Direction.CW);
canvas.drawPath(circle, cPaint);
canvas.drawTextOnPath(QUOTE, circle, 0, 20, tPaint);

Problemas de Renderização.
Todo aplicativo desenvolvido necessita de usabilidade na interface, ou seja, quando o
usuário olha para o sistema, necessita se sentir confortável em operá-lo, seja ele um sistema
corporativo, um site ou até um game.
Existe um vasto campo de pesquisa sobre questões de usabilidade, mas um ponto
importante dentro desta área é quando o desenvolvedor deseja criar jogos. O requinte de
resolução de vídeo, tamanho de tela, tamanho de imagem, operabilidade, som entre outros
pontos são importantes, principalmente para que o jogador se entretenha com aplicação por
um bom tempo.
Neste tipo de aplicação encontram problemas para com o trabalho em tamanhos de
imagens, resoluções e telas de dispositivos. Exemplo deste é criar interfaces gráficas
utilizando objetos, tamanhos e posicionamento estáticos. Ao criar uma aplicação para um
dispositivo especifico com tela de 3” é necessário o programador realizar ajustes e
redimensionamento de cada objeto caso queira disponibilizar uma aplicação para dispositivos
com telas de 5”.
Ficando praticamente inviável, por parte do programador, o controle de diversas
versões de software para modelos específicos de celulares. Limitando, assim, a publicação
 12

softwares para modelos.

Para isto, dentro do ambiente de desenvolvimento do Android há diretórios diferentes
para cada resolução drawables, drawable-hdpi, drawable-ldpi, drawable-mdpi. Cada um
desses diretórios só será utilizado de acordo com a resolução do Android que o dispositivo
esteja utilizando, ou seja, qual modelo de emulador que estiver usando. Por exemplo, quando
for usada a resolução de 480x800, é utilizado o diretório drawable-hdpi, para a resolução
320x480, é utilizado o diretório drawable-mdpi, para a 240x400, é utilizado o diretório
drawable-ldpi.

Redimensionamento.
Para auxiliar nesta tarefa de redimensionamento e como proposta deste artigo, foi
criado e testado com vários projetos a classe Resize. Essa classe tem como objetivo o
redimensionamento ou o posicionamento dos objetos, com a finalidade de se adaptar para
diversas telas. Na Figura 6 é mostrada modelagem UML10 dessa classe.

Figura 6: Modelagem da Classe Resize

A classe contém como atributos principais e privativos o tamanho da largura e altura

da página. O processamento ocorre quando a classe é instanciada, na qual, obtém o valor
altura e largura padrão do dispositivo em questão, além de carrega o valor padrão para o qual
foi desenvolvimento. Este se faz pertinente para que ocorra o calculo e redimensionamento de
objetos ao chamar qualquer método desta classe posteriormente.
Segue abaixo o trecho de código da inicialização.
Display display = ((WindowManager)
getSystemService(WINDOW_SERVICE)).getDefaultDisplay();
this.width = display.getWidth();
this.height = display.getHeight();

10
UML - Unified Modeling Language é uma linguagem de modelagem padrão de uso geral no domínio
de orientação a objetos em engenharia de software.
 13

Da mesma forma, a classe disponibiliza outros métodos para solucionar o problema.

Um desses métodos é o positioning, tem como responsabilidade de dado um valor e o
tamanho da tela, calcular a posição do objeto para o dispositivo em questão, com base no
tamanho da tela previamente carregado, com isto basta posicionar o objeto em questão com o
valor proporcional que método retornou, como exemplo abaixo.

circle.addCircle(redimensionar.positioning(150, Resize.Height),
redimensionar.positioning(150, Resize.Width),
redimensionar.positioning(100), Direction.CW);

Outro ponto pertinente é o método de redução de imagem, em que o objetivo é o

desenvolvedor ter apenas uma imagem com maior resolução e para se adaptar a tela, a classe
retorna uma imagem com a resolução proporcional a imagem enviada, abaixo segue o trecho
referente ao redimensionamento da imagem.

/* redimensiona a imagem */
BufferedImage imagem = ImageIO.read(arquivo);
BufferedImage new_img = new BufferedImage(new_w, new_h, Buff-
eredImage.TYPE_INT_RGB);
Graphics2D g = new_img.createGraphics();
g.drawImage(imagem, 0, 0, new_w, new_h, null);
ImageIO.write(new_img, image.getExtensaoImagem(), arquivo);

Problemas do Redimensionamento.
Esta solução torna-se viável para aplicativos que não necessitem de constante
redimensiomento de imagem e que disponham de um maior espaço de armazenamento em
disco. Estas limitações se aplicam devido ao custo computacional de redimensionar uma de
imagens e de gravar em disco ou memória a imagem processada para ser utilizada pelo
aplicativo. Com exemplos destes podemos ressaltar o desenvolvimento jogos com cenários
ricos em 3D, necessitando diversas imagens e troca das mesmas constantemente.
Neste contexto aplica-se outro problema que é o tamanho padrão da imagem, ou seja,
ao criar a imagem será necessário gravá-la com maior resolução para atender os diversos
dispositivos, porém, o software ao final terá maior espaço em disco.
 14

Levando em consideração que a maioria dos usuários realiza os downloads11 de seus

aplicativos através do celular GSM12 (Global System for Mobile Communications) que
contém limitações na velocidade de download. Há um ponto em questão para a solução,
download de megabytes desnecessários, pois a solução foi desenvolvida para atender diversos
tipos dispositivos e telas.
Uma das possíveis sugestões é separar em categorias e criar as imagens com maior
resolução, na categoria celular com resolução máxima que os atenda e outra categoria para
tabletes13 em que as imagens seriam especificas para estes que contem telas maiores.

Testes – Frames por Segundo

Para validar esta solução foi desenvolvida uma aplicação que o principio é apenas
trocar 30 imagens diversas, cada uma a cada segundo, com o intuito de simular o conceito de
frames por segundo14 (fps).
Os testes foram realizados em dois dispositivos padrões de mercado, Galaxy SI e
Galaxy 5 da Motorola, como mostrado no quadro abaixo.

Tabela 1: Especificações de CPU dos celulares usados no teste.

Galaxy SI I9003 CPU: 1Ghz Cortex A8 CPU, PowerVR SGX530, TI OMAP 3630 chipset.

Galaxy 5 I5500 CPU: 600MHz.

Em outros requisitos como memória, ambos usaram cartão SD de 1gigabyte, porém o

software não apresentou atrasos na imagem ao rodar no Galaxy SI devido a sua capacidade de
processamento, mas já no Galaxy 5 houve atrasos ao exibir as imagens, pois processador
deste é inferior ao do primeiro.

Conclusão e Trabalhos Futuros

Por fim, viabiliza-se que em casos normais, como em jogos 2D ou no
desenvolvimento de aplicativos diversos que necessite atender diversos dispositivos em uma
única solução, economizando tempo do desenvolvedor, não haverá problemas de atrasos na

11
Transferência de dados de um computador remoto para um computador ou dispositivo local.
12
GSM - conjunto de padrões desenvolvido, para descrever as tecnologias de redes de celulares digitais.
13
Tablet é um dispositivo eletrônico em formato de prancheta, que contém diversos aplicativos, versões e
sistemas operacionais.
14
Frames por segundo (fps) é a unidade de medida da cadência de um dispositivo audiovisual.
 15

renderização da imagem e de posicionamento de objetos na tela conforme sua resolução,

desde que o processador seja superior a 600Mhz.
Para trabalhos futuros, dentro deste escopo, o ideal seria a concepção de buffers de
imagens, com o intuito de diminuir o atraso ao exibi-las na tela.
Outro conceito que poderia ser explorado é a utilização de linguagem nativa do
Android. Esta é feita em C e C++, dando maior desempenho, devido ao fato de não estar
diretamente plugada a uma maquina virtual Dalvik, que realiza as chamadas ao sistema
operacional dos nossos aplicativos.
Já existe programas que utilizam este recursos para desenvolvimento de jogos 3D,
usando a biblioteca OpenGL S1.0. Nestes casos é necessária resposta imediata do sistema
operacional para o processamento e a renderização de imagens, o que não há uma imagem
pronta e sim a contextualização dos pontos, vértices, cores em cima de um plano.
Diferentemente do processo utiliza neste artigo que é o redimensionamento de imagens
estáticas, pré-criadas.
Sobre trabalhos relacionados a este perfil ainda não foi encontrado nos mesmo moldes
e contextualização, visto em casos extremos já se viabiliza a pensar a usar a linguagem nativa.
Porém durante o desenvolvimento deste trabalho a própria Google lançou diversas
atualizações de plataforma e atual Android 3.2 de julho 2011, contêm o contexto de interfaces
adaptativas nativa especifica para tabletes e no anúncio feito em setembro por representantes
da Google a versão Android 4.0 terá interface adaptativa para celulares e tabletes (GOOGLE,
2011).

Referências Bibliográficas

BARTH, F. J.; SATAHSI, G. E., Uma arquitetura para criação de interfaces adaptativas para
televisão interativa. In: SIMPÓSIO BRASILEIRO SOBRE FATEORES HUMANOS EM
SISTEMAS COMPUTACIONAIS, 6., 2004, Curitiba. Anais do VI Simpósio sobre Fatores
Humanos em Sistemas Computacionais. Curitiba, UFPR, 2004. p. 15-20.
BURNETT, ED. Hello, Android: Introducing Google´s Mobile Development Plataform. Dal-
las, Texas. The Pragmatic Bookself, 2009.
CINDRAL, BELINE. Sistemas operacionais para celulares. 2011. Disponível em:
<http://www.techtudo.com.br/artigos/noticia/2011/01/afinal-o-que-e-android.html>. Acesso
em: 25 de maio de 2011.
CONINX, K.; LUYTEN, K.; VANDERVELPEN, C.; VAN DEN BERGH, J.; and
CREEMERS, B.; Dygimes: Dynamically Generating Interfaces for Mobile Computing De-
vices and Embedded Systems. In Chittaro, L., volume 2795 of Lecture Notes in Computer
Science, Springer, 2003. p. 256-270.
DIMARZIO, JEROME F.; Android: A programmer's Guide, New York. McGrawHill E-Book,
 16

2008.
GOOGLE INC. Dev Guide. Documento eletrônico, Abril de 2007. Disponível em:
<http://developer.android.com/guide/topics/fundamentals.html>. Acesso em 04 de agosto de
2011.
GOOGLE INC. Dev Guide. Documento eletrônico, Julho. Disponível em:
<http://developer.android.com/sdk/android-3.2.html>. Acessado em: 31 de Julho de 2011.
GRUMAN, GALEN. Windows Phone 7: Don't bother with this disaster. 2010. Disponível em:
<http://www.infoworld.com/d/mobilize/windows-phone-7-dont-bother-disaster-211?page=0,0
> Acesso em: 30 de julho de 2011.
ITO, G. C.; FERREIRA, M. G.; SANT’ANNA, NILSON. Uma ferramenta para geração de
interfaces adaptativas. Instituto Nacional de Pesquisas Espaciais. ISBN: 972-8924 20-8, 2006.
LECHETA, RICARDO R. Google Android: Aprenda a criar aplicações para dispositivos
móveis com Android SDK. 2° Edição. São Paulo. Novatec Editora, 2010.
MCQUEEN, ROD; BALSILLIE, JIM; LAZARIDIS, MIKE.BLACKBERRY. Inside Story of
Research in Motion. New York. H.B. Fenn & Company, 2010.
MENKHAUS, GUIDO .Adaptive User Interface Generation in a Mobile Computing Envi-
ronment. Tese de PhD, University of Salzburg, Austria, 2002.
NILSEN COMPANY. Apple Leads Smartphone Race, while Android Attracts Most Recent
Customers. Disponível em: <http://blog.nielsen.com/nielsenwire/online_mobile/ apple-leads-
smartphone-race-while-android-attracts-most-recent-customers/>. Acesso em: 30 de julho de
2011.
OHA et al. Building a Better phone for consumers. 2011. Disponível em:
<http://www.openhandsetalliance.com/oha_overview.html>. Acesso em: 15 maio. 2011.
PEREIRA, LÚCIO CAMILO OLIVA; SILVA, MICHEL LOURENÇO. Android para desen-
volvedores. Rio de Janeiro. Brasport. 2009.
WAUTERS, ROBIN. There are now more free apps for Android than for the iphone: Distimo.
Disponível em: <http://techcrunch.com/2011/04/27/there-are-now-more-free-apps-for-
android-than-for-the-ios-platform-distimo/>. Acesso em: 30 de julho de 2011.
WEINTRAUB, SETH. Has Android's growth slowed down?. Documento eletrônico, Dezem-
bro de 2010. Disponível em <http://tech.fortune.cnn.com/2010/12/06/has-android-stopped-
growing/> Acessado em 02 de abril de 2011.
YAROW, JAY; ANGELOVA, KAMELIA. CHART OF THE DAY: Android Used By More
Developers Than Apple. Disponível em: <http://www.businessinsider.com/chart-of-the-day-
platforms-most-used-by-mobile-developers-in-early-2010-2010-
7?utm_source=Triggermail&utm_medium=email&utm_campaign=SAI_COTD_070610>.
Acesso em: 30 de julho de 2011.