Desenvolvimento para Dispositivos Móveis Material Apoio AOL 3

Prévia do material em texto

Componentes de aplicações Android
Componentes de aplicativo são os blocos de construção de um app Android. Cada componente é um ponto de entrada por onde o sistema ou o usuário pode entrar no aplicativo, sendo que alguns componentes dependem de outros. 
Para entender como ocorre o desenvolvimento Android, é necessário direcionar-se a um importante componente e verificar como os aplicativos Android são criados. Diante deste contexto, um tema que normalmente é utilizado no desenvolvimento Android é o Intent.
Um Intent é desenvolvido levando em consideração as ações de um usuário e pode ser definido como um comando que determina o que deve ser executado: você pode se deparar com uma situação em que apareça uma determinada ação, como por exemplo “Abra esse site”, isto indica que os Intents são tão relevantes quanto a codificação Android, do ponto de vista da navegação inovadora. 
O INTENT DE DESENVOLVIMENTO ANDROID
Diante do cenário exposto, é possível notar que o framework possui uma elevada influência dentro de um aplicativo Android. Isto ocorre porque ele apresenta uma mentalidade web direcionada aos aplicativos web. Porém, é importante ressaltar que esta plataforma não possui apenas um navegador de alta performance, não se limita ao JavaScript e nem aos atributos pertencentes ao servidor, pois a sua função é semelhante ao funcionamento de uma plataforma Android e o seu nível de interação aos chamados dispositivos móveis. 
Sendo assim, a internet passa a apresentar um poder elevado, pois as distâncias físicas são reduzidas a um clique realizado pelo usuário. Estes cliques são denominados como Uniform Resource Locators (URLs) ou Uniform Resource Indentifiers (URIs). A utilização destes URI’s, de maneira efetiva, possibilita uma acessibilidade facilitada e célere à informação necessária.
Além da sua eficiência em relação ao acesso de dados e informações, qual a relação existente entre as URLs e os Intents? Bem, a resposta para este questionamento requer uma análise na qual se leva em consideração a maneira que o usuário móvel navega na plataforma e isto será determinante para o êxito comercial delas. É essencial perceber que as plataformas que reproduzem as situações ou experiências que ocorrem no desktop, ao utilizar um dispositivo móvel, serão permitidas somente a um conjunto reduzido de usuários do tipo hardcore. 
No mundo cada vez mais adepto ao uso de dispositivos móveis, a presença de menus longos e o uso de diversos direcionamentos não apresentam uma boa aceitação no mercado móvel, pois este mercado se caracteriza pela facilidade e pelo alto nível de instintividade na utilização. É como um determinado usuário ou consumidor, que certamente irá adquirir um produto com base nas características presentes na publicidade exposta, porém dificilmente lerá o manual de instruções inserido no produto. 
A interface do usuário apresenta uma usabilidade relacionada a essa inserção no mercado. Tudo funciona sequencialmente: se as URI’s refletirem um modelo de acesso de dados da plataforma com uma navegação predominantemente intuitiva e clara, consequentemente a interface do usuário irá expor as mesmas características. 
Ao apresentar os Intents e os IntentFilters, é preciso defini-los como estruturas inovadoras utilizadas para auxiliar a navegação e ativação de um Android. O seu funcionamento traz como modelo a expressão “clique aqui”, que simboliza o centro de utilização e criação de aplicativos móveis direcionados para a plataforma Android. 
É importante que você saiba que um Intent nada mais é do que uma declaração de necessidade formada por uma variedade de informações que apresentam o ato ou serviço esperado. É preciso sempre verificar a ação solicitada e os dados acompanhantes desta ação.
Já um IntentFilter consiste em uma declaração de habilidade e interesse em disponibilizar auxílio para os Intents em necessidade. Normalmente, um IntentFilter se caracteriza por ser genérico ou exclusivo, de acordo a quais Intents ele disponibiliza seu serviço.
A ação de um Intent se caracteriza geralmente através do uso de um verbo (view ou edit). Várias ações oriundas do Intent são estabelecidas como itens pertencentes à classe Intent, porém os responsáveis pela criação de aplicativos podem desenvolver também novas ações.
É importante ressaltar que um membro de dados de um Intent é apresentado em forma de um URI. Isto implica dizer que um Intent pode ser definido como uma informação visualizada de maneira virtual, como um endereço de web, por exemplo. Para deixar mais claro o conceito é possível observar, no Quadro 1, alguns exemplos de URI Android.
Quadro 1. URIs comumente usados no Android. Fonte: ABLESON; KING; SEN; ORTIZ, 2012.
A relação existente entre o Intent e o seu respectivo aplicativo é estabelecido pelo IntentFilter, que apresenta exclusividade aos dados pertencentes ao Intent, à sua atividade ou ambas situações. Vale ressaltar também que os IntentFilters apresentam um campo denominado de categoria ou category, que auxilia na classificação de uma determinada a ação. Vale se atentar que à medida que um Intent é emitido, o sistema analisa alguns aspectos importantes, como Activities, Services e BroadcastReceivers registrados, e envia o Intent para o espaço de armazenamento mais adequado. O Diagrama 1 demonstra a relação existente entre os Intents, IntentFilters e BroadcastReceivers.
Diagrama 1. Relação entre os Intents, IntentFilters e BroadcastReceivers. Fonte: Ableson; KING; SEN; ORTIZ, 2012.
Você pode notar que os IntentFilters são rotineiramente estabelecidos dentro do arquivo denominado de AndroidManifest.xml, pertencente a um aplicativo Android através da tag <intent-filter>. Podemos defini-lo como um arquivo que expõe o aplicativo. Uma atividade normalmente executada em um dispositivo móvel é procurar um registro de contato para iniciar, por exemplo, uma chamada ou uma mensagem de texto.
Dentro deste contexto, é possível também verificar uma informação mais essencial, como um registro de contato de um usuário. Em casos assim, é necessário desenvolver um Intent com a configuração direcionada para o action view, além de um URI que simbolize um determinado interesse. 
Vale fazer uma ressalva: os Intents expostos até o momento são denominados de implícitos. Esta modalidade se caracteriza por estabelecer uma relação de dependência do IntentFilter e do ambiente Android com o objetivo de enviar o Intent para o contêiner adequado. Paralelo a isto, temos o Intent denominado de explícito, no qual é possível determinar qual a classe que possibilita a manipulação do Intent. 
Você pode se questionar qual a utilidade desta especificação. Bem, a especificação é importante à medida que se sabe, com exatidão, qual Activity irá manipular o Intent. Vejamos a linguagem que apresenta um construtor que utiliza uma classe como argumento para desenvolver um Intent explícito:
public void onClick(View v) { 
try {
 startActivityForResult(new Intent(v.getContext(),RefreshJobs. 
class),0);
 } catch (Exception e) { 
 . . . 
 }
 }
É possível perceber como um desenvolvedor Android desenvolve um Intent e solicita a sua manipulação. De maneira similar, é possível implementar o aplicativo Android com um IntentFilter. Isso indica que ele consegue responder a Intents já estabelecidos no sistema, anunciando uma nova funcionalidade direcionada à plataforma. 
Vale mencionar que a resolução de um Intent ocorre no momento da realização e não quando o aplicativo é compilado. É preciso acrescentar recursos exclusivos relacionados à manipulação de Intents direcionados a um dispositivo, lembrando que este tipo de envio realizado no momento da execução é denominado de late binding. 
CONTEXTUALIZANDO
É notável que o usuário irá dispor de experiência exclusiva com o Android graças a variedade dos Activities, em paralelo com os IntentFilters inseridos em cada dispositivo. É importante mencionar que a sua estrutura sofre atualizações dos mais variados aspectos referentes ao Android para disponibilizar funcionalidades e uma sofisticação personalizada.PRINCIPAIS MODELOS DE COMPONENTES ANDROID
Ao aprofundar os conceitos referentes às classes Intent e IntentFilter, é preciso tratar dos principais componentes que formam os aplicativos Android, além da sua relação com o modelo de processo. Vejamos os principais:
// Activity
 
A utilização de uma interface do usuário em um aplicativo não é obrigatória, porém, caso seja utilizada, é necessário o uso de uma Activity. Existe uma forma mais simples de compreender o uso de uma Activity Android: basta relacioná-la a uma tela visível. Isto ocorre porque existe uma relação individualizada entre uma Activity e uma tela de interface do usuário. 
Você irá perceber que os aplicativos Android apresentam várias Activites, nos quais cada uma delas apresenta uma IU replicando as situações iniciadas, seja pelo sistema e ou pelo usuário. Ao desenvolver um aplicativo, é preciso criar classes oriundas da classe-base Activity, que utiliza diversos views para expor os componentes da interface ao usuário.
Vejamos a classe Activity aumentada através das classes de usuário: 
package com.msi.manning.chapter1; 
import android.app.Activity;
import android.os.Bundle; 
public class Activity1 extends Activity { 
@Override 
public void onCreate(Bundle savedInstanceState){ 
	super.onCreate(savedInstanceState);
setContentView(R.layout.main);
 } 
 }
Vale frisar que a classe Activity está inserida no Java android.app, visualizado no momento da execução do Android. O período de execução Android é implantado no arquivo android.jar. Você notará que uma das mais relevantes ações realizadas por uma Activity é apresentar os componentes da interface do usuário, que são inseridos como views e são estabelecidos em arquivos de layout XML. A transferência de uma Activity para outra é realizada através do startActivity() ou por meio do startActivityForResult(), à medida que se deseja criar um padrão síncrono, no qual o argumento desses métodos é considerado uma instância de um Intent.
É notável que a Activity pode simbolizar um elemento visível de um aplicativo inserido no Android. Por meio da classe view, a Activity é o elemento dos aplicativos Android mais usável. O modelo Android 3.0 expôs um novo modelo de componente de aplicativos, denominado de Fragments, que se caracterizam por estarem ligados a Activities e por apresentarem um ciclo de vida próprio, ao disponibilizarem um controle mais efetivo do aplicativo em relação às Activities. 
// Service
Imagine a situação na qual um aplicativo apresenta um ciclo de vida longo. Em uma situação como esta, a melhor opção de componente é o Service. 
Uma maneira de aplicar o Service de forma satisfatória é realizá-lo dentro de uma base periódica ligada ao alarme de sistema e então fazer o Service se encerrar quando a atividade for executada de maneira completa. A Service é definida como uma classe no tempo de execução Android que pode ser ampliada:
package com.msi.manning.chapter1;
import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;
public class Service1 extends Service implements Runnable { 	
public static final String tag = "service1";
 private int counter = 0;
 @Override 
 protected void onCreate() {
 super.onCreate();
 Thread aThread = new Thread (this);
 aThread.start();
 }
 public void run() {
 while (true) { 
 try { 
 Log.i(tag,"service1 firing : # " + counter++);
 Thread.sleep(10000);
 } catch(Exception ee) {
 Log.e(tag,ee.getMessage());
 }
 }
 } 
@Override
 public IBinder onBind(Intent intent) {
 return null;
} 
}
É importante compreender que esse código necessita de um pacote denominado de android.app.Service, que deve ser importado. Esse pacote se caracteriza por apresentar a classe Service. O que podemos observar também é que o mecanismo de log do Android, denominado de android.util.Log, é extremamente importante para o processo de depuração. 
A classe Service1 amplia a classe Service e implanta uma interface denominada de Runnable, cuja função é realizar a sua atividade essencial em um thread separado. Em seguida, o método denominado de onCreate, que pertence à classe Service, possibilita que o aplicativo realize atividades na categoria inicialização. Por fim, podemos tratar do método onBind, no qual é possível falar sobre a comunicação dos interprocessos.
É compreensível que os Services sejam iniciados através do método startService(Intent), que pertence a uma classe do tipo abstrata denominada de Context. Isso indica que o Intent é utilizado para dar início a um resultado esperado na plataforma. Já que o aplicativo apresenta uma interface do usuário dentro de uma Activity e uma forma de executar uma atividade de plano secundário através de uma instância de Service, é chegado o momento em que o BroadcastReceiver precisa ser explorado. Importante frisar que o BroadcastReceiver consiste em uma forma alternativa de aplicativo Android direcionado ao processo de Intents.
// BroadcastReceiver 
É comum, no uso dos dispositivos móveis, que sejam realizadas chamadas telefônicas ou o recebimento e envio de mensagens. Caso o aplicativo deseje executar alguma destas ações, é preciso registrá-lo na forma de um BroadcastReceiver. Vale frisar que um aplicativo se registra com o objetivo de receber Intents e, para isto, utiliza qualquer um dos métodos a seguir: 
O aplicativo pode inserir um componente <receiver> dentro do arquivo AndroidManfest.xml. Este aplicativo descreve o nome inserido na classe BroadcastReceiver e descreve os seus IntentFilters. É importante que você se atente ao fato de que o IntentFilter apresenta o Intent ao qual o aplicativo deseja processar. Não há a necessidade de o aplicativo estar em execução para ocorrer a ativação, desde que o receptor esteja registrado no arquivo AndroidManifest.xml. Havendo um evento, automaticamente o aplicativo será iniciado durante a notificação do evento de ativação. 
A segunda possibilidade é o fato de um aplicativo ser registrado no momento da execução através do método RegisterReceiver presente na classe Context. 
O BroadcastReceiver tem aspectos similares aos Services: ambos não possuem interface do usuário. Outro aspecto, ainda mais relevante, se refere ao fato de o código ser executado utilizando o método onReceive de um BroadcastReceiver, o que significa que ele não deve realizar previsões sobre o tempo de duração das operações mais extensas. 
É preciso que você entenda que se o BroadcastReceiver necessitar de um valor maior para realizar a execução de código, é indicado que este código comece através de uma solicitação direcionada a um Service, que por sua vez atuará de maneira complementar em relação à função requisitada. Isto ocorre porque o elemento de um aplicativo Service é planejado e destinado ao uso em operações classificadas de longo prazo, diferente do que ocorre no BroadcastReceiver, que é realizado para se contrapor a diversos gatilhos. 
EXPLICANDO
A classe Intent tem a função de ativar o BroadcastReceiver. Existe uma distinção entre os parâmetros estabelecidos, considerando o fato de que o usuário pode estar começando uma Activity, um Service ou até mesmo um BroadcastReceiver. Porém, a mesma classe Intent é utilizada na plataforma Android, em toda a sua totalidade.
Vale mencionar que um BroadcastReceiver adota uma metodologia abstrata denominada de onReceive com o objetivo de processar os Intents recebidos. Podemos considerar que os argumentos pertencentes a este método são o Context e um Intent. O método retorna ao void, porém determinados mecanismos são favoráveis em apresentar resultados, como por exemplo o setResult, que devolve ao solicitante um código de retornocompleto, um valor de retorno classificado como String e um valor denominado de Bundle, que se caracteriza por dispor de uma quantidade qualquer de objetos. 
Vejamos uma listagem exemplificando como ocorre a ativação de um BroadcastReceiver após o recebimento de uma mensagem de texto:
package com.msi.manning.unlockingandroid;
import android.content.Context;
import android.content.Intent;
import android.util.Log;
import.android.content.BroadcastReceiver
public class MySMSMailBox extends BroadcastReceiver {
public static final String tag = "MySMSMailBox";
@Override
public void onReceive(Context context, Intent intent) {
 Log.i(tag,"onReceive"); 
 if (intent.getAction().equals
("android.provider.Telephony.SMS_RECEIVED")) { 
Log.i(tag,"Found our Event!"); 
 } 
}
Vamos debater sobre alguns elementos que compõem esta listagem. Podemos observar de imediato que a classe MySMSMailBox amplia a classe BroadcastReceiver, demonstrando que esta abordagem de subclasse é a maneira mais objetiva de utilizar um BroadcastReceiver, pois se você observar com atenção o nome da classe MySMSMailBox será empregado no arquivo AndroidManifest.xml. Outro aspecto importante se refere à variável tag, que é utilizada de maneira conjunta com o mecanismo de log, visando auxiliar na nomeação das mensagens remetidas ao console de log de um emulador. Vale mencionar que uma tag inserida no log possibilita um filtro, além de organizar as mensagens de log inseridas em um console. 
Outro ponto a ser discutido é referente ao método onReceive, no qual acontece todo o serviço executado em um BroadcastReceiver. É preciso que o usuário adote esse método, no qual um dado BroadcastReceiver consegue armazenar diversos IntentFilters. Importante expor que as instâncias de BroadcastReceiver podem ser desenvolvidas para uma quantidade arbitrária de Intents. E o que isso implica? Bem, é necessário assegurar que o aplicativo manipule o Intent adequado, observando a ação do Intent recebido. Isso indica que, na oportunidade em que o aplicativo recebe o Intent almejado, ele precisa dar segmento com a funcionalidade almejada.
Uma atividade corriqueira realizada em um aplicativo de SMS, por exemplo, é validar uma determinada mensagem e apresentá-la ao usuário através de recursos disponibilizados no NotificationManager. Na Figura 1, você pode observar que é necessário apenas que você registre a ação no log, ou seja, o BroadcastReceiver só dispara e recebe esse Intent quando estiver inserido na lista do arquivo AndroidManifest.xml acompanhado de uma tag IntentFilter adequada.
Figura 1. AndroidManifest.xml. Fonte: ABLESON; KING; SEN; ORTIZ, 2012. (Adaptado).
Você pode observar que a listagem da Figura 1 apresenta componentes essenciais para o aplicativo responder a uma mensagem adquirida. Determinadas atividades realizadas na plataforma Android solicitam que o aplicativo apresente uma vantagem estabelecida. Um aplicativo necessita de permissões essenciais que podem ser obtidas através da tag <uses – permission>. Você deve notar que uma tag apresenta o nome da classe que aplica o BroadcastReceiver. 
Um questionamento pode ser feito: e se o aplicativo não se comportar da maneira esperada, o que deve ser realizado? Caso isto ocorra, é preciso, de imediato, verificar o seu arquivo Android.xml e buscar o ponto anterior ao nome da classe. Vale lembrar que o IntentFilter é determinado na tag e que o Android SDK dispõe de ações direcionadas para os Intents padronizados. Se atente também que os aplicativos de usuário podem estabelecer os seus próprios Intents e realizar a sua própria busca. 
Bem, como você já observou, nós já debatemos sobre os Intents e as classes Android que têm como função processá-los e manipulá-los. Diante deste cenário, é possível debater sobre um ponto importante referente ao aplicativo Android: o ContentProvider. 
// ContentProvider 
Uma das inúmeras funcionalidades de um aplicativo está relacionada a sua capacidade de gerenciar dados. Nesta condição, se um aplicativo necessitar apresentar esses dados a outros diferentes aplicativos, em que a sua execução ocorre dentro de um ambiente Android, é preciso levar em consideração o uso do ContentProvider. Caso um elemento componente de aplicativo necessite utilizar dados provenientes de outros aplicativos, basta acessar o ContentProvider pertencente ao outro aplicativo. O ContentProvider insere uma série padronizada de métodos, possibilitando a um aplicativo o acesso a um arquivo de dados, no qual este acesso precisa ser direcionado às operações ligadas a leitura, escrita ou ambas situações. 
É relevante mencionar que um ContentProvider pode disponibilizar dados, por exemplo, para uma Activity ou Service em duas situações básicas: dentro de um mesmo aplicativo ou em aplicativos distintos. Ele pode empregar qualquer tipo de método referente ao arquivamento de dados acessível dentro de uma plataforma Android. 
Podemos considerar também que o ContentProvider consiste em uma categoria de dados que disponibiliza uma abstração destes dados aos seus clientes e concentra as rotinas de arquivamento e recuperação em apenas um local.
E como ocorre o arquivamento dos dados inseridos em um ContentProvider? 
Estes dados disponibilizados em um ContentProvider podem ser considerados como modelos tradicionais. Caso um nome de arquivo retorne como uma etapa de consulta ContentProvider, consequentemente o aplicativo não acessará o arquivo de forma direta, ou seja, o usuário deverá utilizar a classe acessória denominada de ContentResolver, que consiste em um método openInputStream, utilizado no acesso aos dados binários. 
Você perceberá que os dados de um ContentProvider são visualizados através de um aplicativo Android através de um URI Content. Isto acontece quando um ContentProvider estabelece esse URI como uma String pública estática final. O Diagrama 2 demonstra a relação existente entre ContentProviders, arquivos de dados e clientes. 
Diagrama 2. ContentProvider. Fonte: ABLESON; KING; SEN; ORTIZ, 2012. (Adaptado).
Com isso, podemos compreender sobre as principais classes de aplicativos Android e como elas são executadas em conjunto, o que consiste em uma atividade extremamente complexa. É importante debater sobre o arquivo Android (AndroidManifest.xml), que relaciona todas as etapas essenciais para realizar um aplicativo Android dentro de um dispositivo.
VAMOS REFORÇAR O QUE APRENDEMOS ATÉ AGORA?
Para que um aplicativo para dispositivos móveis execute ações como receber chamadas telefônicas ou mensagens, é preciso registrá-lo de que forma?
· BroadcastReceiver.
ENVIAR
Correto
👍
Muito bem, a resposta está correta! 
É comum, no uso dos dispositivos móveis, que sejam realizadas chamadas telefônicas ou o recebimento de mensagens. Caso o aplicativo deseje receber ou enviar alguma destas ações, é preciso registrá-lo na forma de um BroadcastReceiver.
Componentes de interface gráfica
Este uso facilitado é perceptível quando um usuário desenvolve algumas UIs, porém existe um limite que restringe manipulações nos elementos da interface do usuário característicos do Android. 
Agora, visualizaremos como desenvolver gráficos através de uma API Graphics do Android, meios de como criar animações e observar o suporte oferecido pelo Android no modelo OpenGL. 
ELEMENTOS GRÁFICOS E ANIMAÇÕES COM A API GRAPHICS DO ANDROID
Para demonstrar as habilidades gráficas do Android, é necessário inserir um pacote android.graphics, que disponibiliza todas as classes de nível mais baixo necessárias para que o usuário desenvolva elementos gráficos. Vale frisar que o pacote gráfico lida com elementos como bitmaps e telas, por exemplo. De fato, não são os únicos pacotes gráficos disponíveis, porém são os elementos utilizados na maior parte dos aplicativos. Geralmente, o usuário utiliza o Java para atrair a API Graphics com o objetivo de desenvolver elementos gráficos com maior nível de complexidade. 
É possível observar o desenho básico, utilizando o Java e a API Graphics através de uma listagem na qual é possível criar um retângulo.
packagecom.msi.manning.chapter9.SimpleShape;
public class SimpleShape extends Activity {
@Override
protected void onCreate(Bundle icicle) {
super.onCreate(icicle);
setContentView(new SimpleView(this));
}
private static class SimpleView extends View {
 private ShapeDrawable mDrawable =
 new ShapeDrawable();
public SimpleView(Context context) {
 super(context);
 setFocusable(true);
 this.mDrawable =
 new ShapeDrawable(new RectShape());
this.mDrawable.getPaint().setColor(0xFFFF0000);
 } 
@Override
protected void onDraw(Canvas canvas) {
int x = 10;
 int y = 10;
 int width = 300;
 int height = 50;
 this.mDrawable.setBounds(x, y, x + width, y + height);
 this.mDrawable.draw(canvas);
 y += height + 5;
 }
 } 
 }
Você deve compreender que é necessário, primeiramente, importar os pacotes essenciais, dos quais se incluem os gráficos. Ao importar o ShapeDrawable, será possível acrescentar formas ao desenho criado. Posteriormente, é preciso desenvolver e configurar uma view, além de criar um novo ShapeDrawable com o objetivo de acrescentar o nosso Drawable. Você pode se questionar: o que fazer depois da criação de um ShapeDrawable? Bem, é possível estabelecer formas a ele, a começar pelo código, onde utilizamos, por exemplo, o RectShape. Em seguida, é possível empregar o método onDraw(), utilizado para criar o Drawable no Canvas. Ao final, podemos empregar o método setBounds() para estabelecer o limite no qual o usuário irá desenhar o retângulo, utilizando o método denominado de draw(). É importante mencionar que uma forma alternativa de realizar este mesmo procedimento é através do XML, no qual o Android possibilita ao usuário a definição de formas para delinear em um arquivo de atributos XML.
// Desenhando com XML 
Você notará que, com o Android, é possível desenvolver projetos mais simples, utilizando uma abordagem de arquivo XML. Mas por que utilizar o XML? 
Um dos motivos está na simplicidade de fazer. Outro motivo está ligado aos elementos gráficos apresentados por XML, que podem ser alterados depois através da programação. Sendo assim, o XML consegue disponibilizar uma forma mais simples de realizar o projeto definido inicialmente. O desenvolvimento do desenho com XML depende da criação de um ou mais objetos Drawable, onde eles são estabelecidos como arquivos XML dentro do seu diretório. O XML desenvolve um retângulo simples seguindo a listagem que pode ser observada a seguir: 
<?xml version=”1.0” encoding=”utf–8”?>
<shape xmlns:android=”http://schemas.android.com/apk/res/android” >
 <solid android:color=”#FF0000FF” />
</ shape>
Você pode observar que, ao utilizar as drawables XML do Android, o padrão estabelecido é um retângulo, porém é possível selecionar uma maneira distinta utilizando a tag type e escolhendo, por exemplo, o valor oval, rectangle, line ou arc. Para que a forma XML seja utilizada, é necessário fazer referência a ela dentro de um layout. Isto é possível através da listagem visualizada na Figura 2.
Figura 2. XmlLayout.xml. Fonte: ABLESON; KING; SEN; ORTIZ, 2012, p. 250.
É necessário desenvolver uma Activity simples e inserir uma interface do usuário dentro de um ContentView:
public class XMLDraw extends Activity {
@Override
public void onCreate(Bundle icicle) { 
 super.onCreate(icicle);
 setContentView(R.layout.xmldrawable);
 } 
 }
É importante que você saiba que, ao executar esse código, é possível projetar um retângulo simples. Entretanto, o usuário também consegue inserir desenhos mais complexos ao empilhar ou ordenar drawables XML, além de inserir maneiras que desejar, de acordo com o espaço.
// Explorando maneiras XML drawable
Uma possibilidade de desenhar diversas formas com XML é desenvolver diversos arquivos com a mesma extensão XML. É possível fazer isso ao modificar o arquivo xmldrawable.xml com o intuito de transformá-lo para que que fique de acordo com a listagem da Figura 3, que acrescenta uma série de maneiras e as organiza verticalmente.
Figura 3. xmldrawable.xml. Fonte: ABLESON; KING; SEN; ORTIZ, 2012, p. 232.
No código da Figura 4, é possível observar a criação de um retângulo com as bordas arredondadas. Foi acrescentada uma tag denominada padding, ao qual é possível determinar, dentre outros aspectos, o espaço existente entre os objetos na interface do usuário.
Figura 4. Listagem com a tag padding. Fonte: ABLESON; KING; SEN; ORTIZ, 2012.
É possível utilizar também a tag stroke, que possibilita estabelecer o estilo da linha que forma a borda do oval, como mostrado na Figura 5.
Figura 5. Listagem com a tag stroke. Fonte: ABLESON; KING; SEN; ORTIZ, 2012.
É importante mencionar que o fragmento de código exposto no código da Figura 6 apresenta uma introdução da tag corners, que possibilita o desenvolvimento de cantos arredondados através do android:radius.
Figura 6. Código com a tag corners. Fonte: ABLESON; KING; SEN; ORTIZ, 2012.
Ao final, é possível desenvolver uma maneira do tipo line, através de uma tag denominada size e utilizando o atributo android:height. Isto possibilita descrever a quantidade de pixels utilizados na vertical para o tamanho da linha, conforme a Figura 7.
Figura 7. Uso da tag size e do atributo android:height. Fonte: ABLESON; KING; SEN; ORTIZ, 2012.
Como você deve ter observado, o Android possibilita aos desenvolvedores a criação programática do que eles necessitam e o que pode ser desenhado, utilizando os recursos de animação do Android.
// Criando animações com a API Graphics do Android 
O Android se caracteriza por suportar diversos métodos para desenvolver uma animação. Normalmente, isto ocorre por meio de XML, através das animações quadro a quadro XML do Android, utilizando a API Graphics ou por meio do suporte do Android para OpenGL ES. A aplicação Android possibilita o desenvolvimento de animações mais simplificadas, demonstrando uma série de imagens dispostas sequencialmente dando a impressão de movimento. Ele determina cada quadro da imagem como um recurso drawable, no qual as imagens são apresentadas por meio de uma view. Ao utilizar esse recurso, é possível estabelecer uma série de atributos dentro de um arquivo XML denominado de AnimationDrawable.start(). 
Para visualizar o método utilizado para desenvolver uma animação, é necessário que o usuário realize o download deste projeto no site da Manning (www.manning.com/ableson3). Posteriormente, é necessário desenvolver um projeto denominado de XMLanimation. Após criar um diretório e disponibilizar as imagens, é preciso gerar um arquivo XML (Simple_animation.xml), que apresenta o código, conforme se visualiza na listagem da Figura 8.
Figura 8. Simple_animation.xml.
O passo seguinte é editar o arquivo main.xml para que o mesmo se torne similar com a listagem observada na Figura 9.
Figura 9. Resultado da edição do arquivo main.xml.
Você pode notar que foi acrescida uma tag ImageView ao arquivo, utilizada na configuração do layout do ImageView. Ao final, é possível desenvolver o código para realizar a animação. Portanto, é possível concluir que desenvolver uma Animation, utilizando uma XML no Android, não inclui grandes dificuldades. É claro que é possível realizar animações mais difíceis, porém para que isto ocorra é necessário gerar, de maneira programática, as animações com nível maior de sofisticação, utilizando habilidades gráficas na versão 2D e 3D do Android.
EXPLICANDO
Ao criar animações com a API Graphics do Android, o usuário animará o globo de forma programática, fazendo com que a tela se mova. Posteriormente, será desenvolvido um thread no qual a animação será realizada, além de um Handler utilizado para auxiliar no retorno direcionado ao programa que indicam alterações no nível da animação. 
// Desenvolvendo o projeto 
Um método de animação se caracteriza por usar, por exemplo, uma imagem ligada a um sprite. Mas o que seria um sprite? Este termo se refere a uma imagem em nível bidimensional, ou até mesmo uma animação, que se encontra sobreposta de duas maneiras: ou diretamentea um fundo ou em uma apresentação gráfica com maior grau de dificuldade. 
Imagine, por exemplo, a criação de uma animação que apresenta uma bola quicando: nesta condição, é preciso movimentar o sprite na tela. De início, é necessário o desenvolvimento de um novo projeto, ao qual podemos nomear de BouncingBall junto com um BounceActivity. Neste contexto, é possível copiar e colar o código dentro da listagem necessária para o desenvolvimento. 
// Fazendo a animação acontecer 
Com a listagem pronta, é possível observar que todo o serviço relacionado à animação da imagem foi realizado. De imediato foi desenvolvido um drawable, com o objetivo de acolher a imagem originada do globo, além de um Point utilizado para posicionar e monitorar o globo de acordo com a aplicação da animação. Posteriormente, geram-se enumerações, visando o arquivamento de valores destinados às direções horizontal e vertical, o mapeamento do globo direcionado à variável mySprite e, por fim, a configuração do logotipo Android na condição de fundo da animação. 
Ao finalizar a primeira etapa do trabalho de configuração, é preciso desenvolver uma nova View, além de configurar os limites direcionados para o Drawable. Após esta configuração é necessário desenvolver uma lógica condicional simples cujo objetivo é verificar se o globo sairá da tela: caso isso ocorra é necessário alterar o seu direcionamento. Ao final, é preciso delinear o globo utilizando o método draw().
Mesmo não sendo uma animação das mais instigantes, o interessante aqui é que o usuário consiga empregar os conceitos importantes como o estabelecimento de limites e a movimentação de drawables, dentre outros aspectos. Caso o usuário deseje alcançar uma maior capacidade gráfica, é necessário o uso do OpenGL.
APRESENTAÇÃO DA OPENGL E RENDERSCRIPT DO ANDROID
Um dos aspectos mais importantes referentes à plataforma Android está relacionada ao seu suporte direcionado à OpenGL for Embedded Systems (OpenGL ES). Mas o que significa isto? Bem, a OpenGL ES é a modalidade direcionada aos sistemas embarcados que estabelece uma API com características de diversas plataformas e linguagens, direcionadas para os componentes gráficos de um computador. Vale citar que uma API OpenGL ES não disponibiliza auxílio à API OpenGL de forma completa.
E o que isto indica? Que uma importante parcela pertencente à API OpenGL foi removida para possibilitar que o OpenGL ES seja realizado em uma diversidade de dispositivos, como por exemplo os telefones celulares, PDAs e alguns sistemas embarcados. 
Mas como surgiu a OpenGL ES? Esta versão foi genuinamente criada pela Khronos Group e representa uma API espetacular para componentes gráficos nas versões 2D e 3D, principalmente no que se refere a aplicativos graficamente intensivos. Já que o Android consegue suportar a aceleração de um hardware 3D, os responsáveis pela criação podem desenvolver aplicativos graficamente intensivos destinados aos hardwares que apresentam aceleradores com a mesma tecnologia.  
Apesar do Android normalmente suportar o padrão estabelecido pela OpenGL ES, o usuário precisa levar em consideração as características essenciais do hardware e do seu aparelho. Portanto, antes de iniciar um projeto com OpenGL o usuário deve levar em consideração o hardware objetivado e realizar testes intensos para evitar a sobrecarga do seu hardware com componentes gráficos OpenGL. 
// Criando um contexto OpenGL 
Os conceitos essenciais do OpenGL ES são utilizados para o desenvolvimento de um OpenGLContext e uma Window direcionados para a criação de desenhos. Aparentemente, esta atividade é mais complexa em relação à API gráfica do Android, entretanto a configuração é realizada de uma só vez. 
Para executar o OpenGL ES dentro de um Android, é preciso que um usuário realize os procedimentos mais generalistas, como por exemplo:
· Criar uma subclasse view personalizada;
· Adquirir um handle direcionado a um OpenGLContext, que possibilita, dentre outros aspectos, o acesso à funcionalidade OpenGL ES dentro do Android;
· Usar o identificador direcionado ao objeto GL e posteriormente utilizar os seus métodos para realizar diversas funções GL, dentro do método onDraw() da view.
Adotando estes procedimentos básicos, o usuário desenvolverá uma classe que utiliza o Android, gerando uma superfície em branco destinada para o desenho. 
É necessário utilizar comandos OpenGL ES para desenhar algo na superfície. De início, é necessário abrir um novo projeto denominado de OpenGLSquare e desenvolver uma Activity com o mesmo nome e inseri-los em uma listagem. Esta listagem gera uma tela preta vazia e lá podemos observar o código necessário para gerir e desenhar qualquer visualização do tipo OpenGL ES. 
// Apresentando o RenderScript do Android 
O RenderScript é definido como uma nova API no Android com o objetivo de auxiliar os responsáveis pelo desenvolvimento que necessitam de uma performance elevada direcionada para operações gráficas com o uso computacional intensivo. É preciso entender que esta API já se encontra presente em versões anteriores do Android, apesar de não estarem disponíveis de maneira pública. Somente a partir do Android 3 o RenderScript passou a ser considerado como um mecanismo importante para o uso em jogos e aplicativos graficamente intensivos. 
O RenderScript estabeleceu um novo padrão à plataforma Android, pois tem como referência o C99, que é considerado como um dialeto moderno da linguagem C. Outro aspecto se deve ao fato do RenderScript ser compilado para o código nativo presente em cada dispositivo no período de execução, porém é controlado por APIs de nível elevado executando em uma VM do Android.
Esta API apresenta um conjunto de vantagens e desvantagens. Podemos considerar que a primeira vantagem de usar o RenderScript se deve ao fato de ele utilizar uma linguagem de nível menor, disponibilizando uma performance mais elevada. Além disso, ele possibilita que os aplicativos Android utilizem, por exemplo, CPUs multiprocessadas com mais facilidade e escolhe, por projeto – no momento de execução –, a abordagem de melhor performance para realizar o seu código. 
Além disso, o RenderScript apresenta uma performance espetacular e um nível de compatibilidade com multiplataforma, sem a obrigação de indicar dispositivos específicos ou de desenvolver suas próprias arquiteturas para ser compatível com a multiplataforma. 
Em relação às desvantagens, podemos citar que a mais relevante se refere ao fato do RenderScript utilizar o C99, pois ele altera o padrão do estilo Java que faz parte da maioria dos desenvolvedores Android. Outra desvantagem se deve ao fato dos aplicativos RenderScript apresentarem um alto nível de complexidade de desenvolvimento em relação aos aplicativos Android habituais. 
A maioria dos aplicativos RenderScript não pode ser executada no emulador e isso determina a realização de uma depuração em um hardware. A presença de muito mais bugs é mais uma desvantagem, pois o RenderScript se encontra em linguagem C e o aplicativo Android Development Tools (ADT), atualizado para o Eclipse, não suporta as diversas extensões. 
Você pode ter certo receio em desenvolver o RenderScript, porém é preciso desenvolvê-lo sem exageros se comparados com as APIs Android e uma sintaxe Java padrão. É preciso utilizar o RenderScript em aplicativos caracterizados por serem graficamente, ou computacionalmente, intensivos. 
De fato, criar um aplicativo RenderScript é mais complexo em relação a um aplicativo Android normal, pois é preciso planejar o seu aplicativo de maneira similar. Porém, é necessário lembrar que, ao desenvolver os arquivos RenderScript, estarão inseridas as extensões de arquivo .rs em paralelo aos arquivos .java.
Para criar o seu aplicativo RenderScript, é preciso utilizar o assistente de projeto Android nativo da ADT e desenvolver um projeto RenderScript. De imediato, é necessário criar um novo projeto, utilizando a ADT e selecionar "Create project from existing sample", conforme se observa na Figura 10.
Figura 10. xmldrawable.xml. Fonte:ABLESON; KING; SEN; ORTIZ, 2012, p. 232. (Adaptado).
VAMOS REFORÇAR O QUE APRENDEMOS ATÉ AGORA?
Quais procedimentos são necessários para executar o OpenGL ES dentro de um Android?
· Adquirir um handle direcionado a um OpenGLContext, que possibilita, dentre outros aspectos, o acesso à funcionalidade OpenGL ES dentro do Android. 
· Criar uma subclasse view personalizada. 
ENVIAR
Correto
👍
Muito bem, a resposta está correta! 
Adotando estes procedimentos básicos o usuário desenvolverá uma classe que utiliza o Android, gerando uma superfície em branco destinada para o desenho.
Gerenciadores de layout
O Android é composto por diversos layouts e, para que exista uma compreensão mais detalhada sobre eles, é preciso entender de que maneira os elementos gráficos se comportam e a sua origem. 
De fato, os componentes gráficos são derivados de subclasses das classes definidas como view e ViewGroup, pois servem de referência para o desenvolvimento dos layouts.
É importante mencionar que toda a interface apresenta uma série de características ligadas ao fato de:
· Ser desenvolvida empregando objetos do tipo view ou ViewGroup;
· No momento de compilação, cada componente presente no arquivo XML ser reunido dentro da sua classe Android correspondente;
· Os requisitos presentes no XML serem simbolizados como métodos;
· Estarem dispostos dentro de uma área retangular inserida na tela.
Uma view consiste em um retângulo de exibição do usuário, ou seja, uma instância de classe android.view, em que é possível gerenciar todos os elementos e interações. É uma classe que serve de referência para todos os componentes visuais inseridos em um Android, também conhecidos como widgets.
Uma ViewGroup pode ser definida como uma classe que dispõe de diversos componentes menores, denominados simbolicamente de “filhos”. Ele simboliza os controles ou gerenciadores de layout, que se caracterizam por estabelecer a forma e a localização onde os componentes serão implantados na tela.
Qualquer elemento view ou ViewGroup pode ser inserido em outras classes view ou ViewGroup, ou seja, uma dentro da outra, acrescidas de elementos visuais desenvolvidos partindo das Views, conforme se observa no Diagrama 3.
Diagrama 3. Hierarquia de classes. Fonte. LECHETA, 2018. (Adaptado).
Você pode observar que aba view ou ViewGroup apresenta uma série de propriedades, as quais estão presentes em basicamente todas as views e ViewGroups. Vejamos alguns exemplos:
· android:layout_width="" - informa o comprimento da View ou do ViewGroup;
· android:layout_height="" - determina a altura;
· android:layout_gravity="" - informa de que maneira as views menores (filhas) serão posicionadas;
· android:layout_weight="" - objetiva atribuir peso ao componente. Ele é exclusivo para as views linearlayout ou tablelayout.
A seguir, veremos alguns requisitos para estabelecer as margens (margin) que os componentes terão.
· android:layout_margin="" - determina a margem para os quatro lados;
· android:layout_marginLeft="" - indica as dimensões da margem esquerda;
· android:layout_marginTop="" - indica as dimensões da margem superior;
· android:layout_marginRight="" - indica as dimensões da margem direita;
· android:layout_marginBottom="" - indica as dimensões da margem inferior.
Vale frisar que, além desses requisitos, é possível usar atributos relacionados ao alinhamento (align) de acordo com alguns comandos, como por exemplo o Android:layout_marginBottom="", que indica o tamanho da margem inferior. 
PRINCIPAIS MODELOS DE LAYOUT
Você notará que os principais layouts presentes em um Android são classificados de:
· Linear layout (horizontal ou vertical);
· Relative layout;
· Frame layout;
· Table layout ou frame layout;
· Grid layout.
Em determinadas situações, usaremos alguns layouts desenvolvidos pelo Android ou nos encontraremos em uma situação em que o usuário será o responsável pela criação dos próprios layouts, que podem apresentar um perfil simples ou com alto nível de complexidade. 
Porém, é possível fazer um questionamento: o que de fato é importante quando o assunto é o layout?
Primeiramente, é necessário entender que os layouts são configurados por meio da linguagem XML. Cada layout apresenta uma variedade de requisitos dos quais é possível executar configurações de maneira similar com a linguagem CSS. Outro aspecto a ser observado é que qualquer arquivo XML presente em uma interface do Android precisa de um layout raiz, entretanto não há impedimentos para que se agregue certa quantidade de layouts neste layout raiz. Dentro de um Android, todo layout apresenta basicamente dois requisitos básicos: o width e o height. Mas, é importante observar que aninhar layouts em outros layouts e implementar widgets requer um certo nível de organização. 
Fazendo uma analogia ao conceito de família, todo layout obedece a seu pai. Isso indica que layouts e widgets inseridos em outros layouts precisam se limitar ao tamanho do layout acolhedor (pai), visando aderir ao seu conteúdo.
Os requisitos básicos que ajudam nestas configurações e implementações podem ser definidos como:
· O atributo MATCH_PARENT, que é responsável por informar que o componente usará toda altura ou largura pertencente ao layout pai;
· O atributo WRAP_CONTENT, que é responsável por informar que o componente usará apenas o tamanho necessário para receber seu conteúdo.
Outro aspecto que você, caro leitor, deve compreender se refere aos layouts desenvolvidos em xml. Eles são informados dentro das classes Java através do método setContentView, porém vale lembrar que isso só é possível por meio da classe R. Ela tem a função de fazer a transição entre o xml e o java. A listagem a seguir apresenta como o método setContentView pode ser apresentado:
public class ExemploJNI extendes Activity {
 @Override
 public void onCreat (Bundle savedInstanceState) {
 super.onCreat( savedInstanceState) ;
 String msg = getMensagem() ;
 TextView tv = new TextView( this ) ;
 tv.setText(msg) ;
 setContentView(tv) ; 
}
/ /Método native implementado em C 
Public native String getMensagem() ;
No que se refere ao Relative Layout, vale frisar que este layout é bastante utilizado, pois é possível dispor dos widgets por meio das relações estabelecidas entre si. Isto ocorre quando utilizamos requisitos que determinam que a localização do botão "calcular" ficará abaixo da EditText, que consequentemente receberá um botão determinado ao lado esquerdo do botão denominado de "limpar". Ele possibilita às views denominadas (filhas) de especificar a sua posição em relação à view principal (pai). 
É possível alinhar os dois elementos das mais variadas maneiras: por borda direita, um abaixo de outro, centralizado na tela ou à esquerda, dentre outras opções. 
Ao usar o Relative Layout, é necessário alterar o "id" do componente no instante da aplicação do mesmo. Caso a modificação ocorra após ter sido criado todo o layout da Activity, o “id” será desfeito. 
É importante frisar que neste layout os elementos são ordenados por meio de uma relação estabelecida entre eles. Quando um componente é renomeado, os outros acabam se dissipando. No instante em que estes elementos estabelecem uma relação entre si, outros requisitos acabam sendo utilizados de acordo com os códigos que adotam. O Quadro 2 apresenta algumas propriedades adotadas para alinhamento.
Quadro 2.. Propriedades para alinhamento. Fonte: DARWIN, 2012, p. 283.
Quanto ao Linear Layout, podemos defini-lo como um dos mais simples de usar graças à condição dele adotar as orientações vertical ou horizontal. Ao desenvolver um Linear Layout, o padrão de orientação adotado é o vertical, um sobre o outro. É preciso alinhar todos os views filhos seguindo uma direção, seja vertical ou horizontal, a depender de como se define o requisito de orientação. 
Se utilizarmos, por exemplo, o atributo layout_orientation na posição vertical, isso implica afirmar que todos os componentes serão alinhados verticalmente um sobre o outro. Contrariamente,o layout_orientation inserido na posição horizontal gerará componentes alinhados um ao lado do outro. 
É possível criar um arquivo layout XML utilizando um Relative Layout raiz. Imagine, por exemplo, que dentro desse Relative Layout raiz sejam aplicados um Linear Layout horizontal e um vertical. Sequencialmente, dentro destes dois Linear Layouts, são inseridos dois botões para verificar a sua disposição. Diante desta situação, é possível compreender como são inseridos os layouts com maior nível de complexidade dentro do Android.
Outro gerenciador, o Frame Layout, disponibiliza todos os elementos em forma de pilha, levando em consideração que o último elemento inserido se encontra no topo da pilha. O Frame Layout sobrepõe todos os componentes, no qual só é possível visualizar o último componente de widgets acrescentado na tela. 
Em um primeiro momento, você pode achar que este é um layout sem grande utilidade, porém é de extrema importância para realizar o processo transitório das imagens para os jogos, por exemplo. Vale frisar que o Frame Layout é planejado basicamente para apresentar um componente por vez ou para impedir uma área na tela para apresentar um único item.
Dentro de um Frame Layout pode haver diversos componentes, entretanto estes componentes podem se sobrepor às views filhas subsequentes, que são projetadas sobre as views anteriores, de maneira parcial ou total. Podemos considerá-la como um dos modelos mais simples de layout, no qual todos os componentes denominados de “filhos” são estabelecidos na área superior esquerda presente na tela. Ao transferir o elemento para o Frame Layout, é possível sugerir a propriedade Gravity, onde o mesmo ficará localizado.
A Table Layout é um layout caracterizado pela relevância e o uso intensificado. Ele alinha os widgets por meio de linhas e colunas, onde cada linha inserida consiste em uma TableRow. Este layout atua seguindo alguns aspectos, como:
· O posicionamento de Views filhas dentro de linhas e colunas;
· A formação através de objetos TableRow que estabelecem as linhas na tabela;
· O fato de que cada linha pode apresentar variadas células definidas por qualquer outro modelo de view;
· A possibilidade de as colunas serem destacadas para cobrir o espaço apresentado na tela;
· A chance de cada TableRow apresentar mais de um componente sendo que cada um será disposto de maneira a se assemelhar a uma coluna;
· O fato das colunas na TableRow serem realizadas por meio dos próprios componentes;
· A ideia de juntar colunas ou linhas não possui aplicação prática dentro do contexto de layout inserido com o table.
A Scrollview é definida como um modelo diferenciado especial de Frame Layout, que possibilita ao usuário analisar uma lista de views que utilizam um espaço maior que o limite no display físico. Ele disponibiliza de maneira automática na rolagem para visualização de dado, onde o ScrollView pode apresentar somente uma view.
VAMOS REFORÇAR O QUE APRENDEMOS ATÉ AGORA?
De acordo com o estudado no tópico "Gerenciadores de layout", relacione cada termo com sua definição.
· Views
· GroupViews
· Relative Layout
· Um retângulo de exibição do usuário, ou seja, uma instância de classe android.view.
· Uma classe que dispõe de diversos componentes menores, denominados “filhos”.
· Layout que dispõe de widgets por meio das relações atribuídas entre si.
ENVIAR
Correto
👍
Muito bem, a resposta está correta! 
De acordo com o estudado no tópico Gerenciadores de layout, relacione cada termo com sua definição, uma view consiste em um retângulo de exibição do usuário, ou seja, uma instância de classe android.view, em que é possível gerenciar todos os elementos e interações. Uma ViewGroup é definida como uma classe que dispõe de diversos componentes menores, denominados simbolicamente de “filhos”. E o Relative Layout é um layout muito utilizado por conta da sua grande disponibilidade de views.
TENTE NOVAMENTE
Agora é a hora de sintetizar tudo o que aprendemos nessa unidade. Vamos lá?!
SINTETIZANDO
Verificamos que os componentes de aplicativo são extremamente importantes no desenvolvimento um aplicativo Android, no qual os componentes são meios de sistema em que alguns componentes dependem de outros. Neste contexto visualizamos a presença do Intent, que é um comando que indica o que deve ser executado.
Observamos também que desenvolver aplicativos Android é mais fácil em relação à utilização das plataformas de aplicativos móveis, graças às UIs, que limitam manipulações nos componentes da interface do usuário Android. As habilidades gráficas do Android utilizam um pacote android.graphics, que apresenta classes necessárias para o desenvolvimento de elementos gráficos. 
O Android é formado por vários layouts e, para que exista uma compreensão mais precisa, é necessário compreender de que forma os elementos gráficos se comportam. Os componentes gráficos são derivados de subclasses das classes conhecidas como view e ViewGroup.